AI Agent 工具设计:接了上百个工具,为什么反而更难干活?

TL;DR：工具多不等于更好用——决定成败的不是“接了多少”，而是“这一轮让 Agent 看见多少”。

假设你让 AI Agent 查一笔航班改签政策。它接入了上百种功能：查天气、读日历、订机票、查政策……看上去无所不能。但如果每次出发前，系统都把这上百种功能的完整说明塞给它，它反而要从一大堆相似按钮里辨认“该按哪个”。Agent 是能分步骤使用工具完成目标的 AI 助手；工具多，不等于眼前的任务更容易做好。

要解决这个问题，先分清两件事。能力形态说的是一项本领做成什么：专用功能、通用命令行，还是 Skill（写明某类任务该如何操作的说明文件）。展示策略说的是眼下让 Agent 看见多少本领：全部说明都摆出来，还是先给目录、用到时再展开。就像超市既要决定一件商品怎样包装，也要决定货架上同时展示多少件——包装与陈列有关，但不是同一个决定。

这一步为什么关键？因为工具说明会占用模型一次能处理的信息空间；这部分消耗通常以 token 计量，可以粗略理解为信息篇幅的单位。换句话说，“看多少”本身，就是一笔要权衡的开销。

MCP 解决接入，不能替你解决选择

本节要点：MCP 只负责“怎样接得上”；至于“这一轮该给 Agent 看哪些工具”，仍要由运行 Agent 的应用自己决定。

MCP 全称 Model Context Protocol，可以把它想成让不同 AI 应用连接外部服务的一套通用插座：一端是使用工具的 AI 应用，另一端是提供功能的服务。服务可提供可调用的工具，也可提供供读取的资料和可复用的提示模板。它解决的是“怎样接得上”，不是“今天该挑哪个”。Skill Hub 则更像说明书的分发商店，提供某类任务的操作指引，有些 Skill 还附带可执行脚本。两条渠道并非非此即彼；Skill 也可以通过 MCP 被发现和传递。

无论从哪里接进来，运行 Agent 的应用都得决定：这一轮先给它看多少。工具的完整 schema，可以理解为一张详细表单，写着功能、必填字段和格式。

把一百张表单一次性摊开，既占空间，也容易让相似入口混在一起。更好的办法通常是先给简短目录，选定要做的事后，再展开相应表单。

拿“帮我规划明天去机场的路”作例子：一开始只需找到查航班和地图的功能；查航班后若发现暴雨风险，再去找天气功能。

主动发现就是让 Agent 在做事途中提出“我现在需要查天气”，由系统找到相关功能并补上说明，而不是任务开始时就猜出所有可能需求。

要实现它，仍须维护可搜索的目录，并处理找错、找不到、说明动态加入所带来的成本。Skill 的“先看目录、再翻正文”也属于按需查阅，但不能保证目录一定选对。

一个值得警惕的实验差异

本节要点：方案预期“按需查找”能提高准确率，实测却未必——小样本测试里两组打平，预期与结论要分开看。

有一项实验对比了两种做法：把大量工具说明一次性交给小模型，或让它在需要时再查找。方案预期：后者能改善表现——按需查找，听起来本应更聪明。

实际对照结果却更谨慎：在其 Qwen3-4B 模型的三道任务里，两组都是 3/3 完成，准确率均为 100%。换句话说，这次小规模测试没有证明准确率提高；它报告主动发现减少了工具详细说明的暴露量和实测用时，但操作过程仍出现无关调用和过早结束。预期与实测要分开看，三道题也不足以保证所有场景都一样。

对使用者来说，接入方式并不是唯一问题：系统是不是把所有功能都摊给 Agent？找不到合适工具时，它会坦白“没找到”，还是硬选一个相似但不适用的？这两点，往往比“接了多少工具”更值得追问。

对搭建者来说，还有安全问题：第三方提供的工具说明可能夹带诱导性指令，Skill 附带的脚本也可能运行在你的电脑上。就像下载一个应用，能搜到、能安装，不等于该立即授予它通讯录和邮件权限——需要检查来源、版本，以及它实际能访问什么。

说到底，工具设计的难点从来不在“接得上”，而在“什么时候、让它看见多少”。少而准的可见范围，加上一句诚实的“没找到”，往往比一百个摊开的按钮更有用。