工具爆炸问题：为什么你的智能体在 30 个工具时就会崩溃

每个智能体的演示都从三个工具开始。一个网页搜索，一个计算器，也许再加一个代码执行器。智能体每次都表现完美。于是你上线了，团队开始添加各种集成——Slack、Jira、GitHub、邮件、数据库查询、内部 API。六个月后，你的智能体拥有了 150 个工具，却有 40% 的概率选错。

这就是工具爆炸问题，也是生产环境智能体系统中最少被讨论的失败模式之一。退化并非线性的——而是断崖式的。一个在 5 个工具时准确率达 95% 的智能体，在你给它 100 个工具时可能会跌破 30%，即使模型和提示词完全没有改变。

非线性退化曲线

Berkeley Function Calling 排行榜讲述了一个清晰的故事：单个工具调用的准确率在隔离测试中可以达到 96%，但在大规模工具集、多轮对话的场景下会骤降至不到 15%。退化的发生源于三个叠加因素。

第一，上下文污染。每个工具定义都会消耗 token。一个简单的单参数工具在提示词中大约占用 96 个 token。一个包含 28 个参数的复杂工具则需要 1,633 个 token。将其扩展到 37 个工具，你仅在工具定义上就消耗了超过 6,000 个 token，而用户的实际查询还没有进入画面。对于 4K-8K 上下文窗口的模型来说，这几乎不留任何推理空间。

第二，语义混淆。现实组织中的工具并不具备清晰、互不重叠的描述。你最终会拥有 send_slack_message、post_notification、send_alert 和 create_channel_message——这些工具都可以合理地处理"通知团队这次部署的情况"。模型必须根据微妙的描述差异进行消歧，而随着候选集的增长，它猜错的概率越来越高。

第三，多步骤任务中的组合爆炸。当智能体需要从 100 个工具中串联三个工具时，它需要在大约一百万种组合的可能性空间中导航。规划开销的增长速度超过工具数量的增长，模型将推理预算花在了工具选择上，而非任务完成上。

阈值究竟在哪里

从业者们通过痛苦的经验总结出了大致的性能分级：

• 1-5 个工具：可靠。任何主流模型都能在最少的提示工程下很好地处理。
• 5-10 个工具：通过优化描述和仔细的工具命名可以正常运作。
• 10-30 个工具：可测量的退化开始出现。你需要架构层面的干预——检索、路由，或两者兼具。
• 30+ 个工具：朴素的"把所有工具塞进提示词"的方法会失败。工具选择准确率降至可用阈值以下。
• 100+ 个工具：没有检索或路由层，智能体在工具选择上基本处于瘫痪状态。

这些数字会随着模型能力的变化而有所浮动，但曲线的形状始终如一。GPT-4o 在 NESTFUL 基准测试的链式 API 调用中，即使在优化设置下也仅达到 28% 的完整序列匹配准确率。问题不在于模型不擅长工具调用——而在于这项任务在组合复杂度上急剧增长，暴力填充上下文的方式无法解决。

三种真正有效的架构模式

Tool RAG：先检索再选择

最直接的修复方案直接借鉴了文档 RAG 的思路。与其将所有工具定义塞进提示词，不如将工具描述嵌入向量存储，并为每个查询仅检索最相关的 top-k 工具。

效果非常显著。研究表明，智能工具检索可以将调用准确率提升三倍，同时将提示词长度减半。Anthropic 的 RAG-MCP 框架将大规模工具集的工具选择准确率从 13% 提升至 43%——虽然还不完美，但相比"基本等同于随机"已是巨大的进步。

实现很简单：将每个工具的名称、描述、参数模式和使用示例进行嵌入。在查询时检索前 5-10 个候选工具，仅将这些呈现给模型。你可以通过混合检索（结合语义搜索和关键词匹配）、LLM 辅助重排序以及对模糊输入进行查询改写来进一步增强效果。

需要注意的是，静态嵌入相似度无法很好地捕捉工具依赖关系。如果工作流的第二步需要工具 B，但用户的查询在语义上只匹配工具 A，纯检索方法会完全遗漏工具 B。这时动态检索——基于原始查询和不断演进的执行上下文来决定工具选择——就变得至关重要了。

层级路由：两级分发

当你的工具清单跨越多个领域（CRM、邮件、分析、基础设施）时，单次检索很难准确跨越领域边界。层级路由在此基础上增加了一个显式的分发层。

该模式的工作方式如下：一级路由器将用户意图分类到某个领域（例如，"这是一个邮件操作请求"）。二级选择器只看到该领域内的工具，从中挑选具体工具。每一级的决策空间都小得多——8 个领域而非 150 个工具，然后在一个领域内 12 个工具而非 150 个。

这与人类组织处理请求的方式如出一辙。你不会让公司里每个员工都来评估是否应该由他们处理一张工单。你先路由到正确的团队，再路由到正确的人。

代价是延迟。两次 LLM 调用而非一次。对于面向用户的同步智能体来说，这很重要；对于异步后台智能体来说，通常可以接受。你也可以将第一级实现为轻量级分类器（微调的小模型甚至基于规则的路由器），以最大限度地减少延迟影响。

工具整合：STRAP 模式

有时候最好的架构就是更少的工具。Single Tool Resource Action Pattern（STRAP，单工具资源操作模式）于 2026 年初提出，旨在解决工具膨胀最常见的根源：每个实体的每个 CRUD 操作都对应一个工具。

以一个典型的邮件平台集成为例。朴素方法会创建独立的工具：create_email_list、get_email_list、update_email_list、delete_email_list、create_sequence、get_sequence——以此类推，跨越 20 多个实体。这轻轻松松就是 80-100 个工具用于单个集成。

STRAP 将这些整合为带有 resource 和 action 参数的领域级工具。不再是 96 个工具，而是 10 个：email(resource: "list", action: "create", name: "Newsletter")。将此模式应用于 Outlet 邮件平台的实际结果：96 个工具减少到 10 个，上下文开销减少约 80%，工具选择错误降至接近零。

其核心洞察在于：LLM 一旦选对了工具，在填充结构化参数方面表现出色。困难的部分是工具选择，而非参数构造。通过将选择空间从 96 个选项压缩到 10 个，你将大部分复杂性转移到了问题中容易的部分。

STRAP 最适用于工具遵循跨多个实体的统一 CRUD 模式的场景——这描述了大多数 SaaS 集成。当每个工具执行的是真正独特、互不相关的操作时，STRAP 就不太适用了。

没有人谈论的组织问题

仅靠架构无法解决工具爆炸问题。更深层的问题在于组织层面：工具之所以不断累积，是因为没有人对其生命周期负责。

在大多数团队中，添加一个工具只需要一个下午的 PR。但移除一个工具需要审计哪些智能体在使用它、是否有工作流依赖它、以及替代方案是否覆盖了所有边界情况。这种不对称性意味着工具清单只增不减。

生产环境的智能体团队需要与成熟 API 团队多年前学到的相同纪律：

• 能力重叠检测。定期审计你的工具清单，排查功能重复。如果三个工具可以通过不同渠道发送通知，考虑一个带 channel 参数的单一 notify 工具是否更好。
• 使用追踪。记录智能体实际调用了哪些工具。30 天内零调用的工具是废弃候选。频繁被选中但随后报错的工具需要更好的描述或替换。
• 废弃仪式。建立工具下线流程：标记为已废弃，在工具描述中重定向到替代方案，监控残余调用，然后移除。这与业界花了十年才学会的 API 版本管理纪律如出一辙。
• 每个智能体的工具预算。为每个智能体设置明确的可访问工具数量上限。如果一个智能体需要超过 20-30 个工具，那是一个信号，表明应该将其拆分为专用子智能体或添加路由层——而非继续扩大工具集。

正在成型的技术栈

生产环境的工具管理技术栈正在向分层架构收敛，其形态与微服务领域的演进惊人地相似：

最底层是工具注册中心，存储所有可用工具及其模式、描述、使用示例和元数据（所有者、废弃状态、领域标签）。这是唯一的事实来源。

其上是检索层，索引工具描述并执行语义搜索和关键词搜索，为任何给定查询缩小候选范围。

再上层是路由层，通过分类或层级选择将请求分发到特定领域的工具子集。

最后是智能体运行时，它只看到与当前任务最相关的 5-10 个工具。智能体不知道也不关心注册中心中有 200 个工具——它在一个聚焦且可管理的工作空间中运行。

这种分层方法还支持扁平工具列表无法实现的治理能力：按工具的访问控制、工具调用的审计日志、昂贵工具的速率限制，以及在更广泛部署之前将新工具分阶段推出给部分智能体。

为 10 个工具构建，为 1000 个工具架构

工具爆炸问题本质上是一个扩展性问题，而与大多数扩展性问题一样，解决方案不是避免增长——而是在需要之前就添加正确的间接层。

如果你的智能体工具少于 10 个，那就没问题。投入精力写好工具描述，然后继续前进。如果你正在接近 30 个工具，现在就实施检索或整合策略，不要等到准确率下降到侵蚀用户信任的程度。如果你已经超过 50 个工具，你需要的是层级路由和组织级别的工具治理，而不仅仅是更好的提示词。

在生产环境中真正有效的智能体，不是工具最多的那些，而是每个工具都可被发现、描述清晰、且仅在真正相关时才呈现给模型的那些。架构模式已经存在。更难的部分是建立组织纪律，防止你的工具清单变成智能体版的杂物抽屉。