优雅地失败,与「载具」 — 工具坏了模型需要什么,以及外壳才是产品
这一章讲三件事: 工具出错的时候,该返回给模型一个什么形状的东西; 「没搜到」和「出岔子」为什么必须分成两种东西返回; 以及 2026 年整个行业不约而同走到的同一个结构上——模型只是里面可换的一块。
它在全书链条里的位置: 第 13、14 章把工具接上去了。 这一章讲工具坏了怎么办,以及包在模型外面那一整圈到底是什么。 后半节是全书最新、在别处几乎看不到的一节。
1. 顶层全景:把价格上限传成 0
这一章的主走查还是第 14 章那个商品搜索工具,但这次我们故意把它弄坏:
用户说:「帮我找一件 0 美元以下的夹克。」 ← 一个不合法的价格上限
▼
① 不做任何处理:
工具抛出 `TypeError: 'NoneType' object is not iterable`
→ 模型对用户说:**「我在搜索时遇到了一个错误。」** ← **没用**
▼
② 换成一个固定形状的回复:
`{"success": false, "error": "invalid_price",
"message": "Price must be greater than zero."}`
→ 模型说:**「我没法搜索 0 美元以下的产品。你是不是想设一个别的价格上限?」** ← **有用**
▼
③ 再换一种:价格合法,但库里确实没有匹配的
→ 返回 `success: true` + 空列表 + 一条建议
→ 模型说:「50 美元以下没找到夹克,不过这里有几件价位高一点的」**并再发一次调用**
▼
④ 给工具加上 5 秒超时,再加上「最多重试三次,间隔 1 秒、2 秒、4 秒」
▼
⑤ 最后把这个工具放进外壳里跑:凭据和审批留在控制这一侧,
**模型生成的代码在隔离的那一侧执行;那一侧崩了,从上一个检查点恢复**
图说:①→③ 是「返回什么」,④ 是「等多久、重试几次」,
⑤ 是「这一切被装在什么东西里」。
**四个字段、那两句回答、5 秒和 1/2/4 秒都是书里的原数。**
2. 工具出错时,模型需要的到底是什么
这一节是全章的地基,而书把它压缩成了一句话。
先看现象:一段程序堆栈,模型接不住
工具会失败——接口超时、数据库挂了、网络断了、查询什么也没查到。 书说,如果你的工具不管这些情况,你的 AI 要么崩掉、要么编一个答案、要么把用户搞糊涂1。
走查第 ① 步就是最常见的那种糊弄:
工具内部炸了,抛出一行程序错误:
TypeError: 'NoneType' object is not iterable
这行字被原样塞回给模型。模型看得懂吗?
它能读出这是一段程序错误,但它读不出:
· 是我参数传错了,还是服务坏了?
· 我该重试,还是该换个问法,还是该道歉?
· 我该跟用户说什么?
于是它只能说:**「我在搜索时遇到了一个错误。」**
图说:**这句话对用户没有任何用处。** 他不知道该改什么,只知道没成。
那一句关键的话
书自己加粗标出的:工具失败时,模型需要的是关于「哪里出错了」的结构化信息, 而不是一段程序堆栈。2
「结构化」在这里的意思很具体:不是一段自由的文字, 而是几个固定的格子,每个格子里放 一样固定的东西。 因为模型要拿这几个格子做不同的事。
3. 那四个格子,以及模型拿它们各做什么
这一节讲这一章的第一个承重机制。
书要求每一次返回——不管成没成——都长成同一个形状3:
{
"success": true / false, ← 成没成
"error": null / "错误码", ← 哪一类错
"message": "给人看的一句话", ← 说人话的解释
"results": [ … ] ← 结果本身
}
书说这个统一形状在三件事上帮到模型,而这三条正好一一对应前三个格子:
| 格子 | 模型拿它干什么 |
|---|---|
success | 判断这次操作到底成没成 —— 决定接下来是往前走还是收拾残局 |
message | 直接把这句话用进给用户的回复里 —— 不用它自己组织措辞,也就不会自己发挥 |
error 的错误码 | 决定下一步做什么: 重试、请用户澄清、还是给个替代方案 |
第二条值得停一下,因为它是这一节最实用的一点:
那句 message 是你写的,不是模型编的。 你写「价格必须大于零」,
模型就能照着说;你什么都不写,它就只能自己编一句含糊的。
走查第 ② 步的完整样子:
用户:「帮我找一件 0 美元以下的夹克。」
▼
工具校验输入:max_price = 0,不合法
▼
返回:{ "success": false,
"error": "invalid_price",
"message": "Price must be greater than zero.",
"results": [] }
▼
模型看 success → false,知道没成
模型看 error → invalid_price,知道是**我传的参数不对**,不是服务坏了
→ 所以**不该重试**,该请用户改
模型看 message → 拿这句话当素材
▼
它对用户说:「我没法搜索 0 美元以下的产品。你是不是想设一个别的价格上限?」
图说:**注意最后这句话里包含一个建议。** 建议之所以出得来,
是因为错误码告诉了它「问题出在输入上」——**这正是错误码存在的理由。**
书还给了三种它专门处理的输入问题,可以照抄4:
| 输入问题 | 错误码 | 给人看的话 |
|---|---|---|
| 搜索词是空的 | empty_query | 「请提供一个搜索词。」 |
| 价格上限 ≤ 0 | invalid_price | 「价格必须大于零。」 |
| 返回条数超出范围 | 不报错,直接夹到 1–50 之间 | —— |
第三行的处理方式不一样,值得注意: 条数写得离谱不影响语义, 所以书选择悄悄夹回合法区间,而不是拒绝这次请求。 「什么错该报、什么错该自己吸收掉」是一个需要判断的设计决定,书用这三行示范了它。
4. 一个常见错误:把「没搜到」当成失败
这一节讲书专门拎出来讲的一个坑,而它的价值远超过它的篇幅。
先看现象:两件事被塞进了同一个格子
「数据库挂了」和「搜了但一件都没匹配上」——很多人会把两者都返回成失败。 书说它们是两回事5:
| 出岔子 | 空结果 | |
|---|---|---|
| 发生了什么 | 数据库挂了、输入非法、超时 | 搜索本身完整地跑完了,只是没匹配上 |
success | false | true |
| 额外给什么 | 错误码 + 道歉性质的说明 | 一条建议(「试试更宽泛的搜索词,或者去掉价格过滤」) |
为什么分开这么要紧:模型看到这两种会走完全不同的下一步
模型看到 success: true + 空列表:
它知道**系统是好的,只是这个条件下没东西**
→ 它会说:「50 美元以下没找到夹克,不过这里有几件价位高一点的……」
→ **而且它会自己再发一次工具调用**,换个条件再搜一遍
模型看到 success: false:
它知道**有东西坏了**
→ 它会道歉,并建议用户稍后再试
→ **它不会再自作主张地重搜**——因为重搜也是坏的
图说:**同一件事(用户什么也没拿到),两种返回,两种完全不同的后续行为。**
把空结果错报成失败,你就永远拿不到上面那条「自己换条件再搜一次」。
这两句回答的意思取自书里的示例。
判断(我们的,不是书里的): 这一条的普适价值在于它揭示了一个更一般的规则: 返回值的形状,决定了模型下一步的行为空间。 你把两种情况压成同一个
false,模型就丢掉了区分它们的依据 ——不是它不够聪明,是你没给它可以据以判断的东西。 如果错,会错在: 如果你的工具只有一种失败方式(比如它只是读一个本地文件), 那分不分开都一样,这条讲究就是多余的开销。 判据是:数一数这个工具有几种「用户拿不到东西」的原因——超过一种,就必须分开返回。
5. 等多久、重试几次
这一节讲主走查第 ④ 步,书给了具体的数。
做法一:给工具设一个超时。 书的示例是 5 秒——
超过 5 秒还没返回,就按 timeout 这个错误码返回失败,不再干等6。
书说这防止的是什么:外部服务慢或者没响应时,你的 AI 无限期地挂在那儿。
做法二:超时之前先重试几次。 书把这一条写成了生产上的必须项:
一次瞬时的网络错误,不该让整个请求失败。 常见做法是最多重试三次,间隔 1 秒、2 秒、4 秒,然后才把超时错误返回给模型。7
第 1 次调用 → 失败
▼ 等 1 秒
第 2 次调用 → 失败
▼ 等 2 秒
第 3 次调用 → 失败
▼ 等 4 秒
第 4 次调用 → 还失败 → **这时才返回 {"success": false, "error": "timeout"}**
图说:间隔一次比一次长(1 → 2 → 4),叫**退避**。
**为什么要越等越久:** 如果对方是被打垮了,你立刻重试只会雪上加霜;
**等的时间翻倍,等于给对方留出恢复的余地。**
(「为什么越等越久」这层解释是我们补的,书只给了 1/2/4 这三个数。)
书给这一整节的收尾是一条可以当规矩用的话:
每一条出错的路径,都应该返回一个模型能理解、能据以行动的响应。 如果你发现自己在往外扔原始异常或者含糊的消息,就重构, 直到每一种失败方式都有一个清晰的、结构化的回复。8
6. 「载具」:同一个模型,装进不同的外壳,能力差出一大截
这一节是全书最新的一块,写于 2026 年,别处几乎看不到。
先看现象:一个工具单独摆在那儿,什么也不会发生
书的起头一句很干净:
一个工具本身是死的。它需要有个东西来决定什么时候调它、拿结果做什么、 出岔子了怎么恢复。9
那个「东西」就是这一节要讲的。
它是什么:模型之外的那一整圈
| 单独一个模型 | 加上那一圈之后 |
|---|---|
| 收一个提示词,吐一段回答 | 会话与状态管理——把多轮任务串起来 |
| 记忆机制——存上下文、需要时取回来 | |
| 工具系统——调浏览器、调命令行、读写文件、调外部接口 | |
| 输出通道——把结果写回到别的系统里,而不只是返回一段文字 |
这一整圈,书叫它 harness,直译是「挽具、载具」。 我们后文统一叫「载具」。
书引的一句话把这件事说尽了:模型提供推理,载具提供能力。10
这句话的分量在于它把「产品」这两个字挪了位置: 模型是可以换的(今天用这家、明天换那家),而载具是你自己的。 书的原话是:模型正在迅速商品化,真正的工程难题在于让它们在具体场景里跑起来的那套脚手架。
架构上最要紧的一条:把凭据和模型写的代码彻底隔开
这是这一节最该带走的东西。
┌──────── ─────── 载具(控制的这一侧)──────────────┐
│ agent 的那个循环(推理 → 行动 → 观察) │
│ 工具路由:这次该调哪个 │
│ 审批:哪些动作要人点头 │
│ 追踪:每一步都记下来 │
│ 状态与检查点 │
│ ★ **凭据、账单信息、审计日志全部留在这一侧** ★ │
└────────────────────────────────────────────────┘
│ 任务往右流 ▲
▼ │ 结果往左流
┌─────────────── 沙箱(干活的那一侧)──────────────┐
│ 读写文件 │
│ 跑命令行命令 │
│ ★ **模型生成的代码在这里执行** ★ │
│ —— 这一侧**拿不到**上面那些凭据 │
└────────────────────────────────────────────────┘
图说:**「沙箱」指的是一个被围起来的执行环境**——
里面的程序能读写自己那一亩三分地,但碰不到外面的东西。
**这条分界线的全部意义在最后一行:模型写出来的代码,拿不到你的凭据。**
**沙箱崩了,载具从上一个检查点恢复状态、继续往下走。**[^11]
图里那个词也先说清:载具每隔一段会存一次检查点(把「现在走到哪一步、手里有什么」 整个存下来一份,相当于游戏里的存档点)。 出事之后不必从头再来, 从最近那一份接着走就行。
为什么这条线非划不可,把第 13 章那条分水岭再往前推了一步: 第 13 章说「工具会改变外部世界,所以要小心」; 这里说「模型生成的代码本身就是不可信输入,所以要把它 关起来跑」。
书说这个结构是行业各自撞出来的,不是谁定的标准
书说 2026 年初,几家主要 AI 公司和几个开源社区各自独立地走到了同一个结构上11:
- OpenAI 在它的 agent 开发套件和命令行工具里把这个模式形式化了: 一侧是模型原生的载具(循环、审批、追踪、记忆),另一侧是真正执行代码的沙箱环境;
- 一个叫 OpenClaw 的开源项目,书说它在 GitHub 上超过 30 万星标,成为该平台星标最多的软件项目, 用来说明这个结构不是某一家的私有资产:它不挑模型(Claude、GPT(这两个和后面的 DeepSeek、Llama 一样,都是具体模型的名字,分属不同厂商)、DeepSeek、本地跑的 Llama 都能配)、本地优先、社区可扩展,接了 40 多个消息渠道。 书对它的总结是:模型是可互换的模块,载具才定义产品;
- NVIDIA 的一个企业版方案把这套推向企业部署:agent 跑在一个沙箱运行时里, 在操作系统内核这一层强制精确的权限边界,让敏感的活留在组织自己的机器上。
补充(不在书里,依据我们自己的 agent 书架):我们核实了 OpenClaw 这一条。 我们书架上收了这个项目并做过完整拆解,登记的星标数是 386,672(2026-06-29 复核), 比书说的 30 万更高,书的说法成立。 但有一处对不上:书说「40 多个消息渠道」,我们的拆解量出来的是「20 多个聊天应用」。 我们没有再去核第三个来源,两个数都列在这里,请以你自己去看时的实际数为准。12
7. 让环境变得「agent 读得懂」:四条实践
这一节讲的东西看着像团队规范,实际是可靠性工程。
先看那个把话说透的发现
先说清里面一个词:持续集成指的是,每次改动代码都自动跑一遍构建和测试的那套流水线。
书引了 OpenAI 一个团队的做法:他们用 agent 建了一个真正的生产软件产品, 零手写代码,大约一百万行——应用逻辑、测试、工具链,外加持续集成的配置, 平均每位工程师每天 3.5 个代码合并请求13。
他们的核心发现,书原样引了下来:出问题的时候,解法几乎从不是「再努力一点」, 而永远是「缺了什么能力,以及我们怎么让它对 agent 变得可读」。
这句话把责任从「模型不行」挪到了「环境没准备好」。 下面四条都是从这句话长出来的。
| 实践 | 具体说什么 | 为什么 |
|---|---|---|
| ① 给它一张地图,不是一本百科 | 项目里放一份写给 agent 看的说明文件(现在通行的约定叫 AGENTS.md),但它最好是一份约一百行的目录,指向更深的文档,而不是把什么都塞进去 | 书说单体式的说明文件必然烂掉:它挤占真正的任务上下文、agent 分不清哪些还有效、而且烂得比谁都维护得快 |
| ② 让代码仓成为唯一的事实来源 | 设计决策、架构约束、执行计划、质量标准,都要变成带版本、能被找到的文件 | 书这句话最狠:从 agent 的视角看,任何它在上下文里拿不到的东西,实际上就不存在。 活在聊天记录里、文档软件里、人脑子里的知识,对系统是不可见的 |
| ③ 不变量靠机器强制,不靠文档(不变量指那些「无论如何都必须成立」的规矩,比如「这一层不许直接读数据库」) | 用代码检查工具和结构性测试去强制这些规矩,而且报错信息要直接写成「该怎么改」的指令 | 和第 3 节那四个格子是同一个道理: 报错信息会变成 agent 下一步推理的素材。规则编码一次,处处生效 |
| ④ 偏爱无聊、可组合的技术 | 接 口稳定、文档齐全、在训练材料里出现得多的技术,agent 用起来更可靠 | 书给了一条反直觉的推论:有时候自己重实现一个简单功能,比绕开一个行为不透明的外部库更划算——因为一个自己写的、测试齐全的实现,对未来的 agent 更可读 |
第 ② 条值得多说一句,因为它改变的是工作习惯而不是代码: 你和同事在聊天里达成的那个约定,对 agent 等于不存在。 它不是「没看到」,是「根本不在它的世界里」。
8. 一个不太乐观的数:能力跑在安全前面
书用一组对照结束这一章14:
| 说法 | 数 |
|---|---|
| 已经在用 AI agent 的组织 | 79% |
| 拿到了完整安全批准的 agent 部署 | 只有 14.4% |
| 计划部署 agent 的组织 | 83% |
| 觉得自己已经准备好安全地这么做的 | 只有 29% |
这两组数各自内部就是彼此的参照物:79% 对 14.4%,83% 对 29%。 两组指向同一件事:用的人远远多于准备好的人。
而书紧接着说明了这为什么和上一节的结构有关:
你建的那些工具就是攻击面:每一个能读文件、查数据库、调外部接口的工具,都是一个潜在入口。 agent 系统的设计要预设会有提示词注入和数据外泄的尝试。15
(「提示词注入」指的是:攻击者把指令藏在 agent 会读到的内容里 ——一封邮件、一个网页、一份文档——让它把那些字当成你下达的命令去执行。)
书给的两道防线,正好是这一章的前后两半:
第一道: 输入校验 + 结构化错误(第 3、4 节)
第二道: 载具与沙箱分离(第 6 节)
→ **凭据、账单、审计日志,全部留在模型生成的代码碰不到的那一侧**
图说:**注意这两道防线的层级不同。** 第一道防的是「工具被喂了坏参数」,
第二道防的是「模型本身被人操纵了」——**后者必须靠架构,靠不了校验。**
9. 作者的判断与证据
书里给了证据的:
| 说法 | 证据是什么 |
|---|---|
| 结构化错误 vs 程序堆栈的效果差别 | 给了两句一模一样场景下的模型回复做对照,差别一眼可见 |
| 空结果和错误必须分开 | 给了两段具体的返回值,以及模型看到各自会说什么 |
| 重试三次、间隔 1/2/4 秒 | 一组具体的数,但书没说这组数是从哪儿来的 |
| 超时 5 秒 | 一个具体的值,同样没给依据 |
| 一百万行、每人每天 3.5 个合并请求 | 一组具体的数,引自 OpenAI 一个团队。书给了参考文献编号,但我们没能核到一手来源 |
| 79% / 14.4% / 83% / 29% | 两组自带参照的数,引自「近期行业调查」。书没点名是哪几份调查 |
| OpenClaw 超过 30 万星标 | 一个可核的数。我们在自己的书架上核过:2026-06-29 记录是 386,672,书的说法成立 |
作者的推测或没给证据的:
| 说法 | 它是什么 |
|---|---|
| 「模型提供推理,载具提供能力」 | 一句引语,书标了参考文献但没说是谁说的 |
| 「模型正在迅速商品化」 | 一句趋势判断 |
| 单体式说明文件「必然烂掉」 | 一条经验总结,没有数据,但它给了三条机制上的理由 |
| 「有时自己重实现比用外部库更划算」 | 一条反直觉的建议,没有案例支撑 |
| 「40 多个消息渠道」 | 和我们书架上量出来的数对不上(我们的拆解写的是 20 多个) |
10. 边界与局限
-
审批只是控制面上的一个词。 「哪些动作要人点头」——谁来点、界面长什么样、 点了之后怎么记账、点错了怎么回滚,书一个字没讲。 这是这一章最大的洞;
-
沙箱怎么做,书没讲。 它说了「隔离的执行环境」和「内核层强制权限边界」, 但没有讲任何一种具体做法(容器?虚拟机?权限系统?)。 读者拿不到可以动手的东西;
-
检查点怎么存、恢复到哪一步,没有细节。 「沙箱崩了就从上一个检查点恢复」 ——检查点存的是什么、多久存一次、恢复之后会不会把一个动作做两遍,全没讲。 最后这一条在能改变外部世界的动作上很要命;
-
提示词注入只有一句话。 书提了这个词,说了要预设它会发生, 但没讲一个具体的防法。 第 21 章的安全三层能补上一部分,但注入这一类没有专门讲;
-
那些 2026 年的项目名和数字会过时。 星标数、渠道数、市场格局, 一年之内会变一遍。要记的是那条控制面/计算面的分界线,和那四个返回值格子。
11. 可带走的
全章那条走查,一行写完: 把价格上限传成 0 →
不处理时工具抛 TypeError,模型只会说「遇到了一个错误」(没用)→
换成 {success:false, error:"invalid_price", message:"价格必须大于零"},
模型说「我没法搜 0 美元以下的产品,你是不是想设别的上限」(有用)→
再换成价格合法但没匹配:success:true + 空列表 + 一条建议,
模型会自己换条件再搜一次 → 加 5 秒超时和 1/2/4 秒的三次退避重试 →
最后把工具放进载具里跑,凭据留在控制面,模型写的代码在沙箱里执行。
- 一句话记住这一章的地基:工具失败时,模型需要的是结构化的「哪里错了」, 不是一段程序堆栈;
- 四个固定格子: 成没成(
success)、哪一类错(error错误码)、 给人看的一句话(message)、结果本身(results); - 模型拿它们各做一件事: 看
success决定往前走还是收场、 直接把message用进给用户的话里、按错误码决定重试还是请用户澄清; message是你写的,不是它编的——你不写,它就自己发挥;- 「出岔子」和「搜到了但没有」必须分开: 前者
success: false, 后者success: true+ 空列表 + 一条建议; - 分开的收益很具体: 看到
true+ 空列表,模型会自己换个 条件再搜一次; 看到false,它知道系统坏了、不会白折腾; - 一条更一般的规律:返回值的形状,决定了模型下一步的行为空间;
- 超时要设(书给 5 秒),而且超时之前先重试三次,间隔 1 秒、2 秒、4 秒 ——间隔翻倍是为了给对方留恢复余地;
- 规矩:每一条出错的路径都要返回模型能据以行动的东西。 发现自己在往外扔原始异常,就重构;
- 载具 = 模型之外那一整圈: 会话与状态、记忆、工具系统、输出通道。 模型提供推理,载具提供能力;
- 架构上最要紧的一条线:凭据、账单、审计日志留在控制的那一侧, 模型生成的代码在隔离的那一侧跑——两边不通;
- 让环境对 agent 可读的四条: 给地图不给百科(约一百行的目录)、 让代码仓成为唯一事实来源、不变量靠机器强制、偏爱无聊可组合的技术;
- 最该记住的一句:从 agent 的视角看,它在上下文里拿不到的东西,实际上就不存在;
- 能力跑在安全前面:79% 的组织在用,只有 14.4% 的部署拿到了完整安全批准。
12. 原文地图
| 主题 | 原书章 | 原文位置 |
|---|---|---|
| 工具会失败的四种方式 | Chapter 7: Tool Integration and MCP | text/10-ch07-chapter-7-tool-integration-and-mcp.txt:534(搜「APIs time out」) |
| 「模型需 要结构化信息,不是堆栈」 | Chapter 7: Tool Integration and MCP | text/10-ch07-chapter-7-tool-integration-and-mcp.txt:539(搜「structured information about what」) |
| 三种输入校验与错误码 | Chapter 7: Tool Integration and MCP | text/10-ch07-chapter-7-tool-integration-and-mcp.txt:578(搜「empty_query」) · text/10-ch07-chapter-7-tool-integration-and-mcp.txt:586(搜「invalid_price」) · text/10-ch07-chapter-7-tool-integration-and-mcp.txt:593(搜「Clamp to valid range」) |
| 四个字段与它们的三个用处 | Chapter 7: Tool Integration and MCP | text/10-ch07-chapter-7-tool-integration-and-mcp.txt:656(搜「Human-readable explanation」) · text/10-ch07-chapter-7-tool-integration-and-mcp.txt:661(搜「helps the model in three ways」) |
| 有无结构化错误的两句回复对照 | Chapter 7: Tool Integration and MCP | text/10-ch07-chapter-7-tool-integration-and-mcp.txt:671(搜「unhelpful」) · text/10-ch07-chapter-7-tool-integration-and-mcp.txt:678(搜「Did you mean to set a different」) |
| 空结果不是错误 | Chapter 7: Tool Integration and MCP | text/10-ch07-chapter-7-tool-integration-and-mcp.txt:682(搜「treating」) · text/10-ch07-chapter-7-tool-integration-and-mcp.txt:710(搜「higher price range」) |
| 超时与退避重试 | Chapter 7: Tool Integration and MCP | text/10-ch07-chapter-7-tool-integration-and-mcp.txt:742(搜「with_timeout」) · text/10-ch07-chapter-7-tool-integration-and-mcp.txt:749(搜「exponential」) |
| 「每条出错路径都要能被据以行动」 | Chapter 7: Tool Integration and MCP | text/10-ch07-chapter-7-tool-integration-and-mcp.txt:755(搜「Every error path」) |
| 载具是什么、「模型提 供推理」 | Chapter 7: Tool Integration and MCP | text/10-ch07-chapter-7-tool-integration-and-mcp.txt:777(搜「A standalone LLM takes a prompt」) · text/10-ch07-chapter-7-tool-integration-and-mcp.txt:781(搜「The harness enables capability」) |
| 控制面与计算面分离 | Chapter 7: Tool Integration and MCP | text/10-ch07-chapter-7-tool-integration-and-mcp.txt:788(搜「control plane」) · text/10-ch07-chapter-7-tool-integration-and-mcp.txt:792(搜「never in the sandbox」) |
| 行业各自收敛出同一个结构 | Chapter 7: Tool Integration and MCP | text/10-ch07-chapter-7-tool-integration-and-mcp.txt:794(搜「emerged independently」) · text/10-ch07-chapter-7-tool-integration-and-mcp.txt:799(搜「300,000 GitHub stars」) |
| 一百万行、每人每天 3.5 个合并请求 | Chapter 7: Tool Integration and MCP | text/10-ch07-chapter-7-tool-integration-and-mcp.txt:818(搜「zero manually-written code」) · text/10-ch07-chapter-7-tool-integration-and-mcp.txt:820(搜「try harder」) |
| 四条实践 | Chapter 7: Tool Integration and MCP | text/10-ch07-chapter-7-tool-integration-and-mcp.txt:825(搜「map, not an encyclopedia」) · text/10-ch07-chapter-7-tool-integration-and-mcp.txt:836(搜「system of record」) · text/10-ch07-chapter-7-tool-integration-and-mcp.txt:843(搜「mechanically」) · text/10-ch07-chapter-7-tool-integration-and-mcp.txt:853(搜「boring, composable」) |
| 安全缺口的四个数 | Chapter 7: Tool Integration and MCP | text/10-ch07-chapter-7-tool-integration-and-mcp.txt:861(搜「79% of」) · text/10-ch07-chapter-7-tool-integration-and-mcp.txt:867(搜「attack surface」) |