理解 Claude Code 的扩展机制，本质上是在回答一个问题：如何让 AI 助手在项目中表现得像一个“老员工”——既懂规矩，又有工具，还不乱花时间。这套机制一共分七类，每类各有其明确的定位、加载时机和上下文成本，下面这张表可以让你一眼看明白：
类型 | 定位 | 加载时机 | 上下文成本 |
|---|---|---|---|
CLAUDE.md | 项目"宪法" | 每次会话自动 | 高（每个请求都带） |
Skills | 技能卡片 | 按需加载 | 低（描述常驻） |
子 Agent | 子 Agent | 任务时生成 | 零（与主会话隔离） |
Agent Teams | 多智能体网络 | 独立实例 | 高（每个 Agent 独立） |
MCP | 外部连接器 | 会话开始 | 中（工具定义） |
Hooks | 事件脚本 | 触发时 | 零（不占上下文） |
Plugins | 打包分发 | 安装时 | 取决于内容 |
有一个核心原则值得记住：把"始终需要"的东西放进 CLAUDE.md，把"偶尔需要"的整理成 Skills，把"大段分析"交给子 Agent。 这能帮你从一开始就避开上下文膨胀的坑。
一、扩展机制全景图
理解这些机制，关键要看它们在整个 Agent 工作循环（Agent Loop）中插在哪里。
Agent Loop 扩展机制插入点
不同阶段插入了不同的机制：
阶段 | 插入机制 | 作用 |
|---|---|---|
Claude 推理前 | CLAUDE.md、Skills、子 Agent | 注入上下文和知识 |
工具调用前 | Hooks (PreToolUse) | 拦截、验证、记录 |
执行结果后 | Hooks (PostToolUse)、MCP | 后处理、触发外部动作 |
如果按加载时机来划分，它们也各不相同：
加载时机 | 机制 | 特点 |
|---|---|---|
会话开始 | CLAUDE.md、MCP | 自动加载，常驻上下文 |
按需调用 | Skills、子 Agent | 手动或智能匹配 |
事件触发 | Hooks | 响应特定事件 |
安装时 | Plugins | 打包复用 |
二、CLAUDE.md：项目的宪法
它的定位很明确：每个会话自动加载的持久上下文，用来存放项目核心约定。说白了，就是给 Claude 一份“项目说明书”，让他一进来就懂规矩。
那么，它和 Memory 有什么区别？
维度 | CLAUDE.md | Memory |
|---|---|---|
位置 | 项目根目录 | 用户目录 |
作用域 | 团队共享 | 个人偏好 |
版本控制 | 提交到 Git | 不提交 |
内容 | 技术规范、架构 | 用户偏好、决策 |
在加载机制上，Claude 会从工作目录向上遍历，收集所有层级的 CLAUDE.md。子目录的文件在访问该目录时会动态加载。
目录结构示例：
/project/CLAUDE.md — 项目级约定 /project/frontend/CLAUDE.md — 前端特定约定 /project/backend/CLAUDE.md — 后端特定约定
要注意，这个文件是有上下文成本的。一个 200 行的 CLAUDE.md，会在每个请求中都跟着走一遍，持续消耗 token。所以最佳实践是保持精简，控制在 200 行以内。
一个典型的 CLAUDE.md 可以这样写：
技术栈：Next.js 14 + TypeScript + Prisma + PostgreSQL 目录结构： - /app — 页面和 API 路由 - /components — UI 组件 - /lib — 工具函数 - /prisma — 数据库 schema 编码规范： - 使用命名导出，不用默认导出 - 组件用函数组件 + hooks - API 路由必须有错误处理 禁止： - 不要修改 /lib/auth.ts - 不要在组件里直接 fetch 测试：npm test / npm run test:e2e
内容膨胀时也别硬扛。可以把参考性文档迁移到 Skills，或者拆分到 .claude/rules/ 目录。
三、Skills：可复用的知识库
Skills 像是 Claude 工具包里的“技能卡片”。它有两种形态：
类型 | 示例 | 触发方式 |
|---|---|---|
参考型 | API 风格指南、数据库 Schema | Claude 自动匹配 |
操作型 | /deploy、/audit | 手动执行 |
配置方式很简单，目录结构一般是：
~/.claude/skills/ └── code-review/ ├── SKILL.md └── references/ └── checklist.md
来看一个 SKILL.md 示例：
--- name: code-review description: Review code for security and performance allowed-tools: Read, Bash context: fork --- 审查代码变更，重点关注安全性和性能。 流程： 1. 获取 diff：git diff 2. 逐文件审查 3. 输出审查报告 参考资料：参见 checklist.md
有两个关键配置值得一提： - disable-model-invocation: true — 设置后 Claude 不会自动调用，只能手动通过 /code-review 触发。 - context: fork — 让技能在隔离上下文中执行，避免污染主会话。
与 CLAUDE.md 的区别在于：
维度 | CLAUDE.md | Skill |
|---|---|---|
加载时机 | 每次会话自动 | 按需加载 |
内容性质 | "始终遵循 X" | "有时参考 X" |
可触发工作流 | ❌ | ✅ |
四、子 Agent：上下文隔离的专项工作者
子 Agent 在主会话内运行，最适合那种“读多写少”的密集型任务。它的核心价值在于上下文隔离。
想象一下这个架构：
主会话 (200K token) ├── 用户对话 ├── CLAUDE.md └── 子 Agent 返回的摘要 (2K token)
子 Agent (独立上下文) ├── 读取 50 个文件 ├── 分析过程 └── 生成摘要返回给主会话
子 Agent 可以读取数十个文件做深度分析，但主会话只收到一个精简的摘要。这就好比让你的得力助手去翻档案室，回来只跟你汇报结论。
典型场景包括： - 代码审查：一个子 Agent 检查安全性，另一个检查性能 - 代码库研究：遍历整个项目，返回关键发现 - 假设验证：独立验证技术方案可行性
那么，它和 Agent Teams 有什么区别？
特性 | 子 Agent | Agent Team |
|---|---|---|
上下文 | 依附主会话 | 完全独立 |
通信 | 单向汇报 | 队友间直接消息 |
协调 | 主 Agent 管理 | 自我协调 |
成本 | 低 | 高（每个 Agent 独立实例） |
什么时候该升级到 Agent Teams？当子 Agent 需要相互通信、多轮讨论、共享状态的时候。
五、Agent Teams：多智能体协作网络
Agent Teams 是完全独立的 Claude Code 会话，支持点对点通信和自主协调。
适用场景包括： - 并行代码审查（安全、性能、风格同时审查后交叉验证） - 多模块开发（不同 Agent 负责不同模块） - 复杂研究（需要多轮讨论和观点碰撞）
配置方式是在 Agent 的 frontmatter 中定义：
agents: security-reviewer: skills: [security-guidelines, owasp-checklist] context: fork performance-reviewer: skills: [performance-patterns, profiling-guide] context: fork
但这里有一个成本警告：每个 Agent Team 成员都是独立实例，成本累加。所以，只在确实需要并行独立工作时使用。
六、MCP：外部世界的连接器
MCP（Model Context Protocol）是一种标准化协议，用来将 Claude 连接到数据库、Slack、浏览器等外部服务。
它和 Skills 之间有天然的协同： - MCP 提供“能力”：数据库连接、API 调用、浏览器控制 - Skill 提供“知识”：Schema 文档、查询模式、消息格式
用户说一句“分析销售趋势”，Claude 就知道查哪张表。
配置示例（~/.claude/settings.json）：
{ "mcpServers": { "postgres": { "command": "uvx", "args": ["mcp-server-postgres", "postgresql://localhost/mydb"] }, "bra ve-search": { "command": "npx", "args": ["-y", "@modelcontextprotocol/server-bra ve-search"], "env": { "BRA VE_API_KEY": "your-key" } } } }
加 MCP 之前，建议做一个安全检查： - GitHub stars > 50 - 最近 30 天有提交 - 没有 --dangerous-* 标志 - 版本要锁定（别用 latest） - 验证 npm 包哈希
另外，不要一上来就配 MCP。推荐的顺序是：CLAUDE.md → Skills → Hooks → 有明确需求时才加 MCP。
七、Hooks：事件驱动的自动化
Hooks 是在循环外运行的确定性脚本，响应特定生命周期事件。它的核心优势是零上下文成本——作为外部脚本运行，默认不占用 Claude 的上下文。
触发时机有以下几个：
事件 | 触发时机 |
|---|---|
PreToolUse | Claude 调用工具前 |
PostToolUse | Claude 调用工具后 |
Notification | 通知事件 |
Stop | 任务完成时 |
典型用例包括：
自动格式化： { "hooks": { "PostToolUse": [{ "matcher": "Write", "hooks": [{ "type": "command", "command": "prettier --write "$CLAUDE_FILE_PATH" 2>/dev/null || true" }] }] } }
危险命令拦截： { "hooks": { "PreToolUse": [{ "matcher": "Bash", "hooks": [{ "type": "command", "command": "if echo "$CLAUDE_TOOL_INPUT" | grep -qE 'rm -rf|DROP'; then echo 'Blocked'; exit 1; fi" }] }] } }
Slack 通知： { "hooks": { "PostToolUse": [{ "matcher": "Write", "hooks": [{ "type": "command", "command": "curl -X POST -d '{"text":"File updated: ..."}' ..." }] }] } }
八、功能组合模式
单个机制好用，组合起来才是真功夫。以下是几种常见的组合模式：
模式 1：Skill + MCP MCP 提供数据库连接，Skill 提供数据模型文档和查询模板。用户说“分析销售趋势”，Claude 就知道查哪张表。
模式 2：Skill + 子 Agent Skill 定义审查流程，子 Agent A 检查安全性，子 Agent B 检查性能，子 Agent C 检查代码风格，主会话汇总报告。
模式 3：CLAUDE.md + Skills CLAUDE.md 里写“遵循 API 约定”，Skill 里放完整的 RESTful 设计规范。
模式 4：Hook + MCP Hook 监听文件保存，MCP 发送 Slack 通知，团队实时收到变更提醒。
九、上下文成本管理
不同机制的上下文开销差异很大，需要心里有数：
机制 | 加载时机 | 成本 | 优化策略 |
|---|---|---|---|
CLAUDE.md | 会话开始 | 每次请求都带 | 保持精简，拆分到 Rules |
Skills | 按需 | 描述常驻 | disable-model-invocation: true |
MCP | 会话开始 | 工具定义 | 工具延迟加载 |
子 Agent | 任务时 | 与主会话隔离 | 天然隔离 |
Hooks | 触发时 | 零 | 控制返回内容 |
优化建议也很直接： 1. CLAUDE.md 精简到 200 行以内，参考文档放 Skills 2. 大型 Skills 文档设置 disable-model-invocation: true 3. 大段分析任务用子 Agent 隔离开 4. MCP 只在有明确需求时才添加
十、决策树
最后，当你面对一个问题时，可以用这棵决策树来选工具：
需要持久化到每个会话？ ├── 是 → CLAUDE.md 或 .claude/rules/ │ └── 针对特定目录？ │ ├── 是 → .claude/rules/ + paths │ └── 否 → CLAUDE.md └── 否 → 需要连接外部服务？ ├── 是 → MCP └── 否 → 需要并行/隔离执行？ ├── 是 → 需要通信？ │ ├── 是 → Agent Teams │ └── 否 → 子 Agent └── 否 → Skills 需要事件自动化？ → Hooks 需要跨项目复用？ → Plugins
