工具选择：什么时候该模型挑，什么时候该你挑

会用工具的 Agent 在 demo 里看起来很有力，因为模型在选下一步做什么。它在生产里看起来很脆弱，因为模型在选下一步做什么。可用工具的空间随特性线性增长，随边界情况二次增长——超过大约十二个工具之后，模型开始混淆它们的角色，靠工具名表面的相似性来挑选。

工具数量增长时会出什么问题

超过十到十五个工具之后，描述在模型的表征里开始模糊。模型选了搜索工具，而正确答案是数据库查询，因为两者的描述里都有”lookup”。模型选了简单的工具，而本该选复杂的那个，因为简单那个匹配了用户措辞。这一切都不会在单次调用测试里出现——它出现在某个工具悄悄处理了本该由另一个工具处理的请求时，答案技术上有效，但运营上错了。

架构层面的答案，不是 prompt 层面的

把工具按用途分组，把请求路由给只看得到相关子集的子 Agent。给顶层模型暴露的工具，比你内部实际暴露的少——五个目的清晰的可见工具，胜过二十个无差别工具。对破坏性或昂贵的工具，要求显式的名字匹配，而不是模型挑选。

Agent 该挑的工具数量，比你想给它的要少得多。超过某个阈值之后，每多一个工具，都让所有其他选择变得更糟。