别再混淆 MCP 与 Skill：一个负责系统对接，一个确保任务稳定执行
团队讨论 agent 落地时，十有八九会引出两个关键词：MCP，Skill。
问题恰恰就在这里——这两个概念经常被混用。有人说“先搭 MCP”，聊着聊着却变成了代码规范。有人觉得“做个 Skill 就行”，最后却在纠结如何对接 Figma、GitHub、Notion。
讨论到最后，大家以为在同步方案，其实连问题都没对齐。
先给出一个核心判断：
MCP 解决的是连接问题，Skill 解决的是复用问题。
说得再直白些：
MCP更像是接口层，负责将 agent 连接到外部世界Skill更像是能力层，负责将一套执行方法封装起来
两者并非同一回事，但在实际项目中经常绑定在一起使用。
先厘清语境
有一句话必须说清楚，否则后续容易越聊越偏。
MCP 这个词相对稳定。无论看 Anthropic 还是 OpenAI，它基本都指向同一类事物：让 AI 应用接入外部工具、数据和工作流的协议层。
但 Skill 这个词就没那么统一了。
不同产品中，Skill 的实现方式和边界并不完全相同。本文所说的 Skill，主要指 agent 产品中的“技能包”能力——也就是把指令、参考资料、脚本、资源文件和工作步骤打包在一起，让 agent 在特定场景里稳定完成任务。
因此，这篇文章并非在对比两个标准协议，而是想拆解 AI 工具链里两个经常被混淆的层次。
MCP 到底解决什么问题
先说 MCP。
MCP 并非用来“增强智能”。它做的是更基础的工作：将模型连接到外部系统。
你可以把它当作 AI 世界里的统一接口。
如果你的 agent 需要：
- 读取 GitHub issue
- 查询 Notion 文档
- 连接数据库
- 调用内部 API
- 访问设计稿、日志系统、监控平台
那么你首先要解决的问题一定是：如何接入，如何将这些能力以统一方式提供给模型。
这正是 MCP 的职责。
从官方定义看，MCP server 向外暴露的通常是 tools、resources、prompts 这几类能力。换句话说，MCP 更关注的是：
- 外部系统提供了哪些可用能力
- 这些能力如何被标准化描述
- agent 怎样发现并调用它们
所以，MCP 更像是协议层和连接器。
它不定义你的团队如何做代码评审，也不定义文章怎么排版，更不会告诉 agent“遇到这种问题先查哪个文档，再跑哪个脚本，再用什么格式输出”。
它只负责一件事：
把外部世界安全、稳定、标准化地接入进来。
Skill 到底解决什么问题
再说 Skill。
Skill 的重点不在于“接入”，而在于“沉淀”。
当某类任务反复出现，而你每次都要重新讲一遍步骤，这时你缺的往往不是新工具，而是一套能复用的方法。
比如这些场景：
- 每次做代码审查都要重复解释团队规范
- 每次将设计稿转为前端代码都要重复说明目录结构、组件约束、验收标准
- 每次写技术文章都要重复强调目标读者、语言风格、结构模板
- 每次排查线上问题都要重复提醒先看日志、再看监控、最后写复盘
这些问题有个共同点：
agent 并非做不到，而是每次做法都不一致。
这时候你真正需要的，就是 Skill。
Skill 本质上是在封装一套稳定的工作流。里面可以包含：
- 任务说明
- 执行步骤
- 参考资料
- 脚本
- 模板
- 输出格式
如果说 MCP 给了 agent 一双手，那么 Skill 更像是在教它“这双手平时该怎么干活”。
所以 Skill 更偏能力编排，而非工具接入。
它解决的是：
- 同样的任务，如何每次都做得差不多
- 团队经验，如何沉淀成 agent 能反复调用的能力
- 复杂任务，如何从“临场发挥”变成“流程复用”
为什么很多人会把它们混在一起
因为在真实场景中，它们本来就经常一起出现。
举个很典型的例子。
比如你要做一个“从设计稿生成前端页面”的 agent 流程。
这个流程里可能会有几步：
- 读取 Figma 设计稿
- 提取颜色、间距、组件信息
- 按团队规范生成 React 代码
- 运行截图或测试
- 输出交付说明
这里面：
- “读取 Figma 设计稿”更像 MCP 的事，因为它涉及外部系统接入
- “按团队规范生成 React 代码并完成自检”更像 Skill 的事，因为它是流程和规范的复用
所以很多团队会自然地把两者揉到一起。
其实不然。
更准确的理解应该是：
MCP 负责把能力接进来，Skill 负责把能力组织起来。
一个偏“连”，一个偏“用”。
拿一个真实场景拆开看：Figma 到前端代码
光讲概念还是有些抽象。
直接拿一个许多团队都想尝试的场景来拆——设计师在 Figma 里出稿，agent 自动生成一个可继续开发的前端页面。
第一次做这件事的人，很容易把所有内容都塞进一个“大 Prompt”。第一版也许能跑，第二版开始不稳定，第三版基本就没人敢碰了。
更稳妥的做法，还是先按层拆分。
第 1 层：MCP 负责把 Figma 能力接进来
这一层不关心“页面怎么写”，只关心“agent 到底能拿到什么”。
比如一个 Figma 相关的 MCP server，可以给 agent 暴露这些能力：
- 根据文件或节点 ID 读取设计稿信息
- 获取节点树、文本内容、颜色、尺寸、间距
- 导出图片素材或图标
- 读取组件、变体、样式 token
这一层解决的全是接入问题：
- 能不能连接到 Figma
- 能连到什么粒度
- 返回的数据长什么样
- 权限和调用方式怎么控制
这些都很关键，但还不是“前端页面生成流程”本身。
所以 MCP 做完以后，agent 最多只是获得了：
“我现在能看懂这份设计稿了。”
它还没有获得：
“我该按你们团队的方式把它写成代码。”
第 2 层：Skill 负责把“设计转代码”的方法固化下来
到了这一层，问题就从“怎么连”变成了“怎么干”。
比如你可以把下面这套流程沉淀成一个 Skill：
- 先读取 Figma 节点树，确认页面结构
- 提取设计 token，映射到团队已有的颜色和间距变量
- 优先复用现有组件库，不要直接生成一堆散装 div
- 页面结构按项目目录规范落盘
- 运行 lint、测试或截图检查
- 输出“哪些地方是 1:1 还原，哪些地方做了工程化调整”
这时 Skill 封装的就不是“Figma API”，而是团队自己的做法。
比如它可以额外规定：
- 组件优先使用
Button、Card、Modal这些现有组件 - 样式优先走 design tokens，不直接写魔法数字
- 复杂布局先拆 section，再拆 block
- 图片资源要落到哪个目录
- 最终输出必须带一个自检清单
这些东西才真正决定结果是否稳定。
如果只做 MCP，会发生什么
很多团队就是卡在这里。
他们把 Figma 接进来了，agent 也确实能读取节点信息，但生成代码还是一会儿一个样。
第一次可能是原生 CSS，第二次改成 Tailwind，第三次又开始手搓一套不符合项目规范的组件。
这不是 MCP 失效，而是你只解决了“看得到设计稿”，没解决“怎么稳定产出项目代码”。
如果只做 Skill，会发生什么
反过来也一样。
如果你只写了一套“设计转代码流程”，但 agent 根本拿不到 Figma 的结构化信息，那它只能靠截图猜测。
截图猜布局，做 demo 没问题，真要用于生产流程就很悬。
因为它很容易：
- 看不出精确间距
- 识别错组件层级
- 漏掉交互态和变体
- 把可复用组件识别成静态块
所以只做 Skill，也不够。
更合理的落地方式：MCP 提供观察能力，Skill 提供生产规则
这个场景最顺手的拆法，其实就一句话：
MCP 让 agent 能“读懂设计稿”，Skill 让 agent 能“按团队要求写代码”。
把它看成一条流水线就行：
Figma 设计稿
↓
MCP：读取节点、样式、素材、组件信息
↓
Skill：套团队规则，决定如何映射到组件库和目录结构
↓
生成前端代码
↓
Skill：自检、截图、补充交付说明
一个更接近实战的拆分方式
如果真要在团队里落地，不妨这样拆：
MCP 层负责：
- 读取 Figma 文件和节点
- 导出图标或图片素材
- 提供设计 token 和组件元数据
Skill 层负责：
- 决定是生成 React、Vue 还是原生页面
- 决定优先复用哪些业务组件
- 决定目录结构、命名规则、样式方案
- 决定生成后怎么验证和怎么汇报结果
这样拆有个直接好处：Figma 接入能力可以复用到很多任务里。
今天你拿它做“设计转代码”，明天也可以拿它做“设计走查”，后天还可以拿它做“设计稿和线上页面差异检查”。
而 Skill 则可以按团队习惯继续细分。
比如：
- 一个 Skill 专门做营销页生成
- 一个 Skill 专门做后台表单页生成
- 一个 Skill 专门做移动端页面还原
这种扩展方式会更健康。
MCP 负责共享底层接入，Skill 负责沉淀上层流程。
再看一眼工程里长什么样
如果把这个方案放进一个真实项目里，它的目录大概会长这样：
agent-workspace/
├── .mcp/
│ └── servers/
│ └── figma-server.json
├── skills/
│ └── figma-to-frontend/
│ ├── SKILL.md
│ ├── references/
│ │ ├── component-mapping.md
│ │ └── design-token-rules.md
│ └── scripts/
│ └── post_check.sh
├── src/
│ ├── components/
│ ├── pages/
│ └── tokens/
└── CLAUDE.md
这几层的职责其实很清楚。
.mcp/servers/figma-server.json 这一类配置，重点是告诉 agent：Figma 能怎么接、能调哪些接口、能读哪些资源。
而 skills/figma-to-frontend/ 这层，重点是告诉 agent：拿到设计稿信息以后，代码该怎么组织、token 该怎么映射、现有组件该怎么复用、生成完以后要做哪些检查。
一个足够表达思路的伪配置
先看 MCP 这一层。
下面这段不是某家产品的官方配置原样，只是方便理解的伪配置：
{
"server": "figma",
"capabilities": {
"tools": ["get_file_nodes", "get_component_meta", "export_asset"],
"resources": ["design_tokens", "component_variants"]
}
}
这段配置只说明一件事：agent 现在能从 Figma 拿到哪些结构化能力。
再看 Skill 这一层。
# figma-to-frontend
## Workflow
- 先读取目标节点的结构和样式信息
- 优先映射到现有组件库，不直接生成散装结构
- 间距和颜色优先使用 `src/tokens/` 中已有变量
- 页面文件落到 `src/pages/`
- 公共块抽到 `src/components/`
- 生成后运行 `scripts/post_check.sh`
## Output
- 给出生成文件列表
- 标明哪些地方无法 1:1 还原
- 标明哪些地方使用了工程化替代方案
这段就明显不是接入层配置了。
它不关心 Figma 怎么连接，关心的是另外几件事：页面怎么生成、组件怎么复用、结果怎么验证、最后怎么交付。
为什么这两段最好分开放
原因很简单，它们的变化频率本来就不一样。
MCP 层的变化，往往来自外部系统能力变化。比如 Figma API 变了，或者你想新增素材导出能力。
Skill 层的变化，往往来自团队工程规范变化。比如你们从 CSS Modules 切换到 Tailwind，或者开始强制复用某套业务组件。
如果把这两层揉成一个大文件，后面维护只会越来越混乱。
拆开以后，收益很直接：
- 换接入方式，不一定要改流程
- 换流程规范，不一定要改接入层
- 同一套 Figma MCP，可以复用给多个 Skill
- 同一个 Skill，也可以迁移到别的设计数据来源
所以更愿意把它们理解成“接口层”和“能力层”。
三个场景，帮你快速判断该用谁
直接看判断题。
场景一：你要接 GitHub、Notion、数据库
优先考虑 MCP。
因为这里的核心问题不是流程，而是接入。
你首先要解决的是：agent 能不能访问这个系统、访问时暴露哪些能力、调用方式是否统一、权限边界怎么控制。
如果连都没连上，后面的流程设计没有意义。
场景二：你要把一套团队流程固定下来
优先考虑 Skill。
比如你想让 agent 稳定执行下面这套流程：先读取 CLAUDE.md，再查看项目目录，修改代码前先运行定位命令，输出必须包含验证步骤，代码评审优先报风险，不先讲总结。
这时候你真正要沉淀的是“做事方法”。
它可能完全不依赖外部系统。
就算需要外部系统，也不是问题的核心。
场景三：你既要接系统，又要固化流程
两者一起上。
比如你要做一个“需求文档 -> 拆任务 -> 写代码 -> 自测 -> 提交 PR”的 agent。
这类场景里：
- 用 MCP 接文档系统、代码仓库、CI、设计平台
- 用 Skill 固化拆解方式、实现步骤、提交流程、验收清单
很多团队最后真会落地的，其实就是这个形态。
不是二选一，而是分层协作。
一个实用判断框架
以后再遇到“这事该做 MCP 还是 Skill”，先问自己 3 个问题就行。
1. 这个问题的核心，是接外部能力，还是复用内部方法？
如果重点是“连系统”，偏 MCP。如果重点是“沉淀流程”，偏 Skill。
2. 没有外部系统，这件事还成立吗？
如果没有 GitHub、Figma、Notion、数据库，这个能力就不存在，那大概率是 MCP 场景。
如果就算没有外部系统，流程本身依然成立，比如代码 review、文章写作、发布清单，那更像 Skill 场景。
3. 你想复用的，到底是工具，还是做法？
复用工具，偏 MCP。复用做法，偏 Skill。
这三个问题一拆，基本就不会再混。
最容易踩的三个误区
误区一：Skill 是 MCP 的上位替代
不是。Skill 不会自动帮你接入外部系统。它可以消费工具，但它不等于工具接入层。
误区二：MCP 做完以后，不需要 Skill
也不是。你把一堆工具接进 agent，只是让它“能做更多事”。但“能做”不等于“稳定做对”。很多团队接了一堆工具以后，结果发现 agent 输出还是不稳定。原因通常不是工具不够，而是流程没固化。
误区三：Skill 只是换皮 Prompt
这么理解，真把 Skill 看扁了。Prompt 当然也是 Skill 的一部分。但真正有用的 Skill，不只是几段提示词。它更像一个可复用的能力包，里面会带上步骤、参考、脚本、模板和约束。重点不是“怎么提问”，而是“怎么稳定交付”。
我更建议你把它理解成这张分层图
用户需求
↓
Skill（流程、规范、模板、脚本、输出要求）
↓
MCP（连接外部工具、数据、服务）
↓
GitHub / Notion / Figma / 数据库 / 内部 API / CI
这张图最大的用处，是帮你快速判断问题该在哪一层处理。
如果你现在遇到的是“agent 拿不到数据”，去查 MCP。如果你遇到的是“agent 每次做法都不一样”，去补 Skill。
别一上来就继续堆 Prompt。
最后说一个更现实的判断
团队真把 agent 用起来以后，最稀缺的通常不是模型能力。
而是两样东西：
- 能稳定接入外部世界的接口层
- 能持续复用团队经验的能力层
MCP 补的是前者，Skill 补的是后者。
所以这两个概念最好的关系，不是谁替代谁。
更实际的说法是：
MCP 让 agent 有地方可去，Skill 让 agent 知道到了以后该怎么做。
如果你只做 MCP，你得到的是一堆可调用能力。如果你只做 Skill，你得到的是一套可能落不了地的流程。
先拆开，再组合着用，很多 agent 架构问题反而会清楚得多。
参考资料
- MCP 官方文档：modelcontextprotocol.io/docs/gettin…
- Claude Code MCP 文档：code.claude.com/docs/en/mcp
- OpenAI Codex 产品页：openai.com/codex/
- OpenAI Codex 发布文：openai.com/index/intro…
- OpenAI Docs MCP 文档：platform.openai.com/docs/docs-m…
