
如何用 Skills 减少 MCP 的 Token 浪费
MCP 工具会将大量 Token 注入上下文窗口。了解为什么将 MCP 工具转换为 Skills 可以减少高达 98% 的 Token 消耗,以及如何用 MCP2Skill 实现这一转换。
你给 AI Agent 连接的每一个 MCP 服务器,都会在 Agent 做任何事之前,把完整的工具 Schema 注入上下文窗口。连接十几个服务器,每个暴露 20 多个工具,光是工具定义就会消耗数十万 Token。Anthropic 自己的工程团队发现,在工具密集的场景下,这部分开销可以膨胀到 150,000 Token,拖慢响应速度,推高每次调用的成本。
解决办法不是减少工具,而是采用更智能的加载策略。这就是 Skills 发挥作用的地方——也是 MCP2Skill 在原始 MCP 暴露与 Token 高效的 Agent 工作流之间架起桥梁的关键。
原始 MCP 暴露的 Token 问题
当你把 AI Agent 直接连接到 MCP 服务器时,有两样东西会消耗 Token:
-
工具定义膨胀。 每个工具的名称、描述、输入 Schema 和输出 Schema 都会预先注入上下文窗口。光是一个 GitHub MCP 服务器就暴露了约 80 个工具。再加上文件系统、浏览器、数据库服务器,你的 Agent 就要背负一个在单次任务中永远用不完的庞大工具表面。
-
中间结果累积。 每次工具调用返回的结果都会留在上下文中。大文件读取、搜索结果、API 响应在多步骤工作流中不断堆积。
结果是:你的 Agent 花在 思考工具 上的 Token 比实际完成任务用的还多。延迟上升,成本攀升。在极端情况下,上下文窗口在工作完成之前就被填满了。
为什么 Skills 能解决这个问题
Skill 是位于模型和底层能力之间的打包层。它不会一次性把所有工具定义塞进上下文,而是先暴露一个 简洁的描述——一扇小门。更深层的指令、脚本和引用只有在任务真正匹配时才会加载。
实际效果对比:
| 方式 | 进入上下文的内容 | 加载时机 |
|---|---|---|
| 原始 MCP | 每个已连接服务器的完整工具 Schema | 始终加载,每次请求都带 |
| 基于 Skill | 每个 Skill 的一段简短描述 | 仅当 Agent 判断 Skill 相关时才加载 |
Anthropic 在代码执行 MCP 中演示了这一模式:让 Agent 按需发现工具,而不是预先加载所有定义,Token 使用量从 150,000 降到了 2,000——减少了 98.7%。
MCP2Skill 如何将 MCP 转换为 Skills
MCP2Skill 自动完成从原始 MCP 工具到 Token 高效 Skills 的转换。工作流分三步:
1. 定义能力边界
从服务或工作区开始。MCP2Skill 允许你在工作区级别过滤工具,这样 Skill 只打包特定工作流所需的能力——而不是源服务器的整个工具表面。
2. 生成与预览
MCP2Skill 生成 Skill 文件(SKILL.md、脚本、引用),并在写入磁盘前展示预览。你可以检查文件树、核对指令、在导出前调整边界。
3. 安装到 Agent
确认 Skill 没问题后,直接安装到目标 AI Agent 客户端。Agent 现在拥有了一个聚焦、按需加载的能力——而不是每次调用都背负的原始工具表面。

什么时候用 Skill 路径
Skills 不是 MCP 的替代品——而是补充。在以下场景使用 Skill 路径:
- 你 反复运行同一个工作流(比如"获取会议纪要并总结")。
- 能力边界 稳定——指令不会在调用之间变化。
- 你想 降低高频任务的 Token 成本。
在以下场景保留 MCP 网关路径:
- Agent 需要从外部系统获取 实时变化的数据。
- 你想要一个可供 多个客户端复用 的统一管理端点。
- 任务是探索性的,不符合可重复的模式。
总结
MCP 带来的 Token 浪费不是理论问题——它直接打击你的 API 账单和 Agent 延迟。通过将高价值的 MCP 工作流转换为 Skills,你能用更少的 Token 成本获得同样的能力。MCP2Skill 让这个转换自动化:定义边界,预览输出,安装 Skill。
从一个工作流开始。测量转换前后的 Token 使用量。然后决定下一步要转换哪些能力。
更多文章
邮件列表
加入我们的社区
订阅邮件列表,及时获取最新消息和更新


