工具越多越笨：Agent 的「工具选择税」与三种解法

团队常有一个直觉：给 Agent 更多工具，它就能干更多事。现实经常反过来——从 8 个工具加到 40 个之后，成功率不升反降，而且失败方式变得很奇怪：它能调对工具，但参数传错；或者明明有专用工具，偏去用通用搜索绕一圈。

这笔税是从哪扣的

叫它”工具选择税”：每增加一个工具，模型在”选哪个、怎么调”上的决策成本上升，而这个成本会从任务成功率里扣。

三个具体机制：

注意力摊薄。 40 个工具的 schema 描述通常占 4000～8000 token，挤占的是上下文里放任务细节的空间。同时模型要在 40 个高度相似的描述里比对，相似工具（search_docs / find_document / query_knowledge）会互相干扰。

描述污染。 工具描述写得越长越全，区分度反而越低。当每个工具都声称”可以查询各种信息”，选择的依据就消失了。

错误连锁。 工具多了，模型倾向于”多用几步凑答案”。一次任务从 3 步变 7 步，每步 95% 正确率，整体正确率从 86% 掉到 70%——步骤数是复利敌人。

解法一：分组加载（按域按需暴露）

不做一次性全量暴露，而是先判断任务属于哪个业务域，只加载该域的 5～8 个工具。域判定用一次极轻的分类调用，甚至可以用规则/关键词兜底。

用户："帮我看看上周那个合同能不能改交付日期"
→ 域名：合同管理 → 加载工具：search_contract, get_contract, check_clause,
  update_contract_draft, get_approval_flow

要点：域判定必须在工具描述之外完成，不能靠模型在 40 个工具里自己发现规律。这个”路由层”最好显式存在，可观测、可测试。

解法二：两段式路由（先找工具，再执行）

把”找工具”从”执行任务”里拆出来，是收益最高的一步：

1. 用工具目录（名称 + 一句话描述）做一次检索，返回候选 3～5 个。
2. 只把候选工具的完整 schema 放进上下文，再让模型执行。

好处不仅是省 token。更关键的是检索用的目录可以独立维护和评测：如果某个任务找不到正确工具，你能明确知道是”目录描述问题”，而不是”模型太笨”。问题从玄学变成工程。

代价是多一次调用延迟。对延迟敏感的场景，可以把常用工具固定为”常驻工具集”，其余走检索。

解法三：工具合并（减少同名概念）

很多工具其实是同一个能力的不同切面：get_user / get_user_orders / get_user_address 完全可以合并为一个 get_user_info(fields: [...])。

合并原则：同一实体、同一权限、同一数据源的动作，合并成一个工具 + 参数区分。 反过来，不同权限等级的动作坚决不合并——把”查退款”和”发起退款”放进同一个工具，等于把权限校验交给了模型。

怎么量化这笔税

别凭感觉砍工具，做一次对照实验：

1. 固定 30～50 个真实任务，准备标准答案（该调哪些工具、关键参数）。
2. 跑三组：全量 40 工具 / 分组加载 / 两段式路由。
3. 记录四个数：工具选择准确率、参数正确率、平均步数、整体任务成功率。

通常你会看到：工具选择准确率差距不大，但平均步数从 7 降到 3.5，整体成功率能涨 15 个点以上。步数是最灵敏的先行指标，先看它。

一个反直觉的结论

砍工具的目标不是”少”，而是”每次决策时上下文里只有相关的几个”。一个合理的生产 Agent 通常常驻 4～6 个基础工具（搜索、读、写、算、问人），其余按需调度。

工具的丰富度应该体现在系统能力里，而不是单次上下文中。这两者混淆，就是工具选择税的来源。