给 AI Agent 上 100 个工具，看起来很强，其实是个致命陷阱

你以为给 AI Agent 更多工具，它就会更聪明？Prosodica 的 Sohail Shaikh 和 Ankush Rastogi 用真实生产数据泼了一盆冷水：工具一多，Agent 不仅更慢、更贵，还会明显变笨。这场演讲拆穿了一个正在被大量团队复制的危险设计模式。

一个看似“很合理”的决定，正在悄悄毁掉你的 Agent

很多 AI 团队都有一个直觉：既然 Agent 需要调用工具，那不如一次性把所有工具都丢给它。Demo 时，这个设计几乎完美——模型看起来无所不能，调用链条也很顺滑。Sohail 在开场就点破了问题：这个方案在 10 个工具以内可能还能撑住，但当工具目录增长到几十、上百个时，系统会开始全面崩坏。

他们把这种模式称为“100-Tool Agent Trap”。陷阱之所以危险，是因为它不是立刻失败，而是缓慢失控：响应时间变长、推理成本飙升、更糟的是，模型的决策准确率开始明显下滑。你以为自己在‘增强能力’，实际上是在给模型制造认知噪音。

为什么工具一多，模型反而更容易选错？

演讲中反复出现一个词：context overload（上下文过载）。当你把几十个甚至上百个工具描述同时塞进 prompt，本质上是在逼模型解决一个它不擅长的问题：在巨大的候选空间里做精细决策。

Sohail 指出，随着工具数量增加，prompt 变长、语义变稀释，模型对每个工具的区分能力会下降。幻觉不一定来自模型“胡说”，而是来自选择空间被污染。更糟的是，这种错误是系统性的：一旦超过某个阈值，准确率会出现明显塌陷，而不是线性下降。

Ankush 从系统角度补了一刀：更长的上下文，意味着更高的 latency 和更高的 token 成本。你付出了更多钱，却换来了一个更慢、更不稳定、也更难调试的 Agent。

语义路由：别让模型一次看完所有工具

解决方案并不复杂，但非常反直觉：不要让模型一开始就看到所有工具。

他们给出的核心设计是 Semantic Routing + Just-in-Time Context。简单说，语义路由就像一个“工具货架”：先用轻量级的路由逻辑，根据用户意图筛选出极小一部分可能相关的工具，再把这些工具注入到模型的上下文中。

Ankush 用了一句很形象的比喻：工具不是模型的常驻记忆，而是“需要时再取”。这种 just-in-time 的上下文注入，让模型的 working set 始终保持很小。结果是三重收益：决策更准、响应更快、成本更低。

在他们展示的对比中，一旦生产系统的工具数量超过 50 个，引入基于路由的架构就不再是‘优化’，而是‘必须’。

真正的错误：让模型替你做架构决策

在实施清单那一页，演讲抛出了一个值得所有 AI 工程师警惕的判断：很多 Agent 架构，本质上是在让模型解决一个它不该解决的问题。

工具选择，本来是一个检索和系统设计问题，却被直接丢给了大模型。语义路由的价值，并不是“更聪明的 prompt”，而是把职责拆清楚：系统负责缩小选择空间，模型只负责在合理范围内做判断。

他们强调，评估 Agent 时，不要只看工具目录能扩多大，而要看模型的有效工作集能不能保持稳定。工具可以无限增长，但模型不应该被迫一次性理解全部世界。

总结

这场分享真正击中的，不是某个具体技巧，而是一个正在被广泛忽视的工程常识：更多上下文，不等于更好的智能。对 AI 从业者来说，最重要的 takeaway 是——当你的 Agent 开始变慢、变贵、变笨时，别急着怪模型，先检查是不是掉进了“100-Tool Agent”的陷阱。

行动建议很明确：把工具选择当成检索问题来设计，引入语义路由，让上下文按需注入，而不是一次性倾倒。未来 Agent 的竞争力，可能不在于谁的工具更多，而在于谁更懂得什么时候不该让模型看到一切。

关键词： AI Agent， 语义路由， 工具调用， 上下文管理， 系统架构

事实核查备注： 需要核查：演讲者姓名拼写（Sohail Shaikh / Sohaib Shaikh）、公司名称 Prosodica、工具数量阈值（50 个工具）、视频发布时间（2026-06-28）、核心概念表述是否为原话或意译