ReAct 推理范式是什么？它如何让 Agent 更可靠地完成任务？

前言

大语言模型擅长理解语言、生成内容和归纳知识，但当任务需要“查资料、调用工具、核实结果、分步执行”时，仅靠一次性生成答案往往并不可靠。

ReAct（Reasoning + Acting）提供了一种更适合智能体（Agent）的工作方式：让模型在任务过程中交替进行“推理”和“行动”，并根据行动得到的真实反馈持续修正下一步。

它不是让模型想得更久，而是让模型在需要时走出去验证、执行和学习。

一、什么是 ReAct？

ReAct 是 “Reasoning and Acting” 的缩写，直译为“推理与行动”。它由研究者在 2022 年提出，核心思想非常直观：Agent 不应只在内部思考，也应在外部环境中行动；而行动得到的观察结果，应反过来影响后续推理。

一个典型的 ReAct 循环包含四个部分：

Thought（思考）：判断当前信息是否足够，以及下一步最值得做什么。
Action（行动）：调用工具、搜索网页、查询数据库、运行代码或操作系统。
Observation（观察）：读取工具返回的结果、报错或环境变化。
Answer / Next Thought（回答或继续思考）：决定是否完成任务，或基于新信息进入下一轮。

它的基本循环可以概括为：

用户目标
   ↓
思考：我还缺少什么信息？
   ↓
行动：搜索 / 查询 / 执行工具
   ↓
观察：获得真实结果或错误反馈
   ↓
思考：结果是否可信、下一步怎么做？
   ├── 信息不足 → 继续行动
   └── 条件满足 → 输出最终答案

与“直接回答”相比，ReAct 最大的区别在于：Agent 的结论不只是来自参数记忆，还来自任务执行期间获得的外部证据。

二、为什么单纯的语言模型容易在复杂任务中失误？

假设你问一个 Agent：“帮我规划下周去上海的商务行程，并推荐靠近会场、价格合适的酒店。”

如果模型直接回答，它可能生成一份看起来完整的计划，但其中隐含着几个风险：

会场地址可能理解错了；
酒店价格可能早已变化；
房间可能已经售罄；
推荐路线可能没有考虑实际交通时间；
行程日期、星期与航班时刻可能并不匹配。

这类回答的问题不一定是语言组织能力不足，而是模型把不确定的信息“补全”成了一个听起来合理的答案。

ReAct 的处理方式不同。它会将任务拆开：

确认会场地点
→ 查询目标日期
→ 搜索酒店与实时房价
→ 计算通勤距离和时间
→ 对比候选方案
→ 输出带依据的建议

每一步都可以被外部结果验证，因此最终答案更接近“完成任务后的交付物”，而不是“基于印象的回答”。

三、ReAct 如何工作：从思考到行动的闭环

以“查询一家公司的最新财报表现”为例，一个 ReAct Agent 的工作轨迹可能是：

阶段	Agent 的行为	目的
思考	判断“最新财报”属于时效性信息	避免依赖过时知识
行动	访问公司投资者关系页面或权威财经数据源	获取一手信息
观察	读取营收、利润、指引及发布日期	建立事实基础
再思考	检查同比、环比和市场预期是否需要补充	发现信息缺口
再行动	查询历史同期数据或分析师预期	支撑比较结论
输出	生成结论，并说明依据与不确定性	给出可追溯答案

这是一种“先判断、再验证、再决策”的工作流。

可以把它理解为人类处理陌生问题时的自然过程：先想清楚要查什么，再去查；发现信息有冲突，就继续核实；直到证据足够，再给出判断。

ReAct 如何工作

四、ReAct 让 Agent 更可靠的五个原因

1. 用真实观察抑制幻觉

大语言模型会基于已有模式预测下一个词，因此有时会生成貌似合理、实则错误的内容。ReAct 要求 Agent 在关键节点调用工具并读取结果。

例如，面对“今天某城市的天气如何”这类问题，可靠的 Agent 不应该凭训练记忆作答，而应先查询实时天气。这样，答案的依据从“模型印象”变成“当前观察”。

2. 把复杂任务拆成可验证的小步骤

复杂任务的难点通常不在某一个问题，而在多个子问题之间的依赖关系。

例如“整理销售数据并写一份经营周报”至少包括：

找到正确的数据文件；
理解字段含义；
清洗异常值；
计算关键指标；
识别趋势与异常；
形成面向业务的表达。

ReAct 会让 Agent 在每一步停下来检查结果。某一步出错时，错误不会一路传递到最终结论，而有机会在中途暴露和修正。

3. 让工具调用更有目的性

没有 ReAct 的工具型 Agent 容易出现两种极端：

盲目调用：反复搜索、读取大量无关信息；
过早停止：还没有足够证据，就直接给出结论。

ReAct 中的“思考”负责为下一次行动设定目标。例如：我已经拿到数据总量，但缺少按地区拆分，因此下一步应运行分组统计，而不是继续搜索。

这种目标导向使工具不再只是“可用能力的堆叠”，而成为完成任务链条中的明确环节。

4. 能够从错误中恢复

实际环境不会总是顺利：网页打不开、接口超时、权限不足、数据格式异常、代码报错都很常见。

ReAct 的价值之一，是把失败视为“观察结果”，而不是任务终点。

行动：调用数据库查询
   ↓
观察：返回“字段不存在”
   ↓
思考：可能是表结构或字段名理解错误
   ↓
行动：读取数据表 Schema
   ↓
观察：发现正确字段名
   ↓
行动：使用正确字段重新查询

一个可靠的 Agent 不应假装工具没有失败，也不应一遇错误便放弃；它应该理解错误、调整假设、选择替代路径。

5. 提升过程的可审计性

在企业场景里，“答案对不对”固然重要，“它为什么这样得出”同样重要。

ReAct 天然保留了任务轨迹：

依据了哪些数据；
调用了哪些工具；
中间遇到了什么问题；
为什么选择某种方案；
哪些结论仍然存在不确定性。

这使得用户、开发者或审计人员能够复核关键决策。对于金融、医疗、客服、研发和运营等高要求场景，这种可追溯性尤为关键。

五、ReAct 与 CoT 有什么区别？

CoT（Chain of Thought，思维链）和 ReAct 都强调分步推理，但它们解决的问题不同。

对比维度	CoT	ReAct
核心能力	展开内部推理步骤	推理与外部行动交替
是否调用工具	不一定	通常会
信息来源	主要依赖模型已有知识	结合模型知识与实时观察
适合任务	数学、逻辑、文本分析	检索、执行、多步骤工作流
对不确定信息的处理	容易受知识截止影响	可通过搜索、数据库、API 核实
错误修复	主要靠重新推理	可根据工具反馈定位和修正

可以简单地说：CoT 帮助模型“想清楚”；ReAct 帮助 Agent “想清楚以后去验证和执行”。

实际系统中，两者往往结合使用：Agent 在行动前进行必要规划，在行动后根据观察结果继续决策。

六、一个完整示例：让 Agent 完成市场调研

假设任务是：“调研三款竞品的定价、核心功能和用户评价，并输出一份建议。”

一个不采用 ReAct 的系统，可能直接根据记忆写出对比表。风险是信息过期、功能归属错误、评价样本失真。

采用 ReAct 后，流程可以这样设计：

任务：竞品调研与产品建议
   ↓
识别调研维度：定价、功能、评价、差异点
   ↓
逐个访问竞品官网：确认当前套餐与功能页
   ↓
检索可靠评价来源：收集用户反馈
   ↓
归类证据：优点、缺点、适用人群
   ↓
检查信息冲突：官网宣传与用户评价是否一致
   ↓
形成对比：识别市场空白和产品机会
   ↓
输出建议：附证据来源、时间范围与限制条件