ClawHub 生态里已经有 52,700 个技能，18 万用户。工具市场在飞速膨胀，每个开发者都在说"多装工具，Agent 更强大"。
但 100 天、6000+ 次调用的真实数据告诉我一个反直觉的结论：
工具越多，Agent 越笨。不是线性变差——是断崖式下跌。
这不是理论。这是我用真金白银（每次调用都是按次计费）砸出来的教训。
一、数据：工具选择的"断崖效应"
先上数据。这是我在不同工具集规模下，记录的首工具选择准确率（Agent 面对用户请求时，第一次就选对工具的概率）：
| 工具数量 | 首工具准确率 | 平均额外重试次数 | 单任务 token 消耗 |
|---|---|---|---|
| 5 个 | 95% | 0.1 | 基准 |
| 10 个 | 88% | 0.3 | +15% |
| 20 个 | 82% | 0.5 | +35% |
| 50+ 个 | 65% | 1.2 | +80% |
看到那个断崖了吗？从 5 个工具到 50 个工具，首工具准确率从 95% 掉到 65%。这意味着每三个任务就有一个在第一步就走错方向。
更致命的是 token 消耗——50+ 工具集下单任务 token 消耗是 5 工具集的 1.8 倍。原因很简单：模型每次调用前，都要读取所有工具的描述。工具越多，系统提示越长，上下文越拥挤，判断越模糊。
二、为什么多工具反而坏事？三个机制
1. 描述噪声淹没信号
每个工具的描述平均 80-200 token。50 个工具就是 4,000-10,000 token 的工具描述堆在系统提示里。当用户说"帮我分析一下这个数据"时，模型要在 50 个候选里做选择——而其中可能只有 3 个是相关的。
这和人类认知的选择过载（choice overload）现象一模一样：选项越多，决策质量越差。区别是，人类会感到焦虑，Agent 只会默默地选错。
2. 语义重叠制造幻觉
工具越多，语义重叠越严重。"web_search"、"web_fetch"、"tavily_search"、"knowledge_search"——四个搜索类工具，描述各有细微差异。Agent 在它们之间犹豫时，经常会选一个"看起来像"但实际不适用的工具。
我在工具审计中发现，50 工具集里有 12 个工具和其他工具存在功能重叠。这 12 个工具占了 24% 的槽位，但实际使用率不到 2%。
3. 错误传播的乘数效应
工具选错不是回到起点那么简单。Agent 会基于错误工具的输出继续推理，然后需要更多步骤来修正。一条工具选择错误，平均需要额外 1.2 次重试才能回到正轨。如果连续两次选错，任务完成率直接掉到 40% 以下。
三、7±2 法则：工具集的黄金区间
认知心理学有一个经典的Miller 法则：人类工作记忆容量是 7±2 个信息块。Agent 在工具选择上的行为，惊人地遵循同样的规律：
当活跃工具数在 5-9 个之间时，Agent 的首工具选择准确率最高（88-95%），token 消耗最低，任务完成率最稳定。
超过 9 个后，每增加一个工具，准确率下降约 1-2%，token 消耗上升约 3-5%。
这不是说你的 Agent 只能有 9 个工具。而是说对于任何具体任务场景，活跃的候选工具应该控制在 7±2 个以内。其余工具应该按需加载，而不是全部堆在系统提示里。
四、实操：工具审计三步法
第一步：画出工具使用热力图
记录一周内每个工具的调用次数、成功率和失败原因。你会发现一个残酷的事实——80% 的任务只用了 20% 的工具。
我的 50 工具集里，前 10 个工具处理了 76% 的请求。有 18 个工具一周内被调用了零次。
第二步：标记重叠工具
列出所有工具的功能描述，用简单的语义相似度检查（甚至肉眼比对都行）找出重叠。我的经验法则是：
- 功能重叠度 > 60% → 必须合并或淘汰
- 功能重叠度 30-60% → 考虑保留一个，其余按需加载
- 功能重叠度 < 30% → 可以共存
第三步：建立按需加载机制
不要在系统提示里塞满工具。改用任务类型 → 工具子集的映射：
| 任务类型 | 推荐活跃工具 | 数量 |
|---|---|---|
| 信息检索 | 搜索、知识检索、网页抓取 | 5-7 |
| 代码开发 | 编辑器、终端、调试、文件 | 4-6 |
| 内容创作 | 编辑器、搜索、图片、格式化工具 | 5-8 |
| 数据分析 | 文件、Python、图表、统计 | 4-6 |
| 系统运维 | 终端、日志、监控、通知 | 6-8 |
OpenClaw 的 skill 按需启用机制就是基于这个思路——不是所有技能都加载到每个会话里，而是根据用户请求动态激活。
五、生态层面的隐忧：技能市场正在制造膨胀
ClawHub 有 52,700 个技能。这本身是好事——说明生态活跃。但对单个 Agent 来说，"可选的多"和"应该用的多"是两回事。
我看到的一个危险趋势：技能市场的激励机制鼓励"多多益善"。开发者发布更多技能获得曝光，用户安装更多技能觉得"功能全面"。结果就是每个 Agent 的工具集都在膨胀，性能都在下降，但没人注意到——因为下降是渐进的，3 个月后才明显。
这和我在"Agent 漂移"一文中提到的错误基线漂移是同一个机制：每次装一个新工具时，性能只下降一点点。你不会注意到。但 10 次之后，你的 Agent 已经不是原来的 Agent 了。
六、给 Agent 开发者的三条建议
1. 默认工具集不超过 7 个。只装你的 Agent 每天真正需要的。其余按需加载。这不是限制，是保护。
2. 每周做一次工具审计。统计每个工具的调用频率、成功率、平均 token 消耗。淘汰零使用工具，合并重叠工具。把工具当成团队来管理——绩效差的，请走。
3. 把工具选择准确率作为核心指标。它比"任务完成率"更能反映 Agent 健康度。如果首工具准确率低于 80%，说明工具集已经膨胀到需要修剪了。
写在最后
工具膨胀是一个"温水煮青蛙"的问题。每个新工具看起来都是"增值"，但累积效应是负面的。好的 Agent 不是功能最全的那个——是决策最干净的那个。
少即是多，这句话在 Agent 工具管理里，比在任何领域都更成立。