Claude Code 三大机制概览与决策 Skills、Hooks、Subagents

ADRU

386人浏览 · 2026-08-12 16:24:48

ADRU · 2026-08-12 16:24:48 发布

Claude Code 有三种正交的扩展机制 —— Skills（操作手册）、Hooks（事件钩子）、Subagents（独立会话）。它们不是同一件事的三种写法，各自解决不同问题，经常组合使用。

为什么要理解这三者

不少人上手 Claude Code 后有个共同困惑：想让它"每次开发前自动读需求文档"、“改完代码自动跑检查”、“审代码时切换到严格模式”，但翻文档发现有 Skills、Hooks、Subagents 三个东西都好像能做，不知道怎么选。

选错了会出现两种典型问题：

该用 Hook 却用了 Skill：结果 Claude 没在关键节点触发，比如"每次会话开始都要跑一次环境检查"，写成 Skill 就得每次用户手动喊 /check-env，忘一次就出错。
该用 Subagent 却用了 Skill：把 Code Review 写成 Skill，Claude 在主对话里读了几十个文件，之后接着写业务代码时上下文里塞满了 review 时读的东西，token 爆炸不说，还容易被 review 时的思路带偏。

搞清楚这三者的边界，本质上是搞清楚一件事：谁来决定触发、在哪个上下文里执行、结果怎么回收。

用一个日常场景先建立直觉

想象你是一个技术团队 leader，团队里三个角色：

场景：新同事小李要来做一个"用户登录改造"的需求。

角色 A：SOP 手册
公司有一份《需求开发 SOP》放在共享盘里。小李遇到"要开始做需求了"这个场景，主动翻开手册，按上面写的步骤：先读需求文档、再拉分支、然后编码、最后自测。手册是"死的"，什么时候翻、翻哪一节，都由小李自己判断。

→ 这就是 Skill。是给 Claude 看的一份说明书。Claude 判断"当前场景需要用它"时主动去读，然后照着做。

角色 B：门禁系统
公司门口装了个刷卡机，每天早上小李进门必须刷一下。刷卡机是自动的，不需要小李主动想着"我要去刷卡"，进门这个动作触发就自动执行。刷卡失败还能把人拦住。

→ 这就是 Hook。绑定在某个"事件"上，事件一发生自动执行，不需要 Claude 决策。

角色 C：外部专家
写完代码后小李把 diff 发到一个专门的 code review 群，群里有个专职 reviewer 老王。老王只做一件事：审代码。他有自己独立的思路和上下文，不参与小李的日常开发，看完丢一份 review 报告回来就完事。

→ 这就是 Subagent。一个独立的 Claude 会话，被主对话临时召唤出来干活，干完只返回结论。

三个角色协同工作：门禁系统（Hook）负责基础设施；SOP 手册（Skill）指导主流程；专家（Subagent）负责需要独立视角的审查环节。它们各司其职，缺一不可。

三种机制的本质区别

Skill：Claude 的操作手册

一个 Markdown 文件（SKILL.md），可选带一些脚本、模板。文件顶部写清楚"什么情况下用我、怎么用、参数怎么给"，Claude 判断当前对话匹配就把它读进来，按里面的步骤在当前对话里执行。

关键特征：

Claude 主动"读手册"，读到的内容进入当前上下文
中间过程都留在主对话，可以随时和用户互动
不改变工具集，用的还是 Claude 原本就有的 Read / Edit / Bash 等

Hook：事件驱动的自动脚本

hooks.json 配置文件，把"事件"和"要跑的 shell 命令"绑定起来。比如"会话开始时跑 X 脚本"、“每次 Edit 完某个文件后跑 Y 脚本”。事件一发生，Claude Code 自动执行绑定的命令，Claude 本身不做决策。

关键特征：

触发不由 Claude 决定，由事件决定
脚本执行结果可以通过 stdout 反馈回主对话（作为额外上下文）
适合"一定要在某个时机做的事"，不能漏

Subagent：一个新开的 Claude

.claude/agents/xxx.md 文件，里面写清楚"这个 agent 叫什么名字、做什么、能用哪些工具、system prompt 是什么"。主对话通过 Agent 工具把它召唤起来，它开一个全新的上下文从零开始工作，完事只返回一段总结。

关键特征：

独立上下文，看不到主对话历史（除非主对话把内容塞进 prompt）
工具集可以被限制（比如只给 Read，物理上不能改代码）
可以并发（同时开三个 agent 从不同角度看代码）
只返回最终结论，中间过程不污染主对话

一图看懂：对比表

维度	Skill	Hook	Subagent
本质	操作手册	事件钩子	独立会话
触发者	Claude 判断触发	事件自动触发	主对话/用户召唤
执行位置	主对话上下文	Claude Code 进程外	独立子会话
上下文	复用主对话全部	无（脚本自己拿数据）	全新，从零开始
能否交互	能，随时问用户	不能，无人工介入	不能，一次性输入输出
产出去向	全部留在主对话	stdout 注入主对话	只返回一段总结
工具集	主对话有啥用啥	shell 能做什么就做什么	自定义白名单
并发	串行	事件触发时并发执行	可开多个并发
典型形态	`SKILL.md` + 脚本	`hooks.json` + shell 脚本	`agents/xxx.md`
典型场景	按套路做一件事	每次某事发生必跑	独立视角审查

决策树：我该用哪个

回答这三个问题就能选对：

问题 1：触发时机是"事件"还是"意图"？

事件：会话开始、文件被编辑、工具调用完成 → Hook
意图：用户想做 X、Claude 觉得该做 X → 继续问题 2

问题 2：需要主 Claude 看到过程细节吗？

需要（后续还要基于细节继续工作）→ Skill
不需要（只要一个结论/报告） → Subagent

问题 3（补充）：需要并发或独立立场吗？

是（比如同时从 3 个角度审代码，或需要"没被主对话带偏"的新视角） → Subagent
否 → Skill

具体例子走一遍

“每次开会话都要检查本地环境是否装了 Node 20”
→ 事件（会话开始）→ Hook（SessionStart）

“把当前代码改动生成一份 changelog 追加到文件”
→ 意图 + 需要过程留在主对话 → Skill

“审一下我这次改动有没有安全问题”
→ 意图 + 只要结论 + 想要独立视角 → Subagent

“用户输入包含’部署’字样时提醒他先看部署文档”
→ 事件（用户发消息）→ Hook（UserPromptSubmit）

“同时从性能、安全、可维护性三个角度审代码”
→ 意图 + 需要并发 → 多个 Subagent

常见误区

误区 1：用 Hook 做需要 Claude 智能判断的事

有人想在 UserPromptSubmit hook 里"分析用户意图然后自动切换角色"。但 hook 是 shell 脚本，没有 LLM 能力，只能做字符串匹配。

正确做法：hook 只做规则明确的机械动作（记录、打点、简单关键词提醒）；智能判断留给 Claude 自己（通过 skill 的 description 匹配或 subagent 的调度）。

误区 2：用 Skill 做"必须每次跑"的事

有人把"环境检查"写成 skill，指望 Claude 每次都调。结果 Claude 觉得"这次问题很简单不用检查"就跳过了，出问题时才发现。

正确做法：任何"漏一次就出错"的机械动作，都必须用 Hook，因为 Hook 由事件驱动，Claude 没法跳过。

误区 3：用 Subagent 做需要主对话保留细节的事

有人把"读所有配置文件并整理"做成 subagent，想着独立上下文节省 token。结果主对话拿到的是一份摘要，后续想引用"配置里第 3 项"时发现细节没留下来，只能让 subagent 重新做一遍。

正确做法：如果后续工作需要基于细节继续推进，就用 Skill 让主对话看到全部；如果只需要一个结论/报告用于决策，才用 Subagent。

误区 4：认为三者互斥，非此即彼

刚学的人容易问"我到底该建 skill 还是 subagent"，仿佛只能选一个。实际上一个复杂能力经常是三者组合：Hook 打底、Skill 主流程、Subagent 审查。

正确做法：先按决策树选主要机制，再看是否需要另外两者辅助。

快速参考卡

打印贴墙上用：

┌──────────────────────────────────────────────────────────┐
│  Skill      = Claude 主动读的操作手册                    │
│  Hook       = 事件触发的自动脚本                         │
│  Subagent   = 主对话召唤的独立会话                       │
├──────────────────────────────────────────────────────────┤
│  选哪个 3 连问：                                         │
│    1. 触发是"事件"？  → Hook                             │
│    2. 主 Claude 要看过程？  → Skill                      │
│    3. 只要结论/要独立视角？  → Subagent                  │
├──────────────────────────────────────────────────────────┤
│  经典组合：                                              │
│    Hook 建基础设施 → Skill 跑主流程 → Subagent 做审查   │
└──────────────────────────────────────────────────────────┘