30秒快速回答

MCP Skills 是一种按需加载的包装层——它不让 AI Agent 一次性加载所有 MCP 工具定义，而是只暴露一个精简入口，深层指令在任务真正需要时才拉进来。Anthropic 实测：工具定义令牌从 15万 降至 2000，降幅 98.7%，响应速度和成本双双断崖式下跌。

核心价值：你不需要减少工具数量，只需要换一种加载方式。

一、问题在哪：MCP 工具定义的隐性成本

当 AI Agent 接入 MCP 服务器时，一个容易被忽略的开销正在静悄悄地膨胀。

1.1 工具定义到底吃了多少令牌？

每增加一个 MCP 工具，服务器就把该工具的全量定义——名称、描述、输入 schema、输出 schema——一股脑塞进上下文窗口。以下是一个真实场景的估算：

MCP 服务器 工具数量 单工具定义令牌（估） 总计令牌消耗
GitHub MCP ~80 ~800 ~64,000
文件系统 MCP ~30 ~600 ~18,000
PostgreSQL MCP ~40 ~700 ~28,000
Slack MCP ~25 ~650 ~16,250
浏览器 MCP ~20 ~750 ~15,000
合计 ~195 — ~141,250

Anthropic 工程师团队在实际场景中测得，工具密集场景下这类元数据开销会膨胀到 15万令牌。这还只是工具定义本身——每次工具调用的返回结果还会持续累积，进一步挤压留给任务的思考空间。

1.2 后果是什么？

  • 成本失控：15万令牌的元数据，每次调用都要付费。以 Claude Opus 5 的定价估算，单次请求的工具定义开销可达数美元
  • 响应变慢：模型需要”阅读”并”理解”近200个工具才能开始真正工作
  • 推理质量下降：上下文窗口被元数据占据，留给实际任务的”思考空间”被压缩
  • Prompt Cache 失效：工具数量或顺序变化时，缓存的提示处理结果全部作废

打个比方：你每次出门都扛着全套工具箱，但今天只需要拧一颗螺丝。

二、Skills 是什么？按需加载的包装层

2.1 架构对比

Skills 位于模型和底层 MCP 能力之间，不替代 MCP，而是给 MCP 加了一层智能包装。

传统模式（全量加载）：
┌─────────┐    一次性暴露所有工具定义     ┌──────────────┐
│ AI Agent │ ◄────────────────────────── │ MCP Servers  │
└─────────┘    195个工具 × 完整schema     └──────────────┘

Skills 模式（按需加载）：
┌─────────┐  只暴露精简描述（~200 tokens）  ┌──────────┐  按需拉取  ┌──────────────┐
│ AI Agent │ ◄─────────────────────────── │  Skills   │ ────────► │ MCP Servers  │
└─────────┘                               └──────────┘  深层指令  └──────────────┘

2.2 关键机制

特性 原生 MCP 模式 Skills 模式
工具定义加载 启动时全量加载 运行时按需发现
令牌消耗 15万+ 2000（入口描述）
上下文占用 随工具数线性增长 恒定，不受工具总数影响
缓存友好度 工具列表变化即失效 入口稳定，缓存命中率高
适用场景 动态工具组合、跨服务器编排 聚焦任务、重复性工作流

2.3 一个直观的例子

假设你要让 Agent 操作 GitHub：创建 Issue、查看 PR、管理分支。

原生 MCP 模式：Agent 先读完 GitHub MCP 的 80 个工具定义（包括它根本用不到的 Wiki 管理、Gist 操作、Actions 配置等），再从中挑选合适的工具执行。

Skills 模式：Agent 看到一个名为 github-issue-management 的 Skill，描述为”创建和管理 GitHub Issue 的完整工作流”。它选择这个 Skill，此时系统才加载相关的 5-6 个工具定义和操作脚本。其他 70+ 个工具根本不存在于上下文窗口中。

三、怎么创建 Skill？MCP2Skill 三步流程

Anthropic 开源了 MCP2Skill 工具，能将现有 MCP 服务器自动转换为按需加载的 Skill 包。流程如下：

Step 1：确定工作区边界

根据具体工作流裁剪工具集，确保 Skill 只包含相关能力：

# 从 GitHub MCP 服务器中筛选与 Issue 管理相关的工具
mcp2skill scan \
  --server github-mcp \
  --workspace "issue-management" \
  --tools "create_issue,list_issues,update_issue,close_issue,add_labels"

Step 2：生成 Skill 文件并预览

工具自动生成 Skill 描述、操作脚本和参考材料：

mcp2skill generate \
  --workspace "issue-management" \
  --output ./skills/github-issue-management/

生成的文件结构：

skills/github-issue-management/
├── skill.yaml          # Skill 入口描述（~200 tokens）
├── instructions.md     # 详细操作指令（按需加载）
├── scripts/
│   ├── create_issue.py
│   └── manage_labels.py
└── references/
    └── github_api_docs.md

skill.yaml 示例（这是唯一暴露给模型的精简入口）：

name: github-issue-management
description: |
  创建和管理 GitHub Issue 的完整工作流。
  支持创建 Issue、添加标签、分配负责人、关闭 Issue。
tools:
  - create_issue
  - list_issues
  - update_issue
  - close_issue
  - add_labels
# 注意：深层指令在 instructions.md 中，不在此处暴露

Step 3：安装到 AI 客户端

mcp2skill install \
  --skill ./skills/github-issue-management/ \
  --client claude-code

此后，Agent 获得的不是 80 个工具的全量定义，而是一个按需加载的精准能力包。

四、Skills 和 MCP 不是替代，是互补

这个选择取决于你的使用场景：

场景 推荐方案 原因
高度聚焦的重复任务 Skills 令牌效率最高，缓存友好
探索性、动态工具组合 原生 MCP 需要完整的工具发现能力
混合工作流 Skills + MCP 共存 高频任务走 Skill，低频能力保留 MCP 网关
多 Agent 协作 Skills 各 Agent 只加载自己需要的，避免上下文膨胀

最佳实践：

  • 将 80% 的高频操作封装为 Skills，覆盖日常 90% 的调用
  • 保留原生 MCP 网关处理低频、探索性需求
  • 定期审查令牌日志，识别仍然消耗过高的工具定义并继续优化

五、总结

MCP Skills 解决了一个被长期忽视的根本问题：工具定义不是免费的。每加载一个 MCP 工具，你都在为元数据支付令牌账单。Skills 用”按需加载”替代”全量预装”，将令牌消耗从 15 万降至 2000，降幅 98.7%。

三个要点：

  1. 问题在元数据，不在工具数量：不必减少工具，只需改变加载方式
  2. Skills 是包装层，不是替代品：它不取代 MCP，而是让 MCP 更高效
  3. 高频封装、低频保留：用 Skills 覆盖高频任务，用原生 MCP 保持灵活性

延伸阅读：