工具过载问题：为什么工具越多，你的大模型越笨

Writer 团队在对其 RAG-MCP 基准进行插桩测试时发现，当 Agent 可以访问大量工具集时，基准工具选择准确率——在无任何特殊处理的情况下——仅为 13.62%。不是 80%，不是 60%，而是 13%。而同一个 Agent，在通过检索增强的工具选择仅暴露最相关子集后，准确率达到了 43%。工具没变，模型没变，唯一变化的是推理时可见的工具定义数量。

这就是工具过载问题，它正在悄无声息地摧毁大规模生产 AI 系统。

构建 AI Agent 的工程师往往本能地想给它们提供更多能力。更多工具意味着更大的灵活性，不是吗？Agent 可以处理边界情况、覆盖更多用户意图、适应新场景。这个逻辑听起来很直观，却是错的。超过一个相当低的阈值之后，向 LLM Agent 添加工具并不会提升能力——而是会毁掉它。

工具过多时究竟发生了什么

你添加的每一个工具，都有一个大多数团队在为时已晚之前根本没有度量的代价。

工具定义不是免费的 token。一个典型的函数 schema，包含描述、参数名、类型和文档字符串，会消耗 150 到 400 个 token。一个拥有 20 个工具的生产级 MCP 服务器，在 Agent 处理任何一条用户消息之前，就已经消耗了 3,000 到 8,000 个 token。构建多服务器系统的团队，schema 开销经常累积到 5 万到 20 万个 token——往往比实际任务所需的上下文还要多。

但代价不仅仅是延迟和成本。更深层的问题是选择步骤中的认知过载。当模型必须从 40 个可能的函数中选择时，几种失效模式会随之浮现：

• 选择混乱：相似的工具名称和重叠的描述制造了模型无法厘清的歧义。它要么选错，要么犹豫不决地同时调用多个工具。
• 上下文腐化：在注意力机制中，函数定义相互混淆。模型逐渐无法区分那些在人类设计者眼中显而易见的语义差异。
• Schema 噪声：大量无关参数描述占据了本应用于理解用户意图的工作记忆。
• 幻觉工具：在工具数量较多时，模型偶尔会调用不存在的工具，或将不同 schema 中的参数拼凑成一个嵌合体调用。

Berkeley 函数调用排行榜的数据表明，即使是最强的模型，随着工具目录规模的增长，准确率也会出现可测量的下降。这不是某个特定模型的弱点，而是基于注意力机制的架构在处理大型离散选择集时的基本属性。

阈值比你想象的低得多

团队通常以两种方式发现这个问题：要么观察到与提示质量或模型版本无关的神秘 Agent 故障，要么通过受控实验自己发现了这种退化。

实践中的"安全区"大约是每个推理上下文 10 到 20 个工具。低于这个阈值，大多数有能力的模型能很好地处理选择。超过这个阈值，质量开始下降。超过 40 到 50 个工具，许多生产工作流就会变得不可靠，需要进行架构干预。

精确阈值因模型和任务领域而异，但曲线的形状是一致的：一段可接受性能的平台期，随后是一个悬崖。

特别危险的是，这个悬崖并不总是显而易见的。Agent 在选错工具时不会抛出错误，它们会从错误的操作中返回看起来合理的结果。用户看到的是细微的退化——返回了错误数据、意外函数调用带来的副作用、差一点才对的响应。这些在测试中很难发现，因为输出通过了表面级别的质量检查。

工具路由层：架构层面的修复

每一种有效解决方案背后的核心洞见都是相同的：不要给模型所有工具，给它这次具体请求所需的正确工具。

工具路由层位于用户请求和 Agent 推理循环之间。它的职责是在 Agent 开始思考该调用哪个工具之前，将完整的工具目录缩减为上下文合适的子集——理想情况下是 5 到 15 个工具。

路由可以以不同的成熟度实现：

语义检索是最常见的方法。在工具描述上维护一个外部索引（ChromaDB 或类似系统）。当请求到达时，对其进行嵌入，并检索语义上最相似的 top-N 个工具。Agent 只看到这些。这就是 RAG-MCP 及类似系统背后的方法——正是它推动了从 13% 到 43% 的 3 倍准确率提升。

基于规则的路由使用显式逻辑按领域、用户角色或请求类型分配工具子集。与账单相关的查询获得账单工具；数据查询获得分析工具。这比语义路由灵活性差，但更可预测，也更易于审计。

基于 LLM 的路由使用一个轻量级、快速的模型作为分类器，在路由到完整推理模型之前，决定要激活哪个工具领域或 Agent 专长。路由模型处理小上下文；只有目标模型才能看到该领域的完整工具集。

这三种方法共享的关键属性是：它们将工具目录大小与工具上下文大小解耦。你的系统可以支持 200 个工具；但任何一次 Agent 调用只看到 10 个。

分层工具集：扩展工具架构

路由解决了当前的问题，但随着系统变得更加复杂，仅靠路由会变得不够用。你需要结构性的层次。

2026 年开发的 HTAA（混合工具集代理化与适配）框架，将许多团队独立发现的东西正式化了：经常协同使用的工具应该被封装在一起，形成专门化的 Agent。不是一个拥有 50 个工具扁平列表的 Agent，而是一个编排器 Agent 和一组专家 Agent——每个专家 Agent 拥有 5 到 10 个紧密聚焦的工具。

这带来了几个复合收益：

• 降低规划器复杂性：编排器决定调用哪个专家，而不是 50 个函数中的哪一个。这是一个容易得多的选择问题。
• 更好的工具文档：当工具存在于领域上下文中时，它们的描述可以预设领域知识，而不必从头解释一切。
• 更清晰的失效模式：出错时，问题被限定在某个专家的领域内。调试更容易。
• 独立扩展：高流量的工具领域可以单独扩展其专家。

"工具即 Agent"模式具体实现了这种层次结构。专家 Agent——"数据检索 Agent"、"日历管理 Agent"、"代码执行 Agent"——本身作为可调用工具暴露给编排 Agent。编排器的工具列表保持精简，每个专家的工具列表保持专注，整个系统的能力在不降低任何单一推理上下文的情况下得以扩展。

懒加载注册表：按需暴露工具

一种互补的方法是懒加载：不是在会话开始时声明所有可用工具，而是让 Agent 在需要时按需请求工具。

MCP-Zero 及类似实现将工具访问重新定义为一个发现问题。Agent 发出一个结构化查询——"我需要一个能从 Postgres 数据库读取数据的工具"——注册表返回相应的 schema。Agent 只持有其在当前推理链中明确请求过的工具的 schema。

这种方法对于长时运行或多轮 Agent 具有独特优势。随着对话的演进，工具上下文保持整洁，而不是为 Agent 可能需要的每项能力积累 schema。Token 开销随实际使用量增长，而非随潜在使用量增长。

实际权衡是发现机制会增加一次往返延迟。对于工具选择在开始时一次性完成的工作流，会话开始时的检索更简单。对于复杂的、分支的多步骤工作流，懒加载可以有效减少平均 token 消耗。

设计不会伤害你的工具

架构修复了结构性问题，但工具设计质量决定了你拥有多少余量。

最重要的原则是单一职责。每个工具应该只做一件事，有一个明确无歧义的名称，以及一个能清晰说明其边界的描述。当两个工具的能力存在重叠时，模型会犯选择错误。通过拆分或合并来消除重叠。

工具命名必须像对待 API 接口设计一样慎重。只有一个词之差的名称（"get_user_profile" 与 "fetch_user_data"）会制造不必要的歧义。名称应该无歧义地编码动作和实体，工具之间不出现同义词。

工具文档是一个提示，而不是一条注释。模型在推理时会读取你的描述，并用它来决定是否调用这个函数。为模型而写，而不是为人类读者而写。说明该工具的作用、何时使用它，以及——关键是——何时不该使用它。说明反面情况通常比正面情况对消歧更有价值。

保持参数 schema 严格。宽松的类型和可选参数会引发幻觉。如果一个参数总是必需的，就标记它为必需。如果一个值必须是固定集合中的一个，就使用枚举。schema 设计的精确性降低了模型传递格式错误参数的概率。

解决问题之前先度量问题

大多数团队直到质量下降才意识到工具过载。到那时，他们已经交付了一个重构成本高昂的系统架构。

度量工具选择质量的正确时机是在部署之前。构建一个小型的代表性查询评估套件。对每条查询，记录调用了哪个工具、是否正确，以及选择的置信度。在添加工具时运行这个评估。如果准确率下降，说明你越过了阈值——不要在没有解决这个问题的情况下上线。

在生产环境中，明确地对工具调用选择进行插桩。记录每次请求选择了哪些工具，追踪分布情况。如果你看到一批很少被调用的工具却在每次请求中消耗 schema token，它们就是懒加载或专门路由路径的候选。

目标不是最小化系统中的工具数量，而是最小化任意给定推理上下文中的工具数量。这是两个截然不同的问题，解决第二个问题才能解锁构建任意能力系统的能力，同时不牺牲准确性。

结语

"工具越多意味着 Agent 能力越强"这一直觉恰恰是反向的。超过大约 10 到 20 个工具每上下文的阈值，添加能力会摧毁使用它的能力。解决方案不是构建更小的系统——而是构建那些通过路由、层次和懒加载确保每次 Agent 调用只看到所需工具的系统。

工具路由层、分层多 Agent 架构和即时工具发现，正在汇聚成一种生产级大规模 AI 系统的通用架构模式。早日采用这些模式的团队会发现，Agent 可靠性的提升不是尽管拥有更多工具，而恰恰是因为更多工具得到了良好的管理。不这样做的团队，将继续调试那些在孤立环境中看起来正常、却在生产中失效的系统中神秘的准确率回归。

工具目录是基础设施。请像对待基础设施一样对待它：为访问控制而设计，而不仅仅是为可用性而设计。