调取任何生产环境智能体（agent）的一周工具调用追踪（tool-call traces），你会发现其规律如出一辙：三四个工具处理了 90% 的调用，其余数十个工具则瓜分了剩下的 10%。工具目录呈现幂律分布（power law），但框架却将其视为均匀列表。每个工具描述都会出现在每个系统提示词（system prompt）中，每个选择准则都对工具一视同仁，每个评估（eval）在对目录进行采样时，都仿佛 search-files 调用和 refund-issue 调用来自同一分布。事实并非如此。
这种“扁平化”处理的代价在爆发前往往是隐形的。团队增加第 18 个工具，规划器（planner）对最初三个工具的准确率下降了两个百分点，却没人能将这种退化归因于特定变更，因为所有指标都同时发生了偏移。而评估套件本身在目录中也是均匀分布的，它将这些下滑平均成一个看起来依然正常的数字。与此同时，本轮对话中模型不会调用的工具描述所消耗的 token，已经超过了用户实际提示词的 token。
解决方案并非更完美的工具选择准则。而是要承认，“工具目录”实际上是两种不同的数据结构通过惯例硬凑在一起的，正是这种强行捏合让规划器变得更糟。
数据形态：准确率随目录规模呈非线性坍塌
经验曲线比大多数团队想象的要难看。针对不同规模目录运行相同提示词的独立基准测试发现，在拥有约 50 个工具时，现代模型能保持 84%–95% 的选择准确率。当工具增加到约 200 个时，准确率范围会根据模型的不同崩解至 41%–83%。在约 740 个工具时，大多数模型的准确率会坍塌至 0%–20%。RAG-MCP 研究报告称，基准准确率在 10 个工具时为 78%，而在 100 个以上工具时下降到 13.6% —— 降幅达 82%，且并非平滑曲线。性能在团队未曾测量的阈值处跌落悬崖，因为评估没有按目录规模进行分段。
这种崩溃由两种失败模式共同导致。第一种是注意力稀释（attention dilution）：规划器在每一轮都必须阅读每一个工具描述，原本能集中在焦点窗口内的提示词，现在因大量的定义目录而分散了注意力。第二种是位置偏差（positional bias）—— 即著名的“迷失在中间（lost in the middle）”效应 —— 工具目录受此影响比文本检索更严重，因为目录没有叙事动力（narrative momentum）。在 741 个工具的情况下，中间位置（目录的 40%–60%）的选择准确率仅为 22%–52%，而边缘位置为 31%–32%。规划器选错工具并非因为它不知道，而是因为它没有同样仔细地阅读提示词的那部分内容。
Token 成本加剧了准确率成本。一个包含五个服务器的 MCP 配置（GitHub, Slack, Sentry, Grafana, Splunk），仅在工具定义上就消耗了约 55,000 个 token，此时用户的提示词甚至还没加载。拥有 20 个 MCP 服务器、每个服务器暴露 20 个工具 —— 这在企业级规模中很常见 —— 会产生 400 个 JSON Schema 格式的工具定义，而这是目前最消耗 token 的序列化方式。在推理开始前，累积的开销就已占用了上下文窗口（context window）的很大一部分。
热路径与冷目录是不同的产品
恢复性能的架构杠杆是分区（partitioning）。存在一个由高频工具组成的“热路径（hot path）”，它们理应留在提示词中 —— 它们被预加载，有详细描述，被严格的评估准则覆盖，并被视为规划器永久词汇表的一部分。而“冷目录（cold catalog）”中的长尾工具则按需发现：规划器在大多数轮次中根本看不到它们，但它拥有一个查找原语（lookup primitive，如工具搜索工具、检索器或 MCP-zero 风格的发现 API），当请求形状暗示需要某个工具时，该原语会调出相关的冷工具。
Anthropic 最近发布的工具搜索功能是这一模式的具体实例化。标记为 defer_loading: true 的工具不会出现在初始上下文中 —— 规划器只能看到工具搜索原语本身以及预加载的热路径。当 Claude 搜索某种能力时，匹配的工具仅在需要时才扩展为完整的定义。发布的数据非常惊人：工具定义的 token 使用量减少了 85%，同时 Opus 4 的选择准确率从 49% 提升到 74%，Opus 4.5 从 79.5% 提升到 88.1%。三个指标同时变好：token 下降，准确率上升，且目录可以在不按比例损害性能的情况下继续增长。
检索增强变体（通常封装为 RAG-MCP）从框架侧而非 API 侧实现了类似的经济效益。报告的数据 —— 1,084 个提示词 token 对比全工具基准的 2,134 个（减少 50% 以上），工具选择准确率 43.13% 对比 13.62%（提升 3 倍以上）—— 遵循同样的规律：当你的目录超过 20 个工具时，节省 token 的主要杠杆是彻底将冷工具移除出提示词，而不是缩短每个描述。
这两种模式都需要一个独立的索引（index），而这正是大多数团队所低估的。工具搜索步骤需要一个搜索对象 —— 描述、示例查询、参数形状、嵌入（embeddings）或某种混合形式 —— 并且该索引有其自身的时效性要求、质量标准和失败模式，这些都不会映射到规划器的评估套件中。仅仅因为“它就是 RAG”而将检索视为黑盒，会导致你交付的智能体其工具选择能力比全工具基准更差，仅仅是更便宜而已。
每个工具都需要凭本事赢得其描述预算
余下内容仅对会员开放。
会员可读完整内容 —— 每一个公开发布的观点背后，那些框架、决策与推理的全貌。
- 完整文章，包含未公开存档的部分
- 可落地的工作框架，附带权衡与决策依据
- 新文章抢先看，先于公开发布
随时取消 · 一次订阅，畅读全部