Superpowers 执行模型：子 Agent 驱动开发的双阶段评审机制

在 agentic coding 领域，大多数框架将「执行」理解为一次 LLM 调用完成任务，或者用规则引擎按序执行预设步骤。Superpowers 反其道而行：将完整实现计划拆解为 2–5 分钟粒度的原子任务，每个任务通过专用子 Agent 执行，并强制插入 spec 合规审查与代码质量审查两道关卡。这一设计在架构层面带来了显著的可控性与可观测优势，也是它与传统 DSL 流水线最核心的差异点。

任务分发架构：每任务独立子 Agent

Superpowers 的执行模型不依赖单一会话的连续对话，而是以「任务」为原子单位，每次向 LLM 下发一个完全独立的工作单元。子 Agent 驱动开发（subagent-driven-development）技能明确要求：

• 完全隔离的上下文：主 Agent 在分发前提取任务文本与场景上下文，构造精确的 prompt 发送给子 Agent。子 Agent 不继承主会话历史，也不读取外部计划文件 —— 主 Agent 提供完整文本而非引用路径。
• 连续执行原则：任务之间不插入人工确认环节，子 Agent 自主推进直到完成或遇到阻塞状态。唯一的停止条件是 BLOCKED、无法消除的歧义，或全部任务完成。
• 状态分类体系：子 Agent 报告 DONE、DONE_WITH_CONCERNS、NEEDS_CONTEXT 或 BLOCKED 四种状态，主 Agent 根据状态路由到不同处理分支 —— 这本质上是将状态机概念引入 agentic workflow。

关键参数在于「上下文构造粒度」。Superpowers 经验表明：子 Agent 需要「刚好够用」的场景信息。过多导致注意力稀释，过少导致盲目实现。实践中，建议每个子任务 prompt 控制在 800–1200 token，包含任务目标、涉及文件路径、验收标准与禁止事项。

双阶段评审流水线：顺序不能颠倒

Superpowers 执行模型最值得关注的工程决策是评审顺序：spec 合规审查必须在代码质量审查之前完成。这一点看似显而易见，但大多数 agentic 实现将两者合并或调换顺序，导致两个问题：要么代码通过质量审查后才发现与需求不符，要么代码审查消耗算力去评估最终不会采纳的实现。

第一阶段由 spec-reviewer 子 Agent 执行，验证点包括：

• 需求覆盖率：spec 中每个条款是否都有对应实现
• 过度实现检测：代码中是否存在 spec 未要求的额外逻辑
• 边界条件：是否有 spec 明确提及但未处理的极端情况

第二阶段由 code-quality-reviewer 子 Agent 执行，关注点与 spec 审查正交：

• 代码可读性与结构
• 测试覆盖率与测试质量
• 安全实践与性能隐患
• 与项目其他部分的集成一致性

两层审查通过「直到批准」的循环保障质量：若第一阶段发现问题，子 Agent 修复后重新进入第一阶段审查池；若第二阶段发现问题，同样返回修复流程。审查循环次数不设上限，直至两个阶段均通过。

模型分层策略：按角色选型

Superpowers 在模型选择上提出了明确的分层建议，这是在其他 agentic 框架中较少被显式阐述的设计：

• 机械实现任务（1–2 个文件、规格清晰）：使用快速廉价的模型。大量日常实现属于这一类 —— 当任务边界明确时，高端模型并不带来额外收益。
• 集成与判断任务（多文件协调、模式匹配、调试）：使用标准模型。这类任务需要跨文件上下文理解与推理能力。
• 架构设计与评审任务（需要全局理解或复杂决策）：使用最强可用模型。代码质量审查和架构决策属于此类。

这一分层背后的逻辑是成本控制与速度的平衡。以 2–5 分钟粒度的任务拆分，每个任务平均消耗 tokens 量有限，高端模型的成本优势在这种粒度下并不显著。更重要的是，任务粒度越小，廉价模型的失败代价越低 —— 即便一次执行需要重试，总成本仍然可控。

实践中建议的配置参数：

• 实现子 Agent：Claude Haiku 或同等能力级模型
• 评审子 Agent：Claude Sonnet 或 GPT-4o Mini 级别
• 架构决策子 Agent：Claude Opus 或 GPT-4o 级别

工作流集成：与其他技能的衔接

subagent-driven-development 并非孤岛，它与其他技能形成严格的流水线依赖关系。执行前的准备工作由 writing-plans 负责 —— 该技能强制要求每个任务包含精确文件路径、完整代码片段与预期命令输出，且禁止任何占位符（TODO、TBD）。这直接决定了子 Agent 能否成功执行。

执行后由 finishing-a-development-branch 接管，处理测试验证、分支合并决策与工作区清理。中途的 git 工作树隔离由 using-git-worktrees 保证，确保每个功能分支在独立工作空间中开发。

这种强依赖链避免了 agentic 系统中常见的情景：执行引擎不知道输入是什么、输出往哪里写、失败后如何回退。Superpowers 通过技能间的契约关系，将每个环节的输入输出显式化。

与传统 DSL 方案的差异化定位

传统 agentic 流水线（如 AutoGPT、LangChain Agent）通常依赖规则引擎或线性脚本驱动任务执行，特点是确定性高但灵活性低 —— 一旦 DSL 定义完成，执行路径固定，难以动态适应子 Agent 的状态反馈。Superpowers 的设计则是将「执行引擎」本身变成一个 LLM 角色，由主 Agent 根据状态动态路由，这带来了真正的条件分支能力。

但 Superpowers 也有明确的边界：它假设输入已经经过 brainstorming 阶段的充分澄清，且实现计划已经过 writing-plans 的严格分解。对于需求本身不清晰的场景，Superpowers 并不能替代前期的需求澄清过程。这是它作为方法论框架而非通用 agent 系统的核心约束。

可落地的工程参数

若要将此执行模型引入实际项目，建议关注以下可调参数：

任务粒度控制：writing-plans 要求每个任务 2–5 分钟完成。若任务超出此范围，应主动拆分而非强行塞入单一任务。超时会导致子 Agent 状态报告可靠性下降。

上下文上限：主 Agent 每次分发前构造 prompt，建议监控单个 prompt 的 token 消耗。超过 2000 token 时，信息密度过高可能导致子 Agent 忽略关键约束。

模型预算分配：建议按 5:3:2 比例分配实现、评审与架构三类子 Agent 的调用预算。实际比例可根据项目复杂度调整 —— 基础设施类项目可提高架构评审预算至 30%。

评审通过率阈值：建议记录每个阶段的历史通过率。若 spec 评审首次通过率低于 60%，说明 writing-plans 产出的规格质量需要改进，而非单纯增加评审循环次数。

资料来源：GitHub - obra/superpowers（skills/subagent-driven-development, skills/writing-plans）

ai-systems