ReAct（推理与行动）

概念更新 2026-08-05置信度 high#概念#智能体#范式#基础

让语言模型交替进行任务判断、环境动作和结果观察，并用观察结果修正后续行动的 Agent 范式。

是什么

ReAct 来自 Reasoning and Acting。它解决的是“只在语言里推理”与“只盲目执行动作”之间的断裂：模型在每一轮决定下一步行动，环境执行行动并返回 Observation，模型再根据真实反馈继续。

经典教学格式写成：

Thought: 当前缺少什么信息，下一步准备做什么
Action: search
Action Input: 查询词
Observation: 搜索工具返回的事实或错误
...重复...
Final Answer: 基于观察形成答案

现代 API 通常把 Action 表示为结构化 tool call，把 Observation 表示为 tool result；不需要也不应强制暴露模型的完整私有思维过程。生产系统更适合记录简短决策理由、调用参数和可审计结果。

为什么重要

纯 Chain-of-Thought 只能在模型已有上下文中推理，无法获得当前事实或改变环境。纯 Action 策略又缺少对目标、依赖和错误的语言化判断。ReAct 通过环境反馈形成闭环：

搜索后能发现原假设错误并改写查询。
API 返回缺少参数时能补充信息。
代码测试失败时能定位问题并再次修改。
工具不可用时能切换方案或请求人类。

它是理解多数 tool-using Agent 的最小心智模型。

工作原理

1. 构造可行动的上下文

模型需要看到用户目标、当前状态、可用工具的名称/描述/schema、先前 observation 和停止条件。工具越多越好并不成立；相似工具会增加误选。

2. 选择下一步

模型可以：

直接给出最终答案。
调用一个读取型工具获得证据。
调用动作型工具改变环境。
修改计划或选择另一工具。
在信息不足或风险过高时请求人类。

3. 执行动作

运行时验证工具名和参数，再在权限受控的环境中执行。工具错误必须结构化返回，不能把异常静默吞掉。

4. 观察结果

Observation 应尽量接近 ground truth，例如 HTTP 状态、数据库结果、测试输出或文件差异。过长结果需要压缩，但压缩不能丢失关键错误和来源。

5. 检查终止

至少需要：完成条件、最大轮数、超时、预算、连续失败阈值、风险升级和用户中断。

6. 评估轨迹

除了最终答案，还应检查是否选对工具、参数是否正确、是否重复无效动作、是否尊重权限、是否在正确时机停止。

历史与演进

ReAct 论文将语言推理轨迹与任务环境动作结合，并在知识密集型问答和交互式决策任务上展示价值。随后 Agent 框架把其循环封装为 function calling、tool calling、runner 或 graph node。

随着模型原生工具调用能力提升，显式字符串解析的重要性下降，但“决策—动作—观察—修正”的闭环仍是核心。当前实现更强调结构化协议、隐藏私有推理、trace 和可控运行时。

常见误解

“ReAct 等于把 Thought 全打印出来”

ReAct 的本质是用观察驱动下一步，不是公开完整 Chain-of-Thought。可审计系统应记录动作理由和证据，而非依赖私有推理文本。

“有循环就能自动纠错”

如果 Observation 不可靠、工具错误不清晰或模型无法识别失败，循环只会重复错误。

“让模型无限尝试会提高成功率”

无限重试会增加费用和风险。需要最大步数、重复检测和人工升级。

“ReAct 自带规划”

它擅长逐步适应，但长程任务可能需要显式计划、dependency tracking 或外部 workflow。

“任何动作都能交给工具”

不可逆、高权限和高风险动作必须受权限控制、预览、确认或 sandbox 约束。

与相邻概念的区别

与 Chain-of-Thought：CoT 主要在语言空间展开推理；ReAct 把环境动作和反馈纳入循环。
与 Plan-and-Solve：后者先生成较完整计划再逐步执行；ReAct 更强调每次观察后的局部适应。
与 Reflection：Reflection 对一次失败轨迹或输出进行批评并影响下一轮；ReAct 在单次运行中持续观察环境。
与 LLM 工具调用（Tool Use）：工具调用是动作接口，ReAct 是组织多轮决策与动作的控制范式。
与 Agentic Workflow（智能体工作流）：ReAct loop 可以是整个 Agent，也可以嵌在固定 workflow 的一个步骤中。