第 2 章：工具是合同，不是魔法

工具在官方体系里的位置非常清晰：它是一个被结构化定义的接口，模型只能通过这个接口去“请求”外部能力。最小定义包含名字、描述和输入 schema；描述写得越清楚，模型就越知道什么时候该用、什么时候不该用。你可以把它理解为“对模型开放的一小扇窗”，窗外是系统能力，窗内是严格格式。[4][5]

工具调用的语义也不是“模型直接执行”。模型会先发出 tool_use 请求，你的系统或运行时真正执行工具，再把 tool_result 反馈给模型。这个往返链路决定了工具的可控性：错误要结构化、返回要可检验，否则模型很难稳定学习正确用法。对长耗时工具，官方提供了更细粒度的流式协议；对需要在代码环境中再调用工具的场景，还提供 programmatic tool calling，让复杂的数据流发生在受控容器里，而不是在对话里反复堆叠。[6][7]

当工具数量变多，问题从“有没有工具”转为“模型如何找到正确工具”。工程文章提出的 Tool Search Tool 就是把“找工具”单独做成一个入口，其余工具延迟加载。这样模型先用搜索找到少量相关工具，再加载完整定义，不再把所有工具一次性塞进上下文。[54][8]

同一篇文章还强调了“用代码调用工具”的价值。让模型在 code execution 里写脚本调用工具，可以把循环、筛选、聚合都放在程序里执行，只把必要结果返回给模型。这样既减少上下文开销，也让控制流更可靠。对大型工具库而言，这种分层调用比单次对话内的多轮工具调用更稳定。[54][6][12]

工具设计本身也需要工程化。写工具不是在写给开发者用的 API，而是写给“会犯错的执行者”。工程博客给出的思路是：工具集合要少而清晰，命名边界要明显，返回结果要优先给高信号字段，错误信息要具备可执行的修复方向。更重要的是，用评测发现模型的误用模式，再反向修订工具描述与参数结构。[65]

当任务链条复杂、需要严格遵守规则时，Anthropic 提出过一个“think”工具，让模型在关键节点显式写出规则检查与信息缺口。后来他们更推荐 extended thinking，但核心思想一致：在复杂工具链中给模型一个可被触发的“停顿层”，而不是把推理完全隐含在生成中。[58]

技能体系把“工具合同”推进到更高的组织层。Skill 本质上是一个目录，入口是 SKILL.md，必要的细节再分散到其他文件。这种分层加载被称为渐进式披露：模型先看到最少的元信息，当判断需要时再加载更深内容。它的作用不是让模型更聪明，而是让团队的经验可复用、可维护。[1][3][63]

Skill 也可以包含脚本，模型可以在需要时执行脚本而不是把代码读进上下文。这样既节省上下文，又让复杂操作更稳定。把“流程 + 代码 + 资料”组织成目录后，Skill 更像一个可传递的作业手册，而不是一次性的提示词。[63][24]

内建工具可以理解为几类“现成通道”。Web search 和 web fetch 负责把外部信息引入上下文，tool search 用来在大量工具中定位目标；memory 提供跨会话存储；code execution 提供受限计算环境；bash 和 text editor 则是对本地文件和命令的精细操作；computer use 更像远程操控屏幕，让模型通过 UI 完成任务。它们覆盖信息、计算、文件与交互四个维度，但每一种都依赖清晰的边界与权限配置，因为模型只会按合同执行。[8][9][10][11][12][13][14][15]