进三 Tool System：给 Agent 装手脚
本章目录
03.1 Function Calling 与 Structured Output：模型怎么"学会"调函数
呼应 §03.3。补一句底层：模型不是你教它调函数，是训练时就学会了"输出符合 Schema 的 tool_use JSON"。你给工具清单（名字+参数类型），它生成调用；Structured Output（类型化输出，§03.3.1）是把返回也锁死成结构。
两者区别一句话：Function Calling 管"它想调啥"，Structured Output 管"它返回啥样"。
03.2 一次工具调用背后，经历了什么（以 Claude Code 为例）
你以为"调个工具"是一瞬间。其实是四步往返：
① 模型输出 tool_use（要调啥、参数）
② Harness 收到，在沙箱里真正执行
③ 执行结果包成 tool_result 返回
④ 模型带着结果进入下一轮推理
经验：所谓"Agent 卡"，常卡在 ②③——工具慢、权限弹窗、沙箱起不来。优化工具侧，比优化模型侧见效快。
03.3 工具太多选不准？Deferred Loading 与动态工具集
2026 年 4 月，TianPan 一篇文给了个扎心数据：工具一多，LLM 选工具的准确率能跌到 13%。把所有工具 Schema 塞进上下文，既烧钱又选错。
解法三家共认：
- Deferred Loading（懒加载）：先只给少数常用工具，用到再加载。
- 动态工具检索：按用户意图，从几百个工具里检索最相关的 5–10 个塞进去。
- 路由层：用小模型先做"选工具"这道分类，再交大模型。
| 方案 | 思路 | 标叔的结论 |
|---|---|---|
| 全塞 | 简单但笨 | 工具>20 就崩 |
| 懒加载 | 用到才给 | 大多数场景够 |
| 动态检索 | 按意图挑 | 工具成百上千必上 |
03.4 MCP 的工程真相：协议很好，也有硬伤
§03 把 MCP 吹成 USB-C。补个平衡视角——2026 年 6 月 lonae《MCP 工程实战》从五维扒了硬伤：
| 硬伤 | 表现 | 工程解法 |
|---|---|---|
| 传输 | 早期 stdio 难上云、难流式 | 换 Streamable HTTP 传输 |
| 鉴权 | 没有统一 auth 标准 | 网关层补 OAuth |
| 上下文膨胀 | 工具 Schema 全塞爆窗口 | 懒加载（03.3） |
| 发现 | 没有原生服务注册 | 中心化 registry |
| 可观测 | 中间过程黑盒 | 链路追踪补齐 |
核心建议：MCP 是方向，但别神话。接之前先想清：鉴权谁管？流式怎么推？失败了咋办？
03.5 Skills：Agent 时代的知识分发系统
这是 2026 很新的一种形态：把"某件事的 know-how"打包成可插拔的 Skill——里面是 prompt、流程、参考文档。Agent 需要时加载，像给人发一本操作手册。
它解决的是：知识不再写死在系统提示里，而是按需分发。你给 Agent 装 100 个 Skill，它一次只激活相关的两三个。
经验：Skill 本质是"上下文工程的产物"。它让"知识"从沉重提示，变成轻便、可版本化、可分享的模块。
03.6 你敢让 AI 直接跑 rm -rf 吗？四层防线
呼应 §07 七层安全。落到"执行"这一层，生产级权限要四道：
- 允许清单：只允许白名单命令/工具。
- 沙箱：在隔离环境跑，炸了不影响宿主。
- 人工审批：删库、外发、转账必须人点确认。
- 审计日志：做了啥全留痕、可撤销。
注意：永远别给 Agent 一个"全权限 Shell + 你的主账号"。宁可每步问你。