N×M 与统一接口 — 模型凭什么知道你有哪些工具
这一章讲三件事: 为什么「多接几个系统」不是加法而是乘法; 一套统一接口怎么把这个乘法压回加法,以及它明确没有管的那几件事; 还有全章最该讲透的那个机制——模型是怎么知道你有哪些工具的。
它在全书链条里的位置: 第 13 章讲了一个 agent 怎么用工具。 这一章讲工具变成几十个、几百个之后怎么办。 第 15 章接着讲工具出错时该返回什么。
1. 顶层全景:一句「我要一件 100 美元以下的轻便马甲」
这一章的主走查是一次完整的购物问答,从算账开始,到模型写出回答为止:
① 先算账:5 个 AI 应用 × 10 个外部系统 = **50 套各写各的集成代码**
▼
② 换成统一接口:每个外部系统一个服务端、每个应用一个客户端
→ 5 + 10 = **15 套**
▼
③ 我们拿一份七行的商品表格,建出第一个工具:
`search_products(query, max_price, limit)`
▼
④ 用户说人话:**「我要一件 100 美元以下的轻便马甲。」**
▼
⑤ 运行时去问服务端「你有哪些工具」→ 服务端回:工具名、三个参数、各 是什么类型
▼
⑥ 模型自己构造出调用:`{"query": "lightweight vest", "max_price": 100}`
▼
⑦ 这次调用被自动路由到我们的服务端 → 服务端查表格 → 返回 JSON
▼
⑧ 模型写回答:「我找到一件 100 美元以下的轻便马甲:
女士便携马甲,79.99 美元,现货。」
(**这句回答和书自己第 ③ 步那张商品表对不上**——表里 79.99 美元的是防水雨衣,
女式羽绒马甲标的是 99.00。**这是原书未定稿的一处错,不是我们抄错**,详见第 4 节末尾)
▼
⑨ 再挂第二个工具 `check_inventory`,看它自己决定**先搜后查**
图说:第 ⑤ 步是这一章唯一的新机制,其余都是第 13 章那个循环的重演。
**五十变十五、七行表格、79.99 美元这些数都是书里的原数**——
连第 ⑧ 步那句对不上的回答,也是书里的原样。
2. 先算那笔账:它不是加法,是乘法
这一节讲这一章存在的全部理由,而且它只需要一次乘法就能讲完。
先看现象:三件简单的事,三套各崩各的代码
书的开场很有画面感:
你的 AI 助手又崩了。顾客让它查库存、发一条通知、处理一笔付款——三件简单的事。 可你的代码里有 500 行自己写的支付集成、300 行通知服务的对接,而且它们各崩各的。1
为什么会这样:每多一样东西,要写的代码是乘出来的
书把账算得非常具体2:
你的团队在做 5 个 AI 应用:
客服机器人 / 内部邮件助手 / 日程 agent / 文档摘要工具 / 电商助手
每一个都要接同一批外部系统(10 个):
客户数据 / 通知 / 日历 / 商品库存 / 支付 / 内部数据库 …
如果每个应用各自去对接每个系统:
5 个应用 × 10 个系统 = **50 套自己写的集成代码**
→ 其中任何一个系统改了接口,**你要在五个地方分别改**
图说:**关键在那个乘号。** 应用数和系统数各自增长,
要维护的代码量按两者的乘积增长——**这就是「N×M 问题」这个名字的来历。**
书还引了一个数:74% 的企业正在管理或者计划管理超过 500 个数据源3。
这个数请打个问号读。 书给的参考文献指向的那份报告, 标题讲的是另一回事(「近一半企业 AI 项目因数据就绪度差而失败」),和这个 74% 对不上。 我们没能核到一手来源。
3. 那套统一接口:50 变 15
这一节给这一章的名字,并且立刻划清它的边界——边界比名字重要。
做法:两边各定一套标准,中间只有一种对话方式
没有统一接口: 应用 A ──自己写的胶水──► 系统 1
应用 A ──自己写的胶水──► 系统 2
应用 B ──自己写的胶水──► 系统 1 ← **同一个系统又写一遍**
…… 一共 50 条线,每条都不一样
有统一接口: 每个外部系统 → 做成一个**服务端**(共 10 个)
每个 AI 应用 → 用同一套**客户端**逻辑去连(共 5 个)
→ **一共 15 件东西,而且它们之间的对话方式完全一样**
图说:**省下来的不是 35 段代码,是「每一条线都长得不一样」这件事。**
新接一个系统,只要它做成了服务端,**五个应用一个字都不用改就能用上。**
上图里那两个词先说清: 一件东西主动去连别人、发起请求,行内叫客户端 (你的 AI 应用就是客户端);在那头等着被连、收到请求就干活并回结果的,叫服务端 (每个外部系统包一层做成的就是服务端)。这一对词后面几章一直在用。
这套协议的名字叫模型上下文协议,缩写 MCP ——你在任何一份 agent 工具的文档里都会撞见这三个字母4。
书给它的比方是:它就像 AI 世界的 USB。 新工具插上就能用。 这个比方到此为止,后文一律说「统一接口」或者直接叫 MCP。
边界:它管什么,它明确不管什么
这一段是整章最容易被误解的地方,书自己写得很清楚,我们原样传达:
协议处理的是格式校验和错误格式。 但认证、授权、以及你那个服务端本身的安全,仍然是你自己的责任。 ——MCP 统一的是接口,不是安全模型。5
书在几段之后又补了一刀,措辞更狠:
MCP 大幅减少样板代码,但每个工具背后真正的执行逻辑仍然要你自己写。 MCP 统一的是 AI 和工具之间的接口,并不意味着模型在生成或执行后端代码。 目标是让集成变简单,不是变自动。6
为什么这两句非留不可: 因为「统一接口」这四个字最容易让人以为 「接上就自动能用了」。实际情况是——
| 谁负责 | 什么 |
|---|---|
| 协议负责 | 参数长什么样、类型对不对、出错了错误消息是什么格式 |
| 你负责 | 工具里面真正干活的那段代码 |
| 你负责 | 谁能调这个工具、他有没有权限(认证与授权) |
| 你负责 | 服务端本身别被人打进来 |
采用情况(书写于 2026 年):这套协议由 Anthropic 在 2024 年末开源, 现在托管在 Linux 基金会之下,OpenAI、Google、微软、AWS 都支持; 官方注册表里列着数千个服务端,主流 agent 框架原生支持7。
4. 全章最该讲透的一步:模型凭什么知道有哪些工具
这一节是这一章唯一的新机制,也是它和第 05 章那个函数调用真正的分水岭。
先看现象:同样是「模型开口说要调什么」,来源不一样
第 05 章讲过函数调用:你在每次请求里,把函数的名字、参数、描述一起带上去, 模型看了之后决定调不调。
这一章的做法不一样:
函数调用:
你的请求 ──► 模型
请求里带着:「你有这几个函数可用:get_weather(city: str) —— 查天气」
**每一次请求都要带一遍,由你负责带**
统一接口:
你的请求 ──► 运行时 ──► **去问服务端:「你有哪些工具?」**
◄── 服务端回:名字、输入参数、输出格式、用途
**清单由服务端自己提供,模型去问**
图说:**这就是那条分水岭。** 一边是「你每次告诉它」,
一边是「它自己去问」——**而后者意味着你新加一个工具,请求那边一个字都不用改。**
书的原话:每个服务端都实现一个专门的工具清单接口, 返回每个工具的机器可读描述:名字、输入参数、输出格式、用途。8
运行时会在对话开始时去取一次这份清单,把它加载进对话上下文; 从那一刻起,模型对这些工具的推理方式,和对内置函数完全一样。
书对这件事的总结值得记:你那个跑着的服务端,因此从「一堆接口」变成了 「一份声明出来的能力清单」。模型看到的不是裸的地址, 而是「搜索一件商品」「查一下有没有货」这种有语义 的动作。9
补充(不在书里,依据我们的协议书架):书把这份清单说成「一个专门的端点」, 这在实现上不够准确。 客户端和服务端之间发的,是一种叫 JSON-RPC 的消息—— 说白了就是:用一段 JSON 写清「我要调哪个方法、参数是什么」发过去,对方再回一段 JSON。 取工具清单用的那个方法名,就叫
tools/list。10
这个方法返回的每个工具,除了名字和描述,还带一份 JSON Schema ——那是一份用 JSON 写的「参数说明书」:每个参数叫什么、是数字还是文字、必不必填, 都写在里面。 模型正是照着它填出上面第 ⑥ 步那两个字段的。 这个区别对你有实际用处:去翻规范时,该搜的是方法名,不是网址路径。
走查第 ③–⑧ 步:从七行表格到一句回答
书选了一个很聪明的起点:不接真的电商接口,而是用一份七行的表格文件当数据源。 理由它写得很实在:任何人都能跑你的代码,不需要凭据、不需要联网、不需要平台特定的配置。11
③ 那份表格(书里的原数据,七行):
id, title, price, available
1, 男式越野跑鞋, 89.99, 有货
2, 防水雨衣, 79.99, 有货
3, 女式徒步裤, 64.99, **无货**
4, 加厚羽绒服, 129.00, 有货
5, 透气速干内衣, 39.99, 有货
6, 男式羊毛帽, 24.99, 有货
7, 女式羽绒马甲, 99.00, 有货
工具:search_products(query, max_price, limit=5)
按标题 匹配 → 按价格上限过滤 → **只留有货的** → 截断到 limit 条
→ 返回一个字典列表
④ 用户输入:「I need a lightweight vest under $100.」(我要一件 100 美元以下的轻便马甲)
**注意这句话里没有任何关于「该调哪个工具」的提示。**
⑤ 运行时去取工具清单 → 拿回 search_products 的三个参数和它们的类型
⑥ 模型构造出:
{"name": "search_products",
"arguments": {"query": "lightweight vest", "max_price": 100}}
⑦ 这次调用被自动路由到我们的服务端 → 服务端查表格 → 返回 JSON
⑧ 模型写回答:「我找到一件 100 美元以下的轻便马甲:
女士便携马甲,79.99 美元,现货。」
图说:**第 ⑥ 步是这条走查的心脏。** 从「lightweight vest」这句人话,
到 `query` 和 `max_price` 两个字段的值,**中间没有一行是我们写的**——
**是模型看了工具清单之后自己填的。**
(七行表格、参数名、那句回答都是书里的原样;
**书示例里给出的价格 79.99 对应表格里的防水雨衣,而它给的回答说的是「女士便携马甲」
——这两处在原书里对不上,是未定稿的一处小错,我们照实标出来。**)
返回格式那一句也值得记: 工具把结果转成一个字典列表再返回, 书说这正是模型最好用的格式——简单、结构化、像 JSON 的数据,它能逐条遍历、能推理、能讲给用户听12。
中间还有一步:怎么确认它真的通 了
书专门给了一节讲这个,而它很容易被跳过。
做法:把服务端跑起来,用一个命令行工具连上去,像模型那样手动调一次。13
在命令行里输入: search_products query="jacket" max_price=100
应该看到: [ { "id": 2, "title": "Waterproof Rain Jacket",
"price": 79.99, "available": true } ]
再试几个词(vest、pants、layer),观察它怎么响应:
东西存在而且有货 → 出现在结果里
**无货 → 返回空列表**(比如那条「女式徒步裤」)
图说:**这一步的价值在于把「模型不听话」和「工具本身有毛病」分开。**
自己手调一遍通了,后面出问题就一定在模型那一侧。
一条书用加粗标出的安全警告
示例代码里有一个参数被设成了「从不需要审批」,书特意停下来说明:
在生产里,这意味着 AI 可以不经任何人类监督执行任何一次工具调用 ——包括修改数据、下单购买、发送通讯。 敏感操作要设成「总是需要审批」,或者自己实现一套审批逻辑, 高风险动作必须由人确认。14
这条和第 13 章那条分水岭是同一件事的两面: 第 13 章说「工具会改变外部世界」,这里说「所以默认不该让它随便改」。
5. 工具描述其实是写给模型看的路由指令
这一节讲一件看着像文档规范、实则是可靠性问题的事。
先看现象:两个工具名字起得含糊,模型就会选错
书先给了一句总纲:
建的工具多了,你会开始把服务端看成另一种东西: 它不是一堆接口的集合,而是一个面向语言模型的接口层。 工具怎么命名、怎么描述、参数怎么设计,都在影响模型怎么用它。15
反例书给得很直接:一个参数就叫 x。 模型既不知道那是什么,
也不知道什么时候该用这个工具。
走查第 ⑨ 步:两个工具,模型自己决定先后
书在服务端上又挂了第二个工具 check_inventory(查某个具体商品的库存状态),
然后问了一个需要两步的问题16:
用户问:「你们有防水夹克吗?最便宜那件有货吗?」
① 模型推理:「我得先找防水夹克」
→ 调 search_products(query="waterproof jacket")
② 拿到:[{id: 2, title: "Waterproof Rain Jacket", price: 79.99}]
③ 模型推理:「我该确认最便宜那件有没有货」
→ 调 check_inventory(product_id=2)
④ 拿到:{found: true, product: {available: true, status: "In Stock"}}
⑤ 答:「有的!防水雨衣 79.99 美元,现在有货。」
图说:**这一串是自动发生的,我们没有写任何编排代码。**
模型根据问题和工具描述,自己决定调哪些、按什么顺序调。
那么它凭什么决定顺序?靠工具的描述
书把这一点讲成了一条硬规矩:
| 工具 | 它的描述 | 模型据此把它用在哪 |
|---|---|---|
search_products | 「搜索商品目录」 | 发现——我还不知道有什么 |
check_inventory | 「查某个具体商品的库存状态」 | 核实——我已经有 ID,要确认一件事 |
书的原话:如果你把这两个都起个含糊的名字(get_products、get_product_info), 模型就会难以正确选择。清晰的描述,起的是路由指令的作用。17
「路由指令」这个说法请记住,它把一件事从「文档写得好不好」变成了「系统跑不跑得对」: 描述写得含糊,不是文档质量问题,是这个 agent 会走错路。
判断(我们的,不是书里的): 这条规矩的实用推论是 工具描述应该按「什么时候该用我」来写,而不是按「我干什么」来写。 「搜索商品目录」 是在说它干什么;「当你还不知道有哪些商品时用这个」才是在说什么时候用它。 后者才是模型做选择时真正需要的信息。 如果错,会错在: 如果你的工具集里每个工具的用途本来就泾渭分明(只有一个搜索、一个下单), 怎么写都不会选错,这条讲究就是多余的。 判据是:数一数你的工具里有几个名字里带「get」或者「query」——超过两个,就该按用途重写描述了。
6. 书只讲了这套协议的一半
这一节是我们补的,因为不补的话读者会以为「这套协议 = 工具」。
书从头到尾只讲了工具这一件事。而规范里,服务端能提供的东西有三类18:
| 服务端提供的三类东西 | 谁决定它什么时候被用 | 一句话 |
|---|---|---|
| 工具 | 模型 | 暴露给模型自主调用的动作(调接口、写文件) |
| 资源 | 应用 | 应用主动塞给模型的上下文数据(文件内容、提交历史) |
| 提示词模板 | 用户 | 事先写好的一段提示词,用户从菜单或斜杠命令里挑一个用——比如「帮我审查这段代码」 |
这个分法的要害在中间那一列:「谁决定它何时被用」。 工具是模型自己决定调不调的,所以它最危险,也最需要审批和护栏; 资源和提示词模板则轮不到模型做主。 这条控制层级直接决定了它们在界面和安全策略上的不同待遇。
另外两件书也没讲的事:
-
能力协商。 这套协议是「先声明、后使用」的:双方各自声明自己支持哪些特性, 谁都不能用对方没声明的能力。这解释了一个实践问题—— 为什么同一个服务端接到不同的客户端上,可用的功能会不一样;
-
消息怎么送过去。 规范定了两种方式。一种是本地把服务端当子进程启动 (你的应用亲手把它拉起来),两边通过那个进程默认自带的两根管子收发—— 一根读进来、一根写出去,和你在命令行里看到的输出是同一根,行内管这两根叫标准输入输出; 另一种是远程走 HTTP。书的示例用的是远程那一路,但它没说这是一个选项 ——而本地那一路恰恰是桌面端 AI 工具最常用的。
最后一条更实际的:书给的那个建服务端用的框架,参考文献里的仓库地址是错的 ——它写成了某个知名 AI 框架组织下的项目,而那个框架并不是这个项目的东家。 真正的地址我们核实过,在另一个组织下。19
7. 作者的判断与证据
书里给了证据的:
| 说法 | 证据是什么 |
|---|---|
| 5 个应用 × 10 个系统 = 50 套集成,统一之后变 15 | 一笔可以自己验算的账,而且 50 和 15 互为参照 |
| 协议管格式校验和错误格式,不管认证授权和端点安全 | 一条明确的边界声明,书重复了两次 |
| 服务端自己提供工具清单,模型去问 | 一条机制描述,而且给了完整的运行时链路 |
| 工具描述含糊会导致模型选错 | 给了正反两组具体的名字(search_products / check_inventory vs get_products / get_product_info) |
| 74% 的企业管理超过 500 个数据源 | 一个具体的数,但书给的引用对不上号,我们没核到一手来源 |
| 协议托管在 Linux 基金会、注册表里有数千个服务端 | 可核的事实性陈述,但书没给具体链接 |
作者的推测或没给证据的:
| 说法 | 它是什么 |
|---|---|
| 「像 AI 世界的 USB」 | 一个比方,说清了「插上就能用」,说不清「谁负责安全」 |
| 「更好的 schema 带来更聪明的模型行为」 | 一句经验判断,没有对照实验 |
| 那张「用 MCP 前 / 用 MCP 后」的对照表 | 一张推销性质的表(脆弱↔模块化、指数成本↔线性成本),没有任何测量 |
8. 边界与局限
-
只讲了工具,没讲另外两类东西。 资源和提示词模板在书里一个字都没有 ——这一块我们在第 6 节从自己的协议书架补上了;
-
示例里的两个数对不上。 走查第 ⑧ 步那句回答说的是「女士便携马甲」79.99 美元, 而书自己给的商品表格里 79.99 是防水雨衣、女士羽绒马甲是 99.00 ——这是未定稿留下的痕迹,我们照实标出;
-
参考文献里的仓库地址是错的(见第 6 节末),照抄会把读者带到不存在的地方;
-
没有讲工具多了之后怎么办。 一个服务端挂三五个工具很清爽, 挂三百个呢? 模型一次能读进去的量是有限的,清单本身就会把上下文占满—— 书完全没碰这个问题;
-
审批只给了一个参数名。 「敏感操作设成总是需要审批」这句话之后, 审批界面长什么样、谁来批、批不过怎么回退,书全没讲。 第 15 章讲控制面时会碰到一点,但仍然不够;
-
安全只有一句话。 「认证、授权、端点安全是你的责任」——说了责任在谁,没说怎么做。 第 15 章末尾会给一个数字来说明这件事有多不乐观。
9. 可带走的
全章那条走查,一行写完: 5 个应用 × 10 个系统 = 50 套集成 →
换成统一接口后是 15 → 拿七行商品表格建出 search_products(query, max_price, limit) →
用户说「我要一件 100 美元以下的轻便马甲」→ 运行时去问服务端「你有哪些工具」 →
模型自己构造 {"query":"lightweight vest","max_price":100} → 路由到服务端 → 返回 JSON →
模型写出回答 → 再挂一个 check_inventory,它自己决定先搜后查。
- 它不是加法是乘法:应用数 × 系统数,而且每套集成各崩各的;
- 统一接口把乘法压回加法:每个系统一个服务端、每个应用一个客户端,50 变 15;
- 省下来的不只是代码量,是「每条线都长得不一样」这件事—— 新系统接进来,已有的应用一个字都不用改;
- 协议管的只有:参数格式校验 + 错误格式。 认证、授权、服务端本身的安全,以及工具里真正干活的代码,全是你的;
- 一句话记住边界:目标是让集成变简单,不是变自动;
- 和函数调用的分水岭:那边是你每次请求内联把函数描述带上去, 这边是服务端自己提供一份工具清单,模型去问;
- 这条分水岭的实际好处:新加一个工具,请求那边一个字都不用改;
- 链式调用是自动发生的——模型按问题和工具描述自己决定调哪些、什么顺序;
- 正因为如此,工具描述是写给模型看的路由指令,不是给人看的文档。 两个工具都叫得含糊,模型就会选错;
- 建服务端之后一定要先手动调一遍——把「模型不听话」和「工具本身有毛病」分开;
- 默认「不需要审批」在生产里是危险的:那意味着模型可以不经人类监督 修改数据、下单、发通讯;
- 书只讲了工具这一类。 规范里服务端还能提供资源(应用塞给模型的数据) 和提示词模板(用户主动选的),分法的要害是「谁决定它何时被用」。
10. 原文地图
| 主题 | 原书章 | 原文位置 |
|---|---|---|
| 开场:三件简单的事、三套各崩各的代码 | Chapter 7: Tool Integration and MCP | text/10-ch07-chapter-7-tool-integration-and-mcp.txt:30(搜「Your AI assistant just crashed」) |
| 74% 的企业管理超过 500 个数据源 | Chapter 7: Tool Integration and MCP | text/10-ch07-chapter-7-tool-integration-and-mcp.txt:34(搜「74%」) |
| 5 × 10 = 50 那笔账 | Chapter 7: Tool Integration and MCP | text/10-ch07-chapter-7-tool-integration-and-mcp.txt:42(搜「building five different AI applications」) · text/10-ch07-chapter-7-tool-integration-and-mcp.txt:69(搜「50 custom integrations」) |
| 50 变 15、服务端与客户端 | Chapter 7: Tool Integration and MCP | text/10-ch07-chapter-7-tool-integration-and-mcp.txt:73(搜「plug-and-play」) · text/10-ch07-chapter-7-tool-integration-and-mcp.txt:76(搜「MCP Server」) |
| 「像 AI 世界的 USB」与那条边界 | Chapter 7: Tool Integration and MCP | text/10-ch07-chapter-7-tool-integration-and-mcp.txt:80(搜「USB for AI」) |
| 「让集成变简单,不是变自动」 | Chapter 7: Tool Integration and MCP | text/10-ch07-chapter-7-tool-integration-and-mcp.txt:120(搜「reduces boilerplate」) |
| 采用情况(Linux 基金会、数千个服务端) | Chapter 7: Tool Integration and MCP | text/10-ch07-chapter-7-tool-integration-and-mcp.txt:138(搜「Linux Foundation」) |
| 为什么用表格而不是真接口 | Chapter 7: Tool Integration and MCP | text/10-ch07-chapter-7-tool-integration-and-mcp.txt:154(搜「another major advantage」) |
| 七行商品表格 | Chapter 7: Tool Integration and MCP | text/10-ch07-chapter-7-tool-integration-and-mcp.txt:169(搜「Trail Running Shoes」) |
| 工具函数与「模型最好用的格式」 | Chapter 7: Tool Integration and MCP | text/10-ch07-chapter-7-tool-integration-and-mcp.txt:203(搜「search_products」) · text/10-ch07-chapter-7-tool-integration-and-mcp.txt:244(搜「list of dictionaries」) |
| 手动测试服务端 | Chapter 7: Tool Integration and MCP | text/10-ch07-chapter-7-tool-integration-and-mcp.txt:255(搜「simulates how LLMs」) · text/10-ch07-chapter-7-tool-integration-and-mcp.txt:282(搜「out of stock」) |
| 工具清单:和函数调用的分水岭 | Chapter 7: Tool Integration and MCP | text/10-ch07-chapter-7-tool-integration-and-mcp.txt:330(搜「define those functions inline」) · text/10-ch07-chapter-7-tool-integration-and-mcp.txt:332(搜「provides the list of tools」) |
| 「声明出来的能力清单」 | Chapter 7: Tool Integration and MCP | text/10-ch07-chapter-7-tool-integration-and-mcp.txt:341(搜「declarative tool provider」) |
| 完整链路与模型构造出的那次调用 | Chapter 7: Tool Integration and MCP | text/10-ch07-chapter-7-tool-integration-and-mcp.txt:380(搜「plain English」) · text/10-ch07-chapter-7-tool-integration-and-mcp.txt:363(搜「lightweight vest」) · text/10-ch07-chapter-7-tool-integration-and-mcp.txt:407(搜「Packable Vest」) |
| 审批那条警告 | Chapter 7: Tool Integration and MCP | text/10-ch07-chapter-7-tool-integration-and-mcp.txt:373(搜「require_approval」) |
| 工具设计就是接口设计 | Chapter 7: Tool Integration and MCP | text/10-ch07-chapter-7-tool-integration-and-mcp.txt:430(搜「language model API surface」) |
| 链式调用与「路由指令」 | Chapter 7: Tool Integration and MCP | text/10-ch07-chapter-7-tool-integration-and-mcp.txt:505(搜「use multiple tools in sequence」) · text/10-ch07-chapter-7-tool-integration-and-mcp.txt:520(搜「happens automatically」) · text/10-ch07-chapter-7-tool-integration-and-mcp.txt:531(搜「routing instructions」) |