Skills和MCP 到底什么区别

开场

最近有人问我：Skills 会不会干掉 MCP？我得反问一下 ------ 你说的干掉，是把它们放在同一层比了吗？

它俩压根不在一个层面上。拿它俩对线，等于问「HTTP 会不会取代 nginx 配置」，问题本身就问错了。这篇就把这两层拆开讲清楚：一层管「连得上」，一层管「不浪费」。

一、先看定位：不是功能差，是分发层差

喜欢 Skills 的人想的是：我写个脚本给自己 / 给团队用，把工作流编码成 AI 能懂的方式，一个 SKILL.md 文件丢进去就完事，折腾什么 MCP Server。

喜欢 MCP 的人想的是：我要做个服务给所有人用，用户输个 URL 就能用，未来甚至什么都不装，跟 AI 说一句「帮我订机票」就跑起来。

你仔细看，这两拨人要的根本不是同一个东西。差异不在功能，在分发。Skills 是给「自己人」的，MCP 是给「全世界」的。

打个比方：你开了家做服务的店。Skills 的安装说明写的是「把这本手册放到指定抽屉」，用户得有权限打开你家的抽屉；MCP 的安装说明写的是「记住这个门牌号」，谁来都能用，不用进你家。一个是内部工位，一个是临街店面。

但只看定位还不够。这俩在技术层面有本质区别，直接决定你用着爽不爽、贵不贵。

二、MCP：统一插座标准

2024 年以前的 AI 工具生态，像十年前充电线市场 ------ 苹果一根、安卓一根、笔记本又一根，出个门包里塞五六根线。

那时的 Agent 接工具也一样：要让 Agent 读 GitHub，写一套对接；要让 ChatGPT 查数据库，再写一套；要让 Cursor 发 Slack，又是一套。10 个 AI 应用接 20 个工具，理论上要 200 套定制集成，每家都在重复造轮子。

2024 年 11 月，Anthropic 开源了 MCP（Model Context Protocol，模型上下文协议）。它干的事跟统一插座标准一模一样：定一套协议，任何 AI 即插即用任何工具。从此 10 个 AI + 20 个工具 = 30 个 MCP 实现，不再是 200 套定制。数学上叫把 M×N 问题压成 M+N 问题；落到工程上，集成成本断崖式下降。

这层贡献是实打实的，没什么可黑。

三、MCP 的硬伤：上下文被工具定义吃光

但 MCP 有个绕不开的副作用：它吃你的上下文窗口。

机制是这样的：每个 MCP Server 接进 AI 时，必须把所有工具的定义（名字、描述、参数、示例）一次性塞进上下文。一个工具定义大概 500 到 800 tokens，一个 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，占窗口 33%；更狠的案例是 82,000 tokens，占 41%。

这意味着什么？你问 AI「2+2 等于几」，它答「4」只要 5 个 token，但工具定义已经躺在那儿烧了 15,000 tokens。一个最简单问题的成本被放大了三千倍。

更隐蔽的代价在准确率：上下文被工具定义挤占后，AI 选错工具、传错参数的概率显著上升。实战中，挂 2 到 3 个以上 MCP Server，工具使用准确率就开始明显往下掉。

打补丁：Tool Search

Anthropic 自己也意识到了。2025 年 1 月 Claude Code 推出 Tool Search：工具不再预加载，按需发现；工具定义超过上下文 10% 就自动启用；AI 要用某工具时先搜再加载。效果立竿见影，7.7 万 tokens 降到 8,700，少了 85%。

但这是给 MCP 打补丁，不是治本。根源在于 MCP 的设计假设是「把所有工具摆出来让 AI 挑」------ 工具少的时候这套没问题，工具一多就撑不住。而且更大的麻烦还在后面，我先卖个关子，讲完 Skills 你就懂。

四、Skills：图书馆式的渐进披露

Skills 一上手就走了相反的设计哲学：渐进式披露（Progressive Disclosure）。

这词听着唬人，道理很朴素。想象你去图书馆查资料。MCP 的做法是：把你可能用到的所有书一次性全搬到桌上，你说「我就查个电话」，它已经搬了三十本。Skills 的做法是：先给你一张索引卡，每本书只写书名和一行简介；你真要用某本了，再去架子上取；用到哪一页翻哪一页。

技术上分三层：

• 第一层 · 元数据（启动时加载）：只有名字和一句话描述，每个 Skill 约 100 tokens。装 100 个也才 10,000 tokens。
• 第二层 · 完整指令 （相关时加载）：AI 判断某个 Skill 跟当前任务相关，才读完整的 SKILL.md，建议控制在 5,000 tokens 以内。
• 第三层 · 参考资料（需要时加载）：详细 API 文档、数据字典、示例代码，用多少加载多少，理论上容量无限。

换算一下：一个 Skill 可以打包整套 API 文档、几百页参考手册，只要任务用不到，这些内容就永远不占上下文。这是 MCP 那套「一股脑全摊」做不到的。

五、Skills 的杀手锏：脚本不进上下文

很多人只盯着渐进式披露，忽略了 Skills 另一个更狠的能力：自带可执行脚本。

一个 Skill 文件夹通常长这样：

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

关键点来了：AI 跑 scripts/validate.py 时，脚本代码本身不进上下文，只有执行结果返回。

这是什么概念？你有个 500 行的 PDF 处理脚本。传统做法里，AI 要么自己写（烧一大堆生成 token），要么把你的脚本读进来再跑（脚本全文占上下文）。用 Skills，AI 直接跑预写好的脚本，整个过程可能只往上下文里吐 50 tokens 的结果。

脚本走的是 Agent 内置的 bash 工具，不需要 MCP。Python、Bash、JavaScript 都行，你系统跑得动的都能用。于是文件读写、数据处理、格式转换、本地 API 调用这些活，Skill 脚本全包了。

一句话：脚本执行 = 零上下文成本 + 确定性结果。

一个更小的例子，自己写的

任务：把 docs/ 下 30 篇 Markdown 合成一份带目录的 PDF。

MCP 路子（多轮工具调用，中间结果全部回灌上下文）：

[User]  把 docs/ 合成一份带目录的 PDF
[AI]    list_files("docs/")        → 30 个文件名
[AI]    read_file("docs/01.md")    → 全文
[AI]    read_file("docs/02.md")    → 全文
        ... 重复 30 次 ...
[AI]    build_toc(...)             → 目录 JSON
[AI]    render_pdf(...)            → "out.pdf"

上下文里塞满了 30 篇全文 + JSON + 路径，token 爆表。

Skills 路子（一次脚本调用）：

[User]  把 docs/ 合成一份带目录的 PDF
[AI]    (匹配到 Skill) → bash scripts/build_pdf_bundle.sh docs/ out.pdf
[Script] "✅ 已生成 out.pdf：30 篇，目录 12 节"
[AI]    报告已生成，文件 out.pdf

上下文只多了一行输出，约 20 token。差别本质在哪？中间过程不进入上下文，只有结果进入。

六、那 MCP 还有存在意义吗？

有，而且很硬核。但场景会收窄。

需要 MCP 的，都是「Agent 自己够不着」的活：

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

不需要 MCP 的，都是「本地就能闭环」的活：

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

为什么本地任务不需要 MCP？因为 Agent 这个「操作系统」本身就自带 bash、read、write 这些基础工具，大量本地任务 Skills + 内置工具就闭环了，多挂一个 MCP Server 反而白烧上下文。

七、回到那个被遗漏的根子问题

现在可以揭前面卖的关子了。

MCP 的 Tool Search 缓解了「工具定义占上下文」的问题，但没解决根本 。因为工具定义只是一部分，真正的大头是交互过程中产生的中间结果 ------ read_pdf 返回的 50KB 文本、extract 出来的 JSON、generate 出来的段落，每一轮都回灌进上下文累积。

Skills 的脚本执行天然绕开这个坑：脚本代码不进上下文，中间过程不进上下文，只有最终结果进上下文。

这也是为什么我说它俩不在同一层：MCP 解决的是「怎么把世界接进来」(连得上)，Skills 解决的是「怎么把流程封装得不浪费」(省上下文)。一个是协议层，一个是应用层。

八、一条值得辨析的质疑

「如果分析是纯代码完成的，MCP 也能把流程封装成 pdf→doc 一个黑盒；如果分析需要 LLM 介入，那 Skills 实际上也要多轮：解析 PDF → LLM 提取总结 → 生成 doc。」

MCP 能把工具包装成黑盒 ------ 但封装能力不是 Skills 的优势所在，Skills 的优势在上下文策略：

1. MCP 的黑盒仍是「工具」，工具定义照样得进上下文（哪怕按需加载，加载的那次还是要占）；
2. Skills 的脚本跑在 Agent 内置 bash 里，不走工具注册那套，工具定义那笔开销从根上就不存在；
3. 更关键的是，需要 LLM 介入的多步任务里，Skills 仍然可以让 LLM 主导编排，但每一步走脚本封装的确定性操作不回灌上下文，只在关键节点把摘要结果喂回 LLM。编排是 LLM 的，脏活是脚本的，这两者分工后中间结果不必全进上下文。

所以结论不是「Skills 能封装而 MCP 不能」，而是「Skills 从设计上就把上下文当稀缺资源来守，MCP 没这个约束意识」。本质差异在上下文经济学，不在能不能封装。

九、到底怎么选

三个问题问自己：

• 谁来用？ 只有自己 / 团队内部 → Skills 够了。要给外部用户或客户用 → MCP 必选。
• 怎么分发？ 能接受「把文件放到某个目录」→ Skills。希望用户输个 URL 就能用 → MCP。
• 解决什么？ 编码领域知识、定义工作流 → Skills 友好。连外部服务、对外暴露 API → MCP。

最佳实践是配合，不是二选一：Skills 编码你的领域知识，MCP 连接外部服务。比如公司有套特定流程，先查 A 系统再查 B 系统按某顺序处理 ------ 这套「先干什么后干什么」的领域知识用 Skills 写成 AI 能懂的手册；而真正去连 A、B 系统的能力，由 MCP 提供。两层各司其职。

往后看，格局大概率是这样：少数通用 MCP Server 守「远程连接」核心场景（实时外部 API、认证型 SaaS、跨网数据库），本地文件、浏览器自动化、数据处理这些活儿 Skills + 内置工具就接了，而且效率更高。

一句话：优先用 Skills 封装工作流，复杂逻辑用脚本而不是让 AI 一步步操作，只在必须连远程系统时才上 MCP。

金句收口：上下文是 Agent 最贵的资产。MCP 大方地花，Skills 吝啬地省 ------ 谁该用在哪，就看这一层。

---