ReAct 论文解读：大模型 Agent 如何通过“推理 + 行动”完成复杂任务

ReAct 论文解读：大模型 Agent 如何通过"推理 + 行动"完成复杂任务

0. 写在前面

《ReAct: Synergizing Reasoning and Acting in Language Models》是 ICLR 2023 的一篇经典论文，也是理解大模型 Agent、工具调用、RAG 和外部环境交互时绕不开的一篇工作。

这篇论文的核心思想非常直接：大模型不应该只"想"，也不应该只"做"，而应该在解决任务时交替进行推理和行动。推理用于拆解问题、制定计划、跟踪状态、修正错误；行动用于调用外部工具、检索知识、观察环境、执行任务。两者结合后，模型可以从一次性回答升级为一个可以与外部世界交互的智能体。

如果用一句话概括 ReAct：

ReAct 让语言模型按照 Thought → Action → Observation 的循环工作，把 Chain-of-Thought 的推理能力和工具调用/环境交互能力结合起来。

这篇论文对企业级大模型应用非常有启发。今天我们做的知识库问答、智能客服、运维助手、数据分析 Agent、浏览器 Agent、代码助手，很多底层思路都能在 ReAct 中找到原型。

它不是一个复杂的模型结构创新，而是一种 Prompt 范式和 Agent 编排范式。对于工程师来说，它的价值在于告诉我们：复杂任务不能只靠一次性 Prompt，而要让模型在过程中不断思考、行动、观察和修正。

1. 论文背景和要解决的问题

大语言模型在自然语言理解、文本生成和推理任务上表现很强，尤其是 Chain-of-Thought 提示方法提出后，模型可以通过"逐步思考"解决数学推理、常识推理和符号推理问题。

但是，单纯的 CoT 有一个明显问题：它的推理过程主要依赖模型内部知识，缺少外部环境反馈。

例如，用户问一个需要实时知识或多跳检索的问题：

Apple Remote 最初设计用于控制哪个程序？除了 Apple Remote，还有什么设备可以控制这个程序？

如果模型只靠内部知识一步步推理，很可能会出现事实错误。它可以生成一个看起来很合理的推理过程，但这个推理过程未必基于真实证据。这就是大模型常见的幻觉问题。

另一方面，也有一些方法让语言模型直接生成动作，例如调用搜索工具、浏览网页、操作环境等。但如果模型只行动、不推理，也会出现问题：

不知道下一步应该搜索什么；
不能根据观察结果调整计划；
无法跟踪已经完成的子任务；
遇到失败结果时容易重复错误动作；
最终答案缺少解释和判断依据。

因此，论文要解决的问题是：

如何让语言模型同时具备推理能力和行动能力，并在任务执行过程中把二者协同起来。

这也是今天 Agent 系统的核心问题。企业级 Agent 不只是回答问题，还要查知识库、调用工具、访问数据库、读取 API、执行动作、处理失败结果。如果没有推理，Agent 只是机械调用工具；如果没有行动，Agent 只能闭门造车。

ReAct 的目标就是把这两种能力结合起来。

2. 过去方法及不足

2.1 Standard Prompting：直接回答，缺少中间过程

最基础的方法是 Standard Prompting，也就是直接把问题交给模型，让模型输出答案。

这种方式简单、低成本，但缺点也很明显：

对复杂任务不够稳定；
没有中间推理过程；
无法调用外部信息；
错了也难以定位原因；
很容易产生看似自信的错误答案。

对于简单 FAQ 问答，直接回答可能够用。但对于多跳问答、事实验证、网页操作、环境交互等任务，直接回答往往不可靠。

2.2 Chain-of-Thought：能推理，但不接地

CoT 的核心是让模型先生成推理步骤，再给出答案。例如：

text 复制代码

Question: ...
Thought: Let's think step by step...
Answer: ...

CoT 的优势是让模型显式拆解问题，提升复杂推理任务表现。但它仍然主要依赖模型参数中的内部知识。

这会带来两个问题。

第一，知识可能过时。模型训练数据无法覆盖最新事实。

第二，推理可能幻觉。模型会编造中间事实，并基于错误事实继续推理，导致错误传播。

论文在 HotpotQA 的分析中指出，CoT 的失败案例中，幻觉是主要问题之一。相比之下，ReAct 因为可以通过 Wikipedia API 获取外部观察，推理过程更加 grounded。

2.3 Act-only：能行动，但缺少计划和反思

另一类方法是让模型直接输出动作，例如：

text 复制代码

Action: Search[Apple Remote]
Observation: ...
Action: Search[Front Row]
Observation: ...
Action: Finish[answer]

这种方法可以接入外部工具，但如果没有 Thought，模型很难解释为什么选择这个动作，也很难在复杂环境中进行目标拆解。

在 ALFWorld 这类长程交互任务中，如果模型只行动，它可能会重复无效动作，或者忘记当前任务进度。比如已经检查过某个位置没有目标物品，模型仍然继续在那里尝试。

因此，Act-only 的问题是：它有外部反馈，但缺少内部规划。

2.4 ReAct 的定位

ReAct 正是为了解决上述两类方法的不足：

相比 CoT，ReAct 增加了外部行动和观察；
相比 Act-only，ReAct 增加了显式推理和计划；
相比一次性回答，ReAct 可以多轮修正；
相比纯工具调用，ReAct 的过程更可解释。

这也是 ReAct 被广泛用于 Agent 系统的原因。

3. 作者的核心思路和创新

ReAct 的核心思路是让大模型生成两类内容：

Thought：推理轨迹，用于分析当前状态、规划下一步、总结观察结果；
Action：任务动作，用于调用外部工具、搜索知识、操作环境；
Observation：环境或工具返回的结果，用于更新上下文。

整体流程如下：

text 复制代码

Question / Task
  ↓
Thought 1：分析任务，决定需要什么信息
  ↓
Action 1：调用搜索、查询、环境动作等工具
  ↓
Observation 1：获得外部反馈
  ↓
Thought 2：基于反馈继续推理
  ↓
Action 2：继续调用工具或执行动作
  ↓
Observation 2：获得新反馈
  ↓
...
  ↓
Finish：输出最终答案或完成任务

这种范式的关键点在于：推理和行动不是分开的两个阶段，而是交替出现、互相增强。

论文中的一句核心思想可以概括为：

reason to act：通过推理决定下一步行动；
act to reason：通过行动获取外部信息，反过来支持推理。

从工程视角看，ReAct 有三个创新点。

第一，它把 CoT 从"静态推理链"升级为"动态推理-行动循环"。模型不再一次性完成所有推理，而是可以根据工具返回结果逐步修正。

第二，它把工具调用和语言推理统一到同一条轨迹中。Thought、Action、Observation 都在上下文里，模型可以完整看到自己做过什么、查到了什么、下一步应该做什么。

第三，它提供了可解释的 Agent 轨迹。人可以检查模型每一步为什么这么做，工具返回了什么，错误发生在哪一步。这对企业级系统排查问题非常重要。

4. 方法结构和关键算法/公式解析

4.1 Agent 与环境交互形式化

论文将任务看作 Agent 与环境的交互过程。在时间步 t，Agent 接收来自环境的观察，并根据上下文选择动作：

at∼π(at∣ct) a_t \sim \pi(a_t|c_t) at∼π(at∣ct)

a_t：Agent 在时间步 t 选择的动作
π：Agent 的策略，可以理解为语言模型根据上下文生成动作的概率分布
c_t：时间步 t 的上下文
t：交互过程中的时间步

上下文 c_t 由历史观察和历史动作组成：

ct=(o1,a1,⋯ ,ot−1,at−1,ot) c_t = (o_1, a_1, \cdots, o_{t-1}, a_{t-1}, o_t) ct=(o1,a1,⋯,ot−1,at−1,ot)

c_t：当前上下文
o_i：第 i 步环境返回的观察结果
a_i：第 i 步 Agent 执行的动作
o_t：当前时间步的观察结果

传统 Act-only 方法中，模型只在动作空间 A 中选择动作。但 ReAct 引入了语言推理轨迹，把动作空间扩展为真实动作和语言推理的并集：

A^=A∪L \hat{A} = A \cup L A^=A∪L

\hat{A}：扩展后的动作空间
A：任务相关动作空间，例如 Search、Lookup、Finish、Go to、Take 等
L：语言空间，也就是 Thought 或 reasoning trace
∪：集合并集符号

这个公式是理解 ReAct 的关键。它说明 Thought 本身也被看作一种"动作"，只不过它不会改变外部环境，而是改变模型的内部上下文。

4.2 Thought 的作用

当模型生成 Thought 时，它不会让环境发生变化，但会更新上下文：

ct+1=(ct,a^t),a^t∈L c_{t+1} = (c_t, \hat{a}_t), \quad \hat{a}_t \in L ct+1=(ct,a^t),a^t∈L

c_{t+1}：加入 Thought 后的新上下文
c_t：当前上下文
\hat{a}_t：模型生成的语言推理轨迹
L：语言空间

Thought 的作用包括：

分解目标；
规划下一步；
总结观察结果；
跟踪任务进度；
判断是否需要搜索；
处理异常反馈；
调整后续策略。

从今天的 Agent 工程角度看，Thought 对应的就是规划、反思、状态跟踪和中间推理。

4.3 Action 的作用

当模型生成 Action 时，动作会被外部环境或工具执行，然后返回 Observation：

ot+1=Env(at) o_{t+1} = Env(a_t) ot+1=Env(at)

o_{t+1}：执行动作后得到的新观察
Env：外部环境或工具系统
a_t：模型生成的具体动作

在 HotpotQA 和 FEVER 中，Action 是 Wikipedia API 调用，例如：

text 复制代码

Search[Apple Remote]
Lookup[Front Row]
Finish[keyboard function keys]

在 ALFWorld 中，Action 是文本环境动作，例如：

text 复制代码

go to cabinet 1
open drawer 1
take peppershaker 1

在 WebShop 中，Action 是网页购物环境中的操作，例如搜索商品、点击商品、选择选项和购买。

从企业应用角度看，Action 可以对应很多工具：

搜索知识库；
查询数据库；
调用业务 API；
创建工单；
读取日志；
执行 SQL；
调用代码解释器；
查询订单状态；
发送审批请求。

4.4 ReAct Prompt 格式

一个典型 ReAct Prompt 的轨迹可以写成：

text 复制代码

Question: 用户问题

Thought 1: 我需要先理解问题，并确定需要查询什么信息。
Action 1: Search[关键词]
Observation 1: 工具返回的搜索结果。

Thought 2: 根据搜索结果，我需要进一步查询某个实体。
Action 2: Lookup[实体或字段]
Observation 2: 工具返回的详细信息。

Thought 3: 现在已经获得足够信息，可以给出答案。
Action 3: Finish[最终答案]

这套格式的优势是简单、通用、可解释。今天很多 Agent 框架中的"思考-工具调用-观察"模式，本质上都可以看作 ReAct 的工程化延伸。

5. 实验设计与主要结论

论文在四类任务上评估 ReAct：

HotpotQA：多跳问答；
FEVER：事实验证；
ALFWorld：文本交互式环境任务；
WebShop：网页购物任务。

这些任务覆盖了两类能力：

知识密集型推理：需要检索外部知识并推理；
交互式决策：需要在环境中多步行动完成目标。

5.1 HotpotQA 与 FEVER：知识密集型任务

在 HotpotQA 和 FEVER 中，模型可以调用一个简单 Wikipedia API。API 支持三类动作：

Search[entity]：搜索实体；
Lookup[string]：在页面中查找字符串；
Finish[answer]：结束任务并提交答案。

论文结果如下：

方法	HotpotQA EM	FEVER Acc
Standard	28.7	57.1
CoT	29.4	56.3
CoT-SC	33.4	60.4
Act	25.7	58.9
ReAct	27.4	60.9
CoT-SC → ReAct	34.2	64.6
ReAct → CoT-SC	35.1	62.0
Supervised SoTA	67.5	89.5

从结果看，单独 ReAct 在 HotpotQA 上略低于 CoT，但在 FEVER 上优于 CoT。更重要的是，将 CoT-SC 和 ReAct 结合后取得了更好的效果。

我的理解是：HotpotQA 有些问题依赖多跳推理，CoT 的内部推理能力比较有优势；FEVER 更依赖事实验证，外部检索更关键，因此 ReAct 更有价值。二者结合后，可以同时利用模型内部推理和外部知识检索。

论文还分析了 HotpotQA 的成功和失败模式：

类型	ReAct	CoT
成功案例中的真实正确推理	94%	86%
成功案例中的幻觉推理	6%	14%
失败案例中的推理错误	47%	16%
失败案例中的搜索结果错误	23%	-
失败案例中的幻觉	0%	56%
标签歧义	29%	28%

这个结果很关键：ReAct 并不一定在所有指标上都显著超过 CoT，但它明显降低了幻觉。因为它的推理过程受到外部检索结果约束，更容易做到事实 grounded。

5.2 ALFWorld：文本交互式环境任务

ALFWorld 是一个文本游戏环境，Agent 需要在模拟房间中完成任务，例如找到某个物品并放到指定位置。这个任务需要规划、探索、状态跟踪和常识判断。

论文结果如下：

方法	Pick	Clean	Heat	Cool	Look	Pick 2	All
Act best of 6	88	42	74	67	72	41	45
ReAct avg	65	39	83	76	55	24	57
ReAct best of 6	92	58	96	86	78	41	71
ReAct-IM best of 6	62	68	87	57	39	33	53
BUTLER best of 8	46	39	74	100	22	24	37

ReAct best of 6 的整体成功率达到 71%，明显高于 Act 的 45% 和 BUTLER 的 37%。

这个结果说明，在长程交互任务中，Thought 的价值非常明显。没有 Thought 时，模型容易忘记目标、重复错误动作，或者无法把大目标拆成小目标。加入 Thought 后，模型可以显式跟踪状态，例如"我已经找到物品了，下一步需要把它放到指定位置"。

5.3 WebShop：网页购物任务

WebShop 是一个模拟电商网页环境，Agent 需要根据用户需求搜索商品、浏览详情、选择选项并购买。该环境包含大量真实商品信息和用户指令，噪声更大，更接近真实网页交互。

论文结果如下：

方法	Score	Success Rate
Act	62.3	30.1
ReAct	66.6	40.0
IL	59.9	29.1
IL + RL	62.4	28.7
Human Expert	82.1	59.6

ReAct 的成功率达到 40.0%，比 Act 的 30.1% 明显更高，也高于 IL 和 IL+RL。论文指出，ReAct 更容易通过推理判断哪些商品和选项符合用户需求。

这对今天的网页 Agent、购物助手、自动化操作 Agent 很有启发：网页环境噪声很大，仅靠动作序列很难稳定完成任务。模型需要边看页面边推理，判断当前信息是否满足用户约束。

6. 局限性和未来研究方向

6.1 ReAct 依赖 Prompt 示例质量

论文主要采用 few-shot prompting，通过人工构造若干 Thought-Action-Observation 轨迹示例来引导模型行为。这意味着 Prompt 示例质量会直接影响模型表现。

在企业落地中，如果示例选择不好，Agent 可能学习到错误的工具使用方式或错误的推理风格。因此需要构建高质量轨迹样本，并进行持续评估。

6.2 工具和环境反馈仍然可能出错

ReAct 依赖外部观察，但外部工具并不总是可靠。搜索工具可能返回无关内容，数据库可能查不到结果，API 可能超时，网页环境可能变化。

论文中也提到，ReAct 的失败案例中存在搜索结果错误。这说明行动能力并不天然解决问题，工具质量和检索质量同样关键。

6.3 长任务容易产生上下文成本

ReAct 会把 Thought、Action、Observation 都放入上下文。任务越长，上下文越长，token 成本越高，也更容易超过上下文窗口。

企业级 Agent 需要考虑上下文压缩、状态摘要、轨迹裁剪和长期记忆，否则 ReAct 流程在复杂任务中成本会很高。

6.4 安全边界需要额外设计

论文实验中的工具环境相对安全，例如 Wikipedia API、WebShop 模拟购买环境等。但真实企业场景中，Agent 可能调用真实数据库、工单系统、邮件系统、支付系统或生产环境 API。

如果没有权限控制和人工确认，ReAct Agent 可能执行高风险动作。因此工程系统中必须加入：

工具权限控制；
参数校验；
高风险操作确认；
工具调用审计；
失败回滚机制；
用户身份绑定。

6.5 Thought 是否应该暴露给用户需要权衡

ReAct 的 Thought 对调试和可解释性有帮助，但在真实产品中，是否直接展示模型内部推理需要谨慎。企业系统通常更适合展示简洁的过程摘要，而不是完整内部推理轨迹。

例如可以展示：

已查询哪些资料；
已调用哪些工具；
当前结论依据是什么；
哪些步骤失败了。

但不一定要完整展示模型每一步自由生成的 Thought。

7. 工程落地启发

7.1 Agent 不是一次性回答，而是闭环执行系统

ReAct 最重要的工程启发是：Agent 应该是闭环系统，而不是一次性生成器。

一个企业级 Agent 至少应包含：

任务理解；
计划生成；
工具选择；
工具调用；
观察结果解析；
状态更新；
异常处理；
最终回答。

这比普通 RAG 问答复杂得多。RAG 主要解决"查资料回答问题"，而 Agent 还要解决"根据目标执行一系列动作"。

7.2 工具调用必须和推理结合

很多系统把工具调用做成简单的 Function Calling：模型判断调用哪个函数，然后执行。但如果没有显式推理，工具选择可能不稳定。

ReAct 提醒我们，工具调用前应该有任务分析，工具调用后应该有观察总结。工程上可以设计成：

text 复制代码

分析用户目标
  ↓
判断是否需要工具
  ↓
选择工具
  ↓
构造参数
  ↓
执行工具
  ↓
解析返回结果
  ↓
判断是否继续

这就是 ReAct 思想在工程系统中的落地形态。

7.3 RAG 可以看作 ReAct 的一种特例

从某种角度看，RAG 是 ReAct 的一个简化版本。

普通 RAG 流程是：

text 复制代码

Question → Retrieve → Generate

ReAct 风格的 RAG 可以变成：

text 复制代码

Thought：我需要查询哪些信息
Action：检索知识库
Observation：返回文档片段
Thought：判断证据是否足够
Action：继续检索或生成答案

这对复杂知识库问答非常有价值。例如用户问一个跨多个制度的问题，单次检索可能不够，Agent 可以先检索 A，再根据结果检索 B，最后综合回答。

7.4 Prompt 要设计成轨迹，而不是一句指令

ReAct 的 Prompt 不是一句"请一步步思考"，而是一组完整的示例轨迹。企业落地时，Prompt 示例应该覆盖真实业务流程。

例如运维 Agent 的示例可以包括：

text 复制代码

Thought: 用户反馈接口超时，我需要先查询服务状态。
Action: query_service_status[service_name]
Observation: 服务状态正常。

Thought: 服务正常，下一步需要查看最近错误日志。
Action: search_logs[service_name, error]
Observation: 发现数据库连接超时。

Thought: 根据日志，问题可能来自数据库连接池耗尽，需要查询连接池指标。
Action: query_metrics[db_pool]
Observation: 连接池使用率 98%。

Thought: 可以给出初步结论和处理建议。
Action: Finish[...]

这样的轨迹比单纯写"你是运维助手"有效得多。

7.5 需要建立 Agent 评估体系

ReAct 类 Agent 不能只评估最终答案，还要评估过程。

建议指标包括：

评估维度	说明
工具选择准确率	是否调用了正确工具
参数正确率	工具参数是否完整、合法
观察利用率	是否正确使用工具返回结果
任务完成率	是否完成用户目标
轨迹合理性	Thought-Action 是否逻辑一致
幻觉率	是否编造工具结果或事实
安全合规率	是否避免越权和高风险操作
成本指标	平均调用次数、平均 token、平均延迟

没有过程评估，Agent 出错时很难定位是推理错、工具错、检索错，还是最终生成错。

8. 个人理解与总结

我认为 ReAct 这篇论文最值得学习的地方，不是它提出了复杂的新模型，而是它重新定义了大模型的使用方式。

在 ReAct 之前，很多人把大模型看作问答模型：输入问题，输出答案。ReAct 之后，大模型开始更像一个 Agent 控制器：它可以思考、调用工具、读取反馈、更新计划，并最终完成任务。

这对企业级大模型应用非常重要。

企业场景里的问题往往不是一句话能回答的。比如：

"帮我分析这个接口最近为什么变慢"；
"根据知识库判断这个客户问题应该怎么处理"；
"帮我查一下订单异常原因并生成处理建议"；
"根据日志、指标和告警判断故障根因"；
"阅读多份文档后给出合规结论"。

这些任务都需要多步操作。模型必须知道什么时候该思考，什么时候该查资料，什么时候该调用工具，什么时候该停止。

ReAct 给我们的核心启发是：

大模型应用的重点，不只是让模型生成答案，而是设计一个可观察、可控制、可评估的推理-行动循环。

从工程落地角度，我会把 ReAct 总结成四点：

第一，推理和行动要结合。只推理会幻觉，只行动会盲目，二者结合才适合复杂任务。

第二，工具调用要有上下文。工具不是简单函数，调用前要有目的，调用后要有解释。

第三，轨迹比结果更重要。企业系统需要知道模型为什么这么做，错在了哪一步。

第四，安全和评估必须前置。Agent 一旦能调用真实工具，就必须有权限、审计、确认和回滚机制。

如果把 ReAct 用到今天的企业级 RAG 和 Agent 系统中，我建议采用这样的架构：

text 复制代码

用户任务
  ↓
意图识别
  ↓
任务规划
  ↓
Thought：分析当前目标
  ↓
Action：调用检索、数据库、API、工具
  ↓
Observation：读取工具返回
  ↓
状态更新和异常处理
  ↓
必要时继续 Thought-Action-Observation
  ↓
生成最终答案
  ↓
来源引用、权限校验、风险控制

这就是从"聊天机器人"走向"企业级智能体"的关键一步。

总结来说，ReAct 是一篇非常适合大模型应用开发者反复阅读的论文。它的价值不在于某个具体实验分数，而在于提出了一种通用的 Agent 工作范式：让模型在推理和行动之间循环，通过外部反馈不断修正自己的判断。

今天我们做 RAG、Agent、工具调用、智能客服、运维助手、数据分析助手时，本质上都在实践 ReAct 的思想。真正难的不是让模型"想一步"，而是让模型在真实业务系统中"想清楚、查得到、做得对、可追溯、可控制"。