AI 底层逻辑 / 经典论文

ReAct / Toolformer：Agent 工具调用基础

ReAct 和 Toolformer 共同回答了语言模型从“生成文本”走向“执行任务”时的两个底层问题：运行时如何在推理、行动和观察之间形成闭环，训练时如何让模型学会何时调用外部工具。ReAct 把 reasoning、acting、observation 交错成可推进任务的轨迹；Toolformer 则展示模型可以用少量 API 示例和自监督筛选学习工具调用模式。

312 行ai-foundations/papers/03-react-toolformer-agent-foundations.md

ReAct / Toolformer：Agent 工具调用的两条底层线索

本篇为经典论文精读（历史回顾/经典打底定位），机制正文以原论文为锚点；最新进展见文末「SOTA 检查」。

Source Anchors

ReAct: https://arxiv.org/abs/2210.03629 （2022-10）
Toolformer: https://arxiv.org/abs/2302.04761 （2023-02）

核心导读

它们的系统价值不在于构成完整 Agent 架构，而在于把能力、状态和外部环境连接起来。真实系统必须在这条基础循环外补上身份、权限、工具网关、状态管理、终止条件、审计、评估和人工接管，否则“会调用工具”很容易被误解成“可以负责行动”。

1. 这组论文在解决什么问题

普通语言模型的基本能力是根据上下文生成下一个 token。这个能力足以支撑摘要、改写、问答草稿和分类，但它不是完整任务执行。

真实业务任务有外部状态：账户余额、交易状态、工单进度、政策版本、客户权限、库存、审批节点。真实任务也有外部动作：查询、计算、创建工单、发通知、冻结账户、提交报告、升级人工。

如果模型只生成文本，它最多是建议系统。要成为 Agent，它必须能在目标、状态、动作和反馈之间循环：

目标 -> 判断当前状态 -> 选择动作 -> 调用工具 -> 观察结果 -> 更新判断 -> 停止或继续

ReAct 和 Toolformer 分别切入这个转变的两端。

ReAct 关注运行时：模型如何把 reasoning、acting、observation 交错起来，在外部环境反馈中推进任务。

Toolformer 关注能力习得：模型如何通过少量示例和自监督筛选，学会什么时候调用什么 API、传什么参数、如何吸收返回结果。

它们不是完整企业 Agent 架构，但提供了今天 Agent 系统的两个底层问题：

运行循环如何组织？
工具调用能力如何形成？

2. 核心贡献

ReAct 证明，把语言化推理轨迹和环境动作交错生成，可以让模型在知识任务和交互式决策任务上更好地跟踪计划、处理异常、利用外部观察。

Toolformer 证明，语言模型可以在少量 API 示例的引导下，自己生成候选工具调用，并通过“调用结果是否改善后续 token 预测”筛选训练数据，从而学会使用工具。

今天的 Agent 不是直接复制这两篇论文，而是在它们之上补上状态管理、权限、工具网关、工作流、审计、评估和人工审批。

3. ReAct 之前的问题：推理和行动被分开研究

在 ReAct 之前，常见做法有两类。

一类是 chain-of-thought。模型先写出中间推理，再给答案。它能改善部分推理任务，但如果模型的内部知识错了，推理链会把错误一步步放大。

另一类是 action generation。模型直接输出动作，例如在网页或文本环境里下一步点击哪里、搜索什么、购买什么。它能和环境互动，但缺少显式思考时，容易重复错误动作，也不容易解释为什么这么做。

这两类都不够。只推理，没有外部观察，容易幻觉；只行动，没有推理轨迹，容易迷路。

ReAct 的核心问题是：

能不能让模型边想边做，并让每次外部观察反过来修正下一步？

4. ReAct 机制：Thought / Action / Observation

ReAct 的基本轨迹很简单：

Thought: 我需要确认一个事实或决定下一步。
Action: 调用搜索、查找、环境动作或其他工具。
Observation: 工具或环境返回结果。
Thought: 根据观察更新计划。
Action: 继续行动或结束。

关键不是把“思考过程”展示得更像人，而是把 reasoning 和 acting 变成一个闭环。

Reasoning 的作用是：

记录当前目标。
跟踪已经尝试过的动作。
解释为什么需要下一步。
在观察不符合预期时调整计划。
决定什么时候停止。

Action 的作用是：

查询外部知识。
获取当前环境状态。
执行任务步骤。
把模型从参数记忆拉回现实反馈。

Observation 的作用是：

给模型新证据。
暴露错误假设。
让计划可以被更新。

如果没有 Observation，模型可能一路自信地编下去。如果没有 Thought，模型可能像黑箱策略一样不断尝试动作，难以复盘和控制。

5. ReAct 为什么有效

5.1 降低纯 CoT 的幻觉传播

Chain-of-thought 的风险是“错得有条理”。模型一旦在早期步骤编出错误事实，后续推理会围绕这个错误继续展开。

ReAct 通过 action 查询外部知识或环境状态，让模型有机会把错误前提拉回来。例如在 HotpotQA、FEVER 这类知识任务中，模型可以通过 Wikipedia API 查证，而不是只靠内部记忆回答。

5.2 让行动有可解释的中间状态

在交互式任务里，模型不只是输出最终答案，而是产生一条任务轨迹。轨迹中包含它为什么搜索、为什么点击、为什么换策略。

这对调试和信任很重要。失败时可以看出它是目标理解错、工具选错、观察误读，还是停止条件错。

5.3 让异常处理成为循环的一部分

现实任务经常出现工具失败、信息缺失、页面变化、规则冲突。ReAct 允许模型在观察到异常后重新规划，而不是沿着一次性计划硬走到底。

这也是 Agent 与普通 workflow 的差异：固定流程擅长稳定路径，Agent 的价值在于处理语言密集、信息不完整、需要局部判断的节点。

6. Toolformer 之前的问题：工具调用不能只靠人工规则

ReAct 解释了运行时循环，但没有回答另一个问题：模型如何学会工具调用本身？

如果每个工具调用都靠人工写规则，系统会很脆。真实语言里，同一个工具需求有无数表达方式。比如“下周三是几号”“三天后截止吗”“付款日顺延到哪天”，都可能需要 calendar 或 date 工具。

Toolformer 的核心问题是：

能不能让模型自己从普通文本中学会何时调用工具，而不需要人类逐条标注？

7. Toolformer 机制：少量示例 + 自监督筛选

Toolformer 的训练思路可以拆成六步。

为每个 API 提供少量人工示例，让模型知道工具调用文本长什么样。
在普通语料中让模型生成可能插入 API 调用的位置和参数。
执行这些候选 API 调用，得到返回结果。
把 API 调用和结果插回文本。
比较插入调用前后，模型预测后续 token 的 loss 是否下降。
只保留能明显帮助预测的调用样本，用它们继续训练模型。

这一步的关键是筛选标准。模型不是因为“人告诉它这里应该调工具”才学习，而是因为工具返回让后续文本更容易预测。

例如：

The result of 24 * 17 is [Calculator(24 * 17) -> 408] 408.

如果有计算器结果后，模型更容易预测正确数字，这个工具调用就有训练价值。

Toolformer 使用的工具包括计算器、问答系统、搜索、翻译和日历。这些工具大多是低风险、文本输入输出清晰的工具。

8. Toolformer 为什么有效

8.1 把工具使用变成语言建模的一部分

Toolformer 没有把工具调用当成外部 hard-coded planner，而是把 API 调用格式放进文本序列里。模型学习的仍然是语言建模，但文本里多了“可执行片段”。

这让工具调用变成模型可以预测的 token 序列：什么时候写 API 名、传什么参数、如何把返回值接入后续回答。

8.2 用 loss 过滤伪工具调用

模型可能在很多地方胡乱插 API。Toolformer 的筛选机制只保留“调用结果确实有助于预测”的样本。

这相当于给工具调用建立了一个弱监督信号：不是调用越多越好，而是调用后是否让任务文本更可预测。

8.3 保留语言能力

论文关心的不只是工具任务表现，还关心模型是否因为学习工具调用而损害原本语言建模能力。Toolformer 的结果说明，工具增强可以改善多个下游任务，同时基本保留核心语言能力。

9. 论文证据链

论文	核心问题	方法	证据	结论
ReAct	reasoning 与 acting 分离导致幻觉或行动不可控	交错生成 Thought、Action、Observation	HotpotQA、FEVER、ALFWorld、WebShop	交错推理和行动能改善知识任务与交互任务表现，并提升轨迹可解释性
ReAct	纯 CoT 容易错误传播	通过 Wikipedia API 等动作获取外部观察	QA / fact verification 对比	外部观察能缓解只靠内部推理的幻觉
ReAct	交互式任务需要计划更新	环境动作后观察，再继续推理	ALFWorld、WebShop	ReAct 在部分交互 benchmark 上显著提升成功率
Toolformer	工具调用不能依赖逐条人工标注	少量示例生成候选 API 调用，用 loss 改善筛选	多工具、多下游任务实验	模型可以自监督学习何时调用工具
Toolformer	工具增强是否破坏语言能力	将 API 调用样本加入训练	下游任务与语言能力对比	工具调用能力提升，同时基本保留原有语言建模能力

ReAct 论文报告，在 ALFWorld 和 WebShop 上相对若干 imitation / reinforcement learning 基线分别有 34% 和 10% 的绝对成功率提升。Toolformer 论文报告，它在多类下游任务上提升 zero-shot 表现，且不牺牲核心语言建模能力。

10. 两篇论文没有解决什么

它们没有解决企业权限。论文里的搜索、计算、问答、日历等工具和银行核心系统完全不是一个风险等级。能调用工具，不等于有权调用工具。

它们没有解决高风险动作审批。论文没有处理退款、冻结账户、提交监管报告、修改授信额度这类不可逆动作。

它们没有解决工具返回可信度。工具可能过期、错误、权限不足、部分失败、返回格式变化。Agent 不能把所有 Observation 都当真理。

它们没有解决 prompt injection。Agent 一旦读取网页、邮件、PDF、客户上传文件，就可能把不可信内容误当成指令。

它们没有解决审计。ReAct 轨迹看起来可解释，但自然语言轨迹不等于可审计证据链。企业审计需要工具日志、参数、返回、权限判断、版本和最终状态。

它们没有解决停止条件。Agent 可能循环搜索、重复调用、不断改计划。生产系统必须有步数、时间、成本、风险和人工接管阈值。

11. 今天的 Agent 架构如何继承它们

现代企业 Agent 可以把 ReAct 和 Toolformer 分别放到两个位置。

ReAct 影响 Agent runtime：

goal
-> state
-> reasoning step
-> action proposal
-> tool call
-> observation
-> state update
-> stop / continue / escalate

Toolformer 影响 tool-use capability：

tool schema
-> few examples
-> model learns invocation pattern
-> tool result enters context
-> model incorporates result

但企业系统还必须补充五个控制层。

第一是 tool gateway。模型不能直接访问内部 API。所有工具调用都要经过 schema 校验、权限检查、脱敏、速率限制、超时、重试、审计和熔断。

第二是 policy engine。它决定某个用户、某个任务、某个上下文下是否允许某个动作。

第三是 workflow engine。稳定、可预测、合规要求强的流程不应完全交给模型自由发挥。模型应负责语言、判断和不确定节点。

第四是 eval。Agent eval 不只看回答是否正确，还要看工具选择、动作权限、状态更新、停止条件、成本、延迟、异常恢复和人工接管。

第五是 audit trail。审计记录要能回放任务从输入到最终状态的全过程。

12. 一个金融零售例子：支付失败排查 Agent

用户问题：一笔客户付款失败，运营人员希望 5 分钟内知道失败原因和下一步处理建议。

ReAct 式循环可以这样设计：

Thought: 先确认交易当前状态和失败码。
Action: TransactionStatus(transaction_id)
Observation: failed, return_code=R03, timestamp=...
Thought: 需要解释 R03 并检查是否可重试。
Action: ReturnCodePolicy(code=R03, rail=ACH)
Observation: account not found; do not retry until account details are corrected.
Thought: 需要确认客户资料是否近期变更。
Action: CustomerProfileChange(customer_id, window=30d)
Observation: bank account updated 2 days ago.
Finish: 失败原因、证据、下一步、是否需要人工处理。

Toolformer 的启发在于：模型要学会在“失败码解释”“日期窗口”“金额计算”“客户资料查询”这些节点调用工具，而不是凭语言记忆回答。

但系统边界必须清楚：

查询交易是只读工具，可以自动调用。
通知客户可能需要模板和审批。
修改账户信息必须由授权人员完成。
重发付款可能涉及资金风险，需要 policy gate。
所有工具调用要记录 transaction id、用户、时间、参数摘要和返回摘要。

这个例子说明：Agent 的价值是把信息收集、解释和建议串成任务轨迹；真正的风险控制来自工具网关、策略和工作流。

13. 常见误解

误解一：Agent 等于 ChatGPT 加几个工具。纠正：Agent 是目标、状态、动作、观察、记忆、停止条件和权限控制组成的行动系统。

误解二：ReAct 的核心是展示思考过程。纠正：核心是 reasoning 与 external observation 的闭环。展示只是副产品。

误解三：Toolformer 说明模型能自动学会所有企业工具。纠正：论文工具多是低风险文本 API。企业工具需要 schema、权限、审计、审批和错误语义。

误解四：多 Agent 一定比单 Agent 高级。纠正：多 Agent 会增加状态一致性、责任归属、调试和成本问题。只有分工收益明确时才值得做。

误解五：Agent 失败主要是模型不够强。纠正：失败可能来自工具设计、过期观察、权限错误、状态管理、评估不足、循环控制或流程边界不清。

14. 读完后应该能回答

ReAct 与普通 chain-of-thought 的本质差异是什么？
Thought、Action、Observation 分别解决什么问题？
ReAct 为什么能降低纯内部推理的幻觉传播？
Toolformer 如何用少量示例和 loss 筛选学习 API 调用？
为什么工具调用能力不等于企业 Agent 可上线？
Agent runtime、tool gateway、policy engine、workflow engine 分别负责什么？
金融场景里哪些动作必须 human approval？
Agent eval 为什么不能只看最终回答？

15. 后续阅读

ReAct project: https://react-lm.github.io/ （访问日期: 2026-07-01）
Toolformer: https://arxiv.org/abs/2302.04761 （2023-02）
WebGPT: https://arxiv.org/abs/2112.09332 （2021-12）
MRKL Systems: https://arxiv.org/abs/2205.00445 （2022-05）
Gorilla: https://arxiv.org/abs/2305.15334 （2023-05）
SWE-bench: https://arxiv.org/abs/2310.06770 （2023-10）

SOTA 检查 (2026-07-01)

工具接入的现役标准是 MCP，不再是各家自定义的 function-calling 胶水层。Model Context Protocol 于 2024-11 由 Anthropic 开源，已发布 2025-06-18 与 2025-11-25 两个正式规范修订版（后者为一周年版本）；2026 年的工程共识是"新工具集成应构建 MCP server，而非 bespoke function-calling shim"。本篇第 11 节的 tool gateway / tool schema 思想正是 MCP tools 能力的前身。深挖见库内 docs/llm/day129-mcp-deep-dive.md。
Toolformer 的"自监督插入 API 调用再训练"作为训练配方已被取代：2024-2025 起前沿模型（OpenAI、Anthropic 的旗舰模型系列）在后训练阶段原生内置 tool calling / structured output 能力，开发者提供 JSON schema 即可，无需 Toolformer 式的语料改写流水线。但 Toolformer 的核心判断——"何时调用工具应由模型自己学会，而非人工规则"——已成为所有原生 function calling 的默认前提。对照 docs/llm/day128-tool-use-function-calling.md。
ReAct 循环仍是 2026 年 agent runtime 的骨架，但形态已演进：一是 reasoning 从 prompt 里显式写 "Thought:" 变成模型内部的 extended thinking / test-time compute；二是业界把 agent 明确定义为"有目标、工具清单、记忆、预算和评估的有界循环"（bounded loop），而非裸 ReAct prompt——这正好对应本篇第 10 节指出的停止条件/审计缺口被工程化补齐。对照 docs/llm/day126-react-cot-tot.md。
工具调用能力已有专门基准：BFCL v4 衡量函数选择与参数正确性；MCP 场景有 MCPToolBench++（arXiv 2508.07575，2025-08）与 MCPMark（arXiv 2509.24002，2025-09）等压测基准——印证本篇第 11 节"eval 要看工具选择而不只看最终回答"的主张。
框架层注意时效：AutoGen / Semantic Kernel 已进入维护模式，微软官方继任者为 Microsoft Agent Framework 1.0（2026-04 GA）；现役主流还包括 Claude Agent SDK（MCP 集成最深）、LangGraph、CrewAI 等。引用 agent 框架时勿再以 AutoGen 教程为主线。
不随版本过时的框架性结论：第 10 节（论文未解决权限/审批/注入/审计/停止条件）与第 11 节的五个控制层（tool gateway / policy engine / workflow engine / eval / audit trail）是架构不变量——模型和协议换代，这些企业侧控制层只会更重要。工程落地对照 docs/aipa/day100-tool-registry.md、docs/aipa/day103-policy-engine.md、docs/aipa/day102-call-audit.md。