第七章：并行智能体、子智能体与 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 不再是一个在同一上下文里越做越乱的助手，而是由控制者协调的多角色工程流程。