你的工具目录遵循幂律分布，而你却在针对长尾进行优化

调取任何生产环境智能体（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”而将检索视为黑盒，会导致你交付的智能体其工具选择能力比全工具基准更差，仅仅是更便宜而已。

每个工具都需要凭本事赢得其描述预算

一旦你接受了这种分区，第二个预算问题也就随之而来。热路径（Hot-path）工具值得拥有详细的描述、参数示例和消除歧义的提示——规划器在每一轮对话中都会阅读这些内容，而在漏斗顶端的清晰度提升，在数百万次调用中产生的收益足以抵消其成本。相反，冷路径（Cold-path）工具的描述需要针对 检索（retrieval）而非执行进行优化。冷路径检索器必须能根据用户模糊的短语找到工具；一旦找到，完整的定义才会展开并进入上下文。因此，冷路径工具的描述包含两个部分：检索块（富含同义词、示例查询和意图短语）和执行块（富含参数语义和边缘案例指南），两者各有不同的优化标准。

这种拆分也使得强制执行描述质量变得可行。生产环境中的智能体（Agent）最常见的消除歧义失败案例就是工具名称重叠或模糊——例如 notification-send-user 与 notification-send-channel 的混淆，或者来自不同团队的两个 search 工具。Anthropic 自己的指南也明确建议按服务和资源进行命名空间化（如 asana_search、jira_search、asana_projects_search、asana_users_search），正是因为当描述变得模糊时，规划器的选择准确性主要取决于名称的歧义消除。在热路径上，你有足够的预算用一句话描述每个工具的独特职责，确保规划器不会误读。在冷路径上，由检索器负责消除歧义，因此描述的优化目标是 可发现性，而非文辞优美。

一个有用的合理性检查：如果你无法用一句话说明某个热路径工具做了哪些其他热路径工具做不到的事，那么该工具还没准备好进入热路径。它要么需要与邻近工具合并，要么需要重命名以消除歧义，要么需要降级到冷路径目录，让检索器根据意图而非规划器根据名称来消除歧义。

评估分区，而非整个目录

能捕捉到长尾回归（Long-tail regressions）的评估准则是不再只报告单一的准确率数值。热路径条件准确率和冷路径条件准确率是衡量不同系统的不同指标，将它们汇总会产生双重误导：首先，它混合了两种错误模式完全不同的分布；其次，它在较小的样本群中隐藏了性能倒退。

热路径评估应当是严密的：覆盖每个工具、练习每种参数形态、组合热工具的多轮对话流，以及针对每次提示词更改进行的回归测试。冷路径评估在结构上则完全不同——它采样那些应该激活检索器的用户表述，评分是否 检索 到了正确的工具（而不只是选中），并作为一个独立的漏斗跟踪“检索后再规划”的成功率。冷路径的失败可能发生在两个地方：检索器没有找出正确的工具，或者检索器找出了工具但规划器没有从较小的候选集中选中它。日志需要能区分这两种情况。

至关重要的是，热路径需要 晋升测试，冷路径需要 降级测试。当流量发生变化，原本处于冷路径的工具开始承担 8% 的调用量时，必须有人注意到并考虑是否将其移至热路径——包括预加载它、扩展其描述、增加评估覆盖范围——反之，对于份额衰减的热路径工具也应如此。如果没有这一点，分区只会在设计时设定一次，并随实际流量的演变而失效。有了它，分区就变成了运行系统的属性，而非静态配置。

目前基准测试文献尚未统一标准的“热路径/冷路径”指标，这意味着大多数团队必须定义自己的指标。最小可行切分方案是：为每个工具标记分区，按分区切分每次的选择准确率报告，并在感觉不对劲时首先查看冷路径数值。在性能倒退开始后的至少一个季度内，汇总数据都会对你撒谎。

组织失效模式是分区无人负责

大多数团队发布扁平目录的原因并不是因为他们不懂更好的方法，而是因为分区问题无人负责。每个添加工具的团队都希望自己的工具出现在全局目录中，因为那是实现可发现性的方式；没有人希望自己的工具被降级到冷路径，因为他们把“冷”理解为二等公民。拥有规划器的平台团队最有动力执行分区，但政治授权最弱，因为他们并不负责那些依赖单个工具的面向用户的功能。

行之有效的模式是将分区作为工具注册的一种属性，而非下游配置。工具注册时需要声明预期的调用频率，并由平台层强制执行热路径预算门槛（例如，热路径最多只能有 N 个工具，且每季度审核一次），以及由流量驱动的自动化晋升/降级建议。对话的主题由此从“我的工具重要吗？”（一个无法证伪的地位问题）转向“我的工具流量是否证明了其席位的合理性？”（一个带有数据支撑的经验问题）。

第二个组织模式是：热路径工具的评估套件由平台负责；冷路径工具的评估套件由注册该工具的团队负责。这是唯一可持续的分配方式——平台团队无法为他们不使用的 200 个冷路径工具编写高质量评估，而注册团队也无法在他们不拥有的热路径上保持一致的准则。在分区处划分界限，正好将界限划在了所有权自然落下的地方。

接受分区后会发生什么变化

存留下来的思维模型是：智能体 (agent) 的工具目录并非一组权限。它是权限集的生成器——这些权限集是安全团队从未枚举过的，服务于框架从未测量过的流量分布，且其质量标准是评测套件从未通过分区检测到的。这三者中的每一个都是一种修复，但它们只有协同工作才能奏效：没有评测拆分的分区会掩盖回归 (regressions)；没有注册规范的评测拆分会导致分区偏移；没有检索原语的注册规范会将工具降级为规划器 (planner) 无法触达的冷目录。

展望未来，下一代智能体框架可能会将分区视为一种一等抽象 (first-class abstraction)，就像 HTTP 框架对待路由那样——具有声明式的频率层级、自动晋升/降级机制、内置于规划器输入流水线的检索功能，以及默认报告分区准确率的基准测试。我们目前尚未达到那个阶段。与此同时，那些手动维护分区、使用显式的热/冷标签和分段评测的团队，交付的智能体在衡量指标上明显优于不这样做的团队——而不这样做的团队将花费一个季度的时间去追踪一个无法定位的回归，因为数据是在一个并不存在的分布上进行平均的。