让它动手 — 模型表达意图,基础设施决定许可
这一章讲三件事: 让模型「动手」这件事在技术上到底是什么(答案会让很多人意外); 教它用工具时,数据里最容易漏掉的那一半是什么; 以及一个能动手的模型,安全该怎么兜。
它在全书链条里的位置: 前十四章的模型都只做一件事——产出文字。 从这一章开始,它的输出会在世界上留下后果。 而全书总纲里那条线在这里显形:书的后半段其实在问同一个问题——谁来告诉它对不对。 这一章的答案是:工具返回的结果。
★ 第 05 章那笔债在这一章还: 那里说过训练时喂真值、用时接自己写的东西, 一旦某一步写歪,后面每一步都建立在这个歪的基础上。 这一章第 7 节把它变成一个具体的数字,第 6 节给出对策。
1. 先看现象:让它自己去查保单系统
书从一块石头讲起,而那个起头是有用的
书这一章的开场不在计算机上1:
埃塞俄比亚有 个叫 Dikika 的史前遗址,那里有一个洞穴。 大约 340 万年前,一个在洞里避难的早期人类,拿一把粗糙的石刀把肉从骨头上剔了下来。 他留下的那些切痕,在 2010 年被认定为已知最早的工具使用证据。
书要用它说的不是考古,是一句世界观1:
★ 对工具使用者来说,世界不是给定的,而是一个条件性的问题—— 不是「我能做到这件事吗」,而是「什么工具能让我做到这件事」。
书接着用三个例子把这句话钉住: 人不会飞——直到莱特兄弟; 不能在水下呼吸——直到有了潜水装备;不能远距离说话——直到贝尔发明了电话1。
★ 这个起头值得留着,因为这一章的主线就长在它上面。 前十四章的模型一直在回答「我能做到这件事吗」——它会的东西全在参数里,不会就是不会。
这一章开始,它换了个问法:「什么工具能让我做到这件事?」 而谁来批准它用那个工具,是另一个人说了算——这就是下面那句口号的前身。
回到那家保险公司
理赔专员现在想要的不是「你帮我写信」,而是:
「查一下保单 P-4471 的有效期和既往理赔记录,
确认腰椎 MRI 是否需要预授权,然后写拒付说明信。」
这需要模型去碰三个真实的系统:保单主档、理赔历史、预授权规则库。
一个「能自己去调外部系统、并把结果接回来继续办事」的模型,这一行管它叫 agent (直译是「代理」,但中文里几乎没人这么叫,所以这份文档一律留英文名)。 它和前十四章那种「你问一句、它答一句」的模型,区别只有一条: ★ 它的输出里可以包含「去做某件事」的请求,而不只是文字。
第一件要说破的事:模型并没有在联网
这是全章最容易误解的一点,而书把它写成了一句口号2:
模型表达意图,基础设施决定许可。
完整的一圈是这样的:
① **你**用一份结构化说明书描述每个工具:名字、用途、参数、类型
← 这份说明书跟着提示词一起给模型
② 模型判断需要调工具时,**生成一段结构化的调用**
← 它只是生成了一段文字。它没有连接任何东西。
③ **你的基础设施**接手:解析这段文字 → 校验参数类型和取值
→ 真正去调那个工具 → 把结果塞回上下文里,像插进对话的一条新消息
④ 模型接着往下写,这次它能看到工具返回的东西
这个结构带来三样好处,书逐条说明了3:
| 好处 | 为什么 |
|---|---|
| 解析可靠 | 模型的输出遵循一个可预测的格式,基础设施不必去理解自然语言描述的动作,只要从结构化数据里取出字段 |
| 参数校验在执行之前发生 | 一个要整数的工具收到的就是整数,而不是一个「可能能解析、也可能不能」的字符串 |
| 生成和执行清清楚楚地分开 | 这正是上面那句口号的技术基础 |
第二件:这不是从零教起的事
书给了一条能省下大量预算的判断4:
在底座模型这一层,这基本上是一个已经解决的问题。 主要的供应商在这上面投入很大,任何一个企业可能拿来当起点的模型, 在一般情况下至少已经是一个胜任的工具调用者。
★ 所以企业微调很少是在从零教它工具调用的机制, 而几乎总是在给一个已经会用工具的模型补上「你们自己那些接口的知识」。
2. 顶层全景:一次带工具的作业
用户说:「查 P-4471 的保单和理赔记录,确认要不要预授权,然后写拒付信」
│
① 模型先想:这需要工具吗?需要哪个? ← §4:光教语法教不出这个判断
│
② 生成一次结构化调用: get_policy(policy_id="P-4471")
│
③ 你的基础设施:解析 → 校验 → 执行 → 结果塞回 ← §3:每个切换点都是失败点
│
④ 模型读回结果,决定下一步 ← §7:每一步的错会往下复合
│
├─ 工具超时了怎么办? ← §6:★ 只训成功轨迹的模型会在这里崩
│
⑤ 三步都成功 → 整合进最终回答
│
└──► 全程:哪些动作要人点头? ← §9:三层安全栈
图说:**②④ 是模型在干活,③ 全是你的基础设施在干活。**
★ 这一章一半的篇幅在讲 ③ 和它的失败模式,因为那才是工程上真正难的部分。
主走查(全章共用): 上面这次三步作业。 第 3 步的工具会超时,而这一章要交代的是「超时之后会发生什么」。 编造的数每次出现都会标明。
顺带把三个名字分清楚
书专门开了一小节做语义辨析,因为这三个词经常被混用5:
| 名字 | 范围 |
|---|---|
| 工具调用(tool calling) | 最宽:泛指模型调用任何外部能力 |
| 函数调用(function calling) | 窄一些:特指用结构化说明书定义的函数 |
| 代码执行(code execution) | 最窄:模型写代码,由一个执行环境跑它 |
三个名字读者出门都会撞见,所以都留名。
3. 机制一:难的不是写 JSON,是来回切换
现象
很多人以为工具调用的难点是「让模型生成合法的 JSON」。不是。
为什么难:一次生成里要切换三种模式
书从模型的基本工作方式讲起,这一段值得完整转述6:
普通的文字生成是一个连续过程:
产出一个 token → 它成为上下文的一部分 → 下一个 token 基于整段序列产生
★ 工具调用打断了这个流:
① 模型决定要调工具 → **必须停止生成自然语言,改而吐出一个结构化对象**
② **生成暂停。** 基础设施接手,执行工具,把结果当成对话里的另一条消息注回上下文
③ **生成恢复。** 这时模型要一边关注工具的输出,一边接上前面所有内容继续写
书给这个模式起的名字叫交错生成(interleaved generation), 并说它正是工具调用真正困难的地方6:
模型不是在简单地产出文字。它在产出文字、切换到一种格式完全不同的结构化输出、 把控制权让给一个它无法预测其输出的外部系统, 然后基于那个不可预测的结果恢复文字生成。
每个 切换点都是一个失败点
书逐条列了三种7:
| 失败 | 长什么样 |
|---|---|
| 格式坏了 | 生成的结构化数据基础设施解析不了 |
| 格式对但参数错 | 产出的是合法结构,但参数值让工具报错 |
| ★ 拿到结果却不用它 | 恢复生成之后没能正确关注工具的输出,反而凭空编了一个答案——尽管数据刚刚就摆在它面前 |
第三种最阴险,因为它看起来完全正常。
还有一层几乎没人讲的困难
这一条解释了为什么这件事必须专门训8:
模型必须从「把这些转换表示成扁平 token 序列」的训练数据里, 学会管理这套生成与工具调用之间的微妙交接—— 而这些数据里没有任何明确的信号,告诉它生成在哪里暂停、在哪里恢复。
那些标记工具调用边界的特殊 token 或格式约定, 必须独自承担起「信号模式切换」的全部重量。 ★ 把这件事做对,正是「能可靠使用工具的模型」和「不能的模型」之间的分界。
4. 机制二:工具描述不是给人看的文档,它就是提示词工程
现象
很多团队把工具描述当接口文档写:「searches the web」——搜索网页。然后模型乱调工具。
书给的对照
这一组对照值得原样抄下来,因为差别很直观9:
❌ 「搜索网页。」
← 它只说了这个工具**做什么**
✅ 「当用户的问题需要比你的知识截止时间更新的信息时使用它,
或者当你对某个可以通过搜索核实的事实性论断没有把握时使用它。」
← 它说的是**什么时候用**
★ 书的判词:**后者帮模型做的是「该不该调用」这个决定,而不只是「怎么调用」。**
参数说明里的约束,是模型违反不了的约束
这一条给的是一个很实用的杠杆10:
良好类型化的参数说明,通过约束模型能提供什么,来减少调用错误。 如果一个参数必须是 1 到 100 的整数,说明书里就该写死这个约束,而不是让模型去猜。 如果一个参数只接受某几个字符串取值,列一个枚举比在描述里写一句备注清楚得多。
★ 加进说明书的每一条约束,都是模型不可能不小心违反的约束; 而每一处该写没写的地方,都是一个「本可以被校验挡住」的错误的机会。
边界情况必须写进去
这一条直接决定了模型出错时会不会自救11:
| 写进描述里的一句话 | 它让模型学会什么 |
|---|---|
| 「没有结果时返回空列表」 | 让模型有准备去处理这种情况 |
| 「数据库负载高时可能超时——稍等一下再重试」 | ★ 它同时暗示了一条恢复策略 |
书的判词:没有这类文档,模型要么凭空幻觉出一套错误处理策略,要么根本不处理错误。
(「幻觉」是这一行的固定说法,指模型凭空编出一个听起来合理、实际并不存在的东西—— 它不是在撒谎,它只是在续写一段读起来最像样的文字。这个词出门到处都会撞见,所以留名。)
工具太多会污染上下文
书还给了一条容量上的提醒12:
工具定义排在实际交互之前,后果是:工具太多会污染上下文。 渐进式披露这条原则说的是:不要一次把所有工具都摆出来, 而应该按需、及时地给 agent 提供工具信息。
写作当时,由服务端来做工具检索的功能在多数供应商那里还是测试特性。 但不管怎样,好的工具定义是关键,而节制是首要的美德。
5. 机制三:光示范语法,教不出判断
书给的那一句
一个只展示「这是查询、这是工具调用」的数据集,教的是语法,不是判断。 有效的工具使用要求知道什么时候该伸手去拿工具、怎么在几个候选里挑一个, 以及最关键的——工具失败的时候该做什么。因为在生产环境里,工具最终总会失败。13
一份合格的数据集要覆盖整个周期
书列了五段,缺任何一段模型都会在那一段上瞎猜13:
① **可能需要、也可能不需要工具**的提示词 ← 缺了它 → §5 那个「手里有锤子」的病
② 关于「要不要用工具、用哪个」的推理
③ 正确的调用
④ 对返回结果的解释
⑤ 把结果整合进最终回答
★ 那个最容易漏掉的训练信号:教它「哪个工具别动」
这一条书自己说「容易被忽略」,而它的构造方法非常巧妙14:
病:只拿「工具调用总是正确答案」的样例训出来的模型,
会得上一种**手里有锤子、看什么都像钉子**的毛病——
用户的问题只是闲聊、只是反问、或者干脆超出了现有工具的范围,它照样去调工具。
★ 构造方法(很聪明,而且几乎不花钱):
把那条**本来正确的工具**从可用工具集合里**拿掉**,
然后把这条样例**重新标注成「不需要工具」**。
→ 于是同一条数据被用了两次:一次教「该调什么」,一 次教「什么都不该调」。
书还点了名:有基准专门设了一个「相关性检测」的类别来考这件事。
判断(我们的,不是书里的): 这一条的价值在企业场景里被严重低估。 走查上的例子:理赔专员问「这个月的 KPI 怎么算的?」—— 这跟保单系统一点关系都没有,但一个只见过正例的模型会去调
get_policy, 拿一个空结果,然后编一段话。 如果错,会错在: 过度训练「不用工具」也有代价——模型可能变得该查的时候不查, 而这在企业里同样危险(它会拿过时的记忆回答)。 书没有给这个方向的平衡点。
6. 机制四:必须故意注入失败 ★ 第 05 章那笔债在这里还
这一节是这一章最能防止事故的一段,书还专门为它开了一个警告框。
现象:工具总会失败
书先把失败的形态列全15:
接口会返回错误、查询会超时、认证会过期、速率限制会被触发、 服务会临时不可用、结果偶尔会格式畸形或者出乎意料。
★ 只训成功轨迹的模型,会怎么崩
这四种崩法必须记住,因为它们全都会在生产里出现15:
| 崩法 | 长什么样 |
|---|---|
| 无视错误 | 当作工具成功了一样继续往下走 |
| 编造工具结果 | 幻觉出一个听起来合理、但工具从来没返回过的结果 |
| 死循环重试 | 拿完全相同的参数,反复调用同一个正在失败的工具 |
| 直接放弃 | 任务就这么废了 |
书的判词:只在成功轨迹上训过的模型,手里没有任何处理这些失败的样例,只能临场发挥。 而这些临场发挥往往很糟。
★ 这正是第 05 章那笔债: 那里说过,训练时每一步都有真值喂着, 而真用起来它接的是自己上一步的产物。 在这一章,「自己上一步的产物」变成了「一个失败的工具返回」—— 而它从来没在训练里见过这种东西。
怎么做:按失败类 型分门别类地教
书要求训练数据里必须包含各种失败,并且每种配一个恰当的反应16:
| 失败类型 | 该教的反应 |
|---|---|
| 参数校验错误(说明参数给错了) | 改参数重试 |
| 执行错误(工具自己有问题) | 换用备选工具 |
| 超时错误(临时不可用) | 等一下再试 |
| 格式出乎意料的返回 | 去解释它,而不是当它不存在 |
| 真的没救了 | ★ 承认失败,而不是编一个答案 |
这些数据怎么来,书说得很直白16:
构造这样的训练数据,需要有意地往工具调用流水线里注入失败—— 要么模拟错误,要么在容易产生失败的条件下使用真实工具。 这份力气不小,但它是必需的。
没有明确的错误处理训练,模型把失败当成一种它没有预备反应的异常; 有了训练,模型会形成一套「按失败类型匹配的恢复套路」。
走查:那次超时具体会发生什么
第 1 步:get_policy("P-4471") → 成功,返回保单有效期与条款版本
第 2 步:get_claim_history("P-4471") → 成功,返回 3 条既往理赔
第 3 步:check_preauth("腰椎MRI","CT-06") → ★ 超时(数据库负载高)
❌ 只训成功轨迹的模型:
可能性 A:直接写信,信里写「本项目无需预授权」—— **它编的**
可能性 B:同样的参数连调 20 次 —— **死循环**
可能性 C:输出「抱歉,我无法完成」—— **前两步的结果全浪费了**
✅ 训过失败注入的模型:
读到超时 → 依据工具描述里那句「负载高时可能超时,稍候重试」
→ 等 2 秒重试 → 仍然超时
→ 换备选:查缓存的规则表 → 拿到「CT-06 类拒付不需要预授权」
→ 在信里注明「预授权状态取自缓存规则表(更新于 3 天前)」
→ 交给人工确认
★ 注意最后那一步:**它承认了信息来源不是主库。** 这是训出来的,不是自带的。
(20 次、2 秒、3 天这几个数是为演示编的;那四种崩法和五类恢复策略是书里给的。)
7. 机制五:多步的账 —— 这条算术管着后面两章的三件事
那个数字
书给的算式只有一行,但它的后果很大17:
多步推理的核心难题是误差累积。 第 2 步的一个小错,可能在第 5 步变成一个大错,到第 8 步产出一个完全错误的结论。
★ 如果每一步出错的概率是 10%,那么十步都不出错的概率,勉强只有 35%。
0.9 的 10 次方 ≈ 0.349
参照物(这一列是我们算的,书只给了十步那一个数):
3 步: 0.9³ ≈ 73%
5 步: 0.9⁵ ≈ 59%
10 步: 0.9¹⁰ ≈ 35% ← 书给的数
20 步: 0.9²⁰ ≈ 12%
★ 单步九成正确听起来很不错。二十步之后只剩一成。
★ 这条算术在后面两章会解释三件事
判断(我们的,不是书里的): 书把同一个式子在三个地方各算了一遍, 但没有说它们是同一件事。我们在这里讲透,后面只回指:
它解释的 在哪 为什么要给中间步骤打分,而不是只看终点 第 16 章的过程奖励 为什么链条越长反而越差(准确率和链长呈倒 U 形) 第 16 章 为什么会撞上「组合性的墙」(会做三步题,却败在五步题) 第 16 章末尾 如果错,会错在: 这个式子假设各步的错误互相独立,而实际上它们不独立—— 一个上下文里的错误会提高后续出错的概率(所以真实情况可能比这个式子更差), 但同时中间验证又能截断这种传导(所以也可能更好)。 它是一个数量级上的直觉,不是一个可以拿来做预测的公式。
书给的三条对策
它们分别对应上面那三种后果17:
| 对策 | 做什么 |
|---|---|
| 在中间步骤做验证 | 在错误复合之前把它抓住 |
| 保守决策 | 避开那些后果难以逆转的动作 |
| 显式追踪不确定性 | 给「建立在不确定基础上的结论」打上标记 |
8. 机制六:计划,以及记忆的三层
计划首先是给人看的
这一条是书里少见的、把「可监督性」放在能力之前的判断18:
显式的计划不只是为了模型自己。它还使人的监督成为可能。 当 agent 在执行前展示它的计划时,操作者可以审查并批准这个思路。 而当计划是隐式的时候,操作者只看得到动作,必须去反推意图 。
★ 作者的经验:我发现要求 agent 在动手之前先用自然语言说出它的计划, 比任何数量的事后分析都能抓到更多问题。
计划服务于「必须信任这个 agent 的人」,不亚于服务于 agent 自己。
先把「计划」这件事的定义说清楚19:
能动性行为要求规划:把一个「单次动作达不成的复杂目标」, 分解成一串可以依次或并行处理的子目标。 一个说「给这个项目搭一套开发环境」的用户,指定的是一个目标,不是一套流程。 ★ 这个规划能力,正是 agent 区别于单纯的工具使用者的地方。
计划往往是领域特定的
书举了两个层次的例子20:
| 例子 | 说明 |
|---|---|
| 一份 2026 年初发布的研究规划数据集 | 自然科学的研究问题 + 一套评分细则。它说明了规划常常是领域特定的,甚至可能遵循固定的方法论 |
| 科学方法本身 | ★ 书说我们可以把科学方法看成一种研究的规划框架,不管做研究的是人还是模型 |
而作者给了一个亲历的例子,它正好把这一章和第 07 章接上20:
在为生命科学做能动系统时,我常常碰到一些「很少被写下来、也没被形式化」、 但确实体现着可靠逻辑的小方法论。 一个常见的工作流模式是:每次有人提出一个候选药物,就先去查它的某些特性。 ★ 于是我造了一大批合成偏好数据——凡是「先做这些查询」的研究计划,就给它更高的偏好。
★ 注意这正是第 14 章那条口径的又一次实施:那些专家说不出来的顺序, 不是被写成规则,而是被做成了偏好数据。
记忆分三层
书对记忆的处理很清楚,而且每一层的性质不同21:
| 层 | 是什么 | 性质 |
|---|---|---|
| 上下文窗口 | 隐式的短期记忆——放在上下文里的信息模型就能用 | ★ 隐式的意思是:模型并不显式地决定记住什么,它只是使用碰巧出现在上下文里的东西;而且受长度限制 |
| 外部记忆库 | 让 agent 显式地把信息写进持久存储、需要时再取回来 | 显式 |
| 检索 | 需要时把相关信息拉进上下文 | ★ 这就是第 03 章那条外挂检索,换了个用途 |
没有它会怎样,书给了一个很具体的病22:
没有有效的状态管理,agent 会得一种奇特的健忘症:每一步都在不知道前面发生过什么的情况下进行, 导致重复的动作、被遗忘的上下文,以及整体上不连贯的行为。 一个不记得自己已经查过哪些来源的研究 agent,会反复搜索同样的信息。
走查上的样子: 那次超时之后重试,模型第二次又去调了 get_policy("P-4471")——
它忘了第 1 步已经查过。
而这件事要专门训23:
训练有效的记忆使用,需要那些示范了「什么时候存、什么时候取、 以及怎么把取回来的信息和当前情境调和」的样例。 模型应当学会:识别一条信息是否重要到该被记下来、 在记忆里可能有相关内容时去查询它、以及把可能已经过时的检索结果与当前观察调和。
★ 这些技能不会从通用的语言模型训练里自动涌现,它们需要明确的训练。
9. 机制七:安全只能是三层栈,而最小权限压过一切
现象:能力和风险是同一件东西
书说得毫不含糊24:
一个能执行代码的模型,能执行恶意代码。 一个能发邮件的模型,能发垃圾邮件或钓鱼邮件。 一个能修改文件的模型,能删除或损坏重要数据。
从被动生成到主动能动的这个转变,创造出了被动模型不会带来的风险。
书还引了一起真实事件来说明这个张力25:
2025 年 9 月那起编码助手被用于网络间谍的事件,正好演示了这个张力: 一个为了它本来的用途而被有意赋予了广泛工具权限的编码助手, 被越狱、并被改用于自主网络攻击。
(「越狱」指用精心构造的输入,绕过模型被训出来的那些拒绝行为, 让它去做本来会拒绝的事。) ★ 让这个 agent 对合法编码有用的那些能力,同样让它对恶意入侵有用。
★ 最小权限:那句「没有第三好的办法 」
这一段是全章最该记住的东西,书把它写成了一个独立的方框26:
对你提供给 agent 的每一个工具,都问一句:这个 agent 需要这项能力才能完成它的目的吗? 不需要,就把它拿掉。
★ 一个有 5 个工具的 agent,攻击面小于一个有 50 个工具的。 ★ 你不提供的能力,不可能被滥用。
从最小的选项集开始,只有当某项能力的必要性被证明了才加上它—— 而不是为了「可能有用」而预先加上。
而书对「防误删文件」给的那个三段式,值得原样抄25:
防止一个模型删除文件的最安全的办法,是不给它删除文件的权限。 次好的办法是确保这类权力只有在用户批准的情况下才能被调用—— 哪怕这个模型处在「全自动驾驶」模式。 ★ 恐怕,没有第三好的办法。
三层栈,缺一不可
书把安全机制分成三层,并明说没有哪一层单独够用27。
第一层那个词先讲清楚:沙箱就是一个被事先框死的受限执行环境。 你的工具代码在里面跑,而它能打开哪些文件、能连哪些网络地址、能调用操作系统的哪些功能, 全部在它启动之前就已经规定好了,框外的一律被拒绝。
它长什么样、在哪儿: 它不在模型里,而在你的服务器上——通常是一个受限的容器或虚拟机, 那份「允许什么」的清单是你写的一份配置文件。 (出门在任何一份 agent 安全文档里都会撞见这个词,所以这里留原名。)
| 层 | 它提供什么 | 它自己的边界 |
|---|---|---|
| ① 基础设施层的沙箱 | ★ 训练绕不过去的硬限制 | 它作用在命令或操作这一级,而且它的安全性不会高于它底下那套技术实现的定义 |
| ② 训练层的干预 | 让模型「即使技术上被允许,也不愿意」去做有害的动作 | 它是意愿,不是限制 |
| ③ 人在环 | 给那些「训练和基础设施都覆盖不了」的高风险决定提供监督 | 它慢,而且会吃掉自动化的收益 |
书的收口:没有哪一种机制单独够用,稳健的部署把这三层叠起来。27
两层之间的分工,书还给了一句很好用的话28:
基础设施接住训练的失败,而训练避免去触发基础设施。
人在环怎么设计:关键是分类,不是一刀切
书给的判据是按风险分类29:
★ 两个极端都不可用:
每个动作都要人批 → **agent 就没法用了,它存在的生产力理由被否掉了**
一个都不要批 → **邀请有害的自主性**
✅ 按风险给动作分类:
├ 不可逆的动作(发邮件、删文件、下单) → **必须确认**
├ 后果重大或者难以撤销的动作 → **必须确认**
└ 常规的低风险动作 → 不必确认
书给的对照:一个管日历的 agent 可以在最少监督下运行,
而一个能碰财务系统的 agent 不行。
10. 机制八:怎么评一个会动手的模型
结论先行:按结果评,不按动作评
这是这一章的评估口径,而且它和第 10 章那一套是相容的30:
能动性评估的中心是任务完成:给一个目标说明和相应的工具权限,agent 达成目标了吗? ★ 这种「关注结果而不是过程」的取向,反映的是能 动系统的目的: 用户在乎的是他们的目标有没有被达成,而不是具体走了哪一串动作。
判断(我们的,不是书里的): 反过来说——按动作评,等于逼它模仿你的解法。 而你的解法未必是最好的那条,更可能不是唯一一条。 如果错,会错在: 在受监管的领域里,「过程」本身可能就是要求的一部分 (第 14 章那些审计轨迹的要求)。那种场合下,过程不是手段,过程就是结果之一。
但只看成功率不够,还要看效率
书补了一整套效率指标31:
一个能解决问题、却比必要多走十倍步数的 agent, 或者在有更便宜替代品时去调用昂贵工具的 agent,不如一个高效达成同样结果的。
| 效率指标 | 量什么 |
|---|---|
| 走了几步 | 冗余的动作 |
| 调了几次工具 | 调用成本 |
| 生成了多少 token | 直接的钱 |
| 墙钟时间 | 用户等多久 |
还有一条防作弊的设计31:
给中间进展记部分分,能在困难任务上给出更细的表现视图—— 一个「正确识别了思路、完成了大部分步骤」的 agent,和一个「一开始就走错」的 agent, 不该拿同一个零分。
一个基准要满足三条,否则它测不出东西
书给的三条设计要求32:
| 要求 | 为什么 |
|---|---|
| 任务说得足够清楚,成功标准毫无歧义 | 说不清的任务会让「它到底成没成功」变成争议 |
| 成功必须客观可测,最好能自动验证 | 要人来判断成功与否的任务会形成瓶颈,而且引入主观性 |
| 难度要有跨度,从很容易到真正困难 | 否则区分不出不同能力层级的 agent |
三个基准,各测什么
书点了三个的名字,读者出门都会撞见33:
| 基准 | 测什么 | 它硬在哪 |
|---|---|---|
| SWE-bench | 真实的 GitHub 议题,来自热门 Python 仓库 | 要求 agent 在大型代码库里导航、理解议题描述、产出正确的补丁;它用的是生产代码库里的真实议题 |
| WebArena | 在真实网站上做网页导航任务(购物、发帖、找信息) | ★ 它量的是 agent 能不能在真实网页界面那种脏乱的现实里干活,而不是理想化的环境 |
| GAIA | 需要跨工具多步推理的问题:网页搜索、计算、文件操作、接口访问 | ★ 它被专门设计成抗捷径 |
红队:三种攻法,而且这件事永远做不完
书列了红队会用的三类手法34:
| 攻法 | 长什么样 |
|---|---|
| 伪装成合法权威 | 社会工程:声称自己有某种其实没有的权限 |
| 改变 agent 对自己的认知 | 角色扮演场景 |
| 多步渐进 | ★ 一点一点地推边界,慢慢把它挪出安 全区 |
书的口径:安全评估应当是持续的,而不是上线前的一次性评估。 新的攻击向量会随着对手研究已部署系统而出现; 模型能力会因为更新和微调而变化,而这些变化可能影响安全性质; 威胁面貌也会随着新的有害用途变得可想象而移动。34
稳健性:那句值得贴在墙上的话
书对稳健性测试给了一个很好的理由35:
★ 测试发现的每一个失败模式,都是一个不会在生产里让用户吃惊的失败模式; 评估中发现的每一处脆弱,都是一处可以在部署前被修掉的脆弱。
具体要测三类变化35:
① 分布偏移:同一个请求的不同措辞、结构类似的不同领域、
不同的具体程度或正式程度
★ 目的是判断:学到的行为**泛化了**,还是**依赖训练样例的表面特征**
② 噪声输入:错别字、模糊的指代
③ 对抗性稳健:见上一小节
而书给了一句解释为什么 agent 特别难36:
在能动系统里,靶子是任务完成而不是输出——是在世界上的效用,而不是屏幕上的质量。 ★ 而能动交互通常是多步的,这意味着它呈现出的对抗面,比单步交互大得多。
11. 作者的判断与证据
| 说法 | 是哪一类 | 说明 |
|---|---|---|
| 那个 340 万年前的石器 | 有据的考古事实 | 书给了尾注,并说明那些切痕是 2010 年被认定的1 |
| 「模型表达意图,基础设施决定许可」 | 对协议结构的描述 | 这是那套协议的字面后果,不是判断2 |
| 底座模型已经是胜任的工具调用者 | 作者的观察 | 没有配基准数据;但这条判断直接决定企业该花多少钱4 |
| 交错生成是真正难的地方 | 机制论证 | 他逐条给了三个失败点67 |
| 好的工具描述要说「什么时候用」 | 作者的实践口径 | 那组对照是他构造的说明性例子9 |
| 无关性检测的构造法 | 有据的做法 | 书点名了一个专设该类别的基准14 |
| 只训成功轨迹会导致那四种崩法 | 作者的经验判断 | 没有配实验;但它有很强的机制解释(模型没见过这种输入)15 |
| 每步 10% 出错、十步剩 35% | 可验算的算术 | 但它假设各步独立,书没有讨论这个前提17 |
| 「先说计划比事后分析抓到更多问题」 | 作者的经验 | 原文是「I've found that…」18 |
| 那个药物研发项目的偏好数据 | 作者亲历 | 单一案例20 |
| 记忆技能不会自动涌现 | 作者的判断 | 没有配实验23 |
| 那起 2025 年 9 月的事件 | 公开事件 | 书在第 1 章已经讨论过,这里再引用25 |
| ★ 「没有第三好的办法」 | 作者的立场 | 这是他关于权限设计最强硬的一句,而且它是论断不是实测25 |
| 三层安全栈 | 框架 | 书明说没有哪一层单独够用27 |
| 三个基准的定位 | 有据 | 三个都配了尾注33 |
| 「测试发现的每个失败都是不会让用户吃惊的失败」 | 作者的立场 | 它是一句论证,用来说明稳健性投入的回报35 |
12. 边界与局限
- 具体的调用格式和标记约定我们不抄。 书给了几种标记方式的例子 (标签式的、分隔符式的、供应商特有的),它们随供应商和版本变。
- 那份 6 万条的工具调用数据集,我们只交付它的构造思路。 书给了字段格式,属于数据集的接口细节。
- 合成轨迹那条流水线我们只提一句。 书描述了一条三段验证的做法 (格式检查 → 真实执行 → 语义验证),但完整机制属于第 17 章,那里连它的失效方式一起讲。
- 沙箱服务的具体选型不在这里。 书点了几家临时沙箱服务的名字, 它们的取舍是延迟和按次成本,属于会变的产品信息。
- 书里那个「让编码助手生成工具使用轨迹」的专栏,我们按全书口径不覆盖。 它有一条口径值得单独记:编码助手可以生成轨迹并注入失败—— 而那正是第 6 节要的那种数据。
13. 可带走的
- ★ 模型并没有在联网。 它只生成一段结构化的调用; 是你的基础设施去解析、校验、执行、把结果塞回去;
- ★ 「模型表达意图,基础设施决定许可」——这一句是整章的地基;
- 结构化的三个好处:解析可靠 · 参数校验发生在执行之前 · 生成和执行清清楚楚地分开;
- 底座模型已经是胜任的通用工具调用者;企业微调几乎总是在补「你们自己那些接口」, 而不是从零教机制;
- ★ 真正难的是交错生成:自由文本 → 结构化调用 → 交出控制权 → 读回一个它无法预测的结果 → 再接回自由文本;
- 每个切换点都是失败点:格式坏 · 格式对但参数错 · ★ 拿到结果却不用它、凭空编一个答案;
- 模型要从「没有任何暂停/恢复标记」的扁平 token 序列里学会这套交接, 全靠那几个特殊标记承担信 号——把这件事做对,正是能不能可靠用工具的分界;
- ★ 工具描述就是提示词工程:「搜索网页」远不如「当问题需要超出你知识截止的信息时用它」;
- 参数说明里的取值范围和枚举,是模型不可能不小心违反的约束; 边界情况(没结果返回空 / 负载高会超时可重试)必须写进去——它同时暗示了恢复策略;
- 工具太多会污染上下文;按需、及时地披露,节制是首要的美德;
- ★ 光示范语法教不出判断。 数据要覆盖整个周期, 包括「可能需要也可能不需要工具」的提示词;
- ★ 要专门教它「哪个工具别动」:把正确工具从可用集里拿掉、重新标成「不需要工具」; 否则它会得「手里有锤子看什么都像钉子」的病;
- ★ 必须故意注入失败。 只训成功轨迹的模型会:无视错误 · 编造工具结果 · 死循环重试 · 直接放弃;
- 按失败类型配恢复策略:参数错就改参重试 · 工具挂就换备选 · 超时就等 · ★ 真没救就承认,而不是编一个答案;
- ★ 误差复合:每步九成正确,十步全对只剩三成半。 这条算术管着第 16 章的三件事(为什么要过程奖励、为什么链长有倒 U、为什么有组合性墙);
- 三条对策:中间验证 · 避开难以逆转的动作 · 显式追踪不确定性;
- ★ 计划首先是给人看的:要求它先说计划再动手,比任何事后分析都能抓到更多问题;
- 规划往往是领域特定的;而那些说不出来的顺序,可以做成偏好数据(第 14 章那条口径);
- 记忆分三层:上下文窗口是隐式短期记忆 · 外部记忆库是显式的 · 检索按需拉进来; ★ 什么时候存、什么时候取、怎么调和过时信息,要专门训——它不会自动涌现;
- ★ 最小权限压过一切:5 个工具的攻击面小于 50 个;你不提供的能力不可能被滥用;
- ★ 防误删文件最安全的办法是不给删除权限,次好是需要用户批准,没有第三好的办法;
- 安全是三层栈:基础设施沙箱(训练绕不过去的硬限制)· 训练让它不愿做 · 人在环审批;没有哪一层单独够用;
- 基础设施接住训练的失败,训练避免去触发基础设施;
- 人在环按风险分类:不可逆或后果重大的动作要确认,常规低风险的不要; 全批就没法用,全不批就是有害的自主;
- ★ 按结果评,不按动作评——用户在乎目标达成没有,不在乎走了哪串动作;
- 但还要看效率:几步、调了几次工具、多少 token、多少墙钟时间; 中间进展给部分分,防止「一开始就走错」和「差一点做成」拿同一个分;
- 好基准三条:成功标准无歧义 · 客观可自动验证 · 难度有跨度;
- 三个基准:真实 GitHub 议题 · 真实网站上的导航 · 抗捷径的跨工具多步题;
- 红队三种攻法:伪装合法权威 · 角色扮演改变它的自我认知 · 多步渐进推边界; 安全评估是持续的,不 是上线前一次性的;
- ★ 测试发现的每一个失败模式,都是一个不会在生产里让用户吃惊的失败模式;
- 能动系统的对抗面比单步交互大得多——因为它是多步的。
14. 原文地图
| 主题 | 原书章 | 原文位置 |
|---|---|---|
| 那个洞穴与工具使用者的世界观 | From the Cave to the Agent | text/113-fm-from-the-cave-to-the-agent.txt:7(搜「Dikika」) · :9(搜「What tool will enable me to do this」) |
| 调用协议 · 结构化的好处 | From the Cave to the Agent | text/113-fm-from-the-cave-to-the-agent.txt:13(搜「JSON schemas that specify the name」) · :15(搜「Parameter validation catches errors before execution」) |
| 交错生成 · 三个失败点 · 特殊标记的重量 | From the Cave to the Agent | text/113-fm-from-the-cave-to-the-agent.txt:25(搜「Tool calling interrupts this flow」) · :29(搜「interleaved generation pattern」) · :31(搜「hallucinating an answer instead」) · :33(搜「must carry all the weight」) |
| 底座已经会用工具 · 渐进式披露 | From the Cave to the Agent | text/113-fm-from-the-cave-to-the-agent.txt:35(搜「already at least a competent tool caller」) · :57(搜「Progressive disclosure」) |
| 三个名字 · 描述即提示词工程 · 参数约束 | A NOTE ON SEMANTICS | text/114-fm-a-note-on-semantics-tool-calling-function-callin.txt:13(搜「searches the web」) · :15(搜「a constraint the model cannot accidentally violate」) · :17(搜「returns an empty list if no results are found」) |
| 语法不等于判断 · 数据要覆盖整个周期 | Training for Action | text/115-fm-training-for-action.txt:3(搜「teaches syntax but not judgment」) · :7(搜「prompts that might or might not require tools」) |
| 教它哪个工具别动 · 失败注入 | VIBE CHECK: GENERATING TOOL USE TRACES | text/116-fm-vibe-check-generating-tool-use-traces.txt:61(搜「hammer-and-nail problem」) · :67(搜「enter failure loops」) · :69(搜「retrying with modified parameters」) · :71(搜「deliberately injecting failures」) |
| 那个警告框 | WARNING | text/117-fm-warning.txt:3(搜「Deliberately inject failures」) |
| 规划的定义 | The Leap to Agency | text/118-fm-the-leap-to-agency.txt:7(搜「decompose it into subgoals」) · :9(搜「Explicit plan generation」) |
| 计划即沟通 · 领域特定 · 误差复合 · 记忆 | PLANS AS COMMUNICATION | text/119-fm-plans-as-communication.txt:3(搜「catches more problems than any amount of post hoc analysis」) · :7(搜「research planning dataset」) · :9(搜「mini-methodologies」) · :19(搜「barely 35 percent」) · :23(搜「peculiar form of amnesia」) · :25(搜「implicit short-term memory」) · :27(搜「when to store information」) |
| 能力即风险 · 最小权限 · 那起事件 | With Great Power: Safety for Agentic Systems | text/120-fm-with-great-power-safety-for-agentic-systems.txt:7(搜「can execute malicious code」) · :11(搜「principle of least privilege」) · :13(搜「no third best way」) |
| 「5 个工具比 50 个安全」 · 训练层 · 人在环 | LEAST PRIVILEGE FOR AGENTS | text/121-fm-least-privilege-for-agents.txt:3(搜「Capabilities you do not provide cannot be misused」) · :7(搜「instilling reluctance」) · :17(搜「Confirmation patterns」) · :19(搜「Never requiring approval invites harmful autonomy」) |
| 按结果评 · 效率指标 · 基准三要求 | Did It Actually Work? | text/122-fm-did-it-actually-work.txt:7(搜「This focus on outcomes rather than process」) · :9(搜「Partial credit for intermediate progress」) · :11(搜「Difficulty should span the range」) |
| 三个基准 · 红队 · 稳健性 · 三层栈 | Modern Agent Benchmarks | text/123-fm-modern-agent-benchmarks.txt:5(搜「real GitHub issues」) · :7(搜「messy reality of real web interfaces」) · :9(搜「resist shortcut solutions」) · :17(搜「gradual boundary-pushing」) · :19(搜「ongoing rather than a one-time assessment」) · :25(搜「will not surprise users in production」) · :31(搜「hard limits that training cannot circumvent」) · :37(搜「much larger adversarial surface area」) |
| 工具是肌肉,推理是大脑 | Summary | text/124-fm-summary.txt:3(搜「reasoning is the」) |