内容来源：Claude Directory。https://www.claudedirectory.org/blog/claude-code-skills-vs-subagents-vs-mcp
原题：Skills vs Subagents vs MCP vs Hooks: Which Claude Code Extension Should You Use?
原发布时间：2026-06-24
Claude Code 有六种扩展方式——CLAUDE.md、Skills、子智能体、MCP 服务器、Hooks 和插件——它们之间恰好有一些重叠，容易让人困惑。本决策指南将解释每种机制是什么、何时该用、何时不该用，以及如何将它们组合起来。
只要花过一些时间定制 Claude Code，你就一定遇到过这个问题：这项功能应该做成 Skill？子智能体？MCP 服务器？Hook？写进 CLAUDE.md？封装成插件？还是应该通过 /loop 循环或定时例程来运行？
它们全都能“扩展 Claude Code”，而这正是人们容易卡住的原因。这些名称并没有告诉你各自适合什么工作，而且它们之间恰好存在一些重叠——通常可以硬把其中两种机制掰成同一个问题的解决方案，只是效果很糟。
先给出捷径，本文其余内容只是对它的展开：每种机制回答的问题都不相同。 一旦明确自己在问什么，选择就会变得显而易见。
• Claude 应该始终知道什么？ → CLAUDE.md
• Claude 应该能够按需执行哪项可重复任务？ → Skill
• 哪项大型或并行工作需要独立、干净的上下文？ → 子智能体
• Claude 需要访问哪个外部系统？ → MCP 服务器
• 无论模型如何决定，什么事情都必须每次自动发生？ → Hook
• 某件事应该在什么时间、以多高频率自行运行？ → /loop 或例程（自动化属于另一条维度，下文会详细介绍）
• 如何把上面这些机制打包并共享？ → 插件
下面把这些结论具体化。
30 秒对比
| 机制 | 由谁触发 | 本质是什么 | 适用场景 |
|---|---|---|---|
| CLAUDE.md | 始终加载 | 持久指令与项目上下文 | Claude 总是忘记一条本应始终遵守的约定 |
| Skill | Claude（自动）或你（/name） |
针对一项可重复任务打包的提示词 + 可选脚本和文件 | 你经常执行同一项多步骤任务，希望把它封装起来 |
| 子智能体 | Claude 委派 | 针对某项工作的全新隔离上下文窗口 | 任务很大、可以并行，或会污染主上下文 |
| MCP 服务器 | Claude 调用其工具 | 通往外部系统（数据库、API、浏览器、SaaS）的桥梁 | Claude 需要仓库之外的数据或操作 |
| Hook | 运行框架在生命周期事件发生时触发 | 与事件绑定的确定性命令 | 无论模型如何选择，某件事都必须每次发生 |
| 插件 | 由你安装 | 将上述任意机制打包在一起 | 你想一步共享或复用整套配置 |
这张表中最有用的区别是：由谁扣动扳机。 Skills 和子智能体由模型调用——Claude 决定是否使用。Hooks 是确定性的——事件发生时，不管模型愿不愿意，运行框架都会触发。MCP 解决的是连接性——只是让外部工具变得可用。CLAUDE.md 提供的是上下文——始终存在。插件负责的是分发——把其他机制打包起来。
CLAUDE.md：Claude 应该始终知道的事情
CLAUDE.md 是一份 Markdown 文件，Claude Code 会在会话开始时自动将其载入上下文。它不能执行，也没有什么复杂机制——它就是一份长期有效的任务简报。项目约定、运行测试的命令、架构规则、“绝不要修改这个目录”、你偏好的库，都可以写在里面。
适合使用的情况： 你发现自己总在纠正同一个问题。“使用 pnpm，不要用 npm。”“测试文件与源文件放在一起。”“除非明确要求，否则不要添加注释。”一件事说过两次，就该写进 CLAUDE.md。
不适合使用的情况： 指令只与某项特定任务有关（应该用 Skill），或者相关知识体量非常庞大（4,000 行的 CLAUDE.md 会在每轮对话中白白消耗上下文——保持精简，改为链接到外部资料）。
最容易踩的坑是内容膨胀。CLAUDE.md 每一轮都会加载，因此每一行都会对上下文窗口征税。把它当成速查表，而不是 Wiki。
Skills：封装可重复任务
Skill 是一个包含 SKILL.md 的文件夹——其中包括名称、描述、指令集，以及可选的脚本和参考文件。Claude 会读取描述，并在请求匹配时自动调用 Skill；你也可以把它当成斜杠命令显式调用。
关键理念是：Skill 采用渐进式披露。描述以很低的成本留在上下文中，只有当 Skill 真正触发时，完整指令和打包文件才会加载。因此，对于太长、不适合放进 CLAUDE.md，却又太具体、不该始终启用的流程，Skill 是最合适的归宿——例如生成发布变更日志、按照团队风格搭建组件脚手架，或运行 PDF 导出流水线。
适合使用的情况： 存在一项流程明确、可重复的多步骤任务，尤其是该流程有自己的脚本或模板。
不适合使用的情况： 只是需要 Claude 知道某项事实（用 CLAUDE.md），工作需要独立上下文和并行处理（用子智能体），或者本质上是要连接外部系统（用 MCP）。
Skills 也是最值得直接借用而不是从头编写的机制。Claude Directory 的 Skills 合集中有相当一部分可以复制后直接使用。如果你确实要自行编写，自定义 Skills 创建指南会从头到尾讲解 SKILL.md 格式。
子智能体：为专门任务提供干净上下文
子智能体是一个独立的 Claude 实例，拥有自己的上下文窗口，由主智能体派生出来负责一部分工作并汇报结果。Claude Code 内置了 Explore（只读搜索）和 general-purpose 等子智能体；你也可以在 .claude/agents/ 中定义自己的子智能体，为其设置名称、描述、允许使用的工具和模型。
子智能体能带来两种其他手段无法买到的东西：上下文隔离与并行性。一次会把 50 个文件塞进主上下文的代码搜索，可以放到子智能体中执行；它读完所有文件后，只返回三行结论。你也可以同时运行 N 个彼此独立的子智能体——并行审查四个文件，或同时探索三个子系统。
适合使用的情况： 任务很大、噪声很多或特别适合并行——例如大范围搜索、多文件审查，或“去理解整个子系统并做总结”。
不适合使用的情况： 任务很小且是线性的（直接在当前上下文中完成即可），本质上是一套可复用流程（用 Skill），或者需要持久护栏（用 Hook）。子智能体还是一次性委派——它们无法与你持续对话，只能返回一次结果。
更深入的模式——智能体团队、扇出并行、基于成本的模型分层——可参阅子智能体指南与自定义智能体指南。
MCP 服务器：连接仓库之外一切事物的桥梁
*模型上下文协议（MCP）*是一项开放标准，用于将 Claude 连接到外部系统。MCP 服务器可以公开工具*（Claude 能调用的操作）、资源（Claude 能读取的数据）与提示词*。接入服务器后，Claude Code 就能查询 PostgreSQL 数据库、创建拉取请求、操控浏览器、读取 Sentry 错误，或调用服务器封装的任意 API。
判断标准很简单：这项能力是否存在于代码库之外？ 文件、代码与 Shell 命令已经由 Claude Code 的内置工具覆盖——这些不需要 MCP。MCP 适用于 Claude 自身无法触及的事物：生产数据库、Issue 跟踪器、设计工具或可观测性技术栈。
适合使用的情况： Claude 需要读取外部系统，或对外部系统执行操作。
不适合使用的情况： 所谓“工具”只是一个 Shell 脚本或代码转换——这时应该用 Skill 或直接调用 Bash；把它包装成 MCP 服务器属于过度设计。（若想进一步了解什么时候该用或不该用 MCP，请参阅 MCP 已死？。）
你可以浏览目录中的 MCP 服务器，看看哪些系统已经有人封装；设置和配置方法则可参阅完整 MCP 指南。
Hooks：必须自动发生的事情
Hook 是 Claude Code 运行框架在生命周期事件发生时执行的 Shell 命令——这些事件包括 PreToolUse、PostToolUse、UserPromptSubmit、Stop 和 SessionStart 等。Hooks 在 settings.json 中配置，是整个体系的确定性层：无论模型如何决定，它们都会在事件发生时触发，而这正是 Hooks 的意义。
这是唯一不由模型控制的机制，其全部价值也正在于此。每次编辑后自动格式化文件；阻止写入 .env；Claude 宣称任务完成时运行测试套件；记录每一条命令以供审计。如果规则是“每次都必须发生，不能例外”，那么只有 Hook 能提供这种保证——模型可以跳过 Skill 或 CLAUDE.md 中的提示，却无法跳过 Hook。
适合使用的情况： 你需要一个必须在事件发生时确定性运行的护栏或自动化操作。
不适合使用的情况： 是否运行需要判断（通过 Skill 让模型决定），或者只是一次性操作（直接提出要求即可）。
Hooks 指南提供了适用于常见场景、可以直接复制的配置；目录的 Hooks 合集中还有更多示例。
插件：包裹所有机制的外壳
插件并不是第七种机制，而是其他六种机制的集合包。一个插件可以同时提供 Skills、子智能体、Hooks、MCP 服务器配置和斜杠命令，并可通过插件市场一步安装。
适合使用的情况： 你构建了一整套值得分享的配置，或者想安装别人精心整理的技术栈（例如安全审查套件、某个框架专用的工具包），不想手动接入每个部分。
不适合使用的情况： 只为单个仓库解决一个问题——这种情况只需要一个 Skill 或一个 Hook；此时就封装成插件还为时过早。
请参阅最佳 Claude Code 插件汇总和完整的插件合集。
决策流程
如果不确定该选什么，就从上到下依次判断，遇到第一个“是”时停止：
1、是否需要访问外部系统（数据库、API、浏览器、SaaS）？ → MCP 服务器。
2、是否必须在某个事件发生时自动运行，而且每次都要执行、绝无例外？ → Hook。
3、是否应该按计时器或计划自动运行，而不是按需执行？ → /loop 或例程（见下一节）。
4、它是否是一项大型、嘈杂或可并行的工作，需要独立上下文？ → 子智能体。
5、它是否是一套 Claude 应该按需执行的可重复多步骤流程？ → Skill。
6、它是否只是 Claude 应该始终知道的一件事？ → CLAUDE.md。
7、你是否想通过一次安装分享整套配置？ → 插件。
顺序很重要：更具体、更偏基础设施的答案（外部访问、确定性事件、调度）排在前面，因为只要符合其中之一，它几乎总是正确选择。通用上下文工具（Skills、CLAUDE.md）则是后备方案。
组合使用效果最好
真正强大的做法是把它们组合起来。下面是一些反复出现的模式：
• Skill + 子智能体： 一个“审查这个 PR”的 Skill，为每个文件分别派生并行子智能体，最后综合结果。
• MCP + Skill： MCP 服务器连接数据库；Skill 封装每周针对数据库运行的具体查询与报告工作流。
• Hook + CLAUDE.md： CLAUDE.md 规定“我们使用 Prettier”；PostToolUse Hook 则真正运行 Prettier，确保不会忘记这条规则。
• 插件 = 全部机制： 一个 security-review 插件通过一次安装，同时提供 Skill、子智能体、Hooks 和 MCP 配置。
你并不是要为整个工作流挑选唯一一种机制，而是要为每一个组成部分选择最适合的机制。
循环与例程应该放在哪里
这里有个合理的问题：/loop 与例程该怎么算？它们确实存在、也是当前功能，但上面的表格有意没有收录它们——因为它们位于另一条维度上。
前面六种机制回答的是：“Claude 能做什么、知道什么、访问什么？” 循环和例程回答的是：“工作在什么时候运行、多久运行一次？” 这属于自动化，而非能力。自动化有三种形式，需要分清：
• Hooks——基于事件。 在生命周期事件（工具调用、会话开始、停止）发生时触发。具有确定性、在会话内运行，而且免费。前文已经介绍。
• /loop——基于间隔，在当前会话中运行。 在你的机器上、活跃会话内，反复运行提示词或斜杠命令——例如“每 5 分钟重新运行失败的测试”“持续轮询这个 PR，直到变绿”。启动它的会话结束，它也随之停止。
• 例程——基于计划或触发器，在云端运行。 已保存的提示词会根据 Cron 计划、Webhook 或 GitHub 事件，在无人值守的情况下执行——无需保持会话开启。这属于自动驾驶层。
最清晰的心智模型是：Hooks 响应事件；你在场时，/loop 按计时器重复执行；你不在场时，例程独立运行。 因此，如果问题是“如何让 Claude 按固定节奏自动做这件事”，答案并不是 Skill 或子智能体，而是循环（你在场）或例程（你不在场）。/loop 指南完整介绍会话内自动化，例程指南则完整介绍云端自动化。
注意它们之间自然形成的搭配：把“做什么”与“何时做”结合起来。例程保存的提示词通常会调用 Skill，后者可能再委派给子智能体并调用 MCP 工具——自动化层决定工作何时运行，扩展层决定这项工作具体是什么。
常见问题
Skill 与子智能体有什么区别？
Skill 是一套打包后的指令（外加可选脚本），在当前上下文中运行——它定义的是做什么。子智能体是一个拥有独立上下文窗口的 Claude 实例——它决定的是工作在哪里运行。可重复流程使用 Skill；如果工作规模很大或并行程度很高，不应该挤占主会话，就使用子智能体。两者可以组合：Skill 可以把工作委派给子智能体。
什么时候应该用 MCP 服务器而不是 Skill？
如果能力存在于代码库之外——例如数据库、API、浏览器或 SaaS 产品——就使用 MCP 服务器。如果工作是针对 Claude 已经能够接触的内容（文件、代码和 Shell）执行一套流程，就使用 Skill。如果你发现自己只是为了运行本地脚本而构建 MCP 服务器，那么真正需要的是 Skill。
斜杠命令与 Skills 相同吗？
两者关系非常密切。调用 Skill 有两种方式：Claude 将请求与其描述匹配后自动调用，或者你把它作为 /slash-command 显式输入。斜杠命令是手动进入 Skill 的入口——底层机制相同，触发方式不同。
Hooks 会消耗 Token 吗？
不会。Hooks 是由运行框架执行的 Shell 命令，不是由模型运行——它们不会像 Skill 或子智能体那样消耗上下文或 Token。这也是 Hooks 适合用作常驻护栏的部分原因：既具有确定性，又完全免费。
/loop 和例程也属于 Skills 或 Hooks 那样的扩展吗？
不完全是——它们属于自动化，是另一条维度。Skills、子智能体、MCP 和 Hooks 改变的是Claude 能做什么；循环与例程改变的是它何时运行。/loop 在你的机器上、活跃会话内按照固定间隔重复提示词；例程则在云端根据计划或触发器无人值守地运行已保存的提示词。当问题与执行节奏而非能力有关时，就该选择它们；而且要注意，它们通常会调用扩展机制（例如运行某个 Skill 的例程），而不是取代扩展机制。
开始定制 Claude Code 最简单的方法是什么？
从 CLAUDE.md 开始——把你反复强调的约定写下来。然后为第一项经常执行的多步骤任务添加 Skill。只有当你真正遇到子智能体、MCP 服务器和 Hooks 各自解决的具体需求时，再使用它们。不要为尚不存在的问题构建基础设施。
最终结论
这六种机制不是竞争对手，而是一套工具箱。困惑只会在你试图挑选一个“最爱”，而不是根据工作选择工具时出现：
• CLAUDE.md 用来存放 Claude 应该始终知道的内容。
• Skills 用来封装可重复任务。
• 子智能体负责需要干净上下文的大型或并行工作。
• MCP 服务器用来访问仓库之外的世界。
• Hooks负责每次都必须自动发生的事情。
• 插件用来打包并共享所有机制。
在自动化维度上，循环与例程决定这些工作在什么时候运行——是在会话中按计时器运行，还是在云端按计划运行。
弄清每种机制回答的问题，你就不必再靠猜测做选择。
延伸阅读
• 如何创建自定义 Claude Code Skills——从头到尾讲解 SKILL.md 格式
• Claude Code 子智能体指南——扇出、智能体团队和成本感知的模型分层
• MCP 服务器完整指南——MCP 是什么，以及如何连接第一台服务器
• Claude Code Hooks 完整指南——适用于常见自动化、可以直接复制的配置
• CLAUDE.md 指南——如何编写物有所值的项目上下文
• Claude Code /loop——在会话内按固定间隔运行提示词
• Claude Code 例程：让 Claude 进入自动驾驶——定时云端智能体，以及它们与 /loop 的区别
• 最佳 Claude Code 插件——当前值得安装的精选套件
当前版本准确性说明（核对于 2026-07-21）
• 本文来自独立网站 Claude Directory。其页脚明确声明，该网站与 Anthropic 没有从属关系，也未获得 Anthropic 认可或赞助。
• CLAUDE.md 会在会话开始时加载到上下文窗口中。原文之后称它“每轮都会加载”；当前文档描述的是启动时加载，并非每次提示词提交时都从磁盘重新读取文件。
• 原文对 4,000 行的警告是一项合理建议，但 CLAUDE.md 会完整加载，并不会被限制在 200 行。当前文档建议尽量控制在 200 行以内，以提高指令遵从度和上下文效率。
• Skills 通常会载入当前对话，但“Skill 始终在当前上下文中运行”的说法过于绝对。Skills 可以设置 context: fork，在隔离的子智能体上下文中运行。
• 子智能体从独立上下文开始，但已不再是严格的一次性机制。当前 Claude Code 可以携带历史记录恢复子智能体，子智能体也能使用持久记忆；智能体团队消息功能还提供了更多交互方式。
• 把 MCP 视为通往仓库外部系统的桥梁，是一种有用的设计经验，而非协议限制。MCP 服务器可以公开本地或远程工具、资源与提示词。
• Hooks 并不局限于 Shell 命令。当前处理程序类型包括命令、HTTP、MCP 工具、提示词与智能体。Prompt 和 Agent Hooks 会调用模型，因此可能消耗 Token；所以原文 FAQ 中“Hooks 不消耗 Token”的笼统回答只适用于非模型处理程序。
• 匹配的 Hook 由运行框架分发，而不是由主模型选择，但这并不保证实现预期效果：处理程序可能失败、超时、返回非阻断结果或配置错误。
• 插件目前可以打包 Skills、智能体、Hooks、MCP 服务器及相关配置。项目 CLAUDE.md 仍然属于仓库上下文，并非常规插件组件，因此“其他六种机制的集合包”只是一种便于理解的简化说法。
• 文章对调度方式的区分符合当前情况：/loop 是会话范围内的本地调度，例程则在 Anthropic 托管的云基础设施上，根据计划、API 或 GitHub 触发器运行。只要执行模型工作，两者都会消耗用量。
