给智能体配工具像给新人发装备，直觉是装备越多越能干，实际往往相反：装备太多，新人先得花力气挑，挑错了还要返工。这个误区错在哪？错在把工具数量当成了能力本身，而真正决定效果的是任务和工具的匹配度。
错在哪：数量被当成了能力
工具列表长，演示时确实唬人，但每一步执行时，模型都要在全部候选里做选择。二十个工具里挑对一个的概率，天然低于五个里挑对一个，尤其几个工具功能还重叠时。选择本身要耗上下文，工具描述占掉的篇幅，都是挤占正题的隐形成本。拿厨房打比方：灶台摆满二十口锅，厨师光找锅就手忙脚乱；三口锅各司其职，出菜又快又稳。厨艺不随锅数增长，智能体的能力也不随工具数增长。
混乱的代价比缺工具更大
缺工具的表现很直白：任务做不了，报错明显。工具太多的问题是慢性子：任务能做完，但时而选错、时而绕远，效果时好时坏，排查还找不到头绪。慢性问题比急性问题更耗人，因为它消磨的是对整个系统的信任。
从成本视角看也成立：多配一个工具就多一份维护，接口改版、密钥轮换、超时调整都要跟着改。给用不上的工具付维护费，是最典型的隐性支出，精简工具箱的同时也是在精简这份账单。工具多了，报错来源也跟着多，一次失败可能牵出两三个工具的排查，定位时间成倍拉长，排查路径的长短也是配置时该掂量的维度。
缺工具和工具过多，代价不在一个量级。
| 对比维度 | 工具不够 | 工具过多 |
|---|---|---|
| 表现 | 任务做不了，报错明显 | 任务能做完，但时而选错、时而绕远 |
| 问题性质 | 急性，一眼看到 | 慢性，消磨的是对整个系统的信任 |
| 排查难度 | 报错直指缺口 | 一次失败可能牵出两三个工具，定位时间成倍拉长 |
| 维护成本 | 缺了才补，按调用记录增加 | 多配一个就多一份维护，接口改版、密钥轮换都要跟着改 |
| 自查信号 | 有任务因缺工具而失败才加 | 有工具连续几周没被选中就撤 |
正确说法：按任务配最小工具集
正确顺序是先列任务再配工具：这个智能体到底要完成哪几类动作，每类动作挑一个最称手的，同类只留一个。Kimi、纳米AI 这类产品内置的能力清单就是范例，不多但个个有明确分工。新工具想进场，先回答它替代了谁或者补了哪个空缺，答不上来就别加。配置时还可以分层：核心链路的工具常驻，外围能力按需挂载，请求进来先判断要用哪组，再把对应工具挂上，窗口占用和选择噪音一起降。
工具多还常和多智能体幻想配对出现，觉得分工越细越强，「多 Agent 一定比单 Agent 强」错在哪？ 拆过这层；工具挑错后的错误处理也跟着复杂，「Agent 出错重试就好」错在哪？ 讲了为什么重试救不了选错的工具。
判断工具够不够用的自查法
两个方向各查一遍。够用方向：翻最近的调用记录，有没有任务因为缺工具而失败，有才加。过载方向：有没有工具连续几周没被选中，有就撤。像家庭收纳一样定期整理，工具箱才不会越长越乱。
配置完成后再做一次压力测试：故意构造几个边界任务，看工具组能不能顶住。扛得住的配置才敢上量，扛不住的说明工具或描述还有缺口，趁早补齐比上线后补课便宜。数工具的同时也数一数描述字数，超了就精简描述而不是砍功能，两头兼顾才稳。
工具瘦身三步
- 列全任务类型，一类配一个主力工具
- 同类重叠的只留描述最清楚那个
- 季度清点，闲置的下架
工具箱的大小由任务决定，不由收藏癖决定。
全自动幻想和工具堆料常互相加持，觉得工具够多就能放开跑，「Agent 能全自动搞定一切」错在哪？ 已经拆过前者；工具再多，记不住上次的事照样白搭，记忆的真相见 「记忆功能等于真记忆」错在哪？。
关于工具数量再多问三句
- 工具少会不会限制创意任务？：创意靠的是模型本身，工具只管取料和交付，少而准反而少干扰。
- 平台预置的工具都要开吗？：不用，按任务开需要的，预置清单是备选货架不是必点菜单。
- 合并两个相似工具麻烦吗？：通常就是改描述加个参数的事，合并后选择噪音立减，值得做。
