跳到主要内容

ReAct

ReAct（Reasoning and Acting）是理解现代 Agent 执行循环的入口论文。

它的核心价值不是证明模型“会思考”，而是把语言模型的中间决策和外部行动组织成可观察的循环：

  • 模型先根据任务和上下文形成下一步判断。
  • 再选择一个动作，例如搜索、查知识库、调用环境动作或结束任务。
  • 系统执行动作并返回观察结果。
  • 模型基于新观察继续决策。

对工程系统来说，ReAct 最重要的遗产是：

  • Agent 不能只看最终回答。
  • 必须记录行动、工具参数、观察、错误和终止原因。
  • 外部观察可以修正模型的中间判断。
  • 工具返回也可能污染后续决策。

1. 背景问题​

ReAct 试图解决两个早期范式的断裂。

第一类是只让模型做 Chain-of-Thought（CoT）式推理。

这种方式可以把复杂问题拆成中间步骤，但模型仍然被困在已有参数知识和输入上下文里。

当问题需要检索最新事实、读取环境状态或交互式试错时，单纯内部推理会出现两个问题：

  • 中间推理看起来连贯，但事实基础可能是错的。
  • 模型没有机会通过外部观察纠正路线。

第二类是只让模型或策略执行动作。

这种方式可以和环境交互，但如果缺少可解释的中间决策，调试者很难知道：

  • 为什么选这个工具。
  • 为什么传这些参数。
  • 为什么忽略了某个观察。
  • 为什么在错误之后继续执行。

ReAct 的论文贡献在于把 reasoning 和 acting 放在同一条轨迹里。

这使 Agent 既能推理，也能用外部世界的反馈校正推理。

2. 一句话结论​

ReAct 是一种“推理-行动-观察”循环模式，适合需要多步工具调用、环境反馈和可观察轨迹的任务。

它不是生产级 Agent 框架。

它没有自动解决权限、安全、成本、工具可靠性、长时记忆和评测问题。

3. 方法结构​

论文中的典型轨迹由三类片段组成。

片段作用工程化落点风险
Thought当前判断、计划、假设生产中通常保存为内部决策摘要或 trace 摘要不能当事实来源，也不一定适合对用户公开
Action选择工具或环境动作tool name、arguments、权限上下文参数错误会导致错误结果或副作用
Observation工具或环境返回结构化结果、错误码、证据片段外部文本可能包含提示注入或污染

工程实现时，建议把 ReAct 抽象成状态机，而不是把论文中的文本格式照搬进 prompt。

一个更接近生产的状态对象可以是：

{
  "task_id": "case-2026-05-09-001",
  "goal": "回答一个需要检索的问题",
  "step": 3,
  "budget": {
    "max_steps": 8,
    "max_tool_calls": 5,
    "timeout_ms": 30000
  },
  "state": {
    "known_facts": [],
    "open_questions": [],
    "last_observation_ref": "obs_002"
  },
  "trace": [
    {
      "type": "tool_call",
      "tool": "search",
      "arguments": {"query": "ReAct paper ALFWorld WebShop"},
      "result_ref": "obs_002",
      "status": "success"
    }
  ],
  "termination": null
}

4. 实验设置与证据边界​

ReAct 论文主要在两类任务上验证方法。

第一类是知识密集型问答。

代表任务包括 HotpotQA 和 Fever。

这些任务要求模型查找事实、整合证据并给出答案。

论文比较了 ReAct、Chain-of-Thought、Act-only 等设置。

核心观察是：

  • 单纯 CoT 可能产生自洽但错误的推理。
  • 只有行动缺少高层判断，容易在多步任务中迷失。
  • 推理和检索交替可以让模型用观察结果修正下一步。

第二类是交互式决策任务。

代表环境包括 ALFWorld 和 WebShop。

这些任务要求模型在环境中执行动作，例如搜索商品、选择对象、完成目标。

论文中的证据说明 ReAct 在这些受控环境里能提升任务表现和轨迹可解释性。

但这些实验不能直接推出以下结论：

  • ReAct 对任意业务工具都可靠。
  • ReAct 的中间推理一定真实。
  • 只要加入工具调用就能减少幻觉。
  • 长时自主循环可以无监督运行。

5. 核心贡献​

ReAct 的贡献可以分成四层。

第一层是认知结构贡献。

它把“想”和“做”交替起来，让模型不再只能在内部上下文中推演。

第二层是调试结构贡献。

它让每一步行动前后都有可审计的上下文，便于定位失败点。

第三层是工具使用贡献。

它展示了外部工具返回可以成为下一步推理的输入，而不是只作为最终答案证据。

第四层是 Agent Loop 原型贡献。

现代 Agent 系统里的 plan、act、observe、update、stop，很多都可以从 ReAct 的结构中看到影子。

6. 局限表​

局限具体表现工程后果缓解方式
行动空间受控论文工具和环境远比企业系统简单无法直接覆盖权限、交易、审批、幂等等问题为每个工具定义 schema、权限、幂等性和回滚策略
中间推理不保证真实轨迹可能合理但事实错误审计者容易被流畅解释误导把证据、工具返回和最终结论分开记录
工具返回不可信网页、文档、搜索结果可能含恶意指令后续步骤被 prompt injection 影响对外部内容做隔离、摘要、过滤和引用标记
多步成本高每步都可能触发模型和工具调用延迟、费用和失败点增加设置最大步数、最大成本和降级路径
终止条件弱模型可能继续搜索或重复调用循环失控、重复工具调用用明确 stop reason 和预算控制终止
评测不完整最终答案正确不代表过程可靠工具乱用也可能偶然答对同时评估答案、工具选择、参数和观察使用

7. 今天工程系统如何借鉴​

ReAct 最适合借鉴到 Agent 的执行控制层。

可借鉴点包括：

  • 显式维护任务状态。
  • 每一步先决定是否需要外部工具。
  • 工具调用后将观察写入 trace。
  • 基于观察更新下一步，而不是一次性生成完整答案。
  • 支持失败后回退、澄清或交给人工。

一个生产级 ReAct Loop 通常需要补齐这些模块：

模块论文中是否充分覆盖生产系统要求
Tool Registry部分覆盖工具描述、schema、权限、速率限制、负责人
Policy Engine基本未覆盖哪些动作允许自动执行，哪些需要审批
Trace Store概念相关保存模型调用、工具调用、观察、错误、审批
Evaluator部分任务有离线评测集、在线抽样、轨迹评分
Cost Controller基本未覆盖token、工具成本、墙钟时间、重试次数
Security Filter基本未覆盖注入防护、敏感信息过滤、工具返回隔离

8. 不能直接照搬的地方​

不要直接把论文中的 Thought: 原样暴露给终端用户。

现代系统更常见的做法是保存内部 trace，同时向用户展示精简的执行摘要和证据来源。

不要把所有工具都放进同一个 prompt。

工具过多会增加选择错误、上下文污染和提示注入面。

不要让 ReAct 循环自动执行高影响动作。

删除、付款、发信、发版、改权限、外部采购等动作必须经过权限策略和人工确认。

不要只用最终答案评测 ReAct。

至少还要检查：

  • 是否该调用工具。
  • 调用了哪个工具。
  • 参数是否正确。
  • 是否正确使用观察结果。
  • 是否在无证据时编造。
  • 是否在达到预算时停止。

9. 评测方法​

评测 ReAct 类系统要同时看结果和过程。

指标说明数据来源
Task Success Rate最终任务是否按标准完成标注集、用户验收、自动测试
Tool Call Accuracy工具选择和参数是否正确trace 标注、回放评测
Observation Grounding回答是否基于真实观察引用检查、证据对齐
Step Efficiency完成任务用了多少步trace 统计
Failure Recovery工具失败后是否正确降级故障注入、错误样本
Injection Resistance是否抵抗工具返回中的恶意指令红队样本、安全评测
Cost per Success成功任务平均成本token 和工具计费日志

一个简单的回放评测流程：

1. 收集真实任务 trace。
2. 标注每一步的期望工具、参数和终止条件。
3. 固定工具返回，回放不同 prompt 或模型版本。
4. 比较最终成功率、工具调用准确率和平均步数。
5. 对失败样本按原因分类。
6. 只把通过安全和成本门槛的版本发布到生产。

10. 安全与治理​

ReAct 的安全核心在于：观察结果会影响下一步行动。

因此任何进入 observation 的内容都不能默认可信。

关键风险包括：

  • 外部网页告诉 Agent 忽略系统指令。
  • 邮件内容诱导 Agent 泄露通讯录。
  • 工具返回混入伪造错误和伪造审批信息。
  • 检索结果包含过期或被污染的事实。
  • 多轮循环中错误观察不断放大。

治理要求包括：

  • 工具按最小权限注册。
  • 高影响动作强制人工确认。
  • 外部内容与开发者指令隔离。
  • 工具返回保留来源和时间。
  • trace 支持事后审计。
  • 失败时给出明确 stop reason。

11. 适用与不适用场景​

适用场景：

  • 需要多步检索和证据整合的问答。
  • 需要在环境中根据反馈调整动作的任务。
  • 需要记录工具调用轨迹的企业流程。
  • 需要把复杂任务拆成可审计步骤的助手。

不适用场景：

  • 极低延迟的一问一答请求。
  • 不允许模型访问外部工具的封闭问答。
  • 高风险不可逆操作且没有审批系统。
  • 评测器和日志系统都尚未建立的生产环境。

12. 与后续方法的关系​

Toolformer 更关注模型如何学习何时调用工具。

Reflexion 更关注失败后的语言反馈如何进入下一轮。

Tree of Thoughts 更关注多个候选思路的搜索和评估。

Voyager 更关注长期技能库和开放式探索。

Generative Agents 更关注长期记忆、反思和社会行为仿真。

ReAct 是这些方法的基础结构之一，但不是它们的替代品。

13. 权威资料​