工具调用

上一课的结论是「工具是唯一能改变世界的接口」。这一张先回答最底层的问题：模型究竟怎么「调用」它。

因为模型只会输出文本、也不会执行任何东西，所谓「调用」只能拆成四步：① 宿主把工具定义送进请求 → ② 模型输出结构化的调用意图 → ③ 宿主代码执行 → ④ 结果回填给模型。就像你让助理去办事：你先告诉他「有哪些部门可以找、各自负责什么」，他回你一张「我要找财务、需要这些材料」的单子，是你去跑腿，跑完再把结果告诉他。所以下面用一笔 token 账，把「四步往返」的代价算出来。

更自然的做法是「让模型直接生成一段代码字符串，宿主拿去执行」。但自由文本没有固定结构，宿主只能靠字符串匹配去猜「哪个是工具名、哪些是参数」；模型只要换个说法（例如把调用写成一句自然语言，而不是「get_order(id=1)」），解析就失败。所以协议要把「调用意图」限定成结构化字段——这一步换来的是宿主能无条件解析。

上一张卡片把调用拆成了「定义 → 意图 → 执行 → 回填」。这一张盯住第二步：模型吐出来的那段「意图」，凭什么能直接被程序当参数用。

因为模型的原生输出是自由文本，程序没办法拿它去调用接口——所以要先用 schema 把「参数长什么样」写进模型的 context，让它按结构生成。就像填表：先规定好「姓名必填、金额只能是数字、状态只能从三个词里挑」，填的人才有章可循、机器才敢直接入库。所以下面用一笔账，看约束能把「全对率」抬多少。

更笨的做法是「让模型随便吐一段 JSON，宿主自己容错解析」。但自由 JSON 的字段名、类型、嵌套都不受约束，设单个参数正确的概率 0.95，10 个参数一次全对的概率只有 0.95¹⁰ ≈ 0.599；用 schema 把单参数正确率抬到 0.99，10 个参数全对就升到 0.99¹⁰ ≈ 0.904。schema 买的不是「模型更聪明」，而是「错的机会更少」。（口径提示：下面把「一次调用」也视作一个「参数位」——无论按参数计还是按调用计，连乘公式都不变。）

上一张卡片给参数套上了 schema。这一张处理它兜不住的那部分：出错之后怎么办。

因为失败是常态，关键在于「错了能不能被纠正」。做法是把校验器/接口返回的错误信息，当作一次观察拼回 context，让模型看到「刚才错在哪」再重试——就像填表被打回：窗口把「金额栏你填了文字」写清楚，你才知道改哪一格，而不是重填整张表。所以下面算一笔重试的账，同时看看它的代价。

上一张卡片解决了「错了怎么兜」——校验、回填、重试、幂等。这一张换一个更靠前的问题：工具不止一个时，模型到底怎么挑。

因为模型看不到工具的源码，它做选择时唯一能看到的只有名字、描述和参数表，所以选择质量几乎完全由这几行文字决定。就像一排长得差不多的电灯开关：只有 3 个时闭着眼也能摸对，变成 20 个、标签又都写着「灯光」，就得一个个辨认——标签越像，按错的概率越高。所以下面用公开评测的数字，看「工具变多」到底让正确率掉了多少。

更省事的做法是「给每个工具起个名字、配一句话描述就完事」。但模型看不到代码，做选择时只能读到这几行文字：可见工具 25 个时选择正确率 86.7%，涨到 150 个时掉到 76.7%——掉的这 10.0 个百分点，正是「描述区分度不够」在规模上的放大。工具越多，写描述的成本越低，选错的代价越高。

上一张卡片让模型在 20 个工具里挑对了。这一张处理挑对之后的下一件事：一次要调好几个工具，它们的返回结果塞回来会不会把上下文撑爆。

因为模型可以在一轮里同时要 5 个工具（并行调用），执行端也能并发跑，所以这 5 份结果会几乎同时回填进 context。就像一次叫了 5 个外卖骑手：配送确实更快了，但门口一下堆 5 大箱，放不下就得出事。所以下面先算并行省了多少往返，再算回填这笔长度账。

更自然的做法是「把工具返回的原始 JSON 原样塞回上下文」，因为这样最完整。但一次并行 5 个工具、每个回 2,000 token，就是 10,000 token，占 128K 窗口的约 7.8%；这些结果还会留在历史里，10 轮累计到 100,000 token。把「完整」换成「够用」——截断、摘要、只回引用——同一批结果能从 10,000 token 压到 250。

前面五张卡片解决了「怎么调、怎么兜错、怎么选、怎么回填」。最后一张回到最影响成功率的一环：工具本身设计得对不对。

因为模型能看到的只有名字、说明和参数表——写得含糊，它就选错、填错。就像给同事一张写着「处理一下」的便签：他要么问你三遍，要么直接办错；写清「把 X 单的金额从 A 改成 B」，他才一次做对。所以下面先算一笔「工具越多越难选」的账，再给一套可执行的设计原则。