工具使用 — 给概率机器接上「一定对」的能力
这一章讲三件事: 模型「用工具」时到底发生了什么(一组特殊 token 的往返, 没有魔法);训练一个会用工具的模型要动哪些格式与掩码;MCP(Model Context Protocol;协议,即双方对话要守的规矩,这套规矩说的是「模型与上下文」)这个标准解决的是 生态问题而不是模型问题。读完你能把「模型查一次天气」拆到 token 级。
1. 这一章讲什么
「今天谁是总统?」——这个孩子都会的问题能难死一个不联网的语言模型:它的知识 停在预训练数据的截止日(不再更新)。工具是出路,而且不止补时效:代码执行让一个 本质上「按概率吐字」的机器能给出精确答案。书里给的工具使用定位:它是语言模型 能力版图的自然扩张,而 RLHF 与本书所有方法都能用来打磨这项技能1。
2. 顶层全景与主走查
主走查:书里的原例。问模型「第 50 个斐波那契数是多少?」(约定 F_0=0, F_1=1)2:
模型生成的 thinking:好的,我用一个简单循环算第 50 项,然后返回结果。
<code> ← 模型吐出「执行我」标记
def fib(n):
a, b = 0, 1
for _ in range(n):
a, b = b, a + b
return a
fib(50)
</code>
<output>12586269025</output> ← 外部解释器真跑出来的结果,塞回上下文
模型接着回答:第 50 个斐波那契数是 12 586 269 025。
图说:整个过程是「生成→暂停→外部执行→结果入上下文→继续生成」的循环。
没有任何一步在模型内部:数字不是「算」出来的,是「抄」进来的——
这正是精确性的来源。(书里还给了 50 位圆周率的同类例子:代码算,
不背书。)
串起这一循环的伪代码,书里给了形状:循环调用模型,响应里有工具调用就执行、 把结果以 tool 角色追加进消息列表,直到响应里不再有调用,返回文本3。
三个术语先分清(书里的原始区分)4:
| 术语 | 含义 |
|---|---|
| 工具使用 | 模型发结构化请求(工具名+参数)→ 外部执行 → 结果进上下文 → 继续生成 |
| 函数调用(发出结构化的调用指令) | 其参数必须符合预先声明的 schema(即事先写好的格式规范),因此可解析可校验 |
| 代码执行 | 特例:工具是一台代码解释器(如 Python) |
3. 核心原理
3.1 对模型来说,工具就是「带格式的文本」
数据格式上,工具与第 03 章的对话模板一脉相承:system 段里塞进可用工具的清单
(名字、描述、参数的格式规范),模型在回答位置生成形如
search_movies("Star Wars") 的调用,被特殊 token 包住;工具输出作为下一段
token 插进序列5。「会调工具」不是新增了什么模块,是模型学会了在恰当的
位置吐出约定的标记——所以它才能被 SFT 教出来。
3.2 训练的格式与掩码决定成败
书里列的实现决定,两条最要命6:
- 工具输出的 token 必须从训练损失里掩掉——和第 03 章 mask 掉 prompt 同理: 输出是外部系统生成的,不是模型该学预测的东西;
- 一条 assistant 轮内按工具调用切分:工具调用把模型的发言切成几小段, 数据格式要按段组织(书里给了 function_calls 字段——即数据里一格——的样例)。
其余的都属于「各家不一、注意对齐」:Python 还是 JSON 的调用格式;推理 token
跨工具步保留还是清掉(清掉省服务成本,保留利于连续推理——设计决定,无定论);
三家 API(模型厂商对外的编程接口)的格式分歧(OpenAI 的 tool_calls 数组、Anthropic 的 input_schema 加
<thinking>、Gemini 的 AUTO/ANY/NONE 模式);生产系统用受限解码保 JSON
合法、省掉重试7。
3.3 从一次调用到多步智能体
单次调用之上是多步工具推理:ReAct(2022)展示了推理与行动交错生成—— 「想一步、做一步、看结果、再想」,推理帮助更新计划、行动带回信息8。到 OpenAI 的 o3,多步工具使用成了旗舰能力。这也解释了为什么第 07 章的推理模型 与工具天然合流:两者都是「在回答之前多做很多步」,也都在把生成拖长成瓶颈。
3.4 MCP:生态的标准接口语
MCP(Model Context Protocol)解决的不是「模型怎么调工具」,而是「N 个模型 × M 个数据源」的集成爆炸:它把两边都标准化成 server/client/host 三层——server 包一个数据源或能力,client 聚合多个 server,host(如 Claude 桌面端、IDE 插件) 提供界面。
底层用 JSON-RPC(一种一问一答的远程调用消息格式,版本 2.0)。
server 对模型暴露的功能,行话叫原语(协议里最基本的功能单位),有三类:resources(只读数据)、prompts(模板)、tools(可调用函数)9。有了它,模型厂商和工具作者各自对着同一个
标准开发,不用两两适配。书里给了最小 server 代码:get_weather 工具,一个
装饰器声明 schema,一个函数执行查询10。
3.5 工具能力是怎么训出来的
书里把训练栈接回全书主线11:
人工写工具轨迹:太贵 → 主流靠合成(Toolformer 式自标注、ToolBench 式批量生成)
第 1 段 SFT 教基础:调用格式、参数填法、什么时候该调 —— 通常这就够起步
第 2 段 偏好优化(DPO 等):教「该调工具还是直接答」的判断
第 3 段 RL + 环境反馈:多步任务的成败本身当奖励 —— 任务真解决 了才给分
图说:三段正好是本书 03 → 08 → 06 章的顺序。
工具使用不是独立技术,是全书方法的又一次应用。
评测也自带坑:函数调用有专门的排行榜(BFCL);还有个反直觉的指标 pass^k(读作 pass 的 k 次方):同一任务跑 k 次全成功的比率——区别于 pass@k(跑 k 次至少一次成功)。前者量「可靠」,后者量「碰得上」;agent 产品的 差距往往全在前者12。
4. 作者的判断与证据
书里有证据的部分:ToolFormer(计算器/双搜索引擎/翻译/日历)、Gorilla(1645 个 API 及其 APIBench→BFCL 谱系)、ToolLLM(16000+ API)的时间线全部有出处;MCP 的描述与官方文档一致。书里给判断的部分:作者把「产品问题先到后训练层试、成了 再回流早期训练」的循环(第 16 章展开)与工具绑定——工具是新能力最快上车的地方13。
判断(我们的,不是书里的): 这一章真正的分水岭是「代码执行」:搜索只是 补知识,代码执行补的是可靠性——它让模型第一次能对自己输出的行为负责 (跑了就知道对错)。RLVR(第 07 章)里代码域的验证函数、agentic RL 的环境 反馈,吃的都是这份红利。工具与推理在 2025 年合流,接口层的原因就在这。 如果错,会错在: 如果「精确答案」更多来自受限解码与采样策略的改进而非 执行反馈,那代码执行的特殊地位就被高估了——但单元测试作为奖励的实效 目前不支持这个反例。
5. 边界与局限
- 评测偏单轮:BFCL/ToolBench 主要量调用正确性,长程多步任务的成功率与 稳定性仍是开放问题(书里引 pass^k 正是为此);
- 工具输出吃上下文:搜索类工具动辄返回海量结果,截断、摘要,或一页页给(行话叫分页)的策略,书里 只列为待解的工程题14;
- 各家格式不统一:同一份工具清单,跨三家 API 要写三套适配;MCP 缓解但 没有消灭这个碎片化。
6. 可带走的
- 工具调用 = 带格式的文本往返,没有新模块;会调工具 = 会吐约定标记;
- 训练时工具输出必须 mask;一条轮内按调用切段;
- 代码执行补的不是知识,是确定性——50 位 圆周率用算的,不用背的;
- 多步工具 = ReAct 的「想一步做一步」,与推理模型天然合流;
- MCP 管「N 模型 × M 数据源」的集成:server/client/host 三层 + JSON-RPC;
- 训练栈:SFT 教格式 → DPO 教「何时调」→ RL 用任务成败教「怎么调到底」;
- pass^k 量可靠,pass@k 量碰上——agent 产品看前者;
- 新功能先在 post-training 层试装,这是工具能力上车最快的车道。
7. 原文地图
| 主题 | 原书章 | 原文位置 |
|---|---|---|
| 工具的动机(总统问题) | 13 Tool Use & Function Calling | text/32-ch13-13-tool-use-amp-function-calling.txt:48(搜「knowledge cutoff」) |
| 三术语区分 | 13 Tool Use & Function Calling | text/32-ch13-13-tool-use-amp-function-calling.txt:60(搜「structured request」) · text/32-ch13-13-tool-use-amp-function-calling.txt:66(搜「code interpreter」) |
| 50 位圆周率 | 13 Tool Use & Function Calling | text/32-ch13-13-tool-use-amp-function-calling.txt:98(搜「3.14159265358979323846264338327950288419716939937510」) |
| 历史:ToolFormer 到 MCP | 13 Tool Use & Function Calling | text/32-ch13-13-tool-use-amp-function-calling.txt:117(搜「ToolFormer」) · text/32-ch13-13-tool-use-amp-function-calling.txt:117(搜「1645」) · text/32-ch13-13-tool-use-amp-function-calling.txt:123(搜「Model Context Protocol」) |
| pass^k 与 BFCL | 13 Tool Use & Function Calling | text/32-ch13-13-tool-use-amp-function-calling.txt:129(搜「pass^k」) |
| 数据格式与调用 | 13 Tool Use & Function Calling | text/32-ch13-13-tool-use-amp-function-calling.txt:149(搜「function signatures」) · text/32-ch13-13-tool-use-amp-function-calling.txt:155(搜「search_movies」) |
| fib(50) 主走查 | 13 Tool Use & Function Calling | text/32-ch13-13-tool-use-amp-function-calling.txt:246(搜「def fib(n)」) · text/32-ch13-13-tool-use-amp-function-calling.txt:256(搜「12586269025」) |
| 编排循环 | 13 Tool Use & Function Calling | text/32-ch13-13-tool-use-amp-function-calling.txt:279(搜「while True」) |
| ReAct 与 o3 | 13 Tool Use & Function Calling | text/32-ch13-13-tool-use-amp-function-calling.txt:310(搜「reasoning traces and task-specific actions」) |
| MCP 架构与原语 | 13 Tool Use & Function Calling | text/32-ch13-13-tool-use-amp-function-calling.txt:328(搜「JSON-RPC 2.0」) · text/32-ch13-13-tool-use-amp-function-calling.txt:334(搜「resources」) · text/32-ch13-13-tool-use-amp-function-calling.txt:346(搜「Hosts」) |
| MCP server 代码 | 13 Tool Use & Function Calling | text/32-ch13-13-tool-use-amp-function-calling.txt:393(搜「weather-server」) |
| 实现决定(掩码等) | 13 Tool Use & Function Calling | text/32-ch13-13-tool-use-amp-function-calling.txt:432(搜「masked from the model」) · text/32-ch13-13-tool-use-amp-function-calling.txt:469(搜「erased between turns」) · text/32-ch13-13-tool-use-amp-function-calling.txt:475(搜「constrained decoding」) |
| 训练栈 | 13 Tool Use & Function Calling | text/32-ch13-13-tool-use-amp-function-calling.txt:483(搜「Toolformer-style」) · text/32-ch13-13-tool-use-amp-function-calling.txt:483(搜「environment feedback」) |