给 Agent 挂了 50 个工具为什么它开始胡言乱语深扒 Function Calling 的数量陷阱很多刚开始做 AI Agent 的同学最喜欢的操作就是给大模型塞各种工具。查天气的、查库的、发邮件的恨不得把公司所有 API 都通过 Function Calling 挂上去。刚挂 5 个工具的时候测试效果完美。挂到 50 个的时候不对劲了。大模型开始瞎编参数或者放着明明能用的工具不用硬给你输出一段它自己编的“正确答案”。最离谱的是两个功能差不多的工具它偏偏挑那个错的调用。你以为是 prompt 写得不够清楚其实这是大模型典型的“工具数量陷阱”。大模型的注意力是有限的。当你把 50 个工具的 JSON 描述包括每个参数的名字、类型、描述全部塞进上下文里这部分本身就占了成千上万个 token。就算模型支持 128k 上下文它的注意力也会在这个巨大的工具列表里被稀释。这就好比你让一个人去五金店买螺丝刀。如果你给他一张只写了 3 种工具的清单他一眼就能挑出需要的。如果你给他一张写了 500 种五金工具的清单他很可能会看花眼最后随便拿个长得像螺丝刀的扳手回来。而且工具越多描述重合的概率就越大。比如你有一个get_user_info和一个search_user_profile。人类能分清前一个是查底层库后一个是查前端展示页但大模型只能靠你写的 description 去猜很容易就调错了。怎么解决目前业界落地的常见方案就两个。第一个思路是做工具分类也就是分层路由。别把 50 个工具平铺给一个 Agent。把系统拆成多个子 Agent。比如一个专门负责“用户查询”的子 Agent 只有 5 个相关工具一个专门负责“订单操作”的子 Agent 有 3 个工具。主 Agent 的工作不是直接调工具而是判断用户的意图属于哪个子系统把任务丢给对应的子 Agent。这就把一个 50 选 1 的难题变成了 5 选 1 然后再 10 选 1。第二个思路是给工具做 RAG检索增强生成。把这 50 个工具的描述向量化存到向量数据库里。用户输入一个问题系统先去数据库里查出相关度最高的 Top 5 个工具。然后再把这 5 个工具的 JSON 结构跟用户的提示词一起发给大模型。这样大模型每次看到的工具列表都很短命中率和准确度就直线上升了。工具不是挂得越多越好。给智能体一把只有两个功能的瑞士军刀它能用得很溜给它一个装了 100 把刀的工具箱它只会把手割破。下次再遇到 Agent 乱调工具先查查你到底在系统提示词里塞了多少个工具定义。