1. 概念与工作原理
1.1 Command ------ 手动"快捷指令"
-
概念 ：存放在
.claude/commands/目录下的 Markdown 文件，里面是一段你预置的提示词。你在聊天中输入/命令名，Claude 就会"收到"这段提示词并按它执行。Command 的核心理念是把高频、重复性的长提示词变成一个简短的斜杠命令，提升你的使用效率。 -
工作原理 ：用户输入
/命令名→ Claude 读取对应的 Markdown 文件 → 将文件内容直接注入当前对话上下文，如同用户亲自键入了一段详细指令 → 模型据此生成回答。这些命令可以是单次的原子操作，也可以是多步骤的编排。
1.2 Skill ------ Claude 自动"按需加载"的专业工具箱
-
概念 ：Skill 是一个文件夹，内含
SKILL.md文件。通过name和description让 Claude 检索，正文中是具体指令和可选脚本。Claude 会根据对话自主判断是否需要加载某个 Skill，从而获得特定领域的专业知识和工作流程。Skill 的目的是把需要反复使用的知识、操作规范或专用能力封装成可复用的"工具包"，供 Claude 自主取用。 -
工作原理 ：其核心在于"渐进式披露"机制------① 会话启动时，Claude 只读取所有 Skill 的
name+description（仅约 100 token），用于快速判断相关性；② 当用户任务匹配某个 Skill 描述时，Claude 加载该 Skill 的完整正文到上下文（通常 <5k token）；③ 按 Skill 中的指引执行；④ 脚本或捆绑文件在需要时才加载，不一次性全加载。这种设计让你可以拥有几十个 Skill 而不会拖慢 Claude，因为无关任务的 Skill 根本不会被加载。
1.3 Agent (Sub-agent) ------ 独立运行的"特派专员"
-
概念 ：Sub-agent 是一个独立的 Claude 实例，拥有自己的上下文窗口、系统提示、工具集和模型参数，由主 Claude 按需启动。Sub-agent 完成子任务后返回结果摘要并销毁，中间产生的所有调用记录和工具输出都不会进入主对话上下文。其价值在于任务隔离------将复杂、独立、可能产生大量中间输出的子任务交给一个独立的"员工"去完成，避免拖慢主对话或污染其上下文。Simon Willison 的实际测试显示，Sub-agent 可以同时并行运行多个实例完成不同分析任务，主对话则静候最终报告。
-
工作原理 ：主 Claude 判断某个子任务适合独立处理 → 调用
start_agent工具 → 系统启动一个全新的独立 Claude 实例 （新上下文窗口，独立计费）→ 该实例接收子任务描述、独立调用工具、执行操作 → 任务完成后返回最终结果摘要 → Sub-agent 销毁，中间过程完全不进入主对话。
1.4 Hook ------ 生命周期"自动触发器"
-
概念 ：Hook 是在 Claude Code 生命周期中（如用户提交提示词前、工具调用前后、会话开始/结束时等）自动执行的用户自定义 Shell 命令、HTTP 端点或 LLM 提示 。Hook 不由模型判断，而是由宿主进程确定性地执行------每次触发对应事件时，Hook 必然运行，不会遗漏。
-
工作原理 ：你在
.claude/settings.json中配置 hook，指定要监听的事件类型（PreToolUse,PostToolUse,UserPromptSubmit,SessionStart等）和对应的 shell 命令。当 Claude Code 生命周期中触发了该事件时，hook 命令就会被自动执行，命令可以：-
检查操作是否允许（如阻止对敏感文件的修改）
-
修改操作内容（如自动格式化代码）
-
将额外信息反馈给 Claude（通过退出码控制行为）
-
发送通知、记录日志等
-
Hook 的核心价值是自动化流程控制与安全护栏，能够在不依赖模型判断的前提下保障操作规范。
2. Command、Skill、Agent (Sub-agent) 与 Hook 详细对比
| 维度 | Command | Skill | Agent (Sub-agent) | Hook |
|---|---|---|---|---|
| 发起者 | 用户手动 输入 /命令名 触发 |
Claude 自动按上下文判断并加载 | 主 Claude 自动启动 | 事件驱动，由 Claude Code 生命周期事件自动触发 |
| 运行方式 | 直接将 Markdown 内容注入上下文 | 按需注入知识/流程到主上下文 | 独立新实例运行，结果返回主对话 | Shell 命令、HTTP 端点或 LLM 提示在后台执行 |
| 上下文关系 | 注入主上下文，占用主 token | 按需注入主上下文（渐进式披露） | 完全隔离，独立新上下文 | 后台进程执行，不占用对话上下文（但可通过回写干预对话） |
| 决策机制 | 确定性：手动触发后必然执行，但不触发就不会执行 | 概率性：由模型判断是否相关和何时加载，可能在判断上出现偏差或遗漏 | 确定性：Claude 启动后必然执行，按给定目标完成任务 | 确定性：事件触发时 shell 命令必然执行，不依赖模型判断 |
| 可执行操作 | 只能是"提示词文字"，Claude 根据文字自主决定后续动作 | 可包含具体指令 + 可执行脚本，Claude 按指引操作 | 拥有独立工具集，可执行任意允许的操作 | 直接执行 Shell 命令，可读写文件、调用外部程序、拦截/修改工具调用 |
| 典型场景 | 用户主动触发固定工作流（如 /review、/deploy） |
让 Claude 按特定规范或流程工作（如代码规范、API 调用、品牌指南） | 承担独立、复杂、可并行处理的子任务（如大规模分析、批量测试） | 自动化格式化、拦截危险命令、发送通知、强制遵守项目规则等 |
Hook 与Command、Skill、Sub-agent 不是竞争替代关系，而是并行协作的关系 。如果说 Command、Skill、Sub-agent 是在"如何让 Claude 更聪明、更专业"上发力（内容与能力扩展），那么 Hook 则在"如何让整个开发流程更自动、更可靠、更安全 "上提供新的维度------执行层保障。
3. 优缺点对比
| 机制 | 优点 | 缺点 |
|---|---|---|
| Command | • 极简：写一个 .md 文件即可 • 零额外 token 消耗 • 执行确定，无判断偏差 |
• 必须手动调用 ，无法自动激活 • 不能按上下文组合 • 注入的内容永久占用主上下文 |
| Skill | • 主动匹配 ：Claude 能自动判断并加载，无需用户提示 • Token 高效 ：渐进式披露，只加载需要的部分 • 可封装复杂流程和脚本 • 同时安装数十个 Skill 对无关任务无影响 | • 依赖模型判断准确性 ，可能漏激活或误激活 • 加载后的 Skill 保留在主上下文中，长对话时可能累积 • 需要预先设计和维护 |
| Sub-agent | • 任务完全隔离 ，大量中间调用不计入主对话上下文 • 支持并行执行 ，大幅提升效率 • 独立系统提示和工具集，可定制性极强 • 子任务失败不影响主会话 | • 启动/通信有一定开销（延迟 + token 成本） • 调试困难，中间过程不可见 • 编排复杂度高 • 需要为每个子任务定义清晰的目标和输出格式 |
| Hook | • 确定执行 ：事件触发时必然执行，不依赖模型判断 • 零 token 开销 ：Hook 命令不进入对话上下文 • 可用于拦截危险操作，构建安全护栏 • 可以在执行前后自动嵌入自动化流程 • 可响应多种生命周期事件 | • 需要 shell 脚本知识来编写 • 配置不当可能会不当阻断正常操作 • 难以调试 • 对 Hook 机制本身的安全性需保持警惕，恶意仓库可能植入有害命令 |
4. 互补关系与协作原理
四者并非功能"升级"或线性"进阶"关系，而是面向不同维度的互补机制：
| 维度 | Command | Skill | Sub-agent | Hook |
|---|---|---|---|---|
| 解决的问题 | "用户如何快捷触发高频操作？" | "Claude 如何自动获得专业能力？" | "复杂子任务如何隔离执行？" | "流程如何自动化、安全如何保障？" |
| 触发者 | 用户 | Claude（模型自动判断） | Claude（显式启动） | 事件（生命周期触发） |
| 运行位置 | 主对话上下文 | 主对话上下文（按需加载） | 独立新实例 | 后台进程 |
理想的协作模式 可以用"四层协同架构"来理解：
-
用户交互层（Command） ：为用户提供最简洁的操作入口，将复杂意图压缩为
/命令名。 -
能力注入层（Skill）：当 Claude 识别到需要特定知识和规范时，自动加载对应 Skill 来指导自己的思考和行为。
-
任务隔离层（Sub-agent）：当子任务需要独立执行（可能产生大量输出，或需要并行处理）时，主 Claude 启动 Sub-agent 来承担。
-
流程保障层（Hook）：在关键操作前后自动执行安全检查、格式校验、日志记录等，确保整个流程的可靠性和安全性。
四者合一的典型链路：用户输入 Command → Command 中指引 Claude 加载某些 Skill → Skill 指引 Claude 启动一个或多个 Sub-agent → Hook 在 Sub-agent 启动前、工具调用前、会话结束时等节点自动执行额外操作（记录、拦截或后续处理）。四个机制完全可以在同一个任务中协同工作，各司其职。
5. 综合协作实例
根据Command /github-auto-commit【自动提交】 和 Skill code-audit【审计代码】，现在，我们基于这个实际场景补充一个 Hook（auto-commit-linter） 和一个 Sub-agent（test-runner），展示四者如何协同完成一次"自动审计→并行测试→拦截错误提交→规范提交信息"的完整流程。
5.1 各组件职责
| 组件 | 类型 | 具体职责 |
|---|---|---|
/github-auto-commit |
Command | 用户一键入口，定义完整流程："先审计 → 再测试 → 后提交，审核信息规范后推送" |
code-audit |
Skill | 规范审计：定义代码质量检查标准（复杂度、覆盖率、未使用变量等）供 Claude 执行 |
test-runner |
Sub-agent | 隔离运行单元测试 + 集成测试，返回结果摘要 + 失败用例列表（并行执行多个测试套件） |
auto-commit-linter |
Hook | 在 UserPromptSubmit（用户提交提示词前）拦截提交信息并自动校验格式，不符合规范则弹出提醒或修正 |
5.2 完整协作流程
text
[用户] 输入 /github-auto-commit
│
▼
┌─────────────────────────────────────────────────────────────────┐
│ Command: /github-auto-commit │
│ 内容（Markdown）: │
│ “请按以下步骤执行： │
│ 1. 加载 code-audit Skill，对暂存区代码执行完整审计 │
│ 2. 启动 test-runner Sub-agent，在隔离环境并行运行全部测试 │
│ 3. 若前两步均通过，生成规范 commit message │
│ 4. 用户确认后执行 git commit，Hook 自动校验信息格式 │
│ 5. 校验通过后 git push” │
└─────────────────────────────────────────────────────────────────┘
│
├── 步骤1：Claude 自动加载 code-audit Skill
│ • Skill 提供审计标准（复杂度阈值、未覆盖代码检查、依赖漏洞扫描等）
│ • Claude 执行审计，发现问题时输出修正建议，阻塞后续流程
│ • 审计通过后进入步骤2
│
├── 步骤2：主 Claude 启动 test-runner Sub-agent
│ • Sub-agent 在独立新上下文中运行
│ • 并行执行多个测试套件（单元测试 + 集成测试 + e2e 测试）
│ • 返回：“通过: 243，失败: 3，失败用例: login.spec.js, api/auth.test.js, utils/format.test.js”
│ • Sub-agent 销毁，主 Claude 收到结果
│
├── 步骤3：审计+测试均通过 → 生成 commit message
│ • Claude 基于暂存区变更和审计 Skill 的输出生成初步信息
│ • 展示给用户确认
│
├── 步骤4：Hook 在 UserPromptSubmit 事件触发前自动拦截并校验
│ • auto-commit-linter Hook 运行校验脚本
│ • 脚本检查 commit message 是否符合 Conventional Commits 规范（feat: / fix: / docs: / chore: ...）
│ • 不符合规范 → Hook 返回错误信息，Claude 收到提示并引导用户修正
│ • 校验通过 → 允许提交
│
└── 步骤5：校验通过 → git push 推送到远程仓库5.3 Hook 配置示例（.claude/settings.json）
javascript
json
{
"hooks": {
"UserPromptSubmit": [
{
"matcher": "git commit",
"command": "./hooks/auto-commit-linter.sh"
}
]
}
}hooks/auto-commit-linter.sh 脚本示例：
bash
bash
#!/usr/bin/env bash
# .claude/hooks/auto-commit-linter.sh
# 功能：校验 commit message 是否符合 Conventional Commits 规范
# 从 Claude 的用户输入中提取 commit message
MESSAGE=$(echo "$CLAUDE_INPUT" | grep -E "^git commit -m" | sed "s/^git commit -m '//" | sed "s/'$//")
# 规范正则：<type>(<scope>): <subject>
if [[ ! "$MESSAGE" =~ ^(feat|fix|docs|style|refactor|perf|test|chore)(\([a-z]+\))?: ]]; then
echo "❌ Commit 被 Hook 拦截：提交信息不符合 Conventional Commits 规范" >&2
echo "请使用格式：<type>(<scope>): <subject>，例如 'feat(auth): add login validation'" >&2
exit 2 # 退出码 2 表示拦截，Claude 会收到此错误信息
fi
echo "✅ Commit message 格式校验通过"
exit 0✅5.4 为什么这样组合比单一方案更优？
| 只用 Command | 只用 Skill | 只用 Sub-agent | 只用 Hook | 四者协作 |
|---|---|---|---|---|
命令内容会非常长（审计+测试+提交+校验全挤在一个 .md 文件里），难以维护 |
每次都要手动触发，无法一键化完成全流程 | 需要手动管理子任务，缺少自动加载的知识支持 | 只能做自动化控制，无法做复杂判断和多步骤决策 | ✅ 用户只需 /github-auto-commit，其他全部自动完成 |
| 测试的大量日志充斥主对话，干扰后续沟通 | 测试仍在主对话执行，日志依然污染 | 没有审计 Skill，代码质量问题可能遗漏 | 没有知识注入，Hook 无法独立判断代码质量 | ✅ Skill 提供专业审计；Agent 隔离测试污染；Hook 保障规范 |
| 提交信息需要手动记忆格式规范 | 用户可能忘记规范要求 | 提交前缺少强制校验 | Hook 可以校验，但无法替代审计+测试 | ✅ 四环相扣：知识支持 → 任务隔离 → 流程保障 → 一键入口 |
6. 总结
| 机制 | 一句话总结 | 决策原则 |
|---|---|---|
| Command | 用户主动触发的"快捷指令"，压缩重复操作 | 你希望自己主动调用的操作 |
| Skill | Claude 自动加载的"知识包和工作流"，按需注入 | 你想让 Claude 获得专业知识或规范，且希望它自动判断何时使用 |
| Sub-agent | 独立运行的"特派专员"，任务完全隔离 | 子任务复杂、可能产生大量输出，需要隔离或并行执行 |
| Hook | 事件自动触发的"流程保障"，确定性执行 | 需要在操作前后自动执行 Shell 脚本，构建安全护栏或自动化流程 |
这四个概念不是阶梯式进阶关系，而是并行互补的四个协作维度。在真实项目中，它们完全可以------也应该------被组合使用，让 Claude 既聪明（Skill），又强大（Agent），又方便（Command），又可靠（Hook）。