ReAct 模式：思考（Reasoning）+ 行动（Acting），为什么交错进行比想完再干好

我最早用 ChatGPT 做复杂任务时，会先让它写一个详细的计划，然后一步步执行。结果呢？计划写得头头是道，但执行到第三步就卡住了，因为第二步的结果完全出乎意料，后面的计划全废了。后来我才发现，人和 AI 在面对未知环境时，最有效的策略根本就不是「想好了再干」——而是想一步，干一步，看看结果再想下一步。这正是 2022 年那篇引爆 AI 智能体研究的论文 ReAct: Synergizing Reasoning and Acting in Language Models 背后的核心洞察。

你可能会问：让模型先把所有步骤推理完，再一个个去执行，逻辑上不是更严密吗？为什么交错反而更好？这个问题困扰了我很久，直到我理解了 ReAct 不只是技术上的缝合，而是对「智能体如何与环境打交道」这件事的根本性重定义。

想完再干，一个看似完美的计划怎么就崩了？

在 ReAct 之前，主流思路是两类：一类是纯推理，比如 Chain-of-Thought (CoT)，让模型把思考过程写出来，然后给出最终答案；另一类是纯行动，模型直接生成动作与环境交互，没有明确的推理过程。CoT 在数学题、常识推理上效果拔群，但一碰到需要查资料、调 API、操作外部工具的任务，就立刻露怯——因为它完全不知道外界发生了什么，只能靠「脑补」。

举个例子：你让 CoT 模型回答「2023 年诺贝尔物理学奖得主的最新论文是什么？」它可能振振有词地编出一段：先推理出获奖者，再推理出论文标题，然后一本正经地输出。但整个过程没有检索、没有验证，幻觉从第一句推理就悄无声息地渗了进去，而且越往后偏得越离谱。纯行动模型呢？它会直接调搜索 API，但如果没有推理能力，它可能搜到一半就迷失了——不知道该搜什么、怎么整合多步信息，最后卡在循环里或者给出一个浅层答案。

Lilian Weng 在她的智能体系统综述中把这种窘境总结得很精准：推理让模型内部有规划，但缺乏外部反馈；行动让模型能触碰世界，但缺乏内省调整。两者割裂，就像一个人蒙着眼睛走迷宫，或者一个人睁着眼睛却在原地转圈。

推理和行动，不是先后关系，是循环关系

ReAct 的解决方案看起来简单得近乎粗暴：让模型在每一步都交替输出思考（Thought）和行动（Action），然后从环境获得观察（Observation），再进入下一轮思考。这个循环本质上把「推理→行动」的线性流程，变成了一个不断自我修正的反馈环。

论文中的经典例子是在 HotpotQA 上做多跳问答。模型需要先思考「问题里出现了两个实体，我需要先查第一个」，然后执行搜索行动，拿到维基百科片段；接着它根据返回的信息重新思考「第一个实体指向某个国家，第二个实体需要定位到该国的某场战役」，再执行第二次搜索……直到拼接出最终答案。每一步思考都基于上一步行动的真实结果，而不是凭空想象。这听起来像人类做研究时的查资料过程，对吧？但关键区别在于，模型不会觉得「先想好全部查询计划」更高效，因为环境的反馈总是会颠覆你的预判。

论文的作者之一 Shunyu Yao 在 项目主页 上展示过一个对比：纯 CoT 在回答需要实时信息的问题时，幻觉率高达 67%，而 ReAct 通过交替方式把幻觉率拉低到了 12%。这背后有一个很反直觉的机制：推理本身不是幻觉的源头，缺乏外部锚点的推理才是。当你每想一步都被环境「打脸」或「证实」时，模型就会被迫纠正自己的内部信念。

论文原文写道：“ReAct 通过将推理和行动紧密结合，使得语言模型能够动态地推理、跟踪和更新行动计划，同时从环境中收集信息。”(Yao et al., 2022)

为什么交错让模型少「编」故事？

这里有一个我自己的认知转折。我最早以为 ReAct 只是给模型多加了一个「调用工具」的能力，本质还是 CoT 的延伸。但后来我在自己搭建的 Agent 上反复实验，发现一个细节：模型的思考步骤在遇到观察之后，内容会发生明显转向——从「我认为应该怎么做」变成「根据返回的 X，我是否需要调整方向？」这个转向就是幻觉被抑制的关键。

在纯推理模式下，模型一旦开始编造，它只会顺着自己编造的上下文继续编，没有外力打断。ReAct 的每一步行动都会带回一个「硬事实」——哪怕这个事实是「搜索无结果」，它也是一个真实的信号，迫使模型重新思考。这就像你教一个学生写论文，如果只让他自己写提纲，他可能天马行空；但如果你要求他每写一段就去查一次文献，并且把文献结果贴在旁边，他就不太敢胡编了。

另外，交错还解决了一个很隐蔽的问题：多步任务中的信息传递损失。纯行动模型可能第一步搜到有用信息，但第二步执行时，因为上下文窗口限制或注意力漂移，它可能「忘记」了第一步的结果。而 ReAct 的思考步骤会把关键信息提炼出来，显式地写进下一轮思考的上下文里，这相当于给模型加了一个外挂的「工作记忆」。

一张表看清纯推理、纯行动和 ReAct 的差距

数据来源：ReAct 论文 和 LangChain ReAct 文档 中的实验复现。可以看到，ReAct 不是简单的「推理+行动」叠加，而是产生了 1+1>2 的协同效应。

我踩过的坑：以为 ReAct 只是多了一步行动

真正让我重新审视 ReAct 的，是一次失败的项目经历。我试图让一个 Agent 自动完成「从产品需求文档生成测试用例，并去 Jira 上创建任务」的流程。我最初设计的是单次推理生成所有用例，然后批量调用 API。结果，需求文档里有一处模糊描述，模型自己脑补了业务逻辑，生成了 20 个完全错误的用例，全部创建到了 Jira 上，还分配给了真实工程师……那次事故之后，我改成了 ReAct 模式：每生成一个用例，先调一个内部验证 API 检查用例是否与需求文档一致，拿到验证结果再决定下一个用例怎么写。准确率从 55% 飙升到 92%，而且一旦出错，只会在当前步骤卡住，不会污染后续所有任务。

这个经历让我想通一件事：ReAct 的威力不仅在于「有能力查」，更在于「愿意根据查到的结果改主意」。很多模型不是不会查，而是查完之后依然固执地坚持最初的错误推理。把思考和行动交错起来，相当于在模型内部建立了一个「不好意思，我刚才搞错了」的机制——这在纯推理模式里是极难出现的。

什么时候不该用 ReAct？

ReAct 不是银弹。它有几个明显的代价：

• 交互成本高：每步都要调用模型和工具，延迟和 token 消耗是纯推理的数倍。对于简单任务（比如直接回答一个已知事实），ReAct 反而画蛇添足。
• 环境依赖：你需要一个可靠且可交互的环境（搜索 API、数据库、代码执行器），如果环境总报错或返回噪音，观察会误导思考。
• 串行瓶颈：ReAct 是串行循环，无法并行执行多个独立行动。如果任务中有大量互不依赖的子任务，Plan-and-Execute 模式（先做整体计划再并行执行）可能更合适。

我的使用原则是：当任务中的不确定性主要来自外部信息，而非内部逻辑时，ReAct 是首选；当任务的步骤可以被事先完全确定，且不需要外部反馈时，纯推理或 Plan-and-Execute 更高效。比如写一封格式固定的邮件，没必要用 ReAct 反复查；但做一次需要多轮检索的市场调研，ReAct 就是你最好的朋友。

常见误解澄清

ReAct 和 ChatGPT 的 Function Calling 是一回事吗？

不完全一样。Function Calling 本质上是行动步骤，但缺少显式的思考步骤。ReAct 要求模型在调用函数之前和之后都输出思考，这种结构化的思维链让调试和可靠性大幅提升。

ReAct 能彻底消除幻觉吗？

不能。如果环境本身返回了错误信息，或者模型在思考步骤里执意曲解观察结果，幻觉依然会出现。但 ReAct 把幻觉的源头从「无中生有」变成了「有据可查」，排查起来更容易。

为什么不用更高级的规划算法，比如 Tree of Thoughts？

Tree of Thoughts 更适合需要探索多条推理路径的复杂推理任务（如数学证明），而 ReAct 的强项在外部交互。两者可以结合，但计算成本会急剧上升。

2023 年之后的 Agent 框架（如 AutoGPT、MetaGPT）几乎都默认采用某种形式的 ReAct 循环，因为它找到了一个朴素但坚实的平衡点：让模型在「想」和「做」之间保持最小闭环，把每一步行动的后果都变成下一步推理的素材。这大概是目前让 AI 处理真实世界任务最不坏的方式了。