工具太多Agent反而更笨：动态工具发现的设计取舍

一个反直觉的现象

团队把内部系统全接进了 Agent：20 个业务 API、15 个数据库查询、若干 MCP 服务，工具清单超过 80 个。上线后效果比只有 5 个工具的原型明显变差——选错工具、参数乱填、该调不调。

这不是模型变笨了，而是你把选择问题塞给了它。工具数量增长，模型的决策空间是指数级膨胀的，而每次调用前它都得在一堆长得很像的描述里挑一个。

工具爆炸的三个具体伤害

上下文稀释。 每个工具的 schema 都是 token。80 个工具的完整描述可能吃掉上万 token，留给真正任务内容的预算被挤占。

语义撞车。 search_docs 和 query_knowledge_base 和 find_article 对模型来说几乎是同义词，它会随机选，错了还不知道错。

参数幻觉。 工具越多，schema 越长，模型漏填必填字段、把枚举值编造出来的概率越高。

三种解法对比

全量挂载

所有工具一次性塞进上下文。实现最简单，适合工具数少于 15、且彼此区分度高的场景。超过这个量级，收益快速转负。

动态检索（Tool RAG）

把工具描述做成向量索引，每轮根据用户意图检索 Top-K 工具再挂载。优点是工具池可以无限大；代价是多一次检索延迟，且检索错一次，整轮就废。

实践经验：检索层要做得”粗一点”——按领域检索而不是按用户原话检索。比如用户说”这个客户上次买了什么”，检索词应该是”客户/订单数据查询”，而不是原句。

分层路由

先由一个轻量路由器把任务分到 3–5 个子域，每个子域内挂载 5–8 个精挑过的工具。这是最稳的方案：决策空间始终可控，而且每个子域可以有自己的提示词和约束。

代价是工程复杂度：你得梳理工具的能力边界，还得处理跨领域的任务。

选型判断标准

用三个问题决定：

1. 工具有没有天然分域？（销售 / 客服 / 运维）有就上分层路由
2. 工具池会不会持续增长？ 会就至少要做动态检索兜底
3. 任务是不是开放式？ 开放式任务（研究、探索）别贪多，工具少而精胜过多而全

三个必做的工程细节

• 写工具描述时把”什么时候不该用”写进去，比写功能更重要
• 合并同义工具，能用参数区分的能力不要拆成两个工具
• 记录工具选择准确率，这是评估 Agent 最容易被忽略的指标

小结

Agent 的能力上限不是”能调用多少工具”，而是”在多复杂的场景下还能选对”。少而清晰，永远比多而混乱更强。 真想扩展能力，先扩展路由，再扩展工具。