工具多和工具精有什么区别？选型不再纠结

配给智能体的工具，是多多益善还是少而精？先把结论放前面：任务边界清楚的固定场景，少而精更稳；需求开放、用户什么都会问的通用入口，才需要较宽的工具面。数量本身不是能力，挑对工具、把描述写清楚，比堆数量重要得多。

结论前置：先定场景再定数量

判断从场景出发。日报生成器这类边界清晰的智能体，三四个趁手工具足够，多一个都是干扰；像智谱清言这类面向大众的助手，用户可能让它查资料、写文案、算数据，工具面就得宽一些。先回答用户会提哪几类请求，再决定配几个工具，顺序不能反。

还有一条容易忽略的账：上下文占用。每个工具的名字和描述都会进系统提示词，配二十个工具，还没开工就可能吃掉上千字的窗口空间，真正要处理的材料反而被挤。工具面宽的平台通常靠分组和按需挂载来缓解，自己搭流程时也得留神这笔开销，别让货架占了工作台。

数量一多，选择质量就会下滑

大模型每一步都要从候选工具里挑一个，选项越多，相似工具之间误判的概率越大。两个功能重叠的搜索工具摆在面前，模型可能随机挑一个，明明该用第二个却用了第一个。经验法则是：同类功能只留一个，砍掉重叠项，剩下的每个都不可替代。上下文窗口被描述占满时，模型还会漏看关键工具，选错率进一步抬头。

工具描述写得好比多配三个

模型选工具靠的是工具描述，不是工具名字。描述里写清楚什么时候该用、什么时候不该用、输入长什么样，选错率会明显下降。同一批工具，把描述重写一遍，效果就能上一个台阶，这是改造成本最低的一步。像 Kimi 这类助手内置的联网与读文件能力，本身就是精挑后的工具集样例，值得照着学。反例也常见：描述只写了工具名和一句功能介绍，模型只能靠猜，猜错的账最后都算在效果头上。

工具数量还牵扯到另一个取舍：自研工具和外部接口怎么摆，内部工具和外部 API 差在哪？一文看懂 一文拆过责任归属；如果想先搭个原型看看工具够不够用，零代码编排和代码编排有什么区别？ 能帮你定路线。

给工具做减法的三个信号

出现下面任何一条，就该清理工具箱了。一是调用记录里某工具一个月没被选中，它大概率在白白占用上下文；二是两个工具经常被同时考虑、来回犹豫，说明功能重叠；三是加了新工具后，原本稳定的任务开始选错，新工具在抢戏。减法做完还要做一次复述：把保留下来的工具逐个用一句话讲出用途，讲不顺口的说明定位还糊着，要么补描述要么干脆撤掉。这套动作每个季度走一遍，工具箱就能长期保持清爽。

工具精简自查清单

• 每个工具都有独占场景吗
• 描述是否写明适用与不适用情况
• 三个月没被调用的工具还在吗

砍到每个工具都不可替代，才算配到位。

工具定了，执行策略也要配套，规划先行和边走边看有什么区别？ 讲的就是这层；工具平台本身怎么挑，可参考 Agent 平台和自建框架差在哪？。工具面定得合适，智能体的每一步都走得干脆。

关于工具多与工具精的三个常问问题

• 工具精简会让能力变弱吗？：不会，砍掉的是重叠和闲置项，留下的每个都在实际链路上，选择反而更准。
• 描述要写到多细？：细到同事不看代码也知道什么时候该用它，通常两三句加一个反例就够。
• 先加后删还是先想清楚再加？：先想清楚，事后删除要重跑回归任务，成本比事前多想十分钟高得多。