子代理与并行执行
大约 4 分钟
子代理与并行执行
为什么需要子代理
主 agent 的上下文是「一车道」，三个痛点：
1. 上下文挤爆：扫 50 个文件找 bug，读完主上下文也满了
2. 无法并行：单循环只能串行干活
3. 任务污染：探索性搜索产生大量垃圾中间结果，
干扰主任务的推理质量
解法：把子任务扔给「独立上下文」的 subagent，
只把结论带回主线。
子代理的本质
┌─────────────────────────────────────────┐
│ 主 Agent（主上下文） │
│ 任务：修复登录 bug │
│ │
│ Task("在 50 个文件中找到 auth 相关实现") │──┐
│ │ │ 只带回结论：
│ （继续做自己的事/等待） │ │ "auth 逻辑在
│ │ │ src/auth/token.ts:42"
│ ◀──────────────────────────────────────┼──┘
└─────────────────────────────────────────┘
│ 新开一个完整上下文
▼
Subagent：自己的循环、自己的工具、
可能不同的模型/系统提示/权限
（扫了 50 个文件 = 消耗了它自己的 100k 上下文，
这些 token 从未污染主上下文）
关键认知：
- 子代理有独立完整的 agentic loop（它自己就是个小 harness）
- 子代理的最终输出作为工具结果返回主 agent
- 子代理的中间过程（读了哪些文件、试了什么）对主 agent 不可见——这正是价值所在
子代理的类型
| 类型 | 定义位置 | 特点 |
|---|---|---|
| 通用 subagent | harness 内置 | 什么都能干的默认代理 |
| 自定义 agent | .claude/agents/*.md | 用 Markdown 定义专属系统提示 + 工具集 + 模型 |
| 命名 teammate | agent 团队模式 | 长期驻留，可被 SendMessage 继续对话 |
自定义 agent 示例（.claude/agents/code-reviewer.md）：
---
name: code-reviewer
description: 代码审查专家。当需要审查代码质量、找 bug 时使用
tools: Read, Grep, Glob # 最小工具集
model: inherit
---
你是资深代码审查员。审查时：
- 只报告可验证的问题，按严重程度排序
- 必须引用 file:line
- 每个发现给出具体失败场景
tools限定 +description路由：主 agent 看到描述就知道何时委派——工具描述即提示词的原则在子代理身上复现。
并行执行模式
1. Fan-out（扇出）
主 Agent ──┬── Subagent A：审查正确性
├── Subagent B：审查性能
└── Subagent C：审查测试覆盖
│
汇总三个结论 ▼（wall-clock = 最慢的一个，不是三者之和）
2. 对抗性验证
发现 "X 有 bug" → 3 个独立验证者，各自被要求「证明这个结论是错的」
→ 多数推翻 = 丢弃
价值：单代理自查会「顺着说服自己」，独立视角才投得出反对票
3. 流水线 vs 屏障
屏障（barrier）：全等齐再下一步 —— 适合需要合并视角的判断
流水线（pipeline）：A 的产出直接进 B，不等 C —— wall-clock 更短
原则：能用 pipeline 别用 barrier（经典误区：每层都 all() 等齐）
并行写冲突：Worktree 隔离
多个子代理同时改文件 = 灾难。解法：git worktree——每个写型子代理在自己的工作树副本上干：
主仓库（只读分析、合并结果）
├── worktree-1 → subagent 改登录模块 （独立分支）
├── worktree-2 → subagent 改支付模块 （独立分支）
└── worktree-3 → subagent 改文档 （独立分支）
互不冲突，完成后各自提交，主线 review/合并
未变更的 worktree 自动清理
代价：每个 worktree 是完整目录拷贝（盘空间 + 初始化时间），只给「并行写文件」的代理用，纯读的代理不需要。
编排谱系：从模型自由到代码确定
谱系左端：模型自主编排
主 agent 自己决定何时派谁、怎么合并（灵活、不可预测）
Task/Agent 工具 + 自然语言指令
谱系右端：代码确定性编排
用脚本/DSL 固定执行图（明确、可测试）
如 Claude Code 的 Workflow：JS 脚本里显式 pipeline()/parallel()，
agent() 调用可被缓存与断点续跑
实践选择：
探索型任务（找 bug、调研）→ 模型自主
生产型任务（批量迁移、全量审查）→ 确定性编排 + 单步模型执行
什么任务适合派子代理
✅ 适合：
大范围搜索/调研（结果小、过程大）
独立可验证的子任务（批量迁移、逐文件处理）
需要独立视角（审查、验证）
与主线推理无关的机械操作
❌ 不适合：
强依赖主任务上下文的判断（来回传话比自己做还贵）
两步就能完成的小事（spawn 开销 > 收益）
需要用户频繁交互的流程
成本心智
token：子代理各自烧自己的上下文，总 token 往往更高——
你买的是「主上下文不被污染」和「并行 wall-clock」
延迟：并行后 wall-clock = max(子任务)，串行 = sum(子任务)
经验：读密集型调查类任务，3-5 个子代理并行，整体提速 2-4 倍
本篇小结
- 子代理 = 独立上下文的完整 agent，只向主线返回结论
- 三大并行模式：fan-out、对抗验证、流水线
- 并行写必须 worktree 隔离
- 编排谱系：模型自主 ↔ 代码确定，按任务可预测性选择