夜雨聆风
ReAct 讲的不是“让模型多想一点”，而是让模型在复杂任务里形成一个循环：先判断缺什么，再行动，再看结果，再调整。
你可能也遇到过这种情况。
你把一个任务丢给大模型，它很快给出一段结构完整、语气笃定的分析。
但你追问一句：
“那你查过了吗？”
问题就出来了。
查一家公司最近的融资情况，读一份文档到底写了什么，排查一个代码报错，找出流程卡住的那一步，这些任务看起来都可以让模型先分析。
但如果它不能真的去查、去看、去试、去验证，那很多时候，它给你的只是一个合理的猜测。
这就是 ReAct 要解决的问题。
复杂任务里，模型不能只靠脑内推理。它要能意识到自己缺什么信息，然后去读取外部信息，必要时调用外部系统。
这里的“行动”不神秘。搜索网页、读取文档、查询数据库、查看日志，是行动；提交表单、更新状态、调用审批流，也是一种行动。
ReAct 最早主要讨论前一种：模型发现自己缺信息，就决定下一步去哪里查。一旦进入企业场景，后一种也会出现。问题会变成：谁允许它调用，调用后怎么验证，出错后怎么回滚。
所以这篇文章只回答一个问题：
为什么 Agent 的核心是能形成“想、做、看反馈、再调整”的闭环?
ReAct 改掉了什么？
Chain-of-Thought 让模型把中间推理写出来。
这是进步，但还不够。
因为有些任务不是“继续想”就能完成的。
比如判断一家公司值不值得跟进，模型可以写出一套完整分析。但融资、产品、团队、竞品这些事实，不是靠继续推理得出来的。
它必须去查。
所以 ReAct 改掉的是“一口气答完”的直线结构：
输入问题 生成推理 输出答案它把任务改成一个循环：
想：我现在缺什么？ 做：我该调用什么工具？ 看反馈：结果说明什么？ 再调整：下一步要不要改？这里关键的，不是模型能不能调工具。
工具返回的结果，不是任务终点，而是下一轮推理的输入。
所以 ReAct 的重点不是“推理更长”，而是“推理可以被反馈改写”。
为什么这就是 Agent 的核心？
因为 Agent 不是回答器，而是任务推进器。
回答器只需要生成一段文本。任务推进器要面对不完整的信息、工具返回的不确定结果，以及随时可能改变的下一步。
没有闭环，调工具只是外挂功能。
有了闭环，模型才开始像一个能工作的系统组件：先判断，去行动，看结果，再修正。
但模型一旦能行动，风险也会跟着出现。它可能调错工具，读到脏数据，陷入循环，或者做出不可回滚的操作。
所以 Agent 不只要看“答得好不好”，还要看“动得可不可控”。
企业里最该关注什么？
企业做 Agent，不要只盯着“能不能接工具”。
接工具只是入口。更重要的是：这个 Agent 有没有动作闭环。
它什么时候该调哪个工具？工具结果回来后怎么判断是否可信？哪一步要人工确认？哪些动作必须可回滚？
这些问题，比“能不能调用 API”更接近企业落地的核心。
如果任务真的要推进流程，Agent 就不能只回答问题，还要进入系统：查 CRM、读合同、调审批流、看日志、更新状态、触发下游系统。
这时企业要补的是控制平面。
控制平面说白了就是：
规定 AI 什么时候可以动、能动到哪里、哪一步要人确认、出错后怎么撤回。
这也是 ReAct 落到企业里的关键提醒：
AI 怎么动手，动完以后谁来兜底。
最后
如果只用一句话记住 ReAct，我会记住这个转向：
模型不再只是一步步把题想出来，而是开始一边想，一边和外部信息、外部系统交互。
到这里，模型才开始有机会进入工作流，而不是停留在聊天框里。
下一篇最自然的承接，是 RAG。
ReAct 讲的是：模型什么时候该去行动。
RAG 要回答的是：模型行动之前，应该把哪些外部知识带进上下文。
也欢迎在评论区聊聊：你现在最想让 AI 帮你完成哪类真实任务？
参考：Yao 等，《ReAct：协同语言模型中的推理与行动》，2022。
