05 执行与协作：子 Agent、Worktree 与 Review¶

一、计划完成只是控制面准备好¶

writing-plans 的输出不是“可以自动执行的魔法脚本”，而是一份让执行者少做猜测的任务协议。真正执行时，Superpowers 提供两种组织方式：顺序执行和子 Agent 驱动开发。

顺序执行¶

skills/executing-plans/SKILL.md 要求先加载并复核计划，再逐项执行；遇到计划与现实不一致时停止并请求帮助，而不是偷偷扩展范围。它适合任务之间强依赖、上下文连续或改动很小的场景。

子 Agent 驱动开发¶

skills/subagent-driven-development/SKILL.md 把每个任务隔离成一次 implementer → reviewer → fix loop。主 Agent 保留整体方向，子 Agent 只承担一个有清晰输入和输出的任务。

二、SDD 的任务循环¶

flowchart TD
    P[加载并复核计划] --> W[准备隔离 workspace]
    W --> I[派发 implementer]
    I --> R1[检查实现报告]
    R1 --> R2[派发 spec/code reviewer]
    R2 --> D{发现问题?}
    D -- 是 --> F[将具体反馈送回 implementer]
    F --> R2
    D -- 否 --> C[完成任务并记录验证]
    C --> N{还有任务?}
    N -- 是 --> I
    N -- 否 --> FR[最终全局 review]
    FR --> E[finish branch]

这里有两个 reviewer 层次：

任务级 reviewer 检查当前任务是否满足计划和工程质量；
最终 reviewer 在所有任务完成后检查跨任务接口、整体行为和遗漏。

如果只有前者，局部任务可能都“看起来正确”，但合并后仍可能出现接口不一致；如果只有后者，问题会被推迟到最后才发现，修复成本更高。

三、Implementer prompt 为什么强调上下文边界¶

skills/subagent-driven-development/implementer-prompt.md 的任务模板会告诉子 Agent：

只处理当前任务；
先读取相关文件和计划；
按计划里的测试顺序执行；
不因“顺手改一下”扩展范围；
报告改了什么、跑了什么、剩什么问题。

这实际上是在控制子 Agent 的“注意力预算”。主 Agent 不把整段需求和全部仓库灌给 implementer，而是用任务编号、文件范围、接口约定和验证命令构造一个窄上下文。

四、Worktree：隔离的不只是文件，也是认知上下文¶

skills/using-git-worktrees/SKILL.md 先检测现有隔离状态，再选择原生 worktree 工具或 Git fallback。创建后会做三件事：

选择项目允许的目录，避免把工作区散落到不可控位置；
安装项目依赖或执行必要 setup；
在任何实现前运行项目测试，确认基线是干净的。

主分支
 ├── worktree/task-a  ← implementer A
 ├── worktree/task-b  ← implementer B
 └── worktree/task-c  ← implementer C

worktree 解决的不是简单的“避免文件冲突”。它还让每个子 Agent 在一个已知基线中作判断，reviewer 可以把 diff 精确归因到当前任务，主 Agent 也不必从未提交改动中猜测另一个任务的状态。

五、什么时候可以并行¶

dispatching-parallel-agents 把并行条件写得很严格：先识别独立领域，再为每个 Agent 创建聚焦任务，确认它们没有共享写入冲突，最后统一审查和整合。

适合并行的例子：

一个 Agent 分析 API 层，另一个分析前端层；
多个互不相干的失败测试；
不同文档章节的事实整理。

不适合并行的例子：

同一个核心接口的连续修改；
后一个任务依赖前一个任务尚未产出的类型或文件；
多个 Agent 会编辑同一份配置或迁移文件；
任务边界还没有通过设计确认。

并行的底层判断可以写成：

parallel = independent inputs + disjoint writes + mergeable outputs

少一个条件，所谓并行就可能只是把冲突延迟到合并时。

六、Reviewer 不是“再看一遍代码”¶

task-reviewer-prompt.md 把 reviewer 的职责分成两个问题：

Spec compliance：计划要求的行为是否全部实现？有没有漏项、越界或偷换目标？
Code quality：实现是否可维护、是否引入明显回归、测试是否真正证明了行为？

两者必须分开问。一个实现可能代码很漂亮，但漏了计划中的边界；也可能完全满足功能，却把错误处理写成不可维护的分支。

七、Fix loop 为什么必须回到同一个 implementer¶

发现问题后，SDD 不会立刻让主 Agent 自己改，也不会开启一个全新 Agent 重新理解任务，而是把 reviewer 的具体反馈送回当前 implementer。原因是当前 implementer 已经拥有：

任务上下文；
已读过的相关代码；
当前失败状态；
之前的设计假设。

这样能降低重复探索成本。只有在反馈解决后才重新 review；修复和审查之间形成小闭环，而不是把所有不确定性堆到最终阶段。

八、子 Agent 选择模型也是一个决策¶

SDD 专门包含 Model Selection 部分，说明不同任务不必使用同一模型：

机械、边界清晰的实现任务可以使用更快、更便宜的模型；
架构 review、跨文件推理和最终检查需要更强的推理能力；
主 Agent 负责选择与任务风险匹配的模型，而不是只按“越强越好”分配。

这体现了方法论层的资源意识：把昂贵推理用在决策和审查，把重复执行交给更合适的执行者。

九、收尾不是“git commit 一下”¶

finishing-a-development-branch 的步骤顺序是：先验证测试，检测当前环境和 base branch，再向用户提供合并、推 PR 或保留现状等选项。它还区分 detached HEAD、worktree 和普通分支，避免 cleanup 时误删主工作区。

验证 → 识别环境 → 识别 base → 给出交付选项 → 执行选择 → 清理 workspace

这一步保留用户控制权：Agent 可以准备好结果，但不应擅自把分支合并、推送或删除，除非用户选择了对应动作。

小结¶

Superpowers 的协作模型不是“让更多 Agent 同时写代码”，而是把并行限制在独立边界内，把每个任务放进可回滚工作区，用独立 reviewer 和 fix loop 保持证据链，最后把分支收尾作为一个需要用户选择的状态。