别给 AI Agent 两百个工具,给它几个 capability

给 AI Agent 装一堆工具，它反而变笨了——不是模型不行，是工具的组织方式出了问题。一个叫 Caplets 的开源项目，暴露了一个被忽略的产品设计问题。

你的 AI 助手收到一个任务："帮我查一下这个 npm 包有没有已知漏洞。"

它收到指令，然后花了好一会儿——不是在想怎么查漏洞，而是在读工具使用手册。

不是因为模型不够聪明。是因为你给了它两百个工具。

每个工具的参数、schema、使用说明都塞进了上下文窗口。Agent 要先读完所有这些，才知道该用哪个。这个问题的普遍程度，远超很多人的直觉。

一个大问题：工具墙

现在主流的做法是 MCP（Model Context Protocol）。把一堆工具注册给 AI，让模型自己选。

听起来合理。实际的问题是：

MCP 把所有工具的完整 schema 一并塞进 prompt。 你的 agent 还没开始干活，上下文已经被工具描述占满了。

一个实际的数据点：GitHub 的 MCP server 光 tool definitions 就有几千行。如果你同时接了 GitHub、Sourcegraph、文件系统、数据库……那 agent 看到的第一屏，不是你的任务，是一本电话簿。

更糟的是，大 schema 里的小细节也在消耗推理预算。Agent 花 token 读一个它用不上的工具的说明，然后在真正干活的步骤上少了几百个 token。

今天 Hacker News 上有人发了一个开源项目，叫 Caplets。

它的思路很简单：不要给 agent 一面工具墙，给几个 capability 卡片。

具体做法是分两层：

第一层：agent 只看到几个命名好的 capability 入口，比如 osv、github、sourcegraph。每个入口很小，几行 text。
第二层：agent 选定一个入口后，才展开背后的 inspect、search、schema、call。这些大文件不提前塞进 prompt，只在需要时才出现。

一个典型的场景：你要查一个 npm 包的漏洞。

传统 MCP 的做法：把所有工具的描述和 schema 都扔进 prompt，让 agent 自己挑。

Caplets 的做法：agent 先看到一张卡片写着 osv。它点进去，看到 search 和 inspect 两个操作。它选了 search，传入包名，拿到结果。全程只用到了相关的两段指令，其他两百个工具的描述根本没出现。

这个设计至少做了三件聪明的事：

第一，保护上下文预算。agent 有限的 attention 留给了真正的任务，而不是工具说明书。

第二，减少推理干扰。工具多了，模型选错的概率就高。一个聚焦的入口，比一个巨大的选择菜单更可靠。

第三，可复用。一个 Caplet 可以在本地跑，也可以部署到远程服务器给团队用。配置一次，到处可用。

Caplets 触动我的不是这个项目本身，而是它暴露的一个更普遍的问题：

整个行业都在急着给 agent 造工具，但几乎没人想过工具应该怎么组织。

你会给一个新人同事扔一本五百页的操作手册然后说"你自己翻"吗？不会。你会先告诉他：你的职责就这几条，遇到问题再去翻对应的章节。

但我们对 AI agent 就是这么做的：一口气注册几十个 MCP server，每个 server 带着几十个工具定义，一股脑塞进上下文。

这不只是效率问题。这是一个产品设计问题。

当一个工具集大到 agent 需要花 30% 的推理预算来"读文档"时，这个工具集本身就是噪音。而噪音最大的伤害不是浪费 token——是让 agent 在关键任务上犯错，因为你占用了它本来可以用来思考的空间。

Caplets 不一定成为标准答案。但它指出了一个正确的方向：Agent 的工具不在于多，在于精。而"精"的第一步，是让 agent 在不看说明书的情况下就能开始干活。

这不是一个技术问题，这是一个信息架构问题。

等 agent 普及到更多人手里，这个问题会越来越明显。今天能意识到这一点的产品，会在下一轮竞争中拿到一点先手。

不是说 Caplets 这个工具本身会成为赢家。而是它的思路——给能力，不给墙壁——可能会影响接下来一批 AI 产品的设计方式。