子 Agent：什么时候该拆，什么时候别拆

Claude Code 里有个 Agent tool，能在对话中启动独立的子 Agent 去做事。子 Agent 有自己的上下文，做完把结果返回给主 Agent。

听起来很强大，但实际用下来，大部分情况你不需要它。这篇讲清楚：什么时候拆子 Agent 真的有用，什么时候纯属添乱。

子 Agent 的机制

你在 CLAUDE.md 或 slash command 里不能直接调用 Agent tool——它是 Claude Code 自己决定是否使用的内部工具。但你可以通过提示词影响它的决策。

子 Agent 的工作方式：

1. 主 Agent 启动一个子 Agent，给它一段 prompt
2. 子 Agent 在独立上下文中执行，能用大部分工具（读文件、搜索、跑命令等）
3. 子 Agent 完成后，把结果以一条消息返回给主 Agent
4. 主 Agent 拿到结果继续工作

关键特性：
- 独立上下文：子 Agent 看不到主对话历史，只能看到启动时给它的 prompt
- 结果压缩：无论子 Agent 内部读了多少文件、跑了多少命令，返回给主 Agent 的只是一段总结
- 可以并行：多个子 Agent 可以同时启动，并行执行

该用子 Agent 的三个场景

1. 并行搜索和调研

最典型的场景。你让 Claude Code 调查一个问题，需要同时查多个方向。

比如你问："这个项目的认证机制是怎么实现的？"

不拆 Agent 的话，Claude Code 会顺序执行：读 auth controller → 读 middleware → 读 routes → 读 model → 读 config……一步一步来，慢。

拆成子 Agent：

同时启动 3 个子 Agent：
- Agent 1：查 controller 和 middleware 层的认证逻辑
- Agent 2：查 model 层的用户和 session 设计
- Agent 3：查配置文件和环境变量中的认证相关设置

三个方向同时跑，结果汇总。你在 CLAUDE.md 里可以这样引导：

## 调研类任务
当需要调查跨多个模块的问题时，优先并行启动多个子 Agent 分头调研，
最后汇总结论。

2. 保护主上下文

Claude Code 的上下文窗口是有限的。如果一个子任务需要读大量文件但最终只需要一个结论，用子 Agent 可以把"过程垃圾"挡在主上下文之外。

典型例子：

• 在 50 个文件里找某个 API 被调用的所有位置，统计调用模式
• 分析一个大型配置文件，只需要提取几个关键值
• 审查一组测试文件，判断测试覆盖率够不够

这些任务的特点是输入大、输出小。子 Agent 内部消化掉大量信息，只把精华返回。

3. 隔离风险操作

有些任务你不确定会不会搞砸。用子 Agent 加 isolation: "worktree" 参数，它会在一个独立的 git worktree 里工作。改坏了也不影响你当前的工作目录。

## 高风险重构
对于大范围重构任务，使用带 worktree 隔离的子 Agent。
确认结果正确后再合并。

适合的场景：
- 尝试性重构：不确定某个方案行不行，让子 Agent 先试
- 并行方案对比：同时用两种方式实现，比较结果
- 代码生成：生成大量样板代码，review 后再合入

不该用子 Agent 的情况

简单直接的任务

"把这个函数名从 camelCase 改成 snake_case" — 这种直接改就行了。启动子 Agent 的开销（构建上下文、等待返回、解析结果）反而比直接做更慢。

判断标准：如果一个 Grep + 一个 Edit 就能搞定，别拆 Agent。

有强依赖的顺序任务

"先读配置 → 根据配置改代码 → 根据改动更新测试"

这种链式依赖的任务，每一步都依赖上一步的结果。拆成子 Agent 的话，你得把中间结果在 prompt 里传来传去，既麻烦又容易丢信息。顺序执行就好。

需要精确控制的修改

子 Agent 返回的是一段总结文字，不是结构化数据。如果你需要子 Agent 做精确修改（比如在第 47 行插入特定代码），直接让主 Agent 做更可靠。

子 Agent 适合"调研后给结论"，不适合"精确执行修改"。

上下文还很充裕的时候

如果你的对话刚开始，上下文窗口还很空，没必要为了"保护上下文"而拆 Agent。等到对话变长、主 Agent 开始压缩历史消息时，再考虑用子 Agent 做重活。

实际效果对比

以一个真实场景为例：调查一个 Rails 项目里所有用到 before_action 的 controller，分析认证和授权的实现模式。

不用子 Agent：

Claude Code 会逐个读取 controller 文件，每读一个都占用主上下文。如果有 20 个 controller，光是文件内容就可能吃掉大量 token。最后给你分析结论时，前面读的细节可能已经被压缩丢失了。

用子 Agent：

启动子 Agent："阅读 app/controllers/ 下所有 controller，
找出所有 before_action 回调，分析认证和授权模式，
给出分类总结。"

子 Agent 在自己的上下文里读完所有文件，返回一份干净的总结。主 Agent 的上下文几乎没有消耗，拿到结论就能继续推进。

在 CLAUDE.md 中引导子 Agent 的使用

你不能强制 Claude Code 用或不用子 Agent，但可以通过 CLAUDE.md 给出偏好：

## Agent 使用偏好

### 适合拆子 Agent 的任务
- 跨模块调研（同时查 3 个以上目录）
- 大范围代码搜索和统计
- 探索性重构（用 worktree 隔离）

### 不要拆子 Agent 的任务
- 单文件修改
- 顺序依赖的多步操作
- 已经明确知道改哪里的 bug fix

一句话判断法

这个任务的"过程"比"结论"大很多吗？

如果是 — 用子 Agent，让它消化过程、只返回结论。
如果不是 — 直接做，别加中间层。

子 Agent 不是越多越好。它是一个上下文管理工具，不是并发编程框架。用对了能让 Claude Code 在大项目里保持清醒，用错了只是在浪费启动时间。