MCP、Skills、Hooks 到底什么关系？一文理清 Claude 扩展三大机制

本文深入解析了MCP、Skills和Hooks三者的区别与应用场景。MCP作为基础协议层提供外部服务连接能力，Skills是任务编排层实现可复用工作流，Hooks则是执行保障层确保关键操作。文章通过分层架构图、八维度对比表和实战案例，清晰展示了三者的定位差异：MCP解决"能做什么"，Skills解决"怎么做好"，Hooks解决"必须做什么&quot

king0007777777

441人浏览 · 2026-04-19 01:13:19

king0007777777 · 2026-04-19 01:13:19 发布

前言

在第一篇中，我梳理了 MCP 的基础概念；在[第二篇](MCP与AI编程工具集成实战Claude Desktop、Cursor、JetBrains全攻略)中，我分享了 MCP 与各种 AI 工具的集成方式。但在实际使用中，一直有一个困惑：

MCP、Skills 都能扩展 Claude 的能力，它们到底有什么区别？什么时候用哪个？

这个问题困扰了我很长时间，直到我真正理解了它们各自定位在不同层级。带上hooks！本文将从概念定义、技术架构、适用场景三个维度，彻底理清这三者的关系。
在这里插入图片描述

一、先给三个概念一个清晰的定义

1.1 MCP：外部连接器

MCP（Model Context Protocol） 是一个开放标准协议，让 AI 能够通过标准化接口调用外部工具和服务。

类比：USB-C 接口。有了统一接口，充电器、U 盘、显示器都能即插即用，不需要每种设备配一根专用线。

核心能力：

类型	说明	举例
Tools	可执行的操作	查数据库、发邮件、操作浏览器
Resources	可读取的数据	文档内容、配置文件、实时状态
Prompts	预设的提示模板	代码审查模板、Bug 报告模板

1.2 Skills：任务编排

Skills（技能） 是一个可复用的指令包——一个文件夹里放一个 SKILL.md，写清楚遇到某类任务该怎么做。

类比：菜谱。MCP 提供了锅碗瓢盆（工具），Skill 则告诉你怎么用这些工具做出一道菜。

Skill 的典型结构：

my-skill/
├── SKILL.md           # 核心指令文件（必须）
│   ├── YAML 元数据     # 名称、描述、触发关键词
│   └── Markdown 正文   # 工作流步骤、规则、参考
├── scripts/           # 可执行脚本（可选）
├── references/        # 参考文档（可选）
└── assets/            # 资源文件（可选）

在这里插入图片描述

1.3 Hooks：执行保障器

Hooks（钩子） 在 Claude Code 生命周期特定节点自动执行的命令。确定性执行——配了就一定会跑，不需要 AI 判断。

类比：安全装置。不管你钉不钉钉子，每次拿起锤子前都会自动检查有没有戴护目镜。

关键生命周期事件：

事件	触发时机	常见用途
`PreToolUse`	工具执行前	拦截危险命令、校验输入
`PostToolUse`	工具执行后	自动格式化、跑 Lint
`Stop`	Claude 完成回复时	发通知、更新看板
`SessionStart`	会话开始时	加载上下文、设环境变量

二、三层架构：一个关键思维模型

理解这三者关系，最重要的是建立分层思维：

┌──────────────────────────────────────────────┐
│              Skills（技能层）                  │
│     可复用的工作流、领域知识、做事方法          │
│     → 回答"怎么把事做好"                      │
├──────────────────────────────────────────────┤
│              MCP（协议层）                     │
│     连接外部服务的标准化接口                    │
│     → 回答"能做什么"                          │
├──────────────────────────────────────────────┤
│              Hooks（执行层）                   │
│     生命周期事件的自动化执行                    │
│     → 回答"什么事必须做"                      │
└──────────────────────────────────────────────┘

一句话总结：

MCP 给 Claude 能力（连接外部世界）
Skills 给 Claude 方法（编排复杂工作流）
Hooks 给 Claude 纪律（确保关键动作必执行）

三、核心区别：八维度深度对比

维度	MCP	Skills	Hooks
本质	连接外部服务的协议	可复用的指令包	生命周期自动化
所在层	基础设施层	应用层	执行层
触发方式	AI 自主决定调用	用户触发或 AI 自动检测	生命周期事件自动触发
是否需要 AI 推理	是	是	否（确定性执行）
Token 成本	高（工具定义常驻上下文）	低（按需加载）	零（上下文外执行）
适用范围	跨平台（所有 MCP 客户端）	仅 Claude Code	仅 Claude Code
配置位置	`settings.json` mcpServers	`.claude/skills/`	`settings.json` hooks
核心定位	连接	编排	保障

Token 成本详解

这是很多人忽略的关键差异：

机制	Token 占用方式	影响
MCP	每个 Server 的工具定义常驻上下文	以 Playwright 为例，一个 Server 有 20 个工具，定义约 2000-3000 Token，不管用不用都占着
Skills	平时只看名称+描述（~100 Token），按需加载完整内容	不用时不占空间，需要时才加载
Hooks	零 Token	完全在上下文窗口之外执行

实战建议：MCP 服务器不是装得越多越好。2-4 个核心 Server 就够了，复杂流程用 Skill 编排。

四、同一任务，三种做法的对比

以"写完代码自动格式化"为例：

方案 A：用 MCP

连接一个 Prettier MCP 服务器，Claude 写完代码后自己决定是否调用。

问题：Claude 可能"忘了"调，而且工具定义一直占 Token。

方案 B：用 Skills

写一个 Skill，在指令里写"每次编辑后都要跑 Prettier"。

问题：只在 Skill 激活时有效，Claude 在上下文紧张时可能跳过。

方案 C：用 Hooks

配一个 PostToolUse Hook，匹配 Write 工具，每次写文件后自动跑 prettier --write。

结果：每次都执行，没有例外，零 Token 成本。 ✅

结论：必须执行的事，用 Hook。

五、各自最佳适用场景

5.1 什么时候用 MCP？

判断标准：如果你发现自己反复在 Claude 里粘贴 curl 命令或 API 调用结果，说明你需要一个 MCP Server。

典型场景：

场景	推荐 MCP Server
读写本地文件	`@modelcontextprotocol/server-filesystem`
管理 GitHub 仓库	`@modelcontextprotocol/server-github`
查询 PostgreSQL 数据库	`@modelcontextprotocol/server-postgres`
搜索网页信息	`@modelcontextprotocol/server-brave-search`

5.2 什么时候用 Skills？

判断标准：如果你已经在 Claude 里粘贴过 3 次以上相同的指令，它就该是一个 Skill。

典型场景：

场景	Skill 示例
代码审查有固定标准	`code-review` Skill
部署流程有 10 个步骤	`deploy` Skill
文档有特定格式要求	`doc-generator` Skill
CSDN 文章有写作规范	`csdn-publisher` Skill

5.3 什么时候用 Hooks？

判断标准：如果你的需求描述里有"必须"、“每次都要”、“绝对不能”，它就是 Hook。

典型场景：

场景	Hook 配置
写完代码必须格式化	`PostToolUse` → `prettier --write`
绝对不能执行 `rm -rf /`	`PreToolUse` → 拦截危险命令
每次会话开始加载项目上下文	`SessionStart` → 加载配置
完成任务后发送通知	`Stop` → 调用通知 API

六、三者配合：实战案例

案例一：生产环境部署

Hook (PreToolUse):   拦截对生产目录的 rm -rf 命令 → 安全底线
Skill (/deploy):     编排完整的部署流程 →
      ├── MCP (GitHub):    创建 Release Tag
      ├── MCP (Slack):     通知团队频道
      ├── 内置工具:         跑测试套件
      └── 内置工具:         构建并推送 Docker 镜像
Hook (Stop):         把部署结果记录到审计日志 → 合规要求

三层各司其职：

Hook 兜底，防止灾难性操作
Skill 编排流程，确保步骤完整
MCP 处理外部通信

案例二：CSDN 文章发布（哈哈哈提一嘴，这是主包在用的skill，它把这个也放进来了）

Skill (csdn-publisher):   编排文章生成流程 →
      ├── 询问文章类型和主题
      ├── 检测系列文章
      ├── 生成大纲 → 用户确认
      ├── 撰写文章
      ├── 执行审查
      └── 保存到对应目录
MCP (filesystem):         读写文章文件
Hook (PostToolUse):       保存后自动检查 Markdown 语法

案例三：代码审查工作流

Skill (code-review):      编排审查流程 →
      ├── 读取变更文件
      ├── 按审查清单逐项检查
      ├── 生成审查报告
      └── 提交 Review 意见
MCP (GitHub):             获取 PR 变更、提交 Review
Hook (PreToolUse):        确保不会误操作主分支

七、决策流程图

当面临需求时，按以下顺序判断：

需求来了
    │
    ▼
需要连接外部服务吗？（数据库、API、浏览器）
    ├── 是 → 用 MCP
    │
    ▼
必须每次都执行吗？（格式化、安全检查、自动通知）
    ├── 是 → 用 Hooks
    │
    ▼
是不是一个可复用的复杂流程？（代码审查、部署、文档生成）
    ├── 是 → 用 Skills
    │
    ▼
以上都不是 → 直接在 CLAUDE.md 里写规则就行

八、常见误区

❌ 误区一：MCP 装得越多越好

连了 15 个 MCP 服务器，指望 Claude 自己搞定一切。

后果：上下文爆炸，响应变慢，效果反而变差。

正确做法：2-4 个核心 Server 足矣。复杂流程用 Skill 编排，而不是靠堆 MCP Server。

❌ 误区二：用 Skill 做强制性操作

在 Skill 里写"每次编辑后必须跑 Linter"。Skill 是建议，不是命令——Claude 在上下文紧张时可能跳过。

正确做法：必须执行的事用 Hook。

❌ 误区三：只用一种扩展方式

只用 MCP 不用 Skill，或者只用 Skill 不用 Hook。

正确做法：Hook 做保障，Skill 做流程，MCP 做连接，三管齐下。

❌ 误区四：MCP 和 Skills 是竞争关系

MCP 是协议层，Skills 是应用层，它们是互补而非替代关系。事实上，Skill 经常需要调用 MCP 提供的工具来完成工作。

九、与通用 LLM 工具插件的对比

为了更全面地理解，我们进一步扩大对比范围，看看这三者与通用 LLM 工具插件的区别：

维度	Claude Skills	MCP	通用 LLM 插件
可移植性	仅限 Claude	最高（多主机兼容）	最低（厂商锁定）
设置成本	低（写 Markdown 即可）	中（需要开发 Server）	低（安装即用）
治理能力	按 Skill 库管理	集中治理、凭证隔离	因平台而异
延迟	本地执行，几乎为零	本地 stdio 近零延迟	每次调用产生 API 往返
适用场景	可重复的个人/团队工作流	企业级集成、多主机复用	单一平台内快速实现功能

关键洞察：MCP 是唯一跨厂商的标准化方案。截至 2026 年初，OpenAI Agents SDK 已支持 MCP，这意味着你开发的 MCP Server 可以同时服务于 Claude、GPT、Gemini 等多个 AI 平台。

十、推荐配置

类型	数量建议	例子
MCP 服务器	2-4 个	文件系统、GitHub、加 1-2 个业务相关
Skills	5-10 个	代码审查、部署、文档生成、团队流程
Hooks	3-5 个	自动格式化、危险命令拦截、会话初始化