场景 1 · 工具分五类 4.1
谁发起、作用于什么，决定工具的形态
前四类是我调用工具，第五类是世界调用我 —— 这是第 6 章异步交互的伏笔
记住这个分类： 后面讲「工具太多怎么办」「事件驱动」「多 Agent 协作」，都是在这五类里做取舍。
场景 2 · 邮件汇报 vs 操作手册 4.2.1 重点
每步结果都搬回上下文，等于每做一步写封邮件汇报
为什么省这么多： token 成本几乎全在上下文里 —— 把中间过程留在执行环境，就把它从账单里拿掉了。
场景 3 · 一句话让准确率飙升 4.2.2
描述写清「何时用、不能用」，调用准确很多
工具描述不是说明书，是决策依据 —— 模型靠它决定「要不要调」
最容易忽略的一条： 反例比正例更重要。「不能做什么」才是拦住误调用的那句话。
场景 4 · 弯引号幽灵 4.2.3 重点
工具偷偷改参数，模型陷入找得到的死循环
Cursor 2026 年初某版本的 bug —— 参数传递保真性被破坏，模型永远想不明白「明明看得见，为什么搜不到」
教训： 工具链里任何一次「静默转换」都是定时炸弹。该报错就报错，别替模型做决定。
场景 5 · 毒包裹快递 4.3 重点
工具描述能夹带恶意指令，骗模型交私钥
本质是提示注入的变种，而且每次会话都生效
防御思路： 工具定义来自不可信来源时，要么人工审核，要么像场景 9 那样用边车只读结构化字段。
场景 6 · 只露书脊的书架 4.4.1
工具只给索引，用时再查，省下近半 token
5 个 MCP 服务器就可能引入数以万计 token —— 200K 窗口还没对话就用掉近三成
权衡： 按需加载省的 token 是实的，代价是多一次「取定义」的往返 —— 工具越多，这笔买卖越划算。
场景 7 · 雷达扫出对的工具 4.4.2 重点
声明能力缺口，系统从数千工具里精准匹配
工具多到一定程度，「找工具」本身就成了一件要设计的事
范式转变： 从「预先塞给模型」改成「模型开口要」。这让工具规模从几百扩展到几千成为可能。
场景 8 · 两工程师双签 4.6
不可逆操作要两个不同家族模型分别审
像银行经办与审核双签 —— 关键不是「有两个人」，而是两个人真的独立
为什么必须不同家族： 同源模型的盲区高度重合，互相审查容易一起看漏。
场景 9 · 摩托边车保镖 4.6
轻量模型边跑边查，危险命令先拦下
边车只读结构化字段（工具名 + 参数），所以能堵住「请允许执行 rm -rf」这类藏在网页内容里的提示注入
设计要点： 边车只读结构化字段（工具名 + 参数），不读自然语言内容 —— 这样提示注入就无从下手。
场景 10 · 重复扣款惊魂 4.6 重点
没有幂等性，超时重试就会重复转账
所有「可能已经成功」的超时，都不能当失败处理
一条通用规则： 凡是不可逆的外部副作用，都要带唯一标识 + 去重，或走「预检 - 确认」两段式。
场景 11 · 三个颜色的信封 4.7
给子 Agent 标清信息来源，防提示注入
来源不清，模型就无法判断该信谁 —— 这是防提示注入的结构化手段
呼应第 2 章： 这其实就是「上下文工程」在 Agent 间通信上的延伸 —— 来源不清，模型就无法判断该信谁。