用Skills降低MCP协议的Token消耗

MCP 工具会将大量消耗 token 的定义灌入你的上下文窗口。了解为什么应该把 MCP 工具转换成 Skills，并附实战演示。

你的 AI Agent 连接到的每一个 MCP 工具，都会把完整的 schema 发送进上下文窗口——而这发生在 Agent 真正做任何事之前。只要连接十几个服务器，每个服务器暴露 20 多个工具，光是定义部分就在燃烧数十万个 token。Anthropic 自己的工程团队发现，在工具密集型的配置中，这种开销可以膨胀到 150,000 token，每一次调用的响应时间都会变慢，成本也会增加。

解决方案不是减少工具数量，而是更聪明的加载策略。这就是 Skills 的用武之地——也是 MCP2Skill 弥合的地方：它架起从原始 MCP 暴露到 token 高效 Agent 工作流之间的桥梁。

当你把 AI Agent 直接连接到 MCP 服务器时，有两件事在消耗 token：

工具定义膨胀。每个工具的名称、描述、输入 schema 和输出 schema 都会预先注入到上下文窗口。仅 GitHub MCP 服务器就暴露了约 80 个工具。再加上文件系统、浏览器和数据库服务器，你的 Agent 就在背负一个巨大的工具表面——而它在单个任务中永远不可能全部用到。

中间结果积累。每次工具调用都会返回结果，这些结果留存在上下文中。大文件读取、搜索结果和 API 响应会在多步骤工作流中堆积。

结果就是：你的 Agent 花了更多 token 去思考工具，而不是真正完成任务。延迟上升，成本攀升。在极端情况下，上下文窗口在工作完成之前就填满了。

Skill 是一个包装层，位于模型和底层能力之间。它不是一次性把所有工具定义都塞进上下文，而是暴露一个简洁的描述——一扇小小的前门。只有当任务真正匹配时，更深的指令、脚本和引用才会加载进来。

实际对比如下：

Anthropic 用他们的代码执行 MCP 演示了这个模式：通过让 Agent 按需发现工具，而不是预先加载所有定义，他们把 token 使用量从 150,000 减少到 2,000——减少了 98.7%。

MCP2Skill 将这个转换过程自动化，把原始 MCP 工具变成 token 高效的 Skills。工作流分三步：

1. 定义能力边界

从一个服务或工作区出发。MCP2Skill 允许你在工作区级别过滤工具，这样 Skill 只打包对特定工作流重要的能力——而不是源服务器的全部工具表面。

2. 生成并预览

MCP2Skill 生成 Skill 文件（SKILL.md、脚本、引用），在任何内容写入磁盘之前向你展示预览。你可以检查文件树、查看指令，并在导出前调整边界。

3. 安装到 Agent

一旦 Skill 看起来合适，直接安装到目标 AI Agent 客户端。Agent 现在拥有了一个专注的、按需加载的能力——只在相关时才加载——而不是在每次调用时都背负原始工具表面。

Skills 不是 MCP 的替代品——而是补充。在以下情况使用 Skill 路径：

• 你反复运行相同的工作流（例如"获取会议记录并总结"）。
• 能力边界是稳定的——指令在多次调用之间不会变化。
• 你想降低高频任务的 token 成本。

在以下情况保留 MCP 网关路径：

• Agent 需要来自外部系统的实时、变化的数据。
• 你想要一个可复用的托管端点，供多个客户端使用。
• 任务是探索性的，不适合可重复的模式。

MCP 的 token 浪费不是理论问题——它直接冲击你的 API 账单和 Agent 延迟。通过把高价值的 MCP 工作流转换成 Skills，你可以用很小一部分的 token 成本获得相同的能力。MCP2Skill 使这个转换自动化：定义边界、预览输出、安装 Skill。

从一个工作流开始。测量转换前后的 token 使用量。然后再决定下一步要把哪些能力转换过来。