没人使用的长尾：工具带是如何变得尾大不掉的

没人会刻意决定给智能体 (agent) 配备 40 个工具。这就像车库堆满杂物一样自然而然地发生了。你接入一个搜索工具，然后是一个数据库读取器，接着团队里有人发布了 Slack 集成，然后又安装了 ticketing MCP 服务器，因为这只需要一行配置。每次添加在当时看来都是合理的。没人会移除任何东西，因为移除工具感觉就像是在剥夺能力，而剥夺能力感觉就像是一种倒退。

六个月后，你的智能体有了一个工具带，其中有三个它经常使用的工具，十几个偶尔使用的工具，以及二十多个在生产环境中技术上从未被选中的长尾工具。这种“长尾”并非免费，甚至代价高昂。目录中每一个未使用的工具都在主动降低智能体从那些重要工具中做出正确选择的能力。

这是让原本谨慎的团队也会栽跟头的反直觉之处。我们对待工具的方式就像对待库函数 (library functions) 一样：未使用的导入 (import) 在运行时不会产生任何开销，所以可选项越多越好。但 LLM 从未调用的工具与未使用的导入完全不同。它在每一次请求中都占据着上下文窗口。它在每一次决策中都在竞争模型的注意力。它拓宽了模型可能误入的错误答案空间。代价并不是在工具被使用时支付的，而是在工具“未被使用”的每一次请求中支付的。

数据远比你的直觉糟糕

一旦你进行测量，这种失败模式的轮廓就会变得清晰，且结果非常显著。在基准测试和生产报告中，工具选择的准确度会随着目录的增加而下降。根据工具的相似程度和描述的编写方式，有记录的性能损失从个位数到灾难性的崩溃不等。来自多个工具供应商的数据都指向了同一个拐点：当工具数量超过 20 个时，性能开始剧烈下降。主流智能体运行时环境都有硬性上限——有些限制在总共 40 个工具，有些在 128 个——正是因为他们清楚超过这个界限会发生什么。

这种性能衰退背后的两个机制值得单独说明，因为它们需要不同的解决方案。

首先是上下文膨胀 (context bloat)。每个工具的描述都是 Token，而详细的描述会占用大量的 Token。运行大型 MCP 架构的团队报告称，在智能体读取用户实际请求的第一个词之前，工具定义就已经消耗了超过 50,000 个 Token。在一个记录在案的案例中，58 个工具消耗了约 55,000 个 Token；在实际应用中，甚至观察到纯工具模式 (schema) 超过 134,000 个 Token 的情况。这些本可以用于推理、对话历史或本应是核心的检索文档的上下文，模型再也无法感知了。你为一个庞大的上下文窗口付费，却把它花在了描述智能体根本不会调用的工具上。

第二个是注意力稀释 (attention dilution)，它更为隐蔽，因为它不会出现在你的 Token 账单上。即使拥有无限的上下文，提供过多的工具——尤其是几个看起来很相似的工具——也会降低模型做出正确选择的能力。模型的注意力被分散了，它在近乎重复的选项间犹豫不决，产生参数幻觉，偶尔还会进入从业者所说的“决策死循环 (doom-loop of indecision)”，不断调用工具却无法收敛。两个分别名为 search_documents 和 search_knowledge_base 的工具就是一个陷阱。模型无法可靠地将它们区分开来，坦白说，添加第二个工具的工程师也分不清楚。

为什么“直接加上吧，没准有用”是一个统计学错误

这里有一个可以改变你对工具目录看法的框架。正确的问题不是“当这个工具是正确选择时，它是否有用？”，而是“提供这个工具能多大程度帮助模型战胜随机猜测？”

最近关于校正几率后工具选择的研究通过一个值得铭记的指标使这一观点变得具体：测量优于随机的比特数 (bits over random) 的选择度。在 500 个条目的注册库中展示 5 个工具，能给模型提供大约 3.3 比特的选择度——这是一个非常有利的比例。但当一个任务的 3 到 4 个相关工具埋在 58 个工具池中时，即使是运行在该原始池上的完美选择器，也只能获得约 0.02 比特的优于随机几率。信号被淹没了。正确的工具确实存在，但模型选中它的概率与在整个工具带中掷硬币几乎没有区别。

反过来思考，设计原则就显现出来了。选择准确度不是工具的属性，而是模型在决策时看到的“相关工具与干扰项比例”的属性。对当前一代模型的一项验证显示，当工具集被自适应地缩小范围时，模型选中正确工具的概率为 93%，而当提供一个固定的较长列表时，这一比例为 87%——仅仅通过移除干扰项就获得了 6 个百分点的提升。在这两种情况下，所需的工具都存在，唯一的区别是模型必须穿透多少噪音才能看到它。

加载中…