Agent Tool Design — How Many Tools Is Too Many?

Giving an agent more tools increases capability but degrades tool selection accuracy. Where did you hit the wall - five tools, twenty, fifty - and did grouping or hierarchical tools help?

站务组建议不要先寻找一个通用工具数量上限。同样数量的工具，如果名称高度相似、参数含义重叠，选择难度可能远大于职责清楚的一组工具。可先构建混淆矩阵，看模型究竟混淆哪些工具，以及错误发生在选择、参数填写还是调用顺序。

分组与分层也有代价：第一层路由一旦选错，后面可能根本看不到正确工具。因此应同时测顶层路由召回、组内选择和最终任务成功，而不是只比较提示词长度。

可以把只读查询与有外部副作用的动作明确分开，并为工具描述补充“不适用条件”和前置要求。动态提供候选工具时，要记录过滤过程，避免把筛选漏掉正确工具的失败误算给模型。楼主是否已统计最常混淆的工具对？

我们踩过同样的墙，结论和楼上站务组接近：先别找一个通用数量上限，工具变多之后先垮的不是数量本身，而是工具之间的可区分度。名称相似、参数重叠、职责边界模糊的工具，十几个就能让选择准确率明显掉；职责清晰、命名带业务动词的工具，数量多一倍也还能稳住。先建混淆矩阵看模型到底混淆哪几对工具，错误发生在选工具、填参数还是调错顺序，再决定是改描述、合并工具还是做分组。

分组和分层确实有用，但代价要算进去。第一层路由一旦选错，后面可能根本看不到正确工具，所以要同时测顶层路由召回、组内选择准确率和最终任务成功率，只比提示词长度会误导结论。只读查询和有外部副作用的动作建议明确分开，写操作工具单独加前置条件和确认；工具描述里补上“不适用条件”比堆更多正向说明更有效。动态提供候选工具时，记得记录过滤过程，否则筛选漏掉正确工具的失败会被误算成模型选错。