掘地攀登
100.61M · 2026-03-29
团队里一聊 agent 落地，十有八九会冒出两个词：MCP，Skill。
问题是，这两个词经常被混着用。有人说“先把 MCP 搭起来”，说着说着聊的是代码规范。有人说“做个 Skill 就行”，最后又在问怎么接 Figma、GitHub、Notion。
聊到最后，大家以为自己在讨论方案，其实连问题都没对齐。
先把我的判断摆这儿：
MCP 解决的是连接问题。Skill 解决的是复用问题。
再说白一点：
MCP 更像接口层，负责把 agent 连到外部世界Skill 更像能力层，负责把一套做事方法封装起来这俩不是一回事，但在实际项目里经常绑在一起。
有一句得先说，不然后面很容易越聊越偏。
MCP 这个词比较稳。无论看 Anthropic 还是 OpenAI，它基本都指同一类东西：让 AI 应用接入外部工具、数据和工作流的协议层。
但 Skill 这个词没这么稳。
不同产品里，Skill 的实现方式和边界并不完全一样。本文说的 Skill，主要指 agent 产品里的那类“技能包”能力，也就是把 instructions、references、scripts、资源文件和工作步骤打包在一起，让 agent 在特定场景里稳定完成任务。
所以这篇文章不是在对比两个标准协议。 我想拆开的，是 AI 工具链里两个经常被混着说的层次。
先说 MCP。
MCP 不是拿来“增强智能”的。 它干的是更基础的活：把模型接到外部系统上。
你把它当成 AI 世界里的统一插口就行。
如果你的 agent 需要：
那你第一个要解决的问题一定是：怎么连进去，怎么把这些能力用统一方式交给模型。
这就是 MCP 的活。
从官方定义看，MCP server 往外暴露的通常是 tools、resources、prompts 这几类能力。也就是说，MCP 更关心的是：
所以 MCP 更像协议层和连接器。
它不定义你的团队怎么做代码评审，也不定义文章怎么排版，更不负责告诉 agent“遇到这种问题先查哪个文档，再跑哪个脚本，再用什么格式输出”。
它只负责一件事：
把外部世界安全、稳定、标准化地接进来。
再说 Skill。
Skill 的重点不在“接入”，在“沉淀”。
当某类任务反复出现，而且你每次都得重讲一遍，你缺的往往不是新工具，而是一套能复用的方法。
比如这些场景：
这些问题有个共同点：
agent 不是做不了，是每次做法都不太一样。
这时候你真正要的就是 Skill。
Skill 本质上是在封装一套稳定工作流。里面可以有：
如果说 MCP 给了 agent 一双手，那 Skill 更像是在教它“这双手平时该怎么干活”。
所以 Skill 更偏能力编排，而不是工具接入。
它解决的是：
因为真实场景里，它们本来就经常一起出现。
举个很典型的例子。
比如你要做一个“从设计稿生成前端页面”的 agent 流程。
这个流程里可能会有几步：
这里面：
所以很多团队会自然地把两者揉到一起。
其实不是。
更准确的理解应该是：
MCP 负责把能力接进来，Skill 负责把能力组织起来。
一个偏“连”，一个偏“用”。
光讲概念还是有点飘。
直接拿一个很多团队都想做的场景来拆。
这个需求很常见：
设计师在 Figma 里出稿，agent 自动生成一个可继续开发的前端页面。
第一次做这件事的人，很容易把所有东西都塞进一个“大 Prompt”。 第一版也许能跑，第二版开始飘，第三版基本就没人敢碰了。
更稳的办法，还是先按层拆。
这一层不关心“页面怎么写”，只关心“agent 到底能拿到什么”。
比如一个 Figma 相关的 MCP server，可以给 agent 暴露这些能力：
这一层解决的全是接入问题：
这些都很关键，但还不是“前端页面生成流程”本身。
所以 MCP 做完以后，agent 最多只是获得了：
“我现在能看懂这份设计稿了。”
它还没有获得：
“我该按你们团队的方式把它写成代码。”
到了这一层，问题就从“怎么连”变成了“怎么干”。
比如你可以把下面这套流程沉淀成一个 Skill：
这时 Skill 封装的就不是“Figma API”。 而是团队自己的做法。
比如它可以额外规定：
Button、Card、Modal 这些现有组件这些东西才真正决定结果稳不稳。
很多团队就是卡在这里。
他们把 Figma 接进来了，agent 也确实能读节点信息，但生成代码还是一会儿一个样。
第一次可能是原生 CSS。 第二次改成 Tailwind。 第三次又开始手搓一套不符合项目规范的组件。
这不是 MCP 失效。 而是你只解决了“看得到设计稿”，没解决“怎么稳定产出项目代码”。
反过来也一样。
如果你只写了一套“设计转代码流程”，但 agent 根本拿不到 Figma 的结构化信息，那它只能靠截图猜。
截图猜布局，做 demo 没问题，真拿去跑生产流程就很悬。
因为它很容易：
所以只做 Skill，也不够。
这个场景最顺手的拆法，其实就一句话：
MCP 让 agent 能“读懂设计稿”，Skill 让 agent 能“按团队要求写代码”。
把它看成一条流水线就行：
Figma 设计稿
↓
MCP：读取节点、样式、素材、组件信息
↓
Skill：套团队规则，决定如何映射到组件库和目录结构
↓
生成前端代码
↓
Skill：自检、截图、补充交付说明
如果真要在团队里落地，我建议就这么拆：
MCP 层负责：
Skill 层负责：
这样拆有个直接好处，Figma 接入能力可以复用到很多任务里。
今天你拿它做“设计转代码”。 明天也可以拿它做“设计走查”。 后天还可以拿它做“设计稿和线上页面差异检查”。
而 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：
而 skills/figma-to-frontend/ 这层，重点是告诉 agent：
先看 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，或者开始强制复用某套业务组件。
如果把这两层揉成一个大文件，后面维护只会越来越乱。
拆开以后，收益很直接：
所以我更愿意把它们理解成“接口层”和“能力层”。
直接看判断题。
优先考虑 MCP。
因为这里的核心问题不是流程，而是接入。
你首先要解决的是：
如果连都没连上，后面的流程设计没有意义。
优先考虑 Skill。
比如你想让 agent 稳定执行下面这套流程：
CLAUDE.md这时候你真正要沉淀的是“做事方法”。
它可能完全不依赖外部系统。
就算需要外部系统，也不是问题的核心。
两者一起上。
比如你要做一个“需求文档 -> 拆任务 -> 写代码 -> 自测 -> 提交 PR”的 agent。
这类场景里：
很多团队最后真会落地的，其实就是这个形态。
不是二选一。 而是分层协作。
以后再遇到“这事该做 MCP 还是 Skill”，先问自己 3 个问题就行。
如果重点是“连系统”，偏 MCP。 如果重点是“沉淀流程”，偏 Skill。
如果没有 GitHub、Figma、Notion、数据库，这个能力就不存在，那大概率是 MCP 场景。
如果就算没有外部系统，流程本身依然成立，比如代码 review、文章写作、发布清单，那更像 Skill 场景。
复用工具，偏 MCP。 复用做法，偏 Skill。
这三个问题一拆，基本就不会再混。
不是。
Skill 不会自动帮你接入外部系统。 它可以消费工具，但它不等于工具接入层。
也不是。
你把一堆工具接进 agent，只是让它“能做更多事”。 但“能做”不等于“稳定做对”。
很多团队接了一堆工具以后，结果发现 agent 输出还是飘。 原因通常不是工具不够，而是流程没固化。
这么理解，真把 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 架构问题反而会清楚得多。
一天一个开源项目（第57篇）：Unsloth - 2x 更快、70% 更省显存的 LLM 微调库
活用 Claude Code : 从协作者变成可编程的智能基础设施
