工具生态 + MCP 工程

0. 工具是手,但模型不会自动用好

先说清楚这一章和基础路书的分工,否则你又会觉得在重复。基础路书的 LLM API 章已经把工具调用这件事的协议讲清楚了:模型输出一段想调某工具的 JSON,你的代码去执行,把结果塞回去。那一层是词汇,是认得出。这一章从那里接着往下走,讲一件认得出之后才会撞到的事:给模型接上工具,和模型把工具用对,中间隔着大量工程。

这个差距比你以为的大。一个真实的对照能立刻说明:普林斯顿的 SWE-agent 研究让同一个 GPT-4 去解真实的 GitHub issue,只是换了工具接口。用一套为模型专门设计的接口(给模型量身定做的命令、编辑后自动跑 linter、把错误信息写得能指导下一步),解决率是 12.5%;而用非交互式的传统检索方式,只有 3.8%。更狠的是消融实验:同一个模型,自定义命令比直接丢给它一个原始 Linux shell,多解了将近 11 个百分点。模型没变,变的只是它和环境之间那层接口,成绩差出三倍多。

这件事逼出这一章的核心命题。这套研究给了一个很精确的说法:语言模型 agent 是一类全新的用户,它有自己的需求和能力,值得为它专门造接口。Anthropic 把同一句话说成一句口号:你投在 agent 与计算机接口上的功夫,应该和投在人机界面上的一样多。换句话说,过去几十年我们为人类用户打磨界面(按钮放哪、报错怎么写、信息怎么排),现在要为模型这个新用户重做一遍。

工具不是接上就完事的管道,它是一个要像设计人机界面一样去设计的接口——这个接口好不好,直接决定同一个模型能不能干成活。

理解了这个命题,这一章的结构就清楚了。它回答四个工程问题,层层递进:怎么写让模型用对的工具(第 2 节)、模型和工具之间那套协议的工程细节(第 3 节)、工具的来源怎么标准化和规模化(第 4 节 MCP)、当工具是图形界面或者要和别的 agent 协作时接口怎么设计(第 5 节、第 6 节)。

1. 怎么写让模型用对的工具

1.1 第一条也是最反直觉的一条:工具不是越多越好

vibe coder 接工具时的本能是:把后端每个 API 端点都包成一个工具,给模型一长串,让它自己挑。这个本能恰恰是错的。Anthropic 在工具设计的工程实践里把第一条原则说得很直白:更多的工具并不总是带来更好的结果。工具一多,模型的注意力被摊薄,容易选错、用错,光是几十个工具的定义就先吃掉一大截上下文。正确的做法是只建几个针对高价值工作流、深思熟虑的工具,而不是机械地一对一映射 API。

把这条原则落到具体手法,核心动作叫工具合并。与其给模型 list_users、list_events、create_event 三个工具让它自己编排,不如直接给一个 schedule_event,把那几步揉进一个工具内部;与其给一个 read_logs 把整个日志倒给模型,不如给 search_logs 只返回相关的几行;与其给一堆查客户信息的小工具,不如给一个 get_customer_context,一次把相关信息都编译好返回。合并的判据是工作流,不是 API 结构:模型真正要完成的是一件什么事,就给它一个对应那件事的工具。这条原则会在 第 4 节 的工具治理里再次回响,因为工具数量本身就是一个要管理的问题。

1.2 命名、返回值、错误消息:每一处都是性能变量

工具的名字不是给人看的标签,是模型判断该不该调它的依据,所以命名是性能变量而不是美学。给相关的工具加公共前缀来划清边界,比如一组工具叫 asana_search、asana_projects_search,另一组叫 jira_search,模型一看前缀就知道边界在哪。Anthropic 实测过,前缀式和后缀式命名在工具调用的评测上有不小的差异,命名方式真的会改变模型的表现。参数命名同理,用 user_id 而不是含糊的 user,少一分歧义模型就少填错一次。

返回值的设计同样是工程。一条原则是返回有意义的上下文而不是底层技术标识:给模型语义化的信息,而不是一个它无从理解的 UUID 或内部 ID。另一条更可量化、也最该记住的是为 token 效率优化返回值。Anthropic 给过一个具体数字:同一个工具,详细模式返回 206 个 token,精简模式只要 72 个,差出将近三分之二,所以可以给模型一个控制 verbosity 的开关让它自己选,默认就做好分页、范围选择、过滤和截断。Claude Code 内部甚至有一条硬上限:工具返回默认截到 25,000 个 token,超了就不让它无限膨胀。

最容易被忽略、但价值很高的一条是:错误消息也是返回值,而且是喂给模型的反馈。一手实践的说法是,要像做 prompt 工程一样打磨你的错误消息,让它清楚地告诉模型具体该怎么改进,而不是丢一个不透明的错误码或一长串栈回溯。一个好的错误消息会把模型引向更省 token 的行为(提示它用过滤或分页),或者直接给出正确输入格式的示例。这正是上一章把错误当成一次 observation 喂回循环那条原则,落到工具返回值这一层的具体写法。最后一条原则把前面几条收成一句话:把工具描述当成给一个新入职同事写的说明书,把所有隐含的上下文都显式写出来，专门的查询格式、小众的术语定义、几个底层资源之间的关系，你写得越像在带新人,模型用得越对。

1.3 工具不是一次写对的,是测出来的

上面几条原则会让你写出更好的工具,但它们有一个共同的陷阱:听起来像是写工具时凭经验就能一次到位。真实的工程不是这样。工具设计是一个测量然后优化的迭代闭环,而这个闭环恰好把这一章和后面的评测章缝在一起。

Anthropic 给了一个完整的做法。先用文档快速搭一个工具原型,本地接成一个 MCP server 跑起来;然后生成一批贴近真实多步工作流的评测任务,用一个简单的 agent 循环把这些任务程序化地跑一遍;接着分析模型的推理过程、每个工具的调用指标、出错的地方;最后，这一步很妙，把评测的完整记录直接粘给模型,让它一次性重构所有工具。它们实测发现,这样优化出来的工具在留出测试集上明显优于人手写的工具。这件事教给你的判断是,别指望坐在工位上把工具想对,把它当成一个可以测、可以迭代的工程对象,而度量它好不好的那套方法,就是 Ch9 评测章要专门讲的东西。

2. Function calling 的协议内幕

2.1 共同地基:模型只提议,执行永远是你的事

讲工具协议的工程细节,得先把那条所有 provider 共享的地基立稳,而 DeepSeek 的文档把它说得最白:模型本身不执行任何函数,它只提议要调哪个工具、填什么参数,你的后端才是真正的执行层,模型永远没有直接碰你 API 的权力。这句话你在基础路书见过它的协议形态,这里要你带着工程的眼光重看一遍:正因为模型只会提议、不会执行,一切权限、校验、安全、成本控制才都落在你截住那次提议、决定执不执行的那一刻。这也解释了上一章那个区分，harness 替你自动化的,正是接住提议、执行、把结果塞回去、再让模型继续这个循环;DeepSeek 故意只发协议契约、不发循环,就是把这层留给你自己看清。

2.2 schema 强制:从「请输出 JSON」到「解码器物理上发不出违规 token」

2024 到 2026 之间,function calling 最大的一次工程跃迁是模型怎么保证输出合法。早期的做法叫 JSON mode,本质是请模型尽量输出合法的 JSON,然后你自己写代码校验、出错重试，模型仍然可能吐出不合 schema 的东西。现在的做法叫结构化输出,机制完全不同:你把 schema 交给 API,模型在采样、也就是逐 token 解码的那一层就被约束住,解码器物理上不可能发出违反 schema 的 token。这不是事后校验,是从源头堵死。OpenAI 的说法很形象:它的解码器发不出违反你 schema 的 token。这一跃迁的工程含义是,2026 年的 production 默认用严格模式加 schema,JSON mode 已经是遗留做法。

但这里有一个迁移时真实会咬人的坑,值得专门记。OpenAI 的几家(包括 DeepSeek 的严格模式)对 schema 有硬要求:对象的每个属性都必须标成必填,而且必须显式禁止额外属性,可选字段只能用允许 null 的类型来表达。更要命的是,OpenAI 较新的 Responses API 默认就把你的 schema 规范化成严格模式，自动把所有字段设成必填，这会把你原本设计成可选的字段悄悄变成必填,除非你显式关掉严格模式。从老接口迁过来的人很容易在这里栽跟头:同一份 schema,换个接口,行为变了。

2.3 并行、流式,和一条直接接上一章的硬规则

工具协议还有两个工程维度值得点到。一个是并行调用:OpenAI 默认就允许模型一轮提议多个工具调用,你可以用参数强制它最多调一个;DeepSeek 和 Anthropic 也都支持一轮多调。另一个是流式:工具调用的参数是逐 token 流式拼出来的,所以你的 harness 要会增量解析还没拼完的 JSON,这跟上一章流式那一节是同一件事的两面。

但最该记住的是一条直接接上一章的硬规则。上一章讲过,reasoning model 时代循环要多搬运一层模型的推理状态。落到工具协议这一层,规则非常具体:普通的多轮对话不需要回传模型的推理片段,但一旦涉及工具调用,你必须把上一轮的推理状态回传回去,否则 reasoning model 会变笨变贵。这正是 上一章 reasoning-model 原生 loop 那条命题在 API 工具层的精确落点,想复习那条命题的来龙去脉可以点回去。这里你只需要记住工具侧的操作结论:跨工具调用,推理状态必须跟着工具结果一起搬运。至于模型内部到底怎么推理,那是模型设计路书的事,跟这条工程规则正交。

3. MCP 工程:从一个工具到一个生态

3.1 为什么需要 MCP:把 M×N 收成 M+N

到这里你会写好单个工具、也懂了协议。但真实系统里工具来自四面八方，GitHub、Slack、内部数据库、各种 SaaS，这就冒出一个会指数爆炸的麻烦。没有统一标准时,每一个 agent 应用(host)要接每一个工具,都得写一套专属的对接代码:三个 host 接三个工具就是九套,接第四个工具就再添三套,这是一个 M 乘 N 的组合爆炸。MCP(Model Context Protocol)就是来解这堵墙的,它定义一套统一协议,让工具只要按这套协议暴露一次,所有支持 MCP 的 host 都能用，M 乘 N 一下子收成了 M 加 N。它常被类比成工具接入界的 USB-C:设备和接口各自只认一个标准,就不用为每一对组合单独造线。

这堵墙的时间线值得记一句,它也是一个清晰的 why-now 锚。2024 年工具接入还是各家拼各家的 hack,每接一个就写一套;2024 年底 Anthropic 推出 MCP 把它标准化;到 2025 年 12 月,Anthropic 把 MCP 捐给了 Linux Foundation 旗下新成立的 Agentic AI Foundation,交给中立基金会托管。一个协议从一家公司的提案走到中立治理,本身就是它从尝试变成行业基础设施的信号，到 2026 年,MCP 已经是企业默认,公共注册表里有近万个 server。

3.2 MCP 的架构:三个角色、两层、一次能力协商

把 MCP 拆开看,它的骨架是三个角色。Host 是 AI 应用本身,比如 Claude Code 或 VS Code,它协调多个连接;Client 是 host 为每一个 server 单独创建的连接代理,一个 server 对应一个专属 client;Server 才是真正提供能力的程序,可以跑在本地也可以在远端。一个 host 连五个 server,内部就有五个 client 各管一条专属连接。这套通信架在两层上:内层是数据层,用 JSON-RPC 这套成熟的远程调用协议定义生命周期和能力;外层是传输层,负责实际的信道和鉴权。同一套消息可以跑在不同的传输上。

连接建立时有一步很关键,叫能力协商。MCP 是个有状态的协议,client 和 server 一握手就先交换彼此支持哪些能力、用哪个协议版本,版本不兼容就直接断开。传输层目前有两种主流选择,各有适用场景:本地的 server 走标准输入输出,进程间直接通信,零网络开销,像本地文件系统这种 server 就用它;远程的 server 走可流式的 HTTP,支持标准的 HTTP 鉴权,推荐用 OAuth 拿 token,这是远程 server 的标准选择。早期那种 HTTP 加长连接的传输方式现在已经降级成只为向后兼容保留,新设计别再用。

3.3 MCP 不只是远程 function calling

这里要纠正一个很常见的窄化理解。很多人(包括只在基础路书听过 MCP 的人)以为 MCP 就是把 function calling 搬到远程,server 暴露的只是工具。其实 MCP 的完整面比这大,server 能暴露三种东西:工具是可调用的函数,资源是上下文数据源(文件内容、数据库记录、API 响应这些可以被读进上下文的东西),提示是可复用的交互模板。光看到工具,你就只用了 MCP 的三分之一。

更能体现 MCP 高出一截的,是它还允许 server 反向向 host 请求两件事。一件叫采样:server 可以请 host 用它的模型出一段完成,这样 server 自己不用内嵌任何大模型 SDK 就能用上模型能力,保持模型无关。另一件叫诱导(elicitation):server 可以反向向用户要更多信息或请用户确认一个动作。这两件事是 MCP 比普通工具 API 高级的关键，server 不只是被动地被调用,它还能借用宿主的模型和宿主的用户。MCP 里还有一个标着实验性的能力叫任务(Tasks),是给昂贵的多步操作做延迟取结果加状态追踪的包装,本质上是上一章那个 durable execution 的思路在协议层自己长出来的原语,说明长任务这件事连协议自己都在往里收。

3.4 工具多了怎么治理:网关与按需加载

MCP 让接工具变容易了,但容易接也意味着很快就会接很多,于是治理本身成了新问题。一个 agent 连几十个 server、每个 server 一条连接,很快就不可治理了。所以 2026 年长出了一个新的基础设施品类叫 MCP 网关:它是 agent 和一堆 server 之间的统一控制面,把多个可信 server 聚合到一个入口,统一处理鉴权传播、会话路由、审计、单点登录。你不需要记住具体哪家网关,只要知道这个治理层存在、以及它解决的是连接和权限的规模化问题。

另一个更直接戳中模型的规模问题是上下文。连一堆 server,几百个工具的定义会先吃掉几万甚至几十万 token,还没开始干活就烧掉一大截,而且工具一多模型选得也更差。解法是按需加载工具而不是全量前置。Anthropic 的工具搜索机制让你把工具标成延迟加载,它们一开始不进上下文,模型需要时先用一个搜索工具按名字或描述找,命中了才把完整定义展开进来。实测这能省掉大约 85% 的 token(五十多个工具从七万多压到八千多),工具选择的准确率在不同模型上从大约一半提升到七到九成。这其实是 第 1 节 那条工具合并原则在规模层的另一条路:要么写少而精,要么写多但按需加载,两条都是在治理工具数量。

3.5 一个正在收敛的范式:让 agent 写代码调工具

工具规模化还逼出了一个 2025 到 2026 年很值得记的范式转变,而且它是两家独立得出同一个结论的,这种收敛本身就说明它不是噱头。核心想法是:与其让模型一个一个地直接调工具,不如把工具呈现成代码 API,让模型写一段代码来编排这些工具。这样能同时砍掉两类浪费，工具定义不用全量前置(模型按需读它要用的那几个),工具之间传递的中间结果也不用来回过模型的上下文(在代码里就处理掉了)。

两家的数字都很惊人,但要诚实地标清楚口径。Anthropic 的方案是把每个 MCP server 当成文件系统上的代码文件,模型按需读取、写代码调用;它举的招牌例子是把一份谷歌文档的内容写进 Salesforce,直接用工具调用要十五万 token,改成写一行代码把前者的内容喂给后者,只要两千 token,省了将近 99%。但要注意,Anthropic 这套目前是一个论证和提案,不是已经上生产的成品实现。Cloudflare 的方案叫 code mode,把 MCP 工具转成带类型和文档的 TypeScript API,让模型写 TS 在一个轻量沙箱里跑,它的服务端版本用搜索加执行两个工具暴露整个 Cloudflare API 的两千多个端点,把一百多万 token 压到大约一千,而且和 API 规模无关。它给的理由很朴素:模型在训练数据里见过海量代码,所以它写代码调工具,比直接调工具更在行。这套范式还顺带连上后面两章，凭证由宿主注入、模型写的代码碰不到密钥,这是 Ch4 和 Ch5 会展开的安全好处。这两家从完全不同的机制走到同一个结论,是一个很值得你记住的趋势。

4. 当工具是一个图形界面

4.1 同一个循环,换一套感知和动作接口

到目前为止工具都是函数。但工具也可以是一整个图形界面:让模型看屏幕截图,然后输出点击坐标、键入、滚动,去操作一个本来给人用的软件。这件事听起来是全新的,其实结构上你已经会了。上一章那个 framing 注 已经埋过引子:循环是模态无关的。把那个感知、推理、动作、再感知的状态机原封不动拿过来,把观测从文本和工具结果换成屏幕截图,把动作从工具调用换成点击和键入,你就得到了一个图形界面 agent。这正是 第 0 节 那个接口思想从命令行界面推广到图形界面:SWE-agent 证明了为模型设计 shell 接口有用,同一个道理,图形界面也要为模型设计一套动作接口。

具体看 Anthropic 的 computer-use,它的动作集就是一套为模型设计的接口:截图、点击某个坐标、键入文本、按组合键、滚动、拖拽,较新的版本还加了一个放大某块区域的动作,专门用来应对小按钮和高分屏看不清的问题。它的循环和上一章的文本循环完全同构:模型看截图、返回一个动作、你的应用在容器或虚拟机里执行、把新截图作为结果回传、直到模型不再请求动作或撞上轮次上限。一手文档反复强调的那条契约在这里同样成立，你的应用必须自己去执行这个动作,模型不能直接执行,动作空间是契约、执行是 harness 的事。至于这个图形界面在哪跑、怎么安全地跑(虚拟显示、容器隔离),是 Ch4 沙箱那一章的对接点。

4.2 token 是硬约束,observation 怎么表征是纯工程决策

图形界面 agent 有一个绕不开的硬约束:token。截图很贵,而且模型给的坐标是在被 API 缩小过的图上给的,你的工具得把坐标缩放回真实屏幕,否则就点歪，这类细节是 grounding 的工程,纯视觉理解本身(模型怎么从像素里认出那是个按钮)归多模态路书,这里不展开。

真正属于这一章、也最该立住的一个工程决策是:你到底喂什么表征回循环。这不是视觉质量问题,是给循环喂什么数据结构的问题,而它有三条路,各有取舍。一条叫标记截图,在截图上把可交互元素叠上编号框,贵(一张截图就要七百多 token,每一步都付),但几乎什么都能跑,canvas、混淆过的页面、嵌套框架都不在话下。一条叫无障碍树,用浏览器生成的语义化结构来表征界面,便宜得多(一页两三百 token,而原始的网页结构是上万 token 的噪声),但它依赖站点的语义标注质量,而现实里近 95% 的站点标注是脏的,所以纯靠它很脆。第三条是混合,以无障碍树为主、视觉为兜底,2026 年的主流就倒向了这一条。

这个选择的分量在于它会层层传导:你选了哪种表征,直接决定速度、成本、准确率、哪些站点能跑、哪些站点改版就崩。observation 表征的更深入工程(怎么动态裁剪、怎么压缩)是 Ch6 上下文工程那一章的事,这里先把这个分叉立住就够了。还有一件必须埋的引子:图形界面 agent 会从屏幕上读到内容,而屏幕上的内容可能藏着恶意指令，网页里、图片里写一句话就可能劫持你的 agent。这是一个全新的攻击面,Ch5 对抗安全会专门讲;这里你只要先意识到,给 agent 装上看屏幕和动手的能力,同时也打开了一扇被攻击的门。

5. Interop:agent 不止连工具,还连别的 agent

最后一节给你一张更大的坐标图。MCP 不是唯一的协议,2025 到 2026 年已经成型了三个协议,各管一条腿,你该知道它们的分工,免得把它们搞混或以为 MCP 包打天下。MCP 管的是 agent 连工具和上下文,这是这一章的重心。A2A(Agent2Agent)管的是 agent 连 agent:它定义 agent 之间怎么互相发现能力、怎么把一个任务交给另一个 agent 去做,到 2026 年已经发布 1.0、有一百五十多个组织在生产里用,还吞并了主要的竞争协议,基本成了这条腿上没有替代品的标准。第三个叫 AG-UI,管的是 agent 连用户和前端,把 agent 后端的消息、工具调用、状态变化以事件流的方式推给界面，MCP 当初不是为前端设计的,没有界面事件流这种原语,AG-UI 来补这条。

这三者是互补不是竞争,一个常见的架构是 agent 之间用 A2A、agent 内部接自己的工具用 MCP。有个心智模型说得好:如果 MCP 是管道,A2A 就是配电盘，单个 agent 的管道铺得再好,多个 agent 组成的协作网络还得能互相传电。这一节只给你坐标、不展开:A2A 那套 agent 之间怎么标准化地交接任务,是 multi-agent 协同的事,留到 Ch8,到时候会拿它和我们现在在 SDK 进程内做的 handoff 做对照。你现在记住三条腿的分工就够了。

综合 · 你给 agent 装好了手

回头看你这一章拿到了什么。你拿到了一条贯穿全章的命题:工具是一个要像设计人机界面一样去设计的接口,同一个模型接口好不好,成绩能差三倍。你拿到了写好工具的几条具体原则，工具不是越多越好、合并成面向工作流的工具、命名和返回值都是性能变量、错误消息是喂给模型的反馈、描述要像带新人,以及一条心法:工具是测出来的不是想出来的。你看懂了模型和工具之间那套协议的工程内幕，模型只提议你来执行、schema 在解码层就被强制、reasoning 状态必须跨工具调用搬运。你理解了 MCP 怎么把 M 乘 N 的集成爆炸收成 M 加 N,它的完整面不只是远程工具还有资源、提示、采样、诱导,以及工具规模化逼出的两条治理路，按需加载和让模型写代码调工具。最后你拿到了图形界面作为动作接口的设计要点,和 agent 协作生态的三协议坐标。

把这些和上一章合起来,你脑子里那台 harness 现在又多了一层:中间是会转的循环,外面包着终止和恢复,现在又接上了一套精心设计、能规模化治理的工具接口，agent 有了一双能用对的手。你从会搭一个空转的循环,走到了能给它装上真正能干活的工具。

你完成了第二站的第二块。合上书,去动手:把上一章那个最小循环接上一两个真工具,故意给一个工具起一个含糊的名字、写一个啰嗦的返回值,看模型怎么用错;再按这一章的原则把名字、返回值、错误消息改一遍,亲手感受接口设计对模型行为的影响。下次回来,我们要解决一个被这一章反复推迟的问题:这些工具会真的改文件、跑命令、动数据库,怎么让它们安全地跑。

本章术语速查

下面按本章顺序复习。加粗是术语,后面是一句话解释;带链接的词可点进术语表看更完整的解释。

接口与工具设计

• ACI · agent-computer interface 为模型这个新用户专门设计的接口;投入应像投人机界面一样
• 工具合并(tool consolidation) 把面向工作流的多步揉进一个工具,而非一对一映射 API
• 命名空间 给相关工具加公共前缀划清边界;命名是性能变量不是美学
• token 效率返回 分页 / 过滤 / 截断 / verbosity 开关;错误消息也是喂给模型的反馈
• eval 驱动的工具开发 工具是测出来的:原型 → 接 MCP → 跑 eval → 据记录重构(连 Ch9)

function calling 协议

• proposal-based 契约 模型只提议工具调用,执行永远是 harness 的事
• 结构化输出(structured outputs) schema 在解码层被强制,模型物理上发不出违规 token(区别于会校验的 JSON mode)
• Responses 默认 strict 坑 新接口默认把可选字段变必填,迁移要当心
• 推理状态跨工具调用回传 涉及工具调用必须回传 reasoning 状态,否则模型变笨变贵(见 Ch2 第 4 节)

MCP

• MCP 三角色 Host(AI 应用)/ Client(每 server 一条专属连接)/ Server(提供能力)
• MCP 完整 primitives 不只 Tools,还有 Resources(数据源)/ Prompts(模板)+ Server 反向的 Sampling / Elicitation
• MCP 网关 agent 与一堆 server 之间的统一控制面,治理鉴权 / 会话 / 审计
• 工具搜索 / 按需加载(tool search) 工具延迟加载、用时再搜,省约 85% token
• 代码即工具(code execution as tool) 让模型写代码编排工具,砍掉定义 + 中间结果开销 1-2 个数量级

GUI 与 interop

• Set-of-Mark 截图叠编号框喂模型;贵但几乎啥都能跑
• 无障碍树(accessibility tree) 语义化界面表征;便宜但依赖站点 markup
• observation 表征取舍 喂截图还是喂结构树,cascade 到成本 / 鲁棒 / 哪些站点能跑
• A2A agent ↔ agent 协议(对照 MCP 的 agent ↔ 工具);深入归 Ch8
• AG-UI agent ↔ 用户/前端的事件流协议

进阶词汇(context engineering / trajectory eval / 对抗安全等)归后续章节,完整术语见术语表 /glossary。

参考文献

Mode A · 引用出处(正文 inline,集中列在此)

• Writing effective tools for AI agents(Anthropic · 2025)· 第 1 节 工具设计 5 原则 + token 效率数字(206→72 · 25k 上限)+ eval 驱动闭环 · 本章 第 1 节 主源
• Introducing advanced tool use(Anthropic · 2025)· 第 3.4 节 工具搜索 defer_loading −85% / 准确率提升 · beta 数字按版本自测
• Code execution with MCP(Anthropic · 2025)· 第 3.5 节 代码即工具 150k→2k(诚实标注:proposal 非 shipped)
• Model Context Protocol · Architecture(spec rev 2025-06)· 第 3 节 Host/Client/Server + 两层 + 完整 primitives + transport
• OpenAI · Function calling + Structured Outputs · 第 2 节 解码层强制 strict + Responses 默认 strict 坑
• DeepSeek · Function Calling · 第 2.1 节 proposal-based 裸层契约(模型提议、harness 执行)
• Anthropic computer-use tool docs · 第 4 节 GUI 动作空间(截图/点击/键入/缩放)+ 坐标缩放 + 注入分类器
• SWE-agent · Agent-Computer Interfaces(Princeton · 2024)· 第 0 节 ACI thesis 实证锚(12.5% vs 3.8% · 消融 +10.7pp)

深 dive 资源(可选 · 想往下走再看)

• Cloudflare · Code Mode · 第 3.5 节 代码即工具的独立收敛证据(TS API + V8 isolate · 1.17M→1k · 凭证不可泄)
• Browser Use(MIT)· 第 4.2 节 无障碍树 + ref 范式的开源 real-case,可读
• A2A Protocol(Linux Foundation)· 第 5 节 agent↔agent 标准(Agent Cards · 任务生命周期)· 深入 Ch8

说明:Agent 工程领域目前没有合格的人讲解系统教学视频,所以本章是纯 Mode A,由原创讲解 + 一手文档/论文/源码扛起。本章涉及的 token / 准确率数字多为厂商 beta 发布时点值,会随版本和 workload 变,引用前按当前文档与自己的负载复核。

下一章

下一章(Ch4)进入第二站的第三块 · 安全执行 ① · 沙箱与执行环境。你这一章给 agent 接上了能改文件、跑命令、动数据库的工具,但这些工具一旦真的执行,就意味着模型生成的代码会在你的机器上跑，这是向内的威胁。Ch4 会讲怎么用沙箱把它关起来:隔离机制的强度阶梯、文件和网络的策略边界,以及一个最高教学价值的真实案例，连前沿实验室都在出口管控上栽过的坑。