这是这篇论文的中文翻译链接一、开篇为什么这篇论文值得看如果你今天在做 Agent几乎绕不过 ReAct。不是因为它已经是“最强方案”而是因为它第一次把一个后来被广泛接受的基本问题讲清楚了LLM 到底应该先想再做还是边想边做在 ReAct 出现之前LLM 主要沿着两条路线解决复杂任务一条是 CoTChain-of-Thought。它擅长“想”尤其擅长数学、常识、多跳问答这类需要中间推理的任务但问题在于它几乎完全依赖模型内部知识不能主动去外部环境拿信息因此很容易出现事实幻觉、错误传播且一旦推理路径偏了很难在线修正。另一条是 Act-only 路线即模型直接决定动作、调用工具、与环境交互它能“做”但往往缺少显式推理导致动作选择的依据不透明也容易在长程任务中迷失状态、陷入重复。论文在引言和图 1 中明确把这两种失败模式并列展示出来CoT 容易“想错但说得像真的”Act-only 则容易“做了很多但不知道为什么这样做”。ReAct 的价值就在于它不是简单把“推理”和“工具调用”拼接而是提出了一个交错式interleaved推理—行动范式模型在求解过程中不再先写完整推理再一次性输出答案也不再只生成动作序列而是不断经历Thought → Action → Observation → Thought → …这个范式级转变的意义非常大。它把 LLM 从“静态知识生成器”推进到“动态环境中的问题求解器”。论文在四类任务上验证了这一点知识问答、事实验证、文本环境决策、网页购物决策。更重要的是它展示了一个后来几乎所有 Agent 框架都在继承的基本思想显式思考负责规划、监控与纠错外部行动负责取证、验证与补充信息。二、一句话结论核心思想ReAct 证明了让语言模型显式生成“思考轨迹Thought”并与“动作Action”交错推进能把 LLM 从只会内部推理的语言模型变成能在外部环境中持续更新认知、执行多步决策的交互式 Agent。更直白一点说ReAct 的真正贡献不是某个具体 benchmark 分数而是奠定了后来 Agent 设计里最经典的闭环用 reasoning 决定该做什么再用 acting 拿回 observation反过来修正 reasoning。三、论文要解决的具体问题问题定义如何让 LLM 在复杂任务中同时具备两种能力1显式、可检查的推理2面向外部环境的动作执行与信息获取。作者把一般任务抽象为 agent 与环境交互的过程时刻 (t) 接收观察 (o t o_tot)基于上下文 (c t c_tct) 选择动作 (a t a_tat)。传统难点在于从上下文到动作的映射是高度隐式的因此作者提出把动作空间从原来的 (A AA) 扩展为 (A ∪ L A \cup LA∪L)其中 (L LL) 是语言空间也就是“thought / reasoning trace”。原文关键假设任务可以表示为文本形式的交互轨迹环境能够返回文本化 observationLLM 能通过少量 in-context examples 学会 Thought/Action 的交替格式对不同任务thought 的稀疏度可以不同问答任务用密集 thought决策任务可用稀疏 thought。成功指标在 HotpotQA、FEVER、ALFWorld、WebShop 四类任务上相比 Standard / CoT / Act-only / imitation learning / RL 等基线取得更好或更稳健的性能同时提供更强的可解释性、可诊断性与可控性。论文特别强调 interpretability、trustworthiness 与 diagnosability 这三个非纯分数维度。四、方法框架总览配系统图4.1 系统图Mermaid是否用户问题 / 环境目标LLM上下文构建\nFew-shot ReAct exemplars 当前轨迹Thought生成Action生成环境执行器 / 工具接口Observation返回是否Finish?输出最终答案 / 最终动作结果4.2 数据流解释输入不是单纯的 question而是任务输入 少样本 ReAct 轨迹示例 当前历史轨迹模型在每一步根据当前上下文先生成一段 Thought这段 thought 不会改变外部环境但会更新内部上下文帮助模型分解目标、提炼 observation、监控进度、决定下一步动作。随后模型生成 Action由环境接口执行返回 Observation新 observation 再进入下一轮 thought。这个循环持续到生成Finish[answer]或任务结束。4.3 与常规方法的关键差异常规 CoT 的轨迹是Question → Thought → AnswerAct-only 的轨迹是Question → Action → Observation → Action …而 ReAct 是Question → Thought → Action → Observation → Thought → Action → …关键差异不只是多了一个字段而是把“语言”从结果解释升级成了决策状态的一部分。作者明确把 thought 视为扩展动作空间中的语言动作它不改变外界但会改变后续决策所依赖的上下文。这个定义非常重要因为它等于把“推理”制度化地放进了 policy loop。五、关键模块拆解【模块一动作空间扩展A → A ∪ L】设计动机传统 agent 的动作空间只有环境动作 (A)。这意味着模型必须把“规划、判断、记忆、纠错”全都隐含在内部状态里完成导致策略不可解释也难以在长轨迹中维持稳定。ReAct 的第一个关键设计就是把“语言化思考”本身纳入动作空间。技术细节作者把 thought 视为一种特殊动作它不会触发环境反馈但会更新上下文 (c t 1 ( c t , a ^ t ) c_{t1}(c_t,\hat a_t)ct1(ct,a^t))。这使 thought 具有“工作记忆”的作用。论文列举了 thought 的多种功能包括分解任务目标、制定行动计划 提供关键事实注入常识跟踪进度与状态迁移处理异常、调整查询与计划。最容易被误解的点很多人第一次看 ReAct会以为它的创新只是 prompt 模板里多写了一个Thought:。其实不对。真正的创新点是thought 被赋予了功能性而不只是解释性。在 ReAct 里thought 不是“事后解释模型为什么这么做”而是“在做决定之前先构造一个更好的决策状态”。工程启示这启发我们今天设计 Agent 时不应把 reasoning 当作日志而要当作状态管理器。也就是说Thought 最有价值的地方不在“给人看”而在“帮助下一步更准”。【模块二交错式生成机制Interleaved Generation】设计动机CoT 的问题是“想完再做”Act-only 的问题是“做而不想”。ReAct 试图逼近人边观察边修正计划。引言中的厨房类比和图 1 都在说明人类的优势不是先完成一个完整计划再执行而是在行动中不断重估。技术细节在知识密集型任务HotpotQA/FEVER中作者采用密集 thought即几乎每次 action 之前都有 thought在决策任务ALFWorld/WebShop中作者采用稀疏 thought让 thought 只决定下一个子目标利用常识推断物体可能位置或商品属性匹配。与直觉的差异直觉上你会觉得 thought 越多越好但论文实际给出的结论更细不是所有任务都适合密集 reasoning。在长程决策环境里thought 如果每步都写反而会造成上下文负担与噪声累积因此作者强调reasoning 的位置比 reasoning 的长度更重要。工程启示现代 Agent 系统常做的“planner 每步都写一大段思考”未必是最优设计。ReAct 更像是在说把 reasoning 放在决策拐点上而不是所有 token 上。【模块三环境接口与观测回灌Observation Feedback】设计动机只有 reasoning 没法解决知识更新问题只有 action 没法关键模块是让 Action 真正接上外部环境然后把 Observation 回灌给后续 reasoning。技术细节在 HotpotQA/FEVER 中作者设计了一个极简 Wikipedia API动作仅有三种search[entity]lookup[string]finish[answer]且它并不是强检索器只能返回页工具做得很弱是为了测试模型是否真的能靠显式 reasoning 引导检索而不是靠工具本身“太强”。在 ALFWorld 中observation 是文本环境状态在 WebShop 中observation 是商品标题、选项、价格、页面按钮等噪声混杂信受 observation而是通过 thought 把 observation 重新压缩成“接下来该做什么”。工程启示今天很多 Agent 不稳定不是因为模型不会调用工具而是因为工具返回后没有形成有效的“二次理解层”。ReAct 告诉我们真正的闭环不是 Tool Call 本身而是Observation → Thought Compression → Next Action六、与已有方法的差异对比分析维度CoTAct-onlyReAct核心能力显式推理工具/环境交互推理与交互闭环外部知识获取无有有推理显式性高低高动态纠错弱中强事实可靠性易幻觉依赖检索但难整合更 grounded长程决策稳定性弱易迷失状态更能跟踪子目标成本/延迟低中较高代表问题内部知识封闭缺乏行动依据轨迹更长、格式更脆弱论文实验也支持这个判断。在 HotpotQA/FEVER 上ReAct 相比 Act 更好说明reasoning 能指导 acting但它与 CoT 的比较不是单向碾压而是出现了任务差异HotpotQA 上 ReAct 27.4略低于 CoT 29.4FEVER 上 ReAct 60.9高于 CoT 56.3。作者给出的解释很关键当任务更依赖最新、精确外部事实时ReAct 的外部交互优势更明显而当任务更依赖结构化推理时CoT 有一定优势。进一步把两者结合起来的ReAct→CoT-SC和CoT-SC→ReAct才是整体最优。在决策任务上ReAct 的优势更直接ALFWorld 最佳 ReAct 成功率 71%明显高于Act 的45webshopReAct 成功率 40.0高于 Act 30.1也高于 IL 29.1 和 ILRL 28.7。七、局限性与复现难点Critical Analysis7.1 理论局限ReAct 不是万能规划器而是“在线局部修正器”尽管 ReAct 强调动态闭环但它本质上仍然是基于当前上下文进行下一步生成而不是显式全局规划。因此它更像“边走边看”的局部策略而不是一个真正的 search/planning framework。论文中一个典型失败模式就是 ReAct 会重复生成前一步的 thought 而可能陷入局部循环。作者甚至在文中推测这与贪心解码有关未来用 beam search 等方法可能改善。7.2 结构约束带来的灵活性损失论文一个非常诚实的发现是虽然 ReAct 提升了 groundedness 和 trustworthiness但其结构化 Thought-Action-Observation 轨迹也限制了推理的自由度导致某些任务上 reasoning error 比 CoT 更高。在作者对 HotpotQA 的人工分析中ReAct 的 reasoning error 比例达到 47%明显高于 CoT 的 16%相反CoT 的主要问题是 hallucination占失败原因的56%。这说明 ReAct 与 CoT 的差异不是“谁绝对更强”而是用灵活性换 groundedness。7.3 搜索质量强依赖工具反馈ReAct 很吃 observation 质量。论文指出ReAct 的 23% 错误来自 non-informative search即搜索结果为空或不包含有效信息。 observation也会被带偏而且不容易恢复。换句话说ReAct 不是把检索问题消除了而是把检索质量问题显式暴露出来。7.4 Few-shot prompt 成本与上下文长度问题ReAct 论文是 prompt-based 范式不是专门训练的新模型。这带来了两个直接工程问题第一prompt 很长。第二复杂任务需要更多 demonstrations而 demonstrations 一多就容易撞上下文窗口限制。 任务复杂的场景仅靠 in-context learning 并不够未来需要更多高质量人类标注与多任务训练。7.5 复现难点你可能复现出“形式像 ReAct行为不像 ReAct”从今天的视角看复现 ReAct 最容易踩的坑有2个把 Thought 写成解释而不是决策状态。这样模型就会“说得很好有任务都强行密集 thought。论文实际上强调问答与决策任务的 thought 密度应该不同。fileciteturn2file1忽视 observation 的再压缩。很多系统接了工具后直接堆 observation没让模型显式抽取关键信息结果上下文很快被噪声淹没。八、工程落地价值为什么现在还要读8.1 直接对应实现今天你在 LangChain、LangGraph、AutoGen、OpenAI function/tool calling、各类 planner-executor 架构里看到的“思考—行动—观察”闭环底层精神几乎都能追溯到 ReAct。虽然很多现代系统已经不再把全部 thought 原样外显但“reason before tool use, update after observation” 这个主线仍然是 ReAct 奠定的。这个判断并不是论文原文直接这么说而是从它定义的交错式范式和后续 Agent 工程实践中可以自然推出来的双向关系——reason to actact to reason。8.2 最值得借鉴的设计我认为 ReAct 留给工程界最重要的不是 prompt 模板而是三条设计原则第一Thought 要承担状态管理功能。不是为了“可解释”才写而是为了“下一步更准”才写。第二Reasoning 的位置 强调 sparse reasoning 的价值而不是无脑长链思考。第三Observation 不是终点而是下一次推理的输入。很多 Agent 系统真正缺的是这个回灌闭环。8.3 适用场景多跳问答、事实核验、需要联网取证的推理需要在环境中持续更新认知状态的任务工具调用不多但每一步都很关键的 Agent需要人类检查轨迹、做人机协同修正的场景。论文在附录中还展示了一个很有启发性的例败轨迹改成成功轨迹。这意味着 ReAct 天然适合做 human-in-the-loop correction。8.4 不适用场景极端低延迟、高并发场景工具调用成本很高、每轮 observation 特别长的场景强并行、多分支搜索任务需要严密全局规划而不是局部在线修正的任务。九、我的判断与推荐指数研究价值⭐⭐⭐⭐⭐它定义了现代 Agent 最经典的交互范式之一。工程价值⭐⭐⭐⭐不是“直接照搬就上线”但里面的状态闭环思想极强直到今天都没过时。必读程度⭐⭐⭐⭐⭐如果没读过 ReAct你很难真正理解为什么那么多 Agent 框架都长成“plan / act / observe / replan”的样子。一句话总结这篇论文应该被看作现代 Agent 闭环范式的起点而不是最终工程解法。对研究者它值得精读因为它把“推理为什么必须进入 agentt 失败不是不会调工具而是不会在工具前后组织 reasoning。十、延伸阅读相关论文/项目前置必读CoT《Chain-of-Thought Prompting Elicits Reasoning in Large Language Models》先理解“为什么显式推理重要”再看文相关工作部分也明确将 ReAct 建立在 CoT 之后并强调自己超越了“孤立、固定的 reasoning”。fileciteturn2file2后续发展Reflexion在 ReAct 基础上加入自我反思与试错记忆ReWOO尝试解耦推理与 observation缓解 ReAct 的串行延迟问题更广义的 planner-executor / graph-based agent本质都在回答 ReAct 留下的问题——如何把 reasoning 放在正确的位置上。工程实现建议复现时建议重点观察论文附录中的 prompt 写法尤其是HotpotQA/FEVER 的密集 thought 设计ALFWorld 的稀疏 thought 设计WebShop 中“reasoning。这些 prompt 不是装饰而是论文方法成立的关键细节。