企业官网建设流程全解析

给 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 乱调工具，先查查你到底在系统提示词里塞了多少个工具定义。