如果把 AI Agent 想象成一位新入职的同事，那么 ReAct 模式解决的其实是一个非常朴素的协作问题。

这位同事口才出众、推理能力也很强。你向它提出一个问题，它能沿着线索分析很长时间，语气还显得十拿九稳。但问题在于，许多实际任务不能仅依赖“思考”来完成。

有些时候，它凭借一连串猜测确实能碰对答案，但这更像是“乱枪打鸟”，缺乏稳定性、可复用性和可交付性。

当你询问今天某个仓库的最新发布版本时，它需要去主动查询。

当你要求它总结一篇学术论文时，它至少需要先读到论文的原文。

只会深入思考，容易在内部逻辑中原地打转。

只会机械行动，又容易像无头苍蝇般四处碰壁。

ReAct 的精妙之处在于，它将“思考”与“行动”融合在同一个节奏中：先进行推理并决定下一步行动；行动完成后观察回馈；再依据新的观察结果继续推理决策。

这个概念听起来并不复杂。

而这恰恰是它最值得深入学习的核心价值。

先用一句话说清楚 ReAct

ReAct 是 Reasoning 和 Acting 的组合缩写，可以通俗地理解为“推理与行动协同”。

在大语言模型领域，它代表的是一种让模型交替进行推理和执行动作的工作模式：模型首先依据当前问题判断下一步应该做什么，接着调用一个工具或执行一个动作，获得观察结果后，再继续判断后续步骤。

它最经典的工作流程通常如下所示：

这里的 Thought、Action、Observation 并非为了追求形式上的戏剧效果。它们分别对应着三个关键环节：

Thought 是模型的中间推理判断。

Action 是模型选择执行的下一步行动，例如发起搜索、查询数据库、打开网页、调用 API 函数或驱动机器人。

Observation 则是行动后获取的反馈信息。

用更通俗的话来说，ReAct 就是不让模型一次性硬挤出答案，而是要求它边执行边观察，边观察边调整。

这非常接近人类处理复杂问题的自然方式。

在处理一个涉及外部信息的问题时，我们很少会在不做任何查证的前提下，从头到尾推导出完整答案。更常见的做法是：先形成一个初步判断，然后去验证它；验证过程中发现偏差，再及时调整路线。ReAct 正是将这个过程提炼成了一种可复用的提示与执行模式。

为什么会需要 ReAct

在深入理解 ReAct 之前，可以先行了解两个更早期、更容易理解的技术方向。

一个方向是思维链（Chain-of-Thought），也就是常说的 CoT。它让模型在回答复杂问题时，将中间推理步骤也写出来。例如在解答数学题、逻辑题或需要多步分析的复杂问题时，如果模型直接给出最终答案，很容易出现跳步错误；而如果先将推理过程写清楚，结果往往会更可靠。

另一个方向是行动执行（Acting），即让模型与外部环境进行交互。比如 WebGPT 让模型使用文本浏览器搜索和浏览网页，SayCan 则将语言模型与机器人可执行的动作相结合，使模型不仅能“制定计划”，还能评估某个动作在当前环境中的可行性。

这两个方向各有其重要价值。

CoT 让模型更擅长思考，但它主要依赖模型内部存储的既有知识。当需要获取实时信息、企业私有数据或外部环境状态时，即使它思考得再深入，结果也可能只是“一本正经地猜测”。

行动执行让模型能够触及外部世界，但如果缺乏推理判断能力，它可能会机械地执行动作，却不明白为什么要这样做、出错后如何调整、何时应该停止。

ReAct 原始论文要解决的核心问题，正是这两种能力被割裂时的困境：推理需要外部反馈来修正，而行动需要推理来保持方向感。

因此，它把二者交错结合起来。

这种模式并非先制定一份完整的计划，然后一口气执行到底；也不是毫无章法地不停调用工具。它更像是一个小型循环：

这个循环虽然简单，却打开了一扇新的大门。

因为从这一刻起，模型的输出不再仅仅是“生成文本”，而开始转变为“完成任务”。

一个小例子：从直接回答到 ReAct

假设用户提问：

如果模型直接回答，它可能会凭记忆给出论文作者和摘要。

运气好的时候答案是对的，运气差的时候就会掺杂错误信息。

问题在于，用户很难判断它到底是经过查询验证，还是仅仅凭记忆背诵出来的。

如果只使用 CoT，模型可能会这样处理：

这比直接回答多了中间推理过程，但仍然没有接触外部实际资料。

如果只使用 Act，模型可能会直接搜索论文标题，获取页面后就把搜索结果直接贴出来。信息虽然有了，但缺乏整理和提炼。

而 ReAct 的处理方式会更接近以下流程：

这个示例本身并不重要，重要的是其中的节奏感。

模型并没有假装自己一开始就知晓全部答案。它首先承认需要查证，然后通过工具获取信息，再将信息整合成最终回复。

对用户来说，这种过程更容易建立信任。

对工程系统而言，这种过程也更容易进行调试。因为你可以清晰地看到每一步调用了什么工具、得到了什么结果、以及为什么决定继续下一步。

ReAct 到底让模型变强在哪里

如今市面上绝大多数 Agent 框架，其底层核心都是 ReAct 循环。这是为什么呢？

关键在于，最核心的提升并非“模型突然变得聪明了”，而是它让模型的聪明才智有了实实在在的落脚点。

第一，它能将外部信息纳入推理环节。

模型内部的知识再丰富，也不等同于它知道当前数据库中的订单状态、网页上的最新内容或文件系统里的真实代码。

ReAct 让模型在需要信息时先去主动获取，然后根据获取回来的结果继续判断。

这对于减少模型产生幻觉至关重要。

当然，工具本身并不能保证绝对真理。搜索结果可能出错，数据库数据可能不干净，API 接口也可能超时。但至少，系统不再单纯依赖模型记忆来回答问题。它多了一条连接现实世界的途径。

第二，它能在执行过程中修正方向。

在复杂任务中，第一步尝试往往并非最优方案。人类亦是如此。

我们查询一个关键词后发现不准确，会换一个词继续查；打开一个页面发现并非目标，会退回重新搜索；调用一个接口发现权限不足，会尝试其他路径。

ReAct 中的 Observation 正是为了给模型一个“看见反馈”的机会。

如果没有 Observation，模型只能沿着最初的错误路线一路错下去。

有了 Observation，它至少有机会暂停一下，自省道：“嗯，刚才那步不对，我需要换个方法。”

第三，它让过程更具可解释性。

这里需要稍微谨慎地说明一下。

ReAct 论文强调这种执行轨迹更容易被人类理解和信任，因为我们能看到模型的中间步骤和具体动作。但在当今许多生产系统中，模型完整的内部推理过程并不一定适合直接展示给用户，也不应该原封不动地暴露出来。

更稳妥的做法是，记录可审计的执行轨迹：模型调用了哪个工具、参数是什么、工具返回了什么、系统做了哪些校验、最终为何给出这个答案。

这类轨迹未必等同于模型的全部真实思考，但它对工程调试已经具有很高的价值。用户看到这些信息后，信服度也会大幅提升。

第四，它让 Agent 从“聊天”走向“办事”。

聊天模型的核心动作是生成文本，从而回答问题。

Agent 的核心动作是推动任务状态的演进。

ReAct 提供的就是一种最小化的推进方式：每次只走一步，每一步都能获得反馈，每次反馈都能影响下一步的决策。

这比一次性生成完整计划要慢一些，但同时也更稳定、更可控。

ReAct 不是什么

一个概念被频繁使用后，就容易笼罩上一层迷雾。ReAct 也不例外。

它并非让模型拥有了真正的自主意识。

它只是让模型按照某种格式生成中间判断和动作请求。模型说“调用搜索工具”，并不代表它真的自己打开了浏览器。

真正执行动作的，仍然是外部的程序、框架或工具执行器。

它也不是正确性的绝对保证。

ReAct 可以让模型去查资料、看结果、修正方向，但如果工具返回的信息质量很差，或者提示词写得含糊不清，或者循环控制做得不好，最终结果仍然可能出错。

一个会使用搜索引擎的人，也可能搜到错误页面，然后一本正经地引用其中的内容。工具本身并不会自动提升判断的准确性，它只是将判断建立在了更真实的基础上。

它也不适合所有类型的任务。

如果问题非常简单，比如“把这段话改得更口语化”，或者“解释一下什么是 JSON”，直接回答可能就足够了。强行套用 ReAct 模式，反而会让简单任务变得十分啰嗦。

这就好比为了打印一个简单的日志消息，何必安装一堆不必要的软件包。

它更适合那些需要外部信息、多步操作或者需要保留详细过程记录的任务。

判断一个任务是否适合使用 ReAct，通常会思考一个简单的问题：

这个任务的下一步，是否强烈依赖于上一步的结果？

如果是，那么 ReAct 通常值得考虑。

如果不是，直接执行可能更高效、更清晰。

放到现代 Agent 里，ReAct 长什么样

刚才提到，如今市面上许多框架其实都带有 ReAct 的影子。但事实上，今天的很多 Agent 框架已经不再需要你从零开始、手工编写 Thought:、Action:、Observation: 这三个字段了。

尤其是在工具调用能力变得成熟之后，模型可以通过结构化的 tool call 直接返回动作意图。框架负责执行工具，再将工具的执行结果追加回模型的上下文。

像 LangGraph 这样的框架会把这种循环封装成图结构：一个节点调用模型，一个节点执行工具，然后根据模型是否还需要调用工具来决定是继续循环还是结束。

但底层的节奏没有改变。

它依然是“三步走”的核心逻辑。

从这个角度看，ReAct 更像是一种工作模式，而不仅仅是某个固定的提示词模板。

在早期的 ReAct 示例中，Thought 通常是可见的文本。在现代产品中，推理步骤可能被隐藏、压缩、结构化，或者替换为更简短的执行说明。但只要系统还在运行“模型选择动作 -> 工具返回观察结果 -> 模型继续决策”这个循环，它就仍然延续着 ReAct 的骨架。

更值得关注的是以下三件事：

模型能否根据上下文选择合适的动作。

工具的执行结果能否可靠地回到模型的视野中。

系统能否有效控制这个循环，防止它失控乱跑。

工程里最容易忽略的几件小事

ReAct 看起来像是提示词技巧，但在实际落地时，很多问题都隐藏在工程细节中。

第一，工具描述要清晰准确。

模型在选择工具时，依赖的是工具的名称、参数结构、描述信息和上下文。如果工具叫 search，描述只有一句“search something”，模型就只能靠猜测来使用它。更好的工具描述要说明它查询哪里、适合什么问题、不适合什么问题、参数应该怎么写。

如果工具描述写得像谜语，模型调用起来就会像猜灯谜一样困难。

第二，Observation 要精简且有用。

工具返回的结果并非越多越好。如果你将整页 HTML、一大段日志或几百行 JSON 全部塞回上下文，不仅容易超出上下文窗口限制，模型反而会难以抓住重点。

更好的做法是，将返回结果整理成结构稳定、信息密度合适的观察信息。例如，搜索工具可以返回标题、摘要、链接和时间；错误结果也应当清楚写明错误类型，而不是仅仅返回一个 failed。

第三，错误也要转换成可理解的观察。

工具执行失败时，不要让整个 Agent 直接崩溃。可以将错误信息包装成模型能够理解的状态：权限不足、参数缺失、接口超时、结果为空、需要用户确认等。

这样，模型才有机会据此调整下一步行动。

例如：

这种方式比直接抛出异常更适合 Agent 的循环处理机制。

第四，要设置明确的停止条件。

ReAct 是一个循环，而循环就需要有刹车机制。

人类也会有钻牛角尖的时候，只是人类通常会被饭点等自然因素打断。而程序不会。

最大调用次数、最大耗时限制、重复工具调用检测、危险动作确认等机制，都不是可有可无的装饰。如果没有这些控制措施，Agent 很可能会在“再试一次”的循环中无限打转。

第五，权限不能完全交给模型。

在 Agent 系统中，更稳妥的做法是将模型视为一个能够表达意图的协作者，而不是一个可以直接持有操作钥匙的执行者。

如果要学习 ReAct，我会怎么走

如果完全没有接触过，不建议一开始就去阅读框架的源代码。

坦诚地说，初次接触时，直接看框架源码往往会让人感到困惑。

框架本身很好，但它会一次性将许多抽象概念呈现在你面前：Graph、Node、State、Tool、Executor、Memory、Checkpoint、Middleware。每个概念本身并不难，但当它们同时出现时，很容易让人误以为 Agent 是一座庞大、复杂的机器。

建议从一个最小化版本开始尝试。

第一步，深入理解普通的聊天模型。

输入用户的问题，模型输出回答。这个阶段先不要考虑工具。理解模型本质上是在根据上下文生成下一段文本内容即可。

第二步，理解工具调用的机制。

向模型提供一组工具说明，让它在需要时输出结构化的调用请求。注意，这个请求本身不会执行任何实际操作。真正执行函数的是你自己的程序。

第三步，将工具结果放回上下文。

程序执行工具之后，将执行结果作为一条新消息交还给模型。模型看到结果后，再继续回答。

第四步，加上循环控制。

如果模型还需要调用第二个工具，就继续执行。直到模型给出最终答案，或者达到设定的最大循环轮数。

这就是一个最小的 ReAct Agent。

它可能只需要几十行代码，但足以让你掌握其核心精髓。

等这个小循环成功跑通之后，再去看 LangGraph、LangChain、AutoGen 或其他 Agent 框架，理解起来就会轻松很多。

只有理解了地基，再看上面的楼层时，才不会感到晕头转向。

我眼中的 ReAct

ReAct，既不是一个过时的提示词模板，也不是一个万能通用的 Agent 终极答案。

它更像是一个学习 Agent 技术的绝佳入口。

它将许多后来变得复杂的概念，压缩成一个非常简单的循环：想一想，做一步，看结果，再想一想。

这个循环朴素到了容易被低估的程度。

但 Agent 的许多关键问题，都可以从这里生长出来：工具如何设计，结果如何返回，错误如何处理，权限如何控制，循环何时停止，过程如何记录，用户为什么应该信任最终的答案。

学习 ReAct 的意义，或许不在于记住那三个英文关键词。

更重要的，是建立起一种清晰的边界感：模型负责判断和表达意图，工具负责接触外部世界，程序负责执行和约束，观察结果负责将现实带回到上下文中。

这几个边界一旦清晰起来，Agent 就不再那么神秘了。

它依然复杂，也依然会犯错，但至少你可以拆开来看、一步步调试、慢慢改进。

很多技术都是这样。

站远了看，像一团迷雾。

走近一点，发现里面其实是一串清晰的脚印。

ReAct 所做的，就是让模型每走一步，都尽量在地上留下一个可追溯的痕迹。我们顺着这些痕迹，才能知道它究竟走到了哪里。

参考链接

• ReAct: Synergizing Reasoning and Acting in Language Models
• ReAct arXiv: 2210.03629
• Google Research Blog: ReAct: Synergizing Reasoning and Acting in Language Models
• Chain-of-Thought Prompting Elicits Reasoning in Large Language Models
• WebGPT: Browser-assisted question-answering with human feedback
• Do As I Can, Not As I Say: Grounding Language in Robotic Affordances
• LangGraph Agents 文档：ReAct pattern 与工具循环
• On the Brittle Foundations of ReAct Prompting for Agentic Large Language Models