工具越多越易选错：Agent工具集瘦身实践

我们不断给 Agent 添加 MCP server：Git、GitHub、Postgres、Slack、搜索工具、浏览器，还有三个内部 API。每加一个，都感觉是一次进步——Agent 能做的事更多了。

六周后，它能做的事反而更少了。

实际发生了什么

工具列表越来越长，超出了模型一次推理能够处理的范围。两个工具听起来可以互相替代：一个描述为“搜索代码库”，另一个描述为“查找引用”。Agent 开始凭感觉选工具，每次调用错误，都要付出一轮重试的代价，还得让人困惑地翻看执行轨迹。

工具数量不等于能力。每增加一个工具，都会给 Agent 的每次决策增加负担，因为它必须把整个工具列表放在上下文里，再从中选择。

这些失效模式是可以预见的

含糊的描述是问题恶化的第一步。“从 API 获取数据”可能对应你安装的四个工具。第二个问题是命名冲突：两个工具都叫 search，一个搜索文件，另一个搜索工单。第三个问题是职责范围不断膨胀——原本只负责一项任务的工具，后来多了三个可选参数，直到谁也说不清什么时候该调用它。

Agent 不会告诉你它在猜。它只会调用听起来最接近的那个，然后继续执行。

解决办法是做减法，而不是添加更多工具

我们把工具列表砍掉了一半。把两个搜索工具合并成一个，明确它的用途。重写每个工具的描述，说明什么时候不该使用它。一个写明“用于仓库文件，不用于工单”的工具，比一个描述更长的工具更能减少错误调用。

在 API 任务中，效果最明显：一个描述清楚、能针对在线 endpoint 执行 spec 的工具，胜过三个分散的获取和解析工具，因为 Agent 不再需要判断究竟该用哪个。最终，我们把这套流程留在本地，而没有再通过另一个 server 接入。

这周值得做一次检查

打开 Agent 的工具列表，把每条描述大声读出来。如果两个工具看起来完全可能用于同一次调用，就把它们合并。如果描述没有说明什么时候应当跳过这个工具，就重写它。你交付的配置看起来可能没那么强大，却能在第一次尝试时做对更多事情。

你的 Agent 究竟有多少个工具——其中有多少个是你在过去一周里用过的？

如果需要进一步采取行动，你可以考虑屏蔽此人和／或举报滥用行为。