背景与动机

大语言模型（LLM）最初以“文本到文本”的形式出现：输入一段自然语言，模型输出一段自然语言。这种方式在写作、翻译、摘要、开放式问答等任务上表现出色，但在需要精确事实、实时信息或与外部系统交互的场景中，暴露出三个结构性缺陷：知识截止、幻觉、以及无法行动。Tool Use（工具使用）正是为了弥合这些缺陷而诞生的接口层。

从纯文本生成到显式工具调用

工具调用并非一夜之间出现，它经历了四个阶段的演进：

1. 纯文本生成

早期的 LLM 只能生成字符串。如果用户问“今天北京天气如何？”，模型只能基于训练语料中的统计模式编造一个答案，既无法保证实时性，也无法验证。

2. Prompt Engineering

工程师尝试把更多事实、上下文、Few-shot 示例塞进 Prompt，让模型“背下来”。这种方法在闭域任务有效，但受限于上下文长度、知识更新成本和事实准确性，无法解决本质问题。

3. Chain-of-Thought（CoT）

CoT 让模型在最终答案前显式输出推理步骤，显著提升了数学与逻辑任务的准确性。但它仍然只是“想”，没有“做”——模型不能真正查询数据库、运行代码或调用 API。

4. ReAct（Reasoning + Acting）

ReAct 将推理过程与外部动作交替：模型输出 Thought，然后输出 Action，环境返回 Observation，模型继续 Thought。这一步把“工具”引入了循环，但 Action 通常是自由文本，需要额外的解析器，鲁棒性有限。

5. 显式 Tool Use

现代大模型直接在输出中生成结构化的工具调用描述，例如 OpenAI 的 tool_calls、Anthropic 的 tool_use 块。运行时可以精确解析参数、校验 schema、执行函数，并将结果以结构化形式喂回模型。这实现了“决策”与“执行”的清晰分离。

为什么需要 Tool Use

Tool Use 解决的核心问题可以归纳为三点：

• 知识截止：LLM 的训练数据有截止日期，无法天然掌握实时股价、天气、库存、私有文档等内容。
• 幻觉风险：当问题超出训练分布时，模型倾向于“合理编造”。工具返回的客观结果可以把生成锚定在事实之上。
• 无法行动：模型本身不能执行计算、读写数据库、发送邮件、控制设备。Tool Use 把模型的“决策能力”外化为“动作能力”。

此外，Tool Use 还带来了工程上的好处：

• 可验证性：工具调用的输入和输出都是结构化数据，便于校验、审计和回滚。
• 可组合性：多个工具可以像积木一样组合，完成更复杂的任务。
• 可扩展性：新增能力不需要重新训练模型，只需要注册新的工具定义。

学术源流

Tool Use 的工程化并非凭空出现，学术界早有相关探索：

Toolformer

Meta 在 2023 年提出的 Toolformer 展示了如何通过自监督方式，让模型学习“在何时调用何种 API、如何构造参数、如何使用返回结果”。它不依赖大量人工标注，而是从模型自身的文本生成中挖掘潜在的 API 调用位置，并用实际调用结果训练模型筛选有用调用。

Gorilla 与 APIBench

UC Berkeley 的 Gorilla 项目通过在海量 API 文档上微调模型，使其能够根据自然语言任务生成准确的 API 调用。APIBench 数据集包含大量 API 定义与调用样本，而 Gorilla 后续推出的 Berkeley Function-Calling Leaderboard（BFCL） 成为评估模型函数调用能力的重要基准。

ReAct / WebGPT / ACT-1

这些工作从不同角度验证了“模型输出动作、环境返回观察、模型再决策”的循环可行。Tool Use 可以看作是 ReAct 的工程化、结构化升级。

2024–2026：从单一调用到协议化生态

2023 年之后，Tool Use 快速从“某个模型的 API 特性”演变为“整个 Agent 生态的基础设施”，出现了四条重要线索：

CodeAct：用代码代替 JSON 作为“动作语言”

CodeAct（Wang et al., 2024）提出让模型直接编写并执行代码来完成动作——循环体内只有一个“执行代码”工具，其他能力全部以 Python 函数/库的形式被代码调用。2026 年的实证研究《The Bitter Lesson of Tool Calling》（arXiv 2608.06370）在 BFCL v4 上对比了 programmatic tool calling（PTC，写代码调工具） 与传统 JSON 原生工具调用，结论是：在 14 个受测模型中，PTC 在 11 个上持平或更优，并行扇出场景下 13 个模型持平或更优，且把顺序调用链折叠进单轮代码可将延迟降低约一半。其“苦涩教训”在于：随着模型代码能力增强，为工具调用专门设计的 JSON 协议可能不再是唯一正解——但 PTC 的收益与模型自身的代码能力正相关，弱模型上并不普适。

评测基准：BFCL 与 τ-bench 家族

• BFCL：Berkeley Function-Calling Leaderboard 从 v1 的单一函数调用，演进到 v2（多语言、多函数并行）、v3（多轮对话、长上下文、幻觉检测），再到 v4（2026 年主版本，v3 榜单已转为展示性质；v4 覆盖 simple / multiple / parallel / live / multi-turn / web-search / memory / hallucination / format-sensitivity 等类别，强调真实可执行的函数调用）。2026-10 的第三方快照显示头部模型约 0.75–0.885（如 BTL-3 约 88.5%、Qwen3.7 Max 约 75.0%，口径不一），同时小模型差距巨大（Llama-3.2-1B 仅约 10.8%）——工具调用仍是高度可训练的技能，与生产要求的可靠性仍有差距。
• τ-bench / τ²-bench（Sierra Research）：不把工具调用当孤立动作，而是评估“工具—Agent—用户”三方交互：Agent 与模拟用户对话、调用领域 API、操作数据库，按最终世界状态打分，核心指标是 pass^k（同一任务连续成功 k 次的概率，衡量可靠性而非运气）。τ²-bench（arXiv 2506.07982，2025-06）新增电信域与“双控”设定（用户侧也持有工具，建模为 Dec-POMDP），2025 下半年起又衍生出 Verified 修正版、银行知识域、全双工语音评测等变体。它揭示的一个残酷事实是：前沿模型的 pass@1 尚可，但 pass^k 与 pass@1 之间存在显著落差——一致性是当前 Agent 可靠性的主要瓶颈。

协议化：MCP 成为工具接入事实标准

2024 年 11 月 Anthropic 发布 Model Context Protocol（MCP）后，2025 年迅速成为连接模型与外部能力的开放协议事实标准：传输从 stdio 演进到 Streamable HTTP，鉴权引入 OAuth 2.1 资源服务器语义，能力上增加了工具注解（annotations）、服务端主动请求用户输入（elicitation）、结构化工具输出（structuredContent）等，2026-07 的规范 RC 进一步走向无状态化。到 2026 年，主流编码助手、Agent 框架与云平台普遍内建 MCP 客户端，“把内部能力封装成 MCP Server”成为企业落地 Tool Use 的主流路径之一；同时头部模型厂商开始把“工具检索”下沉为平台能力（OpenAI DevDay 2026 的 Agents API 内置 tool search、Anthropic 提供 tool search 工具），详见 MCP 主题。

代码执行与浏览器：两类“通用工具”的成熟

2025–2026 年，两类通用工具从 demo 走向 GA：

• 代码执行工具：Anthropic 于 2025 年推出服务端代码执行工具，2026-01 版本（code_execution_20260120）支持 REPL 状态持久化与 programmatic tool calling，成为官方推荐版本；OpenAI 的 ChatGPT Agent、Codex 也把沙箱代码执行作为标配动作空间。
• 浏览器/计算机使用工具：从 Claude Computer Use、OpenAI CUA（Computer-Using Agent，Operator 已并入 ChatGPT Agent）到开源的 browser-use，Agent 获得了“操作真实 GUI/网页”的能力。2026 年 Anthropic 推出面向视口的 browser_toolset 浏览器工具集（2026-08 GA），与完整的 Computer Use 形成分工；OpenAI 在 2026-09-29 的 DevDay 2026 上把 computer use 做成 Agents API 的托管能力（OpenAI 云端浏览器/桌面环境，公测）。评测侧，旧版 OSWorld（Verified）2026 年年中头部已越过人类基线（Claude Fable 5 约 86%，最高约 90%），但新版 OSWorld 2.0（arXiv 2606.29537，108 个长程真实任务）把各家打回 40%–78% 区间（partial 口径；binary 口径更低）——长程桌面操作可靠性仍是明显短板。详见第 6 章。

小结

Tool Use 的演进路径是：从“模型只生成文本”到“模型生成结构化动作描述，由运行时执行”，再到“代码即动作、协议化发现、大规模工具集按需检索”。它不改变模型本身的知识边界，而是把模型变成一个“调度器”：理解意图、选择工具、构造参数、消费结果。下一章将从工程角度拆解它的核心概念。