AI Agent 工具越接越多怎么让它别选错：收敛与评测

Agent 刚起步时，往往只有三个工具：查资料、查数据库、发通知。跑得挺顺。等到项目做深，工具会一路涨到二三十个——读文件、写文件、跑脚本、调接口，连了五个系统，每个系统又拆出三四个动作。这时候你会发现一件怪事：模型没换、提示词没改，Agent 却开始选错工具了。

这不是错觉。工具数量本身就是一个变量，而且它带来的问题比大多数人预想的更早出现。

先把这篇在站内的位置摆清楚：OpenClaw 怎么接 MCP 工具讲的是「怎么把工具接进来」；Function Calling 是什么讲的是「模型底层怎么调工具」；AI Agent 工具怎么设计才好用讲的是「单个工具该怎么写描述和参数」；工具调用失败怎么排查讲的是「调挂了之后怎么查」。这一篇补的是中间那段：工具数量涨上来之后，怎么让它选得准。

一、工具变多，到底坏在哪

四个后果，一个比一个隐蔽：

选择准确率下降。工具一多，就会同时存在好几个「差不多能用」的选项。模型面对相近描述时判断力会明显变差——不是它变笨了，是区分度不够。
上下文被工具描述占满。每一次请求都要把全部工具的说明和参数结构带上。三十个工具的描述合起来可能是几千 token，这些 token 既花钱，又挤占了本该留给任务本身的空间。
参数填串。两个工具参数名相似（比如都叫 query、limit、scope），模型很容易把 A 工具的参数填进 B 工具。
权限失控。工具越接越多，删除、支付、发消息这类高危动作会不知不觉混进默认工具集。这一层可结合权限管理那篇一起看。

判断标准很简单：如果你自己看着这排工具名，都要愣一下才能挑出该用哪个，模型大概率也会愣。

按场景分组。不要给一个通用 Agent 挂全部工具。按任务类型拆成几套——客服场景只挂查单、改单、发消息；数据分析场景只挂查询、画图、导出。这是收益最大、成本最低的一招。
按需加载（工具检索）。先给模型一个「搜索工具」的入口，让它描述需求、检索出三五个候选，再把这些挂进当前上下文。工具上限从「全部」降到「当前相关」。
描述消歧。让相似的几个工具长得不一样：命名加前缀区分来源、描述里写清「什么时候不该用它」、把边界写成一句反例。反例比正例更能拉开区分度。
合并同类项。三个只读不同表的工具，合并成一个「查数据」工具加一个 table 参数，往往比三个独立工具更稳——选择项少了，参数串台也少了。
权限分级。高危工具默认不挂进常规工具集，需要时通过一次明确确认再放进来。默认只读、写操作显式确认。

光靠感觉不行，要有一份选择准确率评测集。建法不复杂：

收集 100–300 条真实输入，每条标注「在这种输入下，正确的工具是哪一个」，可以顺带标上「绝对不能选哪个」。
看三个指标：首选准确率（第一顺位对不对）、前三命中率（正确的有没有出现在前三个候选里）、高危误选率（把不该动的工具选出来几次）。第三个最重要——它衡量的是破坏性错误。
每次调整工具集、改工具描述、换模型，都重跑一遍。这和 Agent 评测的回归思路一致：评测集不是为了拿一个好看的分数，是为了发现「改了 A 会不会弄坏 B」。

评测集怎么建、样本怎么覆盖边界，可以参考评测样本那篇。

工具名和描述写得像。search、query、find、lookup 四个词被用来指四件不同的事，模型分不清。命名要按「动作 + 对象」来，而不是按实现来。
把不该给的工具当备胎挂着。「反正它平时也不会用」是最危险的想法。不用的工具就该撤掉，挂在那就是风险敞口。
只在顺利路径上测过。正常输入选得对，不代表异常输入也选得对。要专门测那些「看起来像 A、实际该用 B」的输入。
把业务规则写死在工具描述里。规则一变就要动工具、动评测集。规则应该放在提示词或配置里，工具描述只负责说清「这个工具做什么、边界在哪」。

优点：直接提升任务成功率，减少「看起来在干活、其实用错工具」的隐性失败；降低 token 成本；让高危动作有了可控边界；评测集建起来之后，后续每次改动都有据可依。

缺点：工具集拆分需要理解业务，前期要花时间梳理；按需加载多了一步检索，链路变长；评测集维护是持续投入，不是一次性工作。

适合谁：工具数量超过十个、且已经出现「选错工具」现象的项目；接了多个业务系统的企业 Agent；对高危动作有合规要求的场景。

不太需要谁：工具就三五个、彼此差异明显的轻量应用——先按工具设计那篇把描述写清楚，就够用了。

最后一句：让 Agent 变强的方向，不是给它更多工具，而是让它在每个时刻只需要面对那几个真正相关的工具。