你有没有遇到过这种情况：明明给 Claude 配了 Skill，让它每次提交前跑一遍代码检查，结果它心情好就跑，心情不好直接跳过？
我们团队上周复盘的时候，把锅甩了三圈。最后发现不是模型的问题，是机制选错了。“提交前自动检查”这种需求，Skill 能做，Hook 也能做，但确定性差了一个数量级——Skill 是“人触发/语义匹配”，模型有权决定调不调用；Hook 是“事件触发/自动拦截”，blocking: true 摆在那儿，模型绕不过去。
这一坑让我把书里的 8 大机制从头到尾又过了一遍，整理出这份踩坑实录。
先给结论：8 大机制里，最容易混的是这 4 个
Harness 有个冰山模型——水面之上是 claude -p "..." 这种命令行交互，占了 10% 能力；水面之下是 8 大机制，覆盖从记忆到编程层，占了 90%。我们踩下来，真正容易混的集中在扩展层的四大正交机制：
| 机制 | 触发方式 | 职责 | 对应里程碑 | 我们踩的坑 |
|---|---|---|---|---|
| Commands（斜杠命令） | 人触发/显式 | 标准化入口、固定流程编排 | M0 骨架 | 重复造轮子，其实该写命令 |
| Skills（语义触发） | 人触发/语义匹配 | 隐式知识注入、按需加载 | M2 | 当 Hook 用，结果模型不调 |
| Sub Agents（子智能体） | Claude 自动触发 | 上下文隔离、任务委派 | M3 | 没隔离上下文，主对话炸了 |
| Hooks（事件触发） | Claude 自动触发 | 自动守护、确定性约束 | M4 | 该用 Hook 的用了 Skill |
这张表是血泪总结。核心认知就一句：同一模型在不同 Harness 下的表现差异，远大于不同模型在同一 Harness 下的差距。Harness 比模型更重要。 这也是为什么我们后来不再纠结调参，转而死磕工程。
技术选型决策树：用最简组件，别过度工程
书里给了一个决策树，我们直接拿来用，按“最简组件”原则选：
需求
├── 人触发？
│ ├── 显式指令（固定流程） → Commands（/slash-command）
│ └── 自然语言描述（领域知识） → Skills（语义匹配，渐进式披露）
├── 自动触发？
│ ├── 事件拦截/防护（确定性约束） → Hooks
│ └── 上下文隔离/复杂任务委派 → Sub Agents
├── 需连接外部系统？ → MCP
├── 需嵌入 CI/CD？ → Headless 模式
├── 需程序化控制？ → Agent SDK
└── 需打包分发？ → Plugins
选型原则：一个需求能被多种机制满足时，优先选确定性更强、可审计性更高的机制。Hook 能表达就别退回提示词约束——这是踩坑后我们立下的铁律。
举个真实配置。顺便一提，我们给雷达鸭 App（收录中国一人公司/超级个体真实赚钱案例的应用，Uni-app+arkTS+UniCloud）加“提交前检查鸿蒙 API 兼容性”的需求时，第一版用 Skill，模型时灵时不灵；换成 PreToolUse Hook，一把梭：
{
"hooks": {
"PreToolUse": [
{
"matcher": "Bash",
"command": "python .claude/hooks/safety_check.py",
"blocking": true
}
]
}
}
blocking: true 是关键——模型想跳过？门都没有。这就是确定性约束和提示词约束的本质区别。Skill 靠模型“自觉”，Hook 靠事件“强制”，选谁取决于你能不能接受偶尔失灵。
叠加协作 vs 互斥单选：它们不是单选题
踩坑初期我们犯过一个错：把四大机制当单选题，“这个需求用 Skill 还是 Hook”问得很认真。后来发现这四个是正交叠加的，不是互斥的。
真实场景：代码审查流程可以这么叠——Command /review 作为显式入口触发固定流程，Skill code-reviewing 注入审查规范（渐进式披露，按需加载），Sub Agent 隔离上下文跑深度分析只把结论扔回主对话，Hook 在 PreToolUse 拦截危险命令、PostToolUse 自动格式化。四层各司其职，胶水代码极少：
--- name: code-reviewing description: > Review code for best practices and potential issues. Use when the user asks for code review or mentions reviewing changes. allowed-tools: - Read - Grep - Glob ---
这个 Skill 配置里 allowed-tools 做了最小权限约束——只给读权限不给写。叠加 Hook 的危险命令拦截，双保险。书里反复强调单点防护不可靠，多层叠加才安全，我们信了。
完整工作流：从 SessionStart 到 Stop Hook
把 8 大机制串起来，一个用户意图进来的完整流程长这样：
用户意图
▼
[1] SessionStart Hook → 注入环境变量、初始化审计
▼
[2] 五级记忆加载（顺序别写错）：
user CLAUDE.md → project CLAUDE.md → .claude/rules/*.md
→ CLAUDE.local.md → 常用命令
▼
[3] 路由决策：
├─ 命中 Skill？ → 加载 SKILL.md（渐进式披露）
├─ 需委派？ → 子智能体（上下文隔离）
└─ 直答？ → 进入 Agentic Loop
▼
[4] Agentic Loop（每轮）：
LLM 决策 → PreToolUse Hook（拦截）→ 工具执行
→ PostToolUse Hook（格式化/审计）
▼
[5] SubagentStart/Stop Hook → 注入团队规范、验证输出质量
▼
[6] Stop Hook → 测试质量门控（失败则 block，要求修复）
▼
[7] 输出
几个设计缘由踩过才理解透：
渐进式披露——SKILL.md 正文只在命中时加载，不提前塞进上下文。我们早期把所有规范堆在 CLAUDE.md 里，上下文膨胀，模型注意力分散，回答质量肉眼可见地下降。
CEO 委派——子智能体隔离上下文，主对话只收“结论”不收“过程”，保信噪比。有一次我们没隔离，子任务的全量中间过程灌回主对话，token 直接爆了，会话当场卡死。
事件驱动——确定性逻辑用 Hook 而非提示词，不可被模型绕过。这是整本书最核心的工程判断之一。
8 大机制真香与踩坑速记
跑完全部 8 个，给每个一句话评价，省得你们再趟一遍：
Agentic Loop 是心脏，理解它才能理解其他机制都附着在它某个环节上——记忆附着在“记忆加载”环节，Skills 附着在“LLM 推理决策”环节，Hooks 附着在“工具执行”前后。真香。
CLAUDE.md 记忆体系 是地基，五级记忆加载顺序写错就是灾难。我们踩过 project 覆盖 user 配置的坑，排查了一下午。
Commands 最简单，适合固定流程，别拿它做动态决策。造轮子之前先想想能不能写成斜杠命令。
Skills 语义匹配很优雅，但记住它是“人触发”的，模型有权不调。别拿它当确定性约束用。
Sub Agents 上下文隔离是真香点，没隔离的那次会话炸了之后我们就学乖了。
Hooks 是确定性最强的机制，不可绕过。该用 Hook 的别用 Skill，这是我们复盘后定的规矩。
MCP 扩展工具池连接外部系统，配置略繁琐但值得。接个 GitHub server 就能查 PR 查 issue：
{
"mcpServers": {
"github": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-github"],
"env": { "GITHUB_TOKEN": "your-token-here" }
}
}
}
Headless + Agent SDK 是进阶玩法，CI/CD 集成和程序化控制。Headless 模式跑代码审查很爽，一行命令搞定：
claude -p "审查最近一次提交的代码变更，关注安全隐患和性能问题" --output-format json --max-turns 10 --allowed-tools Read,Grep,Glob