MCP与Skills的区别：你可能一直理解错了

0. 太长不读

说实话，MCP 和 Skills 这两个概念，在 Claude Code 生态里确实是出了名的容易搞混。一句话概括：MCP 管连接，Skills 管流程。但真正让人头疼的，不是这句话本身，而是——Skills 里可以带脚本，脚本又能调 API、操作数据库……这不就撞到 MCP 的地盘上了吗？

这篇文章会从协议层、运行时、工程实践三个维度，把两者的边界彻底拆清楚。核心结论先放这儿：

• Skills 脚本和 MCP 在能力上确实有重叠，可运行机制完全是两码事
• MCP 是持久化服务进程，而 Skills 脚本是按需执行的、一次性的命令
• 选择的判断标准不是“能不能做”，而是“该用什么姿势做”
• 真正到生产环境，大多数场景需要的是两者协同，而不是二选一

1. MCP 到底是什么

一句话定义

MCP（Model Context Protocol），是 Anthropic 在 2024 年 11 月推出的一个开源标准协议，专门用来把 AI 应用连接到外部系统。你可以把它想象成 AI 世界里的 USB-C 接口——通用、标准、即插即用。

架构三件套

整个架构由三个核心组件构成，各司其职：

┌─────────────────────────────────────────────┐
│  MCP Host（Claude Code / IDE / 任意 AI 应用） │
│                                               │
│  ┌───────────┐   JSON-RPC 2.0   ┌────────┐   │
│  │ MCP Client │ ◄──────────────► │  MCP   │   │
│  │（内置）    │   stdio / SSE    │ Server │   │
│  └───────────┘                  └────────┘   │
│                                               │
│        ┌──────┴─────┐                        │
│        │  外部系统   │                        │
│        │ DB / API /  │                        │
│        │ Notion / GH │                        │
│        └────────────┘                        │
└─────────────────────────────────────────────┘

运行时特征

MCP Server 是一个独立的、持久运行的服务进程。它启动之后，会做以下几件事：

1. 向 Host 注册自己提供的所有工具（这是自动发现的，不需要你手动配置）
2. 维持长连接，保持状态（包括认证、会话、缓存等）
3. 通过 JSON-RPC 2.0 接收调用请求，返回结构化结果
4. 生命周期跟随 Host，不会用完就退出

关键词提炼一下：持久、有状态、结构化通信、自动注册、跨应用复用。

一个具体例子

比如你启动了一个 Notion MCP Server，Claude 会自动获得以下这些工具：

notion-search
notion-create-pages
notion-update-page
notion-query-database-view
notion-get-comments
...（共 15+ 个工具）

不需要你做任何额外的配置，Claude 直接就能知道：自己可以搜索 Notion、创建页面、查询数据库……每个工具的定义、参数约束、返回格式，全部由 Server 进行了结构化声明。干净利落。

2. SKILLS 到底是什么

一句话定义

Skills 是 Claude Code 的本地扩展机制，本质就是一组存放在 .claude/skills/ 目录下的指令文件，用来教 Claude 怎么“做事”。

文件结构

.claude/skills/
└── my-skill/
    ├── SKILL.md            # 必须：指令定义（YAML frontmatter + Markdown）
    ├── scripts/            # 可选：可执行脚本
    │   ├── lint.sh
    │   └── deploy.py
    └── templates/          # 可选：模板文件
        └── pr-template.md

SKILL.md 的两段式结构

---
name: code-review
description: "Use when reviewing PRs or code changes. Don't use for writing new code."
---

## 审查流程

1. 先读取变更文件列表
2. 对每个文件检查以下维度：
   - 安全性：是否引入 OWASP Top 10 漏洞
   - 性能：是否有 N+1 查询、不必要的循环
   - 可读性：命名是否清晰，逻辑是否直接
3. 如果发现问题，运行 `scripts/lint.sh` 验证
4. 输出结构化审查报告

Frontmatter 负责配置触发条件（告诉 Claude 在什么时候用），下面的 Markdown 则定义了具体的操作流程（告诉它怎么做）。

运行时特征

Skills 的加载机制很有意思，是延迟的、按需的：

1. 启动时，Claude 只会加载每个 Skill 的 name + description，占用的资源极少（大约 30-50 tokens/skill）
2. 用户输入到达后，Claude 会扫描所有可用的 Skills，匹配出最相关的那个
3. 匹配成功，才会把完整的 SKILL.md 读取到上下文中
4. 如果指令里引用了脚本，Claude 会通过 Bash 工具去执行
5. 执行完毕，脚本进程就退出

关键词：延迟加载、无状态、纯文本指令、通过 Bash 执行脚本、仅限 Claude Code。

3. 能力重叠：SKILLS 脚本也能调 API

这才是大多数人困惑的根源。我们来看两个具体的例子：

用 MCP 查 GitHub Issues

// MCP Server（持久运行）
// Claude 自动获得 list-issues、create-issue、close-issue 等工具
// 调用时：
await mcp.callTool("list-issues", { repo: "owner/repo", state: "open" });
// 返回：结构化 JSON，包含 issue 列表

用 Skill 脚本查 GitHub Issues

#!/bin/bash
# scripts/list-issues.sh
gh issue list --repo "$1" --state open --json number,title,labels

# SKILL.md
---
name: github-issues
description: "Use when user asks about GitHub issues"
---

查看 issues 时，运行 `scripts/list-issues.sh `。

两种方式，都能顺利地拿到 GitHub Issues。那问题来了——它们到底有什么本质区别？

4. 核心区别：不是能不能，是怎么做

4.1 生命周期

MCP Server:
启动 ──────────── 运行中（持久） ──────────── 随 Host 关闭
    注册工具       处理请求       维持连接

Skill 脚本:
触发 → 执行 → 返回 → 退出
触发 → 执行 → 返回 → 退出
（每次都是全新进程）

MCP Server 启动一次，服务整个会话。而 Skill 脚本每次调用，都会诞生一个新进程，事情干完就立刻退出。

这个差异带来的实际影响非常明显：MCP Server 可以维持数据库连接池、缓存查询结果、保持 OAuth 会话；而 Skill 脚本每次执行，都得重新建立连接、重新走一遍认证流程。

4.2 工具发现

MCP 的工具是“结构化注册”的，Claude 在调用之前，就能精确地知道每个工具的参数类型、约束条件和返回结构。而 Skill 脚本的“工具发现”，依赖的是 Claude 去阅读自然语言指令，然后自己构造出 Bash 命令来执行。

4.3 通信方式

MCP:
Claude ←── JSON-RPC 2.0 ──→ Server
双向、结构化、可流式、支持回调

Skill 脚本:
Claude → Bash("scripts/xxx.sh arg1 arg2") → stdout
单向、纯文本、一次性

4.4 跨应用复用

MCP 是一个协议级的标准。一个写好的 Notion MCP Server，可以同时被 Claude Code、VS Code Copilot、Cursor、ChatGPT 使用——只要是实现了 MCP Client 的应用，都能接上它。

而 Skills 是 Claude Code 的专属功能。换一个 AI 工具来看，那些 Skill 文件就只是一堆普通的 Markdown 文档了。

4.5 一张表总结

5. 那 SKILLS 的真正价值是什么

看到这里，你可能会想：如果 MCP 在“外部连接”这件事上，严格优于 Skill 脚本，那 Skills 存在的意义到底是什么？

5.1 Skills 的核心是知识，不是能力

Skills 最重要的部分，其实不是 scripts/ 目录，而是 SKILL.md 里的那些指令。它真正定义的是：

• 什么时候做：触发条件和反例
• 怎么做：步骤、流程、判断标准
• 做到什么程度：验收标准

# 示例：数据库迁移 Skill

---
name: db-migrate
description: "Use when creating or modifying database migrations. Don't use for queries."
---

## 迁移流程

1. 检查当前迁移状态：`scripts/check-migration-status.sh`
2. 生成迁移文件前，确认：
   - 是否有未应用的迁移
   - 字段命名是否符合 snake_case 约定
   - 是否需要数据回填
3. **禁止**在迁移中使用 `DROP COLUMN`，改用 `ALTER COLUMN ... SET NOT VISIBLE`
4. 生成后必须运行 `scripts/validate-migration.sh` 检查语法
5. 迁移文件名格式：`YYYYMMDD_HHMMSS_description.sql`

这里面，90% 的价值在于流程规范和团队约定。脚本本身，只是用来辅助验证的工具而已。

5.2 Skills 脚本擅长确定性计算

LLM 其实有一些很不擅长的事，比如：

• 精确的正则匹配和文本处理
• 数值计算和统计
• 文件格式转换（CSV → JSON、Markdown → HTML）
• 本地文件系统的批量操作

这些任务，最适合交给脚本去做。Claude 只需要负责调用和解读结果。

## 代码统计 Skill

当用户问项目规模时：
1. 运行 `scripts/count-lines.sh`
2. 解读输出，给出概要

#!/bin/bash
# scripts/count-lines.sh
cloc --json . | jq '{languages: [.header.n_lines], total_code: .SUM.code, total_comments: .SUM.comment, total_blank: .SUM.blank}'

这类任务，既不需要持久服务，也不需要结构化通信。一个脚本，干净利落，足够了。

5.3 Skills 是上下文管理的载体

回到上下文工程的视角来看，Skills 的延迟加载机制，本身就是一种极其聪明的优化：

系统提示（常驻，约 30-50 tokens/skill）
├── skill-1: name + description
├── skill-2: name + description
└── skill-n: name + description

匹配触发后才加载完整指令（几百到几千 tokens）

100 个 Skills 在系统提示里，只占 3000-5000 个 token。完整的指令，只有在需要的时候才会被加载到上下文，用完之后还可以释放。这种渐进式加载的能力，是 MCP 工具定义做不到的——要知道，MCP 那 55,000 个 token 的工具定义，是在启动时全量注入的。

6. 实战：什么场景用什么

6.1 决策树

需要连接外部系统？
├── 是 → 需要持久连接/状态/会话？
│   ├── 是 → MCP
│   └── 否 → 调用频率高？
│       ├── 是 → MCP（连接复用、缓存）
│       └── 否 → Skill 脚本就够
└── 否 → 需要定义工作流程？
    ├── 是 → Skill
    └── 否 → 既不需要外部连接也不需要流程定义 → 可能 CLAUDE.md 就够了

6.2 场景对照表

6.3 协同使用的典型模式

最有价值的用法，其实是两者配合使用：

Skill（流程层）            MCP（能力层）
┌──────────────┐         ┌──────────────┐
│ 1. 读取 PR 变更 │──────────► │ GitHub MCP  │
│ 2. 按规范审查 │         │              │
│ 3. 查关联 Issue │──────────► │ Linear MCP  │
│ 4. 写审查报告 │         │              │
│ 5. 发通知    │──────────► │ Slack MCP   │
└──────────────┘         └──────────────┘

Skill 负责编排“做什么、按什么标准做”；MCP 则提供“连接到哪、怎么通信”。两层各管各的，互不侵入，清晰又优雅。

7. 常见误区

8. 工程落地建议

8.1 从 Skill 开始，按需引入 MCP

大多数团队的初始需求是“让 Claude 按我们的方式做事”，而这正是 Skills 最擅长的地方。不要一上来就搭 MCP Server，步子太大了。

推荐的启动顺序：

1. 先写 CLAUDE.md，定义项目级约定
2. 重复出现的流程，抽成 Skill
3. 需要外部系统交互时，评估是 Skill 脚本够用，还是需要 MCP
4. 高频、有状态、跨应用的场景，再上 MCP

8.2 Skill 脚本转 MCP 的信号

当你发现 Skill 脚本出现以下情况，就该考虑迁移到 MCP 了：

• 每次执行都要重新认证（OAuth token 过期、需要重建连接）
• 脚本里有大量错误处理和重试逻辑
• 多个 Skill 都依赖同一个外部服务
• 需要维持长连接（WebSocket、数据库连接池）
• 其他 AI 工具也需要同样的能力

8.3 控制 MCP 工具数量

前面提到过，5 个 MCP Server 就占了 55,000 个 token，这大概是 200K 上下文的三成。工具定义过多，会直接导致：

• Claude 选错工具的概率上升
• Prompt Caching 的命中率下降
• 上下文留给实际任务的空间变少

记住一个原则：只接真正需要的 MCP Server，不要贪多。

9. 划重点

1. MCP 是协议级标准，提供持久化的外部系统连接；Skills 是 Claude Code 本地扩展，提供流程知识和确定性脚本。两者解决的是不同层面的问题。
2. Skills 脚本确实能干 MCP 能干的部分事情，但机制完全不同：一个是持久服务进程，一个是按需执行的一次性命令。
3. 选择的标准不是“能不能做”，而是“该怎么做”：需要持久连接、状态管理、跨应用复用，用 MCP；需要定义流程、团队约定、确定性计算，用 Skills。
4. 最有价值的用法是两者协同：Skill 编排“做什么、怎么做”，MCP 提供“连到哪、怎么通信”。
5. 从 Skill 开始，按需引入 MCP。不要一上来就搭 Server，也不要用 Skill 脚本硬撑需要持久连接的场景。
6. 控制 MCP 工具数量。5 个 Server 就 55,000 tokens，工具越多，Claude 越容易选错。

参考资料

1. Anthropic, Introducing the Model Context Protocol
2. Anthropic, Extend Claude with skills
3. Anthropic, Introducing Agent Skills
4. Model Context Protocol, What is MCP?
5. Tw93, 你不知道的 Agent：原理、架构与工程实践
6. IntuitionLabs, Claude Skills vs. MCP: A Technical Comparison
7. morphllm, Claude Code Skills vs MCP vs Plugins: Complete Guide