斯坦福大学「Engineering AI Agents」课程第4讲：从 Toolformer 到 MCP，LLM 如何学会调用工具？
文章目录
斯坦福 CS329Z《Engineering AI Agents》Lecture 4：Tool Use
主讲：Diyi Yang 老师，本讲是课程从 RAG 迈向 Agent 的关键一课，核心线索是：LLM 的能力边界决定了它必须借助外部工具，而工程上的挑战在于如何让模型学会调用工具、如何用标准接口暴露工具、以及如何评估工具使用的好坏。
RAG 收尾：为什么检索增强并不够
课件先用一页精炼的框架总结 RAG 的三类问题（这个框架本身就值得记住）：
| 环节 | 问题 | 本质 |
|---|---|---|
| 检索侧 | 召回率上限、索引过期、权限泄露 | 缺证据时 Agent 无能为力 |
| 阅读侧 | "Lost in the middle"、位置偏差、相似但无关内容干扰、证据冲突 | 模型无法充分利用上下文 |
| 循环侧 | 误差复合、无停止规则、提示注入 | 早期错误影响后续决策 |
三个关键实证：
1.文档不是越多越好。引用 Liu et al. 2023 的经典结论：GPT-3.5 闭卷约 56%，只喂相关文档（oracle）可达约 88.5%，差距就是 RAG 的理论空间；但实际中，检索器召回率缓慢爬升到 90%，而 RAG 性能在 10–20 个文档后就迅速饱和，因为模型存在位置偏差，中间位置的信息利用率低（即 "lost in the middle"）。
2.引用本身也会幻觉。RAG 的独特卖点是可溯源引用，但引用是 LLM 生成的，所以也可能被编造。实测发现：人类评分者觉得输出"易读、有用"（1–5 分主观分很高），但引用的精确率和召回率都很低，这是一个重要的警示：主观可用性 ≠ 事实正确性。
3.大海捞针测试（needle-in-a-haystack）作为长上下文利用率的直观检验。
这一节的潜台词：RAG 解决"知识注入"，但解决不了"计算、实时状态、精确操作"，自然引出工具。
为什么需要工具：LLM 的三类边界
课件给出一个漂亮的分类，直接对应解决方案：
| 边界类型 | 具体内容 | 工具化方案 |
|---|---|---|
| 算不了的 | 大数运算、多步逻辑推演、精确可验证操作 | 计算器、代码解释器、符号求解器 |
| 训练时没见过的 | 长尾事实、截止日期后的事件、私有数据 | 网络搜索、RAG、内部语料检索 |
| 够不着的 | 非语言接口（API、数据库）、物理世界、实时状态 | 函数调用/MCP、浏览器与机器人、时钟/传感器/行情 |
依据是 Dziri et al. 2023（Faith and Fate）：随着问题规模增大（乘法位数、逻辑谜题房屋数、DP 序列长度），LLM 的 zero-shot 准确率急剧下降，LLM 做的是模式补全而非系统化推理。
工具的定义（引用 Wang et al. 2024 的综述）：工具是一个运行在 LM 外部的程序函数接口，由 LM 生成函数调用及参数来使用它。最小示例：17,423 × 892 → calculate(17423 × 892) → 15,541,316。
学习调用工具：四篇代表性工作
这是本讲的方法论核心：如何让模型学会"调什么、何时调、传什么参数、如何利用结果"。
1. Toolformer（Schick et al., 2023）自监督自学用工具
只给每个 API 少量示例，让模型自己学习。三步流程设计得很优雅：
•采样：对输入文本，在模型认为"值得插入"的位置（概率超过阈值 τ_s）采样 API 调用候选，如 Pittsburgh is known as [QA("What other name is Pittsburgh known by?")] the Steel City；
•执行：实际运行这些 API 调用，把结果回填进文本；
•过滤（关键创新）：用加权交叉熵损失做对比，"有调用+有结果"相比"无调用 / 有调用无结果"，只有当调用结果能降低后续 token 的损失（超过阈值 τ_f）时才保留。也就是说，用模型自身的困惑度作为"这个工具调用是否有用"的裁判，无需人工标注。
用过滤后的数据微调 GPT-J (6B)。效果：6B 的 Toolformer 在事实补全、QA、数学、时间、多语言等任务上全面超过自身基线，多数任务甚至超过 175B 的 GPT-3，"工具 + 小模型"可以打败"纯大模型"，这是本讲最有力的一张结果图。
2. ToolkenGPT（Hao et al., 2024）工具即词元
把每个工具表示为一个特殊 token（"toolken"），像学普通词嵌入一样学工具嵌入。推理时：模型预测下一个 token，如果是 toolken，则切换到工具模式，用上下文学习（ICL）填参数（工具模式下 prompt 里带 [tool](args) 格式的示例），执行后返回值再切回推理模式。训练时只在 toolken 位置计算损失。优点是无需为每个工具微调整个模型，可扩展到 234 个工具。
3. ToolLLM / ToolBench（Qin et al., 2023）规模化到 16k+ API
从 RapidAPI 爬取 6000+ 真实 API（共 16k+），用 ChatGPT 生成 ReAct 风格的多工具调用轨迹作为训练数据，微调 LLaMA 得到 ToolLLaMA，并配一个神经 API 检索器按指令推荐候选 API，承认了一个现实：工具太多塞不进上下文，检索是必需品。
4. Gorilla（Patil et al., 2023）对抗工具幻觉
从 HuggingFace/PyTorch/TensorFlow Hub 收集 1645 个 API（结构化 JSON 描述），用 GPT-4 自指令生成训练数据。两个贡献：
•检索感知训练（RAT）：微调时故意混入正确和错误的检索结果，训练模型利用好的检索、忽略坏的检索，对低质量检索保持鲁棒；
•AST 子树匹配评估：不比字符串，比较生成调用与标准调用的抽象语法树子树是否等价，以此度量工具幻觉，比精确匹配宽松合理，比纯文本相似度严格。
四者对比（课件总结表，值得品味）
| Toolformer | ToolkenGPT | ToolLLM | Gorilla | |
|---|---|---|---|---|
| 工具调用形态 | 文本内嵌调用 | 新增 token | ReAct 轨迹 | 文本+API 代码 |
| 训练对象 | 整个模型 (GPT-J 6B) | 仅嵌入 | 模型 (LLaMA 7B) | 模型 (LLaMA 7B) |
| 标注来源 | 自监督（损失过滤） | 真值/合成调用 | ChatGPT 轨迹 | GPT-4 自指令 |
| 规模 | 5 个工具 | 234 个 | 16k API | 1.6k API |
演进逻辑清晰：从"学会用几个工具"到"规模化到成千上万工具"，从人工示例到合成数据，从字符串匹配到 AST 评估。
标准接口：三代范式
前面所有方法共享一个痛点：每来一个新 API 就要再训练一次（改模型去适应工具）。工程界的答案是反过来的：改工具的描述方式，让任何模型都能用，运行时给 schema，而不是每个 API 微调一次。
| 代际 | 面向 | 机制 | 局限 |
|---|---|---|---|
| REST API | 人 | 端点+文档，模型要自己读文档、手写 HTTP 请求 | 无机器可读契约，模型须记住 URL、参数名、响应结构 |
| Function Calling | 模型 | 每个工具一份 JSON Schema，模型输出 name + arguments，由 harness 校验并分发 | 工具绑定在某个代码库/厂商生态内，换 API 要重写 |
| MCP | 生态 | 一个协议（JSON-RPC），任何客户端可连；服务器暴露 tools/resources/prompts；运行时发现；一次编写、处处复用 |
MCP 的两个核心原语课件讲得很具体：
•tools/list（发现）：客户端问"你有什么工具"，服务器返回工具列表，每个含 name、description、JSON inputSchema（还带 ttlMs 缓存语义）；
•tools/call（执行）：按 name 选工具、按 schema 传参，结果以 content 数组返回给 host 再交回 LLM。
两个工程示例很实用：
1.OpenAPI → MCP 自动生成：用 FastMCP 从 LMS 的 openapi.json 直接生成 list_assignments、post_grade 等工具——存量 REST 资产可以低成本接入 MCP；
2.双向认证：区分 inbound（agent → MCP server，校验 AGENT_TOKEN）与 outbound（MCP server → 下游 REST API，携带 LMS_TOKEN）——最小权限原则在 Agent 架构中的落地。
五、评估：三个基准，三个层次
| 基准 | 考什么 | 核心设计 |
|---|---|---|
| BFCL（Berkeley） | 单次/多次函数调用 | AST 离线评估 + 真实执行评估 + 多轮多步的基于状态评估；覆盖 Python/Java/SQL 等；专测相关性识别（所有候选工具都不该被调用时，模型要会说"不"） |
| ToolBench | 16k 真实 API 上的指令执行 | 真实 RapidAPI + 人工指令 + 神经检索器 |
| τ-bench（Yao et al., 2024） | 工具–Agent–用户三方交互 | 模拟真实客服场景：Agent 不仅要会调工具，还要遵守业务政策（policy）、在信息不足时主动询问用户 |
BFCL 的三类典型测试直观展现了"会调工具"的多层含义：多选一（从多个函数中选对）、并行调用（一次发多个调用）、相关性检测（错误请求要拒绝，如"乘法请求只给了 add 工具"）。
τ-bench 的 pass^k 指标是本节最重要的思想：不是"k 次尝试至少成功一次"（pass@k），是"k 次采样全部成功"的概率。这奖励的是可靠性与一致性，生产环境的 Agent 一次成功不够，必须次次成功。课件同时指出 τ-bench 自身也在演化（τ²-bench 等引入用户模拟）。
失败模式分类法（工程 checklist 级别的一页）
课件按调用层级归纳失败模式，非常适合直接用作 Agent 调试清单：
•单次调用：选错工具/不该调用时调用了；参数编造字段、类型或单位错误；幻觉出不存在的 API；
•多步链：跳过前置调用、顺序错误；失败后重复重试同一调用而不是退避换路；
•对话层：违反业务政策强行操作；该问用户时擅自假设；非确定性，一次通过、重试失败（正是 pass^k 针对的问题）。
总体评价与核心脉络
这节课的叙事结构是一条完整的技术演化线：
LLM 有明确的能力边界（算不了/没见过/够不着）→ 让模型学会用工具（Toolformer 自监督 → ToolkenGPT 工具即词元 → ToolLLM/Gorilla 规模化）→ 但"每个 API 训一次"不可持续 → 标准接口（REST → Function Calling → MCP，从人到模型到生态）→ 需要客观评估（BFCL 单调用 → ToolBench 规模 → τ-bench 三方交互 + pass^k 可靠性）→ 归纳失败模式指导工程实践
几个值得带走的深层洞察：
1.小模型 + 工具 > 大模型裸奔（Toolformer 6B 超 GPT-3 175B），这是"Agent 路线"对比"暴力缩放路线"的核心论据；
2.可以用模型自身的损失作为工具调用价值的无标注信号（Toolformer 的过滤思想），自监督思想贯穿 Agent 训练；
3.评估范式从"对不对"走向"稳不稳"（AST 精确匹配 → 执行结果 → 状态 → pass^k 一致性），反映了 Agent 从 demo 走向生产的需求转变；
4.接口标准化的方向是"让工具适配模型" MCP 之于工具生态，近似 USB 之于外设：解耦生产与消费方，代价是引入了发现、认证、安全等新的工程问题（课件中双向认证的例子已见一斑）。
如果只记一句话：工具使用是 LLM 从"语言模型"变成"能行动的 Agent"的桥梁，而这节课把这座桥梁拆成了"学习（怎么教会）、接口（怎么暴露）、评估（怎么算好）"三个正交的工程维度。
