第七章：并行智能体、子智能体与 Git Worktree
7.1 为什么需要多 Agent 与隔离工作区
当任务变复杂时，单个 AI 会面临两个问题：
- 上下文污染。 处理多个问题后，AI 容易混淆需求、测试失败和修复思路。
- 工作区冲突。 多个方向同时修改同一仓库，容易相互覆盖或引入难以定位的问题。
superpowers-zh 通过三个 Skills 处理这些问题：
dispatching-parallel-agents：多个独立问题域并发排查。subagent-driven-development：一个任务一个全新子 Agent，并配套审查。using-git-worktrees：为开发创建隔离 Git 工作树。
7.2 dispatching-parallel-agents 的适用场景
当存在 2 个以上可以独立推进、没有共享状态或顺序依赖的任务时，使用并行分派。典型场景：
- 多个测试文件失败，根因看起来属于不同子系统。
- 前端、后端、文档三个互不影响的任务可并行调查。
- 多个 Bug 分别位于不同模块。
- 需要同时调研多个可替代方案。
不适用场景：
- 所有失败可能来自同一个根因。
- 多个 Agent 会编辑同一文件或共享同一资源。
- 任务需要完整系统上下文，不能拆分。
- 还不知道问题域是什么，仍处于探索阶段。
7.3 如何设计并行 Agent 任务
每个 Agent 的任务提示应包含：
- 明确范围。 只看某个测试文件、模块或问题域。
- 清晰目标。 找到根因、修复失败、总结发现。
- 约束条件。 不修改其他模块，不做无关重构。
- 上下文材料。 错误信息、测试名称、相关文件路径。
- 输出要求。 返回根因、修改内容、验证结果。
示例：
你负责调查 tests/export-csv.test.ts 的 3 个失败测试。
只关注导出模块，不要修改权限模块。
请先复现失败，找根因，再做最小修复。
返回：根因、修改文件、验证命令和结果。
模糊提示「修复所有测试」会让 Agent 迷失方向，不利于并行。
7.4 并行结果如何集成
并行 Agent 返回后，控制者需要：
- 阅读每个总结，确认根因和修改范围。
- 检查是否有文件冲突或方案冲突。
- 运行相关测试。
- 运行完整或更大范围验证。
- 对不可信或不完整结果进行二次审查。
不要因为 Agent 报告「完成」就直接相信。仍应使用 verification-before-completion 独立验证。
7.5 subagent-driven-development 的核心流程
subagent-driven-development 面向已有实现计划的执行。它的基本模式是：
- 控制者读取完整计划，提取任务和上下文。
- 每个任务分派一个全新实现子 Agent。
- 子 Agent 完成实现、测试、提交、自审。
- 分派规格合规审查子 Agent，确认代码满足计划且无多余内容。
- 通过后分派代码质量审查子 Agent。
- 审查发现问题则让实现子 Agent 修复并重新审查。
- 任务通过后再进入下一个任务。
- 所有任务完成后进行最终审查和分支收尾。
它的重点不是「并行做所有任务」，而是「每个任务用干净上下文 + 两阶段审查」。
7.6 为什么不并行分派多个实现子 Agent
subagent-driven-development 明确禁止并行分派多个实现子 Agent。原因是实现任务通常会共享代码库状态：
- 两个 Agent 可能修改同一文件。
- 一个任务可能依赖前一个任务的接口。
- 并行提交会造成冲突。
- 审查难以判断哪个变更引入问题。
因此它采用顺序任务 + 独立上下文 + 审查循环的方式，牺牲部分速度换取可控质量。
7.7 子 Agent 的状态处理
实现子 Agent 可能返回四种状态：
| 状态 | 含义 | 处理方式 |
|---|---|---|
DONE |
已完成 | 进入规格审查 |
DONE_WITH_CONCERNS |
完成但有疑虑 | 先评估疑虑，再决定是否审查 |
NEEDS_CONTEXT |
缺上下文 | 补充上下文后重新分派 |
BLOCKED |
无法完成 | 分析阻塞原因，调整上下文、模型或拆任务 |
不要忽略子 Agent 的疑问或阻塞。它们通常说明计划不够清楚、上下文不足或任务过大。
7.8 using-git-worktrees 的价值
Git Worktree 允许同一仓库同时存在多个工作目录，每个目录可位于不同分支。它适合：
- 在不污染当前工作区的情况下开发新功能。
- 同时保留主线、实验分支和修复分支。
- 为子 Agent 或计划执行创建隔离环境。
- 避免频繁 stash 或切分支导致上下文丢失。
superpowers-zh 要求在执行实现计划前建立隔离工作区，尤其是 executing-plans 和 subagent-driven-development。
7.9 Worktree 目录选择
using-git-worktrees 的优先级：
- 如果项目已有
.worktrees/，优先使用。 - 如果没有但有
worktrees/，使用它。 - 检查项目说明文件中是否指定 worktree 目录。
- 如果没有约定，询问用户选择项目本地目录或全局目录。
项目本地目录必须被 .gitignore 忽略。若没有忽略，应先添加到 .gitignore 并提交，防止把工作树内容误提交进仓库。
7.10 Worktree 创建流程
典型流程：
# 创建隔离分支工作树
git worktree add .worktrees/feature-export -b feature/export
cd .worktrees/feature-export# 根据项目类型安装依赖
npm install# 验证基线
npm test
对于不同技术栈，基线命令不同：
- Node.js：
npm install、npm test、npm run build - Rust：
cargo build、cargo test - Python：
pip install -r requirements.txt、pytest - Go：
go mod download、go test ./...
如果基线测试失败，应先报告并询问是否继续，而不是在坏基线上开发。
7.11 多 Agent 与 Worktree 的组合方式
推荐组合：
- 调研类并行任务： 可以在同一只读工作区中并行 Agent 调查，要求不写文件。
- 实现计划： 先创建 Worktree，再用
subagent-driven-development顺序执行任务。 - 多个互不相关功能： 每个功能一个 Worktree，避免分支互相影响。
- 紧急修复： 从主线创建独立 hotfix Worktree，不打断当前功能开发。
避免让多个 Agent 同时写同一个 Worktree，除非工具有明确的合并和锁机制。
7.12 常见风险
风险一：任务拆分不独立
如果两个并行 Agent 都需要改同一接口，最终一定冲突。拆分前要确认边界。
风险二：子 Agent 缺上下文
子 Agent 不继承完整会话历史。控制者必须提供完整任务文本、相关文件路径、约束和预期输出。
风险三：跳过审查
子 Agent 自称完成不等于质量过关。必须进行规格合规和代码质量审查。
风险四：Worktree 未忽略
项目本地 .worktrees/ 未加入 .gitignore 会污染 git status，甚至误提交大量文件。
风险五：基线失败仍开发
如果刚创建 Worktree 就测试失败，后续无法区分新问题和已有问题。应先记录基线状态。
7.13 本章小结
并行 Agent 适合独立问题域，子 Agent 驱动开发适合按计划高质量执行，Git Worktree 提供工作区隔离。三者结合后，AI 不再是一个在同一上下文里越做越乱的助手，而是由控制者协调的多角色工程流程。