Superpowers 系列（五）：上下文治理
多 Agent 执行的难点不只是“怎么并行”。更本质的问题是：每个 Agent 应该知道什么、不应该知道什么、做完后谁来判断、判断结果如何被恢复。
subagent-driven-development 的核心不是“一个任务一个子代理”这么简单，而是一套上下文治理机制。它的 Skill 正文把核心原则写成“每个任务一个 fresh subagent、任务级审查、最终 whole-branch review”，也明确要求子代理不继承主会话历史。
子代理不是越知道越好
很多人使用子代理时，会把完整会话历史、整份计划、前几个任务的长摘要全部塞给它。这样看起来信息充足，实际会带来上下文污染。
Superpowers 的做法相反：子代理不继承主会话历史。主 Agent 为每个任务构造精确 brief，子代理只读取本任务要求、必要接口、已经裁决过的局部决定和报告契约。
这个设计背后有一个判断：实现者需要的是任务真相，不是协调整个过程的历史。太多历史会让子代理试图解释全局，反而弱化当前任务。
主 Agent 的角色是协调者，不是全能执行者
在 subagent-driven-development 里，主 Agent 负责：
- 读取 plan 和 spec；
- 建立本计划专属 workspace；
- 维护 ledger；
- 生成 task brief；
- 派发 implementer；
- 生成 review package；
- 派发 reviewer；
- 对冲突和遗留发现做 ruling；
- 推动最终 review 和分支收尾。
子代理负责局部实现或局部审查。这个分工让主 Agent 保留流程视角，避免被每个 diff 的细节吃掉上下文。
ledger 是抗压缩和恢复机制
长任务会遇到会话压缩、中断、重启。只靠 todo 或聊天记忆，Agent 很容易重复派发已经完成的任务，或者忘记某个修复轮的状态。
Superpowers 要求每个 plan 有独立 .superpowers/sdd/<plan-basename>/ 工作空间，并在 progress.md 记录身份、任务完成、fix round、ruling 和 parked finding。ledger 的第一行标识它属于哪份 plan，避免不同计划的进度互相污染。
这个设计控制的是恢复习惯：恢复时不依赖模型对长对话的印象，而是先读取可见、可验证、可定位的持久事实，再决定下一步派发什么任务。
“Rulings, not stalls” 解决的是执行连续性
subagent-driven-development 有一条很硬的运行规则：执行计划时不要因为普通歧义反复问用户。spec 是绑定权威，plan 是它的论证；两者没有明确回答的地方，主 Agent 作出 ruling，记录原因和错了的代价，然后继续。
这和 brainstorming 的用户批准门禁并不矛盾。设计阶段需要用户批准，因为那是在决定意图。执行阶段面对局部歧义，如果每个小问题都停下来问，计划会被停车场化。
它只在四类情况停下：不可逆或破坏性操作、安全敏感动作、工作区外副作用、以及 plan 坏到所有路径都是猜。这个边界很清楚：普通工程判断由执行控制器裁决，高风险权力还给用户。
子代理审查不是形式，而是独立反力
每个任务完成后会进入任务审查，最终还有 whole-branch review。这个设计不是为了“多看一眼”，而是避免实现者自证正确。
任务审查关注本任务是否满足 spec 和质量要求；最终审查关注整个分支是否仍然成立。局部通过不自动推出整体通过，这一点很重要。实现正确、集成正确、整体目标达成不是同一个结论。
在 Superpowers 内部的边界
subagent-driven-development 是计划执行器，不是设计器。它假设已经存在 spec 和 plan，然后用子代理、ledger、review loop 把计划推完。
如果执行中发现 plan 与 spec 冲突，它会让主 Agent 做 ruling 并记录代价；如果 plan 坏到所有路径都是猜，它才停止。这个边界保证它既能连续执行，又不会在目标不存在时硬跑。
参考资料：
系列导航：