大家好，我是讯享网，很高兴认识大家。这里提供最前沿的Ai技术和互联网信息。



🤵‍♂️ 个人主页：小李同学_LSH的主页

目录

先给结论：这四个东西不在同一层

一、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 才从一个会话工具，变成一个真正可扩展的编程代理系统。

Anthropic 官方对 Skills 的定义很直接：用 SKILL.md 文件把说明写进去，Claude 就会把它加入自己的工具箱；当相关时 Claude 会自动用，也可以手动通过 /skill-name 调用。官方还特别强调，和 CLAUDE.md 不同，Skill 的正文只会在它被实际使用时才加载，所以长参考材料在不用的时候几乎不花上下文成本。

你可以把 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。

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 官方把它定义为：一种把 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 等安全风险，尤其是会接触不可信内容的服务器。

Anthropic 文档明确写到：Claude Code 有内置 subagents，而且 Claude 会根据 subagent 的描述自动决定什么时候把任务委派出去。官方列出的内置 subagents 里，至少包括：

• Explore：快速、只读，适合文件发现、代码搜索、代码库探索
• Plan：在 plan mode 下做研究，帮助形成计划
• General-purpose：适合需要探索和修改并存的复杂多步任务。

文档还说明，Claude 会自动在合适的时候使用 specialized subagents，例如“审查最近改动的安全问题”或“运行全部测试并修复失败”。

Subagents 真正解决的是什么问题

不是“系统接入什么”，而是：

复杂任务应该让谁去做，才能更高效、上下文更干净、角色更专一。

你可以把它理解成任务分派：

Subagent 最有价值的地方有两个：

1. 上下文隔离：不是把所有探索细节都塞进主会话
2. 角色专门化：不同代理用不同工具限制、不同描述、不同任务边界

官方文档里就明确写到 Explore 是只读工具集，Plan 也限制为只读，而 General-purpose 则拥有全部工具。也就是说，Subagent 不是“同一份 Claude 多开窗口”，而是带限制、带角色、带职责分工的代理单元。

Subagents 最适合什么场景

当你发现任务已经出现这些特征时，就该考虑 Subagent：

• 需要先探索，再行动
• 需要研究与执行分开
• 需要把某类任务交给只读代理
• 需要让复杂任务不污染主对话上下文

这和 Skill、Hook、MCP 都不是一个问题层。

实际上一旦你理解分层，就会发现这四者不是互相替代，而是经常一起出现。

一个很典型的场景是：

• 用 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 扩展体系最清晰的分层。