组合性税收：为什么增加工具会让你的规划器性能下降

团队最开始有 5 个工具和一个在生产流量中命中率达 95% 的规划器（planner）。18 个月后，他们有了 51 个工具，而规划器的命中率降到了 26%，原本那 5 个工具能干净利落处理的简单案例——预订会议、查询客户、提交工单——现在有时会路由到错误的工具，因为目录中有三个听起来很像的“替代品”。没有人故意让规划器变差。每一次工具的增加在当时看来都是合理的。这种累积的代价就是“可组合性税”（composability tax），每一个在工具目录增长过程中缺乏淘汰机制的产品都在支付这笔费用。

这笔“税”是一条曲线，而不是悬崖。Berkeley Function Calling Leaderboard 直接测量了这一点：在日历调度任务中，当跨多个领域的工具从 4 个增加到 51 个时，准确率从 43% 下降到了 2%。在客户支持类任务中，GPT-4o 从 58%（单一领域，9 个工具）下降到 26%（7 个领域，51 个工具）。Llama-3.3-70B 在同样的扩张下从 21% 降到了 0%。这种趋势在不同模型和任务类型中不断重复：每增加一个工具，规划器就会在曲线上进一步下滑，而且随着目录变大，边际损害会变得更严重，因为新加入的条目与现有的条目越来越难以区分。

失败模式并非规划器拒绝执行。规划器几乎从不拒绝。它会选择一个听起来合理但错误的工具，或者以一种无法组合的方式组合两个工具，或者使用为另一个工具的 schema 设计的参数来调用某个工具。响应在结构上是有效的 JSON。追踪记录（trace）看起来很干净。评估套件（如果它是围绕最初那 5 个工具构建的）无法捕捉到这种退化，因为新的失败案例尚未包含在内。这就是为什么可组合性税在客户报告之前一直是隐形的。

曲线是真实存在的，而拐点需要你去衡量

人们往往倾向于将工具数量视为一个可以通过工程手段绕过的约束。Anthropic 的 Tool Search 将完整的 schema 移出 prompt，并根据需求发现工具，这使得 Opus 4 在拥有大型工具库的 MCP 评估中从 49% 提升到 74%。代码模式执行（Code-mode execution）可以将一个八轮的 agent 循环压缩为单次调用。Schema 压缩可以将一个 17,600 token 的 GitHub MCP 服务器减少到 500 token。这些方法行之有效，你也应该使用它们。但它们都没有改变一个基本事实：模型仍然必须从一个集合中选择正确的工具，而该集合的基数（cardinality）是团队可以控制的一个旋钮。

将工具数量视为一个旋钮，意味着要为你的产品衡量这条曲线。今天，大多数团队无法告诉你他们的规划器在 20 个工具、30 个工具与 50 个工具下的准确率对比。他们能告诉你目录的大小，却无法告诉你拐点——即增加一个新工具所带来的价值不再抵消其造成的准确率损失的那个临界点。拐点是因产品而异的。一个拥有 5 个高度重叠的 CRM 查询工具的团队，其拐点会比一个拥有 50 个领域完全不同的工具的团队更早到来。可组合性税不是按工具数量支付的，而是按“无法区分的工具”支付的，并根据这些无法区分的工具在实际流量中发生冲突的频率进行加权。

最小可行测量（MVM）是一个保留的评估套件，团队先针对现有目录进行评分，然后在消融实验（ablations）下重新评分：同一套件，移除 20 个工具；同一套件，移除一半目录；同一套件，仅保留使用频率前十的工具。曲线自然就会显现。如果 30 个工具的准确率与 50 个工具时一致，那么最后那 20 个工具就没有产生应有的价值——它们在没有任何回报的情况下对每一个请求征收“税收”。

淘汰指标：频率 × 成功率 × 下游提升

添加工具很容易：一个 PR、一个 schema、一段描述、一次部署。但淘汰工具很难，因为每个工具都有一个构建它的发起人、一个证明其合理性的 Slack 讨论串，以及一个可以被指出的非零调用次数。团队需要的纪律是一个基于证据而非发起人压力的淘汰指标。

该指标由三个相乘的部分组成：

• 工具使用频率：规划器在真实流量中调用该工具的频率。一个每季度仅被调用两次的工具，却让每个请求都在为它的描述 token 买单，这几乎毫无意义。
• 工具调用成功率：当规划器确实调用该工具时，调用是否成功（正确的工具、正确的参数、下游系统接受）？一个频率很高但成功率仅为 30% 的工具，说明规划器正被误导至此——它正在积极地降低本应流向他处的流量的规划质量。
• 下游评估提升：当工具成功执行时，相对于规划器使用次优工具的假设情况（counterfactual），它是否真正推动了用户可见的结果（任务完成度、解决率、解决时间）？一个执行成功但没有提升结果的工具，说明其最接近的替代方案已经足够好了。

加载中…