先说结论
一句话区分：Skill 是“教模型做事的方法论”，离线装进上下文，断网也能用；MCP 是“给模型接通外部服务和数据的通道”，运行时要联网、要凭据。该装技能还是该接服务，不看喜不喜欢，看你要不要实时数据、要不要写操作、要不要跨会话状态。本文数据来自 2026-09-26 的 GitHub API：anthropics/skills 约 17.8 万 star（Agent Skills 官方示例库），modelcontextprotocol/servers 约 9.1 万 star（官方 MCP 服务器集合），python-sdk 约 2.4 万 star。两者不是二选一，往往是搭档。
本质：一个是方法，一个是通道
官方对 skill 的定义是“folders of instructions, scripts, and resources that Claude loads dynamically to improve performance on specialized tasks”——它是一包提示词加脚本加参考资源，在会话开始时只把 name+description（约 100 token）挂进上下文，被调用时才读完整内容（建议低于 5000 token），更重的参考文档按需再读。渐进式加载是 skill 省上下文的关键：未被调用的 skill 只占约 100 token 的 description，不会把整篇长文灌进窗口，这正是它能塞很多个而不撑爆模型的原因；MCP 没有这层缓冲，每个工具的描述始终在场。换句话说，skill 的全部知识在写好的那一刻就固定了，它解决“怎么做”这类稳定问题。
MCP（Model Context Protocol）反过来，是把模型连到一个运行中的服务：数据库、内部 API、文件系统、SaaS。模型通过这个通道实时查数据、调工具。它解决的是 skill 天生做不到的事——拿当下此刻的信息、对外部系统做写操作。规范上 MCP 暴露的是 tools 和 resources，模型按需要调用。
“Skills teach Claude how to complete specific tasks in a repeatable way.” —— 重点在“how”，是方法；MCP 的重点在“access”，是能力通道。
判定表：该装技能，还是接 MCP
| 你的需求 | 装 Skill | 接 MCP |
|---|---|---|
| 知识/流程长期稳定 | 是 | 否 |
| 需要实时数据（现在库存、今天日志） | 否 | 是 |
| 要做写操作（改库、发消息、建工单） | 否（无凭据） | 是 |
| 需要凭据且跨服务鉴权 | 否 | 是 |
| 需要跨会话保留状态 | 否（上下文随会话结束） | 是（服务端持有） |
| 在意延迟和成本 | 是（本地、零网络） | 否（每次往返服务） |
一个实用的判断顺序：先问“这事需不需要此刻的数据或外部系统的写权限”。不需要，就用 skill；需要，就上 MCP。再问“流程本身稳不稳”，稳就写成 skill 固化下来。两者都不要硬凑——别为了“看起来先进”给一个纯本地固定流程也起一个 MCP 服务。现实里多数团队两头都要，关键是把两边职责搞对，别让 skill 去查实时数、也别让 MCP 去背流程。反例很有代表性：有人给“每天生成运营日报”做了个 skill，里面写死“昨日新增用户=xxx”，可这数字是写文件时的快照，三天后模型还拿它当真——这种该接 MCP 查数，而不是写死进 skill。
两者配合：MCP 取数，Skill 定流程
真实场景里它们常搭档：MCP 负责“拿到活数据、执行动作”，skill 负责“拿到之后按什么流程处理”。例如一个发布助手——MCP 连 CI 和仓库拿构建状态、未合 PR，skill 规定评审清单、tag 规则、变更日志格式。模型先经 MCP 取数，再按 skill 里的步骤推进。
# Skill 的 SKILL.md 里描述流程（方法论，离线可用）
description: 发布前读取 CI 状态与未合 PR，按评审清单核对，再打 tag 并写 CHANGELOG。
# 真正“取状态 / 打 tag”的动作，由已连接的 MCP 服务完成
示意性的 MCP 接入（字段名以你用的客户端为准，仅表达结构，不保证逐字可跑）：
{
"mcpServers": {
"ci": { "command": "npx", "args": ["-y", "my-ci-mcp"], "env": { "TOKEN": "..." } }
}
}
分工原则：凡是“查什么、改什么”交给 MCP 工具；凡是“按什么顺序、满足什么标准”交给 skill 写死。这样 MCP 换了实现，skill 的流程不用动；流程升级了，MCP 连接也不用动。具体串起来是五步：一、MCP 拉取未合 PR 与 CI 状态；二、skill 按评审清单逐条核对；三、发现问题退回开发者；四、MCP 打 tag 并推送；五、skill 生成 CHANGELOG 条目。取数和执行全在 MCP，判断与格式全在 skill，各管一段。skill 侧只声明它允许用的本地工具，比如：
---
name: release-flow
description: 发布前按评审清单核对未合 PR 与 CI 状态，打 tag 并写 CHANGELOG。
allowed-tools: Bash(git:*) Read
---
各自的坑
Skill 的坑：
- 拿不到实时数据，写在 SKILL.md 里的“当前版本号”“最新接口”会过期，还被当真理。
- 知识固化，业务规则一变就得改文件重发，否则全员用旧规范。
- description 写太泛会乱触发（见第 67 篇），写太窄又永远不触发。
- 主文件过长会吃上下文，规范建议 SKILL.md 控制在 500 行内，细节拆到 references/。
- allowed-tools 字段仍是实验性，不同客户端支持不一，别把关键权限完全押在它上；需要稳定授权还是走 MCP 的凭据。
MCP 的坑：
- 工具一多，所有 tool 描述都塞进上下文，直接挤爆窗口、拉高延迟和成本——这是接 MCP 最常见的翻车点。经验值是工具尽量控制在十几个以内，超过就按需分批暴露，否则工具清单本身就成了噪声，模型反而不会选。
- 必须联网、必须凭据；服务挂了或 token 过期，模型当场失明，而 skill 断网仍能跑。
- 写操作有副作用，权限和审计要自己兜底，不能假手于“模型觉得该做”。
反模式清单：
- 用 skill 写死“实时库存”之类的活数据，过期了还信。
- 把几十个 API 全挂成 MCP 工具，上下文被工具清单占满，模型反而不会选。
- 该接 MCP 却硬用 skill 配一长串 curl 片段，既无凭据管理又不可维护。
- 该用 skill 却起一个 MCP 服务，只为跑一段固定流程，杀鸡用牛刀。
下一步怎么做
把团队里“稳定流程”先做成 skill 沉淀进仓库（见第 66 篇）；一旦遇到要查实时数据或写外部系统，就去找或写一个 MCP server，从 modelcontextprotocol/servers 仓库挑官方维护的实现。两者不是二选一，而是“方法用 skill 固化、能力用 MCP 接通”的组合——先想清哪段是方法、哪段是能力，自然就知道该装还是该接。若只做纯本地固定流程，一个 skill 顶十个 MCP；若离了线上数据就寸步难行，MCP 才是正解，别用 skill 硬凑实时查询。