🤵♂️ 个人主页：小李同学_LSH的主页
✍🏻 作者简介：LLM学习者
🐋 希望大家多多支持，我们一起进步！😄
如果文章对你有帮助的话，
欢迎评论 💬点赞👍🏻 收藏 📂加关注+
目录
先给结论：这四个东西不在同一层
一、Skills：它不是插件市场，而是“把套路固化下来”
Skills 最适合什么场景
Skills 和 CLAUDE.md 的区别
二、Hooks：它不是“能力”，而是“自动触发器”
Hooks 触发在什么时候
Hooks 最适合什么场景
MCP 在 Claude Code 里到底扮演什么角色
MCP 最适合什么场景
Subagents 真正解决的是什么问题
Subagents 最适合什么场景
五、最容易犯的错：把四者当成替代关系
六、一个最实用的判断法：你该先加哪一层？
第一问：你是不是总在重复给 Claude 讲同一套流程？
第二问：你是不是希望某些动作在固定时机自动执行？
第三问：你是不是总在手动把外部系统的信息复制进聊天？
第四问：你的任务是不是已经复杂到一个代理做会把上下文搞得很乱？
这两个月，很多人开始觉得 Claude Code 不像一个“会补代码的工具”，而更像一个“能接手一段开发流程的编程代理”。Anthropic 官方对 Claude Code 的定位也很明确：它是一个agentic coding tool，能理解代码库、编辑文件、运行命令，并且可在终端、IDE、桌面端和浏览器中使用。
但一旦真正开始用，几乎所有人都会在同一个地方犯迷糊：Skills、Hooks、MCP、Subagents 到底分别是什么，它们到底处在 Claude Code 的哪一层？这四个词经常同时出现，但它们解决的问题其实完全不同。
这篇文章我就只做一件事：把 Claude Code 的扩展体系分层讲清楚。你看完之后，应该能回答这四个问题：
- 什么时候该写 Skill。
- 什么时候该配 Hook。
- 什么时候该接 MCP。
- 什么时候该把任务拆给 Subagent。
先给结论：这四个东西不在同一层
最短的理解方式是：
- Skills：把“常用做法”封装成 Claude 会在合适时机调用的能力包。
- Hooks：在 Claude Code 生命周期的特定节点，自动触发命令、HTTP 或提示逻辑。
- MCP：把外部工具、数据库、API、文件系统这类外部系统标准化接进来。
- Subagents：把复杂任务分派给专门代理去处理。
如果非要用一句更像工程语言的话总结：
Skills 负责“会什么”，Hooks 负责“什么时候自动做”，MCP 负责“能连到什么外部世界”，Subagents 负责“谁来做”。这四层叠在一起，Claude Code 才从一个会话工具，变成一个真正可扩展的编程代理系统。
一、Skills：它不是插件市场，而是“把套路固化下来”
Anthropic 官方对 Skills 的定义很直接：用SKILL.md文件把说明写进去，Claude 就会把它加入自己的工具箱；当相关时 Claude 会自动用，也可以手动通过/skill-name调用。官方还特别强调，和CLAUDE.md不同，Skill 的正文只会在它被实际使用时才加载，所以长参考材料在不用的时候几乎不花上下文成本。
这其实已经说明了 Skills 的本质：
它不是“接一个外部能力”，而是把你反复输入给 Claude 的玩法、清单、流程、操作剧本沉淀下来。官方建议在这些情况下把内容从聊天或CLAUDE.md里升级成 Skill：你反复粘贴同一套 playbook、checklist 或 multi-step procedure，或者某段CLAUDE.md已经从“事实说明”膨胀成“操作流程”。
你可以把 Skill 理解成这样一个函数：
它不直接给 Claude 新的外部系统权限，而是给 Claude 一套更稳定、更可复用的做事方式。
Skills 最适合什么场景
最适合 Skills 的，不是“接数据库”这种外部连接问题，而是这些内部工作流问题：
- 固定的 code review 清单
- 某类 bug 的排查套路
- 某种 PR 生成模板
- 某套重构流程
- 某个测试与验证清单
Anthropic 还写到，Claude Code 内置了一些 bundled skills，比如/simplify、/batch、/debug、/loop、/claude-api。它们和内置命令不一样：这些 bundled skills 是 prompt-based 的，相当于给 Claude 一套详细的操作剧本，再由 Claude 自己去编排执行。
Skills 和 CLAUDE.md 的区别
这点特别容易混。CLAUDE.md更像“长期规则和背景说明”，而 Skill 更像“某种可被调用的专项做法”。官方文档明确说，CLAUDE.md是你希望 Claude 每次开局都知道的项目规则，而 Skill 的正文则是按需加载。
所以最短的判断标准是：
事实、规则、架构背景，放
CLAUDE.md；步骤、套路、清单、流程，做成 Skill。
二、Hooks：它不是“能力”，而是“自动触发器”
Hooks 解决的不是“Claude 会什么”，而是“Claude 在什么时机自动做什么”。
Anthropic 的 Hooks 文档定义得非常清楚：Hooks 是用户自定义的 shell 命令、HTTP 端点或 LLM prompts，它们会在 Claude Code 生命周期的特定点自动执行。Claude Code 会把事件相关的 JSON 上下文传给 Hook 处理器，然后由处理器决定采取什么动作，必要时还可以返回决策。
这说明 Hook 的本质不是“新功能”，而是事件驱动自动化。
如果把它抽象一下，可以写成：
其中：
event是 Claude Code 发生的生命周期事件context是 Claude Code 传来的 JSON 上下文h是你定义的处理逻辑
Hooks 触发在什么时候
官方把 Hooks 的事件节奏分成三类：
- 每次会话一次：如
SessionStart、SessionEnd - 每轮一次：如
UserPromptSubmit、Stop、StopFailure - agent loop 内每次工具调用：如
PreToolUse、PostToolUse
文档还给出了完整的生命周期图，里面甚至包括SubagentStart/Stop、TaskCreated/Completed、FileChanged、ConfigChange等异步事件。
这意味着 Hook 非常适合做这些事：
- 修改文件后自动跑测试
- 执行命令前做权限检查
- 会话结束时自动总结
- 调某类工具前插入规则校验
- 结果失败时自动触发告警或后处理
Hooks 最适合什么场景
一句话：只要你希望“某件事在某个时机自动发生”，就该优先想 Hook。
它非常适合：
- 自动测试
- 自动 lint
- 自动安全检查
- 自动通知
- 自动审计
- 自动后处理
所以 Skills 和 Hooks 的关键区别是：
Skill 是“怎么做”，Hook 是“什么时候自动做”。
MCP 这几年最容易被说偏。
它不是 Claude Code 的某个“小插件机制”，而是一套独立标准。
MCP 官方把它定义为：一种把 AI 应用连接到外部系统的开源标准。使用 MCP，像 Claude 或 ChatGPT 这样的 AI 应用可以连接到数据源、工具和工作流；官方甚至把它类比为 AI 应用的 “USB-C 接口”。
Anthropic 在 Claude Code 的 MCP 文档里也写得非常直白：Claude Code 可以通过 MCP 连接到数百种外部工具和数据源，MCP server 可以给 Claude Code 提供对工具、数据库和 API 的访问能力。官方给的典型使用时机是：当你发现自己总在把 issue tracker、监控面板之类的数据复制进聊天框时，就该考虑直接接 MCP，让 Claude 能读并操作那个系统。
所以 MCP 解决的问题是：
Claude 怎么接入“代码库之外的世界”。
比如：
- JIRA / Linear / GitHub Issues
- PostgreSQL / MySQL / Redis
- Sentry / Datadog / Statsig
- Figma / Slack / Notion
- 自己公司的内部 API
MCP 在 Claude Code 里到底扮演什么角色
它不是行为逻辑层，而是外部能力接入层。
也就是说，Claude 会不会用这些工具、何时用、怎么组织调用，是上层 agent loop 的事；但这些工具“能不能以统一方式暴露出来”，是 MCP 解决的事。
MCP 规范里把服务器暴露的能力分成三大类：
- Resources：提供上下文和数据
- Prompts：提供模板化消息和工作流
- Tools：提供可由模型调用的函数能力。
所以 MCP 比“工具调用”更高一层，它不只是函数，而是一个标准化的 AI 外部接口层。
MCP 最适合什么场景
最适合 MCP 的场景，不是“写一个内部固定流程”，而是：
- 你要接很多外部系统
- 你不想每个系统都手写一套对接方式
- 你希望外部能力能被 Claude 统一发现和调用
- 你希望未来这些外部能力能复用到别的 AI 客户端里
Anthropic 还特别提醒：第三方 MCP server 需要谨慎使用，因为可能带来 prompt injection 等安全风险，尤其是会接触不可信内容的服务器。
Subagents 这一层，经常被误以为只是“多开几个 Claude”。
其实不是。
Anthropic 文档明确写到：Claude Code 有内置 subagents，而且 Claude 会根据 subagent 的描述自动决定什么时候把任务委派出去。官方列出的内置 subagents 里，至少包括：
- Explore：快速、只读，适合文件发现、代码搜索、代码库探索
- Plan：在 plan mode 下做研究，帮助形成计划
- General-purpose：适合需要探索和修改并存的复杂多步任务。
文档还说明，Claude 会自动在合适的时候使用 specialized subagents，例如“审查最近改动的安全问题”或“运行全部测试并修复失败”。
Subagents 真正解决的是什么问题
不是“系统接入什么”，而是：
复杂任务应该让谁去做，才能更高效、上下文更干净、角色更专一。
你可以把它理解成任务分派：
Subagent 最有价值的地方有两个：
- 上下文隔离：不是把所有探索细节都塞进主会话
- 角色专门化：不同代理用不同工具限制、不同描述、不同任务边界
官方文档里就明确写到 Explore 是只读工具集，Plan 也限制为只读，而 General-purpose 则拥有全部工具。也就是说，Subagent 不是“同一份 Claude 多开窗口”，而是带限制、带角色、带职责分工的代理单元。
Subagents 最适合什么场景
当你发现任务已经出现这些特征时，就该考虑 Subagent：
- 需要先探索，再行动
- 需要研究与执行分开
- 需要把某类任务交给只读代理
- 需要让复杂任务不污染主对话上下文
这和 Skill、Hook、MCP 都不是一个问题层。
| 能力 | 解决什么问题 | 最像什么 | 典型使用场景 |
|---|---|---|---|
| Skills | 把常用做法沉淀下来 | 可复用剧本 / 清单 | Debug 流程、PR 模板、代码评审清单 |
| Hooks | 在特定时机自动触发逻辑 | 事件驱动自动化 | 改完文件自动测试、失败自动告警 |
| MCP | 把外部世界接进来 | 标准化外部接口层 | 数据库、工单、监控、设计系统 |
| Subagents | 把复杂任务拆给专门代理 | 角色分工 / 任务委派 | Explore、Plan、复杂多步任务 |
五、最容易犯的错：把四者当成替代关系
实际上一旦你理解分层，就会发现这四者不是互相替代，而是经常一起出现。
一个很典型的场景是：
- 用MCP接进 JIRA、Sentry、数据库
- 用Subagent先做探索和计划
- 用Skill固化“修 Bug 的标准流程”
- 用Hook在修改后自动跑测试和报告结果
这时候系统才真正像一个“能接外部世界、能拆任务、会按流程做事、还能自动验证”的编程代理。
所以千万不要问：
“我到底该用 Skills 还是 MCP？”
更准确的问题应该是：
“我当前遇到的问题，是流程复用问题、自动触发问题、外部连接问题，还是任务分工问题？”
问题层级不同，答案自然不同。
六、一个最实用的判断法：你该先加哪一层？
如果你想快速判断自己现在最该配什么，可以直接按这个顺序问。
第一问：你是不是总在重复给 Claude 讲同一套流程？
如果是，优先做Skill。
因为这说明问题不是“Claude 不会接工具”，而是“你没有把最佳做法沉淀下来”。
第二问：你是不是希望某些动作在固定时机自动执行？
如果是，优先配Hook。
因为这说明问题不是“能力不够”，而是“触发机制不自动”。
第三问：你是不是总在手动把外部系统的信息复制进聊天？
如果是，优先接MCP。
Anthropic 官方就直接建议：当你发现自己总在粘 issue tracker 或 monitoring dashboard 的数据时，应该考虑接 MCP server。
第四问：你的任务是不是已经复杂到一个代理做会把上下文搞得很乱？
如果是，优先考虑Subagent。
因为这说明问题已经不是“有没有流程”，而是“是否该分工”。
Skills 解决“会什么”，Hooks 解决“何时自动做”，MCP 解决“能连到什么”，Subagents 解决“谁来做”。这才是 Claude Code 扩展体系最清晰的分层。
