六层扩展架构
Claude Code 的扩展体系可以从”始终加载”到”完全外部”排列：
┌─────────────────────────────────────────────┐
│ CLAUDE.md 始终加载的上下文（每次会话） │
├─────────────────────────────────────────────┤
│ Skill 按需加载的知识和工作流 │
├─────────────────────────────────────────────┤
│ SubAgent 独立上下文的隔离执行者 │
├─────────────────────────────────────────────┤
│ Agent Teams 跨会话的多代理协作 │
├─────────────────────────────────────────────┤
│ MCP 连接外部服务的协议 │
├─────────────────────────────────────────────┤
│ Hook 在循环外部运行的确定性脚本 │
└─────────────────────────────────────────────┘
Plugin = 上述所有的打包和分发单元软件工程类比
如果把 Agent 比作一个 Web 应用：
| Agent 概念 | 软件工程类比 |
|---|---|
| CLAUDE.md | 项目配置文件（.editorconfig / tsconfig.json） |
| Skill | npm 包 / Python 模块（按需导入的功能模块） |
| SubAgent | Worker Thread / 子进程（独立执行的后台任务） |
| MCP | REST API Client / SDK（连接外部服务） |
| Hook | Express Middleware / Git Hook（生命周期回调） |
| Plugin | npm package（第三方插件包） |
何时用什么？决策表
| 我想… | 用什么 |
|---|---|
| 让 Claude 始终遵守某个规则 | CLAUDE.md |
| 给 Claude 一套可复用的参考文档 | Skill（参考型） |
| 让 Claude 执行一个可重复的工作流 | Skill（任务型，/deploy） |
| 隔离一个大量读取文件的任务 | SubAgent |
| 让多个 Agent 并行工作并互相沟通 | Agent Teams |
| 让 Claude 查询数据库或发 Slack | MCP Server |
| 每次编辑文件后自动跑 lint | Hook |
| 把上述所有打包分享给团队 | Plugin |
上下文成本对比
这是你做架构决策时最需要关注的：
| 特性 | 加载时机 | 上下文成本 |
|---|---|---|
| CLAUDE.md | 会话开始 | 每次请求都在（高） |
| Skill 描述 | 会话开始 | 每次请求都在（低） |
| Skill 全文 | 被调用时 | 仅在使用时 |
| MCP 工具定义 | 会话开始 | 每次请求都在（可能很高） |
| SubAgent | 被创建时 | 与主会话隔离（零） |
| Hook | 触发时 | 外部运行（零） |
关键洞察：SubAgent 和 Hook 是最”便宜”的扩展，因为它们不占主会话的上下文。MCP 可能是最”贵”的，因为所有工具定义都在每次请求中。
容易混淆的特性对比
CLAUDE.md vs Skill vs Rules
| CLAUDE.md | .claude/rules/ | Skill | |
|---|---|---|---|
| 加载 | 每次会话 | 每次会话或匹配文件时 | 按需 |
| 作用域 | 整个项目 | 可按文件路径限定 | 特定任务 |
| 适用 | 核心规范 | 语言/目录特定规则 | 参考文档、可重复工作流 |
Skill vs SubAgent
- Skill = 可复用的内容（知识或指令），加载到当前上下文
- SubAgent = 独立的执行者，有自己的上下文
它们可以组合：SubAgent 可以预加载 Skill（skills: 字段）。
SubAgent vs Agent Teams
- SubAgent = 在你的会话内运行，结果回传
- Agent Teams = 独立的 Claude Code 会话，互相通信
类比：SubAgent 像是在主线程中开的子任务，Agent Teams 像是多个独立进程通过 IPC 通信。
知识检测
概念理解题
-
为什么 Hook 被描述为在 Agentic Loop “外部”运行？它和 Skill 的根本区别是什么？
-
MCP 的上下文成本为什么可能很高？
/mcp命令的作用是什么？ -
Plugin 被称为”打包层”——它自身不提供新能力，而是把其他特性打包。这个设计有什么好处？
应用题
-
你要给团队搭建一个 Claude Code 环境，需求是：(a) 所有人遵守代码规范 (b) 每次编辑后自动格式化 (c) 能查询 Jira 工单 (d) 有一个部署流程。你会用哪些扩展机制？
-
你的 CLAUDE.md 已经 300 行了，Claude 开始忽略其中一些规则。你会怎么重构？
迁移思考题
- OpenClaw 的 Skill 和 Claude Code 的 Skill 格式相同（都是 SKILL.md）。但 OpenClaw 没有
.claude/rules/机制。如果 OpenClaw 要实现类似的功能，你觉得应该怎么设计？
参见
- 04-Skill-技能系统、05-Hook-生命周期钩子、06-MCP-外部工具连接、07-SubAgent-子代理系统 — 各扩展机制的详细讲解
- SlipBox 相关：Skill、Hook、MCP、Agent
参考答案
1. Hook 为什么在 Loop”外部”
Hook 是确定性脚本——不经过 LLM 推理，不受模型”情绪”影响。和 Skill 的根本区别：Skill 的内容被注入上下文由 LLM”理解和执行”（概率性），Hook 由系统直接执行（确定性）。保证 100% 执行率的事情（lint、安全门控）应该用 Hook。
2. MCP 上下文成本高的原因
每个 MCP Server 注册的所有工具定义（函数名 + 参数 Schema + 描述）都在每次请求中发送给模型。一个 Server 可能有 10+ 工具，每个 Schema 几百 token。连接 3-4 个 Server 轻松占 5-10% 上下文。/mcp 命令看每个 Server 的 token 开销。
3. Plugin 作为”打包层”的好处
(1) 复用：同一套配置多项目安装 (2) 版本管理：通过 marketplace 分发更新 (3) 命名空间隔离：/plugin-name:skill 避免冲突 (4) 原子性：安装一个 Plugin 获得完整 Skill + Hook + MCP 配置。
4. 团队环境配置
(a) 代码规范 → CLAUDE.md 或 .claude/rules/ (b) 编辑后自动格式化 → Hook（PostToolUse + prettier） (c) 查询 Jira → MCP Server (d) 部署流程 → Skill（/deploy，disable-model-invocation: true）。打成一个 Plugin 分发给团队更好。
5. CLAUDE.md 300 行的重构
核心规则留 CLAUDE.md（< 100 行）→ 语言特定规则迁移到 .claude/rules/（带 paths 条件）→ 参考文档迁移到 Skill（按需加载）→ 需要强制的规则改为 Hook → 详细文档用 @path 导入。
6. OpenClaw 的 Rules 等价设计
利用 OpenClaw 的 before_prompt_build Plugin Hook，在 Prompt 组装前根据当前文件路径/上下文动态注入匹配的规则内容到 prependContext。或者在 agent:bootstrap Internal Hook 中动态选择注入哪些 Bootstrap 文件。