转载：MCP 和 Skills 到底什么区别？

MCP 和 Skills 到底什么区别？一篇文章说清楚

转载声明：本文转载自 宝玉 @dotey 的 X Article，原文链接：https://x.com/dotey/status/2014025984895258934

作者：宝玉 (@dotey)
日期：2025年1月22日

一句话解释 MCP 和 Skills 的区别：如果 AI Agent 是操作系统，MCP 就是 USB 协议，Skills 就是应用程序。

一位开发者的困惑

有位网友私信问我：“MCP 是不是已经过时了？现在应该全用 Skills？”

这个问题可能很多人都好奇。我理解这种焦虑。AI Agent 工具圈每隔两周就会冒出新东西，每次新东西出来，就有人喊旧的"已死"。

对于喜欢 Skills 的人可能会想：我写个脚本自己用，干嘛搞那么复杂？我就是要编码一下我的工作流程，让 AI 能理解我们团队的做事方式，Skills 写起来简单，放个文件就行，何必折腾 MCP Server？

喜欢 MCP 的人则会认为：我要做一个服务，让所有人都能用，不只是我自己，不只是我团队。我要让用户输入一个 URL 就能用，甚至未来什么都不用装，直接问 AI"帮我订机票"就行。

仔细看其实这两拨人的需求完全不一样。

不是功能差异，是分发方式的差异。Skills 是给自己人用的，MCP 是给全世界用的。

想象你是一家卖服务的公司。你服务的安装说明怎么写？如果你是以 Skills 的方式发布，说明就要说清楚"把 SKILL.md 文件复制到特定目录"，可能还需要特定脚本的运行权限，用户都不一定敢安装。但如果是"输入这个 URL"或者"直接跟 AI 说帮我用这个服务"，也不需要你在本机安装个 nodejs/python，那就好多了。

但光理解定位还不够。这两个东西在技术层面有本质区别，直接影响你的使用体验和成本。

MCP：AI 世界的 USB 协议

还记得十年前的充电线吗？苹果用 Lightning，安卓用 Micro USB，笔记本用各种奇形怪状的电源头。出门一趟，包里塞满五六根线。

AI 行业在 2024 年之前也是这样。

你想让 Agent 读取 GitHub 仓库？写一套对接代码。想让 ChatGPT 查数据库？再写一套。想让 Cursor 发 Slack 消息？又是一套。10 个 AI 应用要连 20 个工具，理论上需要 200 个定制集成。每家都在重复造轮子，开发者苦不堪言。

2024 年 11 月，Anthropic 开源了 MCP（Model Context Protocol，模型上下文协议）。它做的事情，和 USB-C 统一充电接口一模一样：

定义一套标准协议，让任何 AI 都能即插即用地连接任何工具。

有了 MCP，10 个 AI 应用 + 20 个工具 = 30 个 MCP 实现，而不是 200 个定制集成。数学上叫把 M×N 问题变成了 M+N 问题，实践中意味着开发成本断崖式下降。

MCP 的致命问题：上下文爆炸

但 MCP 有一个严重的副作用：吃掉你的上下文窗口。

每个 MCP Server 连接到 AI 时，必须把所有工具的定义（名称、描述、参数、示例）一次性塞进上下文。一个工具的定义大概 500-800 tokens，一个 MCP Server 通常有 10-20 个工具。

来看几个真实数据：

• GitHub MCP Server：27 个工具，消耗约 18,000 tokens
• Playwright MCP Server：21 个工具，消耗约 13,600 tokens
• mcp-omnisearch：20 个工具，消耗约 14,200 tokens

有开发者配了 7 个 MCP Server，还没开始对话，上下文就被吃掉了 67,000 tokens —— 占 AI 上下文窗口的 33%。更夸张的案例是 82,000 tokens，占 41%。

这意味着什么？你问 AI “2+2 等于几”，它回答 “4” 只需要 5 个 token，但工具定义已经消耗了 15,000 tokens。简单问题的成本被放大了 3000 倍。

更糟糕的是，当上下文被工具定义挤占后，AI 选错工具、传错参数的概率会显著上升。实践中，连接 2-3 个以上的 MCP Server，工具使用准确性就会明显下降。

Claude Code 的解法：Tool Search

Anthropic 意识到了这个问题。2025 年 1 月，Claude Code 推出了 Tool Search 功能：

• MCP 工具不再预加载，而是按需发现
• 当工具定义超过上下文的 10% 时自动启用
• AI 需要用某个工具时，先搜索再加载

效果立竿见影：从 77,000 tokens 降到 8,700 tokens，减少 85%。

但这只是在给 MCP 打补丁。问题的根源在于：MCP 的设计假设是"把所有工具摆出来让 AI 挑"，这在工具数量少的时候没问题，工具多了就撑不住。

Skills：渐进式披露的操作手册

Skills 从一开始就采用了不同的设计哲学：渐进式披露（Progressive Disclosure）。

怎么理解呢？

想象你招了个新员工。传统做法是入职第一天把公司所有流程文档、规章制度、操作手册全部打印出来堆在他桌上，这就是 MCP 的做法。而 Skills 的做法是：先给一份简短的岗位说明，等他遇到具体问题时，再告诉他去翻哪本手册的哪一页。

技术上，Skills 是这样实现的：

1. 第一层：元数据（启动时加载）

   • 只有名称和简短描述
   • 每个 Skill 约 100 tokens
   • 装 100 个 Skill 也只占 10,000 tokens

2. 第二层：完整指令（相关时加载）

   • 当 AI 判断某个 Skill 与任务相关时，才读取完整的 SKILL.md
   • 建议控制在 5,000 tokens 以内

3. 第三层：参考资料（需要时加载）

   • 详细的技术文档、API 说明、示例代码
   • 按需读取，用多少加载多少
   • 理论上可以包含无限内容

这意味着：一个 Skill 可以打包整套 API 文档、完整的数据字典、几百页的参考手册，但只要任务不需要，这些内容就永远不会占用上下文。

Skills 的杀手锏：自带脚本

Skills 还有一个很多人忽略的能力：它可以自带可执行脚本。

一个典型的 Skill 文件夹结构是这样的：

1
2
3
4
5
6
7
8

my-skill/
├── SKILL.md          # 核心指令
├── scripts/          # 可执行脚本
│   ├── validate.py
│   ├── generate.sh
│   └── process.js
├── references/       # 参考文档
└── assets/           # 模板、配置文件

关键来了：当 AI 运行 scripts/validate.py 时，脚本代码本身不会加载到上下文，只有执行结果会返回。

这是什么概念？

假设你有一个 500 行的 Python 脚本，用来处理 PDF 表单。用传统方式，AI 要么自己写代码（消耗大量 tokens 生成），要么读取你的脚本再执行（脚本内容占用上下文）。而用 Skills，AI 直接运行预写好的脚本，整个过程可能只消耗 50 tokens 的输出结果。

脚本执行 = 零上下文成本 + 确定性结果

更重要的是：这些脚本通过 Agent 内置的 bash 工具执行，不需要 MCP。

Skills 支持的脚本语言包括 Python、Bash、JavaScript 等，基本上你系统能跑的都能用。这意味着：

• 文件读写？Skill 脚本搞定
• 数据处理？Skill 脚本搞定
• 格式转换？Skill 脚本搞定
• 本地 API 调用？Skill 脚本搞定

MCP vs Skills：什么时候需要什么？

现在我们可以重新审视这两个概念的定位了。

有一句话说得很精辟：Skills 描述工作流程，MCP 提供执行引擎。但很多时候，操作系统自带的引擎就够用了。

这就像 GitHub Actions：工作流文件（相当于 Skills）定义了构建、测试、部署的步骤，但实际执行的还是 bash 命令。YAML 就像菜谱，写清楚先放油、再下葱、最后翻炒，但菜谱本身不会做菜，真正掌勺的是厨师。

问题是：Agent 这个"操作系统"本身就自带了 bash、read、write 等基础工具。对于大量本地任务，Skills + 内置工具就能完成，根本不需要额外的 MCP Server。

还有个类比我觉得很贴切：Skills 像 Slack 里的斜杠指令（slash commands）。你公司 Slack 里可能有几十个 slash commands，大部分你从来没用过，但对特定的人特定的场景很有用。这就是 Skills 的定位：内部工具，按需使用。

但你不可能把 slash commands 卖给外部用户。要对外，得用 MCP。

随着 Skills 普及，MCP 的需求会大幅减少

这是一个正在发生的趋势。

想想看，什么时候你真正需要 MCP？

需要 MCP 的场景：

• 连接远程 CRM 系统获取客户数据
• 调用第三方 SaaS API（Slack、Notion、Jira）
• 查询云端数据库
• 访问需要认证的外部服务
• 做一个服务让外部用户都能用

不需要 MCP 的场景：

• 读写本地文件 → bash + Skill 脚本
• 处理 PDF/Word/Excel → Skill 脚本
• 运行代码分析 → Skill 脚本
• 执行 Git 操作 → Skill 脚本
• 生成图表和可视化 → Skill 脚本
• 优化自己或团队的工作流

事实上，Anthropic 的工程博客提到：他们用"代码执行 + MCP"的方法，把一个 150,000 token 的工作流压缩到了 2,000 tokens —— 核心思路就是让 AI 写代码调用工具，而不是预加载所有工具定义。

这正是 Skills 的 design 方向：用脚本封装能力，用渐进式披露管理知识，最大限度减少上下文消耗。

未来的格局可能是这样的：

1. 少数通用 MCP Server：处理远程连接（数据库、云 API、SaaS 集成）
2. 大量 Skills：编码专业知识和本地工作流

两者在必要时协作，但 Skills 会承担绝大部分"教 AI 怎么做事"的工作。

一个真实案例：自动发布 X Article

这是一个真实发生的演进过程，完美展示了从 MCP 到 Skills 的转变。

需求： 把 Markdown 文章自动发布到 X（Twitter）的长文功能 X Article。

方案一：Playwright MCP

王树义老师（@wshuyi）开发了 x-article-publisher-skill，流程是：

Markdown 文件 -> Python 脚本解析 -> Playwright MCP 操作浏览器 -> X Articles 编辑器 -> 保存草稿

提示词很简洁，功能也很强大。但问题来了：上下文消耗得飞快。

Playwright MCP 有 22 个工具，光工具定义就占用约 8,000-10,000 tokens。更要命的是，每次浏览器交互，MCP 都要返回页面的 accessibility tree（无障碍树）快照。发布一篇文章，每一步都是一次 MCP 交互，结果一篇文章发完，上下文可能已经用掉 50,000+ tokens。

方案二：Skills + CDP 脚本（我的改进版本）

我把 Playwright MCP 部分完全改成了脚本，做成了 baoyu-post-to-x。

核心变化：

• 脚本直接调用 Chrome CDP（Chrome DevTools Protocol），绕过 MCP
• 脚本自己完成所有浏览器操作：打开页面、填充内容、上传图片、保存草稿
• 只返回最终结果给 Agent：“发布成功，草稿链接：xxx”

整个过程，AI 只需要做一件事：调用脚本。上下文消耗可能只有几百 tokens。

为什么差距这么大？

关键洞察：MCP 的设计是让 AI 一步步操作，每一步都要理解及执行；而脚本的设计是把整个流程封装，AI 只需要说"开始"和"结束"。

详细分析

写在最后：回到那个私信

所以我给那位读者的回复是：

MCP 没死。Skills 也很有用。它们解决的是不同问题。

MCP 是 USB 协议，定义了连接标准；Skills 是应用程序，把专业知识打包成操作手册。

Skills 的两大杀手锏 —— 渐进式披露和脚本执行 —— 让它能独立完成大量任务，不依赖 MCP。

到底怎么选？问自己三个问题：

1. 谁来用？ 团队内部用选 Skills，给外部用户用选 MCP。
2. 怎么分发？ 接受复制文件选 Skills，希望输入 URL 选 MCP。
3. 解决什么问题？ 编码领域知识选 Skills，连接外部服务选 MCP。

最佳实践是两者配合：用 Skills 编码你的领域知识，用 MCP 连接外部服务。

对于开发者：优先用 Skills 封装工作流，逻辑用脚本，只在必须连远程系统时用 MCP。如果你只能选一个先学，选 Skills。它更轻量、高效，能解决日常大部分问题。

💡 个人思考：这篇文章很好地解释了 MCP 和 Skills 的定位差异。作为 AI 开发者，理解这两者的适用场景，能帮助我们在构建 AI Agent 时做出更明智的技术选择。