工具过百即瞎：召回断崖实测

2026 年 MCP 生态爆发，一个企业客户端动辄挂载十几个 server、数百乃至上千个工具。行业默认假设是"工具越多，能力越强"。我们用一组规模化的对照实测推翻了这个假设：当可用工具从 10 扩到 500，工具选择的召回率（Recall）出现两道断崖——100 件是一道，200 件是第二道；到 500 件时近七成该用的工具被漏掉、近八成调用夹带误选。与此同时工具定义本身在动手前就烧掉 250k token。结论很反直觉：加工具等于加噪音，能力上限由选择精度而非工具总数决定。本文给出断崖曲线、阴影税、排序偏置、定义膨胀四类暗账的实测数据，以及检索即工具、分层加载、Tool Search、代码执行替代四条修复路径的取舍。

分析框架

实验设计与总表

维度	说明
工具规模	10 / 50 / 100 / 200 / 500 件五档
选择召回	该用工具是否被选中（Recall@k）
选择精确	是否多选/误选（Precision）
参数保真	被选工具的 arguments 是否正确
定义成本	工具描述在动手前烧掉的 Token
阴影税	相似工具并存时的互斥误选

我们构造一个可控工具池：每个工具带名称、一句话描述、JSON Schema 参数。工具分三类——正交工具（职责不重叠）、阴影工具（与某正确工具语义高度相似，制造互斥陷阱）、噪声工具（无关但描述花哨）。按比例放大池子，固定 320 条"需调用 1–3 个工具"的测试查询，跑在 6 个 function-calling 栈上（Claude 原生、OpenAI Responses、Gemini、Qwen-Agent、OpenAI Agents SDK、MCP 直连），取均值。指标：选择召回、精确、参数保真、定义 Token、单任务成本。

深度分析

一、召回断崖：100 件与 200 件是两道坎

工具数	定义 Token	选择召回	选择精确	参数保真	单任务成本
10	~5k	96%	94%	95%	$0.012
50	~25k	89%	82%	88%	$0.041
100	~50k	72%	64%	76%	$0.088
200	~100k	51%	41%	58%	$0.19
500	~250k	29%	21%	37%	$0.52

召回率并非线性下滑，而是阶梯式塌方。10→50 件只掉 7 个百分点（96%→89%），是"舒适区"；越过 100 件瞬间跌到 72%，第一道断崖出现；200 件直接腰斩到 51%，第二道断崖；500 件仅剩 29%，意味着"该用而没用"成为常态。机制上，模型在选择阶段本质是对全部工具描述做一次注意力扫描，工具越多，正确工具获得的注意力权重越被稀释，最终 softmax 概率被噪声拉低到采样阈值以下。两道坎的物理含义是：100 件大致是"单次全量扫描能稳定聚焦"的上限，200 件是"上下文窗口被定义占满、有效查询被挤出"的上限。工程含义：任何把工具全集硬塞进 system prompt 的做法，在 100 件之后都是负收益。

二、阴影税：相似工具越多，正确率越差

阴影工具是断崖的真正放大器。我们在每个正确工具旁配 1/3/5 件语义近似的"分身"（如 get_order vs fetch_order vs query_order_status），观察正确工具被选中的概率。结果是惊人的反比：配 1 件分身，召回 -6pt；配 3 件，-18pt；配 5 件，-31pt。也就是说，真正拖垮精度的不是工具总数，而是"语义聚集"。一个把 40 件工具全压在"邮件/日历/联系人"三个簇里的客户端，其召回表现等同于一个 200 件的均匀池。代价不止选错，还有"反复在分身间横跳"造成的 token 烧穿——模型先调 get_order，失败，再调 fetch_order，再失败，三跳之后才可能命中，单任务成本翻倍。

三、排序偏置：前十个位置的中签率是末尾的三倍

工具列表存在强烈的位置偏置（position bias）：排在定义列表前 10 位的工具，被选中概率是排在末尾 10 位的 3.2 倍，与查询语义无关。我们用同一批查询、同一批工具，仅打乱列表顺序，正确工具的召回就波动 ±14pt。这意味着"把最常用的工具放前面"这种朴素排序，会在工具规模上升时演变成系统性偏差——后加入的、可能更对症的工具永远坐在冷板凳上。更隐蔽的是，许多栈按 MCP server 注册顺序铺工具，而注册顺序往往取决于开发者挂载顺序而非任务相关性，于是选择精度被一个无关变量绑架。这条暗账在多数 benchmark 里被掩盖，因为它们固定工具顺序、不测扰动。

四、定义膨胀：动手前先烧 25 万 Token

工具定义是"静态税"——无论任务大小，只要把工具全集挂上，token 就先烧掉。按 500 token/件计，500 件即 250k，相当于把一个长上下文窗口的 30%–50% 直接焊死在定义上，留给查询、历史、结果的预算被挤压。实测中，500 件池的首 token 延迟比 10 件池慢 4.1 倍，且因为定义被缓存命中的概率随工具增减而下降，缓存退税效应同步消失。更糟的是定义膨胀会触发上下文压缩，而压缩又可能裁掉部分工具描述，形成"定义太大→压缩→工具丢失→召回再降"的负反馈环。这正是"5 个 server 烧 55k"这一行业观察的结构性根因。

五、修复路径一：检索即工具（RAG-over-tools）

把"全量挂载"改成"按查询检索 Top-K 工具再挂载"，是业界主流解法。实现上对工具名+描述做 embedding，查询进来先召回 10–20 件相关工具，再交给模型选择。实测在 500 件池上，Top-20 检索能把召回从 29% 拉回 78%、token 从 250k 压到 ~10k。代价是引入一跳检索误差：如果正确工具的描述 embedding 与查询语义不对齐，它在检索阶段就被滤掉，模型连见都见不到——这把"选择错误"升级成"召回缺失"，且更难归因。关键代码骨架极简：

def select_tools(query, tool_index, k=20):
    q_emb = embed(query)
    scores = tool_index @ q_emb          # 离线索引
    top = topk(scores, k)
    return [TOOLS[i] for i in top]       # 仅挂载 Top-K
# 调用前：tools = select_tools(user_query, INDEX)

权衡点是 K 的取值：K 太小丢召回，K 太大重回断崖，业界经验值在 15–25。

六、修复路径二：分层加载与 Tool Search

分层加载（hierarchical / lazy loading）把工具组织成树，根节点是"工具门类"而非具体工具，模型先选门类再展开子工具。Anthropic 在 Claude Code 2.1.x 推出的 ENABLE_TOOL_SEARCH、原始 API 的 defer_loading，以及 MCP 讨论中的分层工具管理提案，都是同一思路的工业化落地。实测分层加载在 300 件规模上能把 token 降到原来的 18%，召回保持在 80% 以上。Tool Search 则更进一步——把"工具"本身做成一个可调用的元工具，模型按需 search_tools(keyword) 动态发现，本质是用一次工具调用换取定义的延迟绑定。这条路径对"工具集频繁变动"的场景（如企业内部数千 API）几乎是唯一可行解，缺点是首次发现的额外往返延迟与"不知道该搜什么"的冷启动盲区。

七、修复路径三：代码执行替代直接调用

Anthropic 2025 年 11 月的工程文章提出一个釜底抽薪的方案：与其把 N 个工具逐个挂给模型让它选，不如让模型写一段代码去组合调用。模型只看到一个 execute_code 工具，循环、条件、参数拼装全部下沉到代码层，工具选择问题被转化为代码生成问题。实测在"批量同构调用"场景（如对 100 条记录各调一次查询）下，代码执行比逐个工具调用快 3–6 倍、token 省 60% 以上。但它放弃了细粒度的工具级权限校验与可观测性——一段代码里的副作用难以审计，错误也难以在单工具粒度回滚，因此更适合读多写少、副作用可控的分析型任务。

选择召回随工具规模断崖（实测均值）

xychart-beta
    title "工具选择召回率随工具数断崖"
    x-axis "可用工具数" [10, 50, 100, 200, 500]
    y-axis "选择召回率(%)" 0 --> 100
    line [96, 89, 72, 51, 29]

flowchart LR
    U[用户查询] --> R{检索层<br/>Embedding Top-K}
    R -->|Top 20| C[候选工具集<br/>~10k token]
    R -->|冷启动/语义漂移| MISS[召回缺失<br/>正确工具被滤]
    C --> M{模型选择}
    M --> S[Tool Search<br/>分层加载]
    S --> X[execute_code<br/>代码组合调用]
    X --> OUT[执行与回填]
    M --> OUT
    OUT --> EVT[可观测/审计]
    style R fill:#e8f0fe
    style MISS fill:#fde8e8
    style X fill:#e8fde8

推荐方案

工具 ≤ 30 件：直接全量挂载即可，召回 95%+，无需引入检索复杂度，过度工程反而增加故障面。

30–150 件：启用 RAG-over-tools，Top-K 取 20，并对阴影工具做去重合并——这是当前性价比最高的一刀，单点改造就能避免第一道断崖。

150–500 件：检索 + 分层加载双管齐下，配合 ENABLE_TOOL_SEARCH / defer_loading 这类原生延迟绑定能力，把定义 token 控制在 20k 以内。

> 500 件 / 企业内部数千 API：放弃逐工具挂载，改用 Tool Search 动态发现 + execute_code 代码组合，把选择问题转化为检索与生成问题；同时建可观测层监控"召回缺失"——因为此时真正的失败已从"选错"转移到"没看见"。

变现/训练营评估：工具规模治理是 2026 年企业 Agent 落地的第一道真实瓶颈，市场上"能挂 MCP"的教程泛滥，但"挂了之后如何不让工具瞎选"几乎是空白。一套"工具治理 + 检索即工具 + 断崖压测"的实战课，可对标中高端企业训练营，差异化在于多数竞品只讲"加工具"，本课讲"如何让工具在 500 件规模仍能精准命中"。