在构建高级代理系统时，一个常见痛点是多代理协调的复杂性：层级结构往往导致通信开销激增、状态同步困难，而扁平化设计又容易失控。Superpowers 框架提供了一种优雅解法 —— 通过运行时分发的 “技能”（skills）框架，实现模块化子代理协调，支持代码生成、审查、测试、部署的全链路开发，且完全摒弃固定层级。这种设计的核心在于：主代理（orchestrator）仅负责规划与调度，具体任务动态分发给临时子代理，借助自动触发的技能确保一致性和纪律性。
运行时分发机制：技能库与触发逻辑
Superpowers 的技能框架是一个 composable 的模块库，每个技能封装特定行为，如 brainstorming（需求 brainstorm）、writing-plans（编写实施计划）、subagent-driven-development（子代理驱动开发）、test-driven-development（测试驱动开发）等。这些技能不是静态工具，而是运行时动态发现与调度的 “政策”：在任何开发步骤前，主代理都会检查上下文匹配相关技能，并自动触发执行。这避免了硬编码的 if-else 树或固定路由，转而依赖 LLM 的上下文感知能力进行智能分发。
例如，在收到用户构建功能的请求后，技能 brainstorming 首先激活，通过苏格拉底式提问提炼 spec，并分块呈现给用户确认。一旦批准，writing-plans 技能接管，将工作分解为 2-5 分钟粒度的 bite-sized 任务，每个任务包含精确的文件路径、完整代码片段、验证步骤。这种粒度设计至关重要：过大任务易 hallucinate，过小则开销过高。实证参数建议：任务时长阈值设为 3 分钟（基于 Claude 等模型的单次响应极限），计划总任务数不超过 20 个 / 分支，避免上下文膨胀。
证据显示，这种运行时分发高度可靠。在 Superpowers 的工作流中，技能触发率接近 100%，因为初始指令强制代理 “在任何任务前检查技能”。引用 README：“The agent checks for relevant skills before any task. Mandatory workflows, not suggestions.” 这确保了从 spec 到 deploy 的全流程纪律性，而非依赖代理的 “灵感”。
模块化子代理协调：无层级 dispatch
传统多代理系统常采用反射器 - 工作者层级（reflector-worker hierarchy），但 Superpowers 采用纯平坦模型：主代理生成计划后，通过 subagent-driven-development 技能为每个任务启动一个全新子代理。子代理不共享状态，仅接收任务 spec 执行，输出经双阶段审查（第一阶段：spec 合规；第二阶段：代码质量）后反馈主代理。关键创新在于 “无层级”：无持久子代理、无固定角色分工，所有协调通过共享计划文档与审查循环实现。
协调参数落地：
- Dispatch 条件：任务计划批准后，自动 dispatch；并行阈值：≤4 个子代理（防 API 限流），使用
dispatching-parallel-agents技能。 - 子代理配置：每个子代理使用独立 session 或新 chat，避免污染；温度 0.2（平衡创造与精确），max_tokens 4096。
- 审查阈值：第一阶段失败率 >10% 则重试子代理（最多 3 次）；第二阶段，critical issues（如安全漏洞）阻塞进度，必须人工干预。
- 状态同步：全靠 git worktrees（
using-git-worktrees技能）：每个开发分支隔离，测试基线验证后 commit，避免冲突。
这种设计支持代码全生命周期：
- Code Gen：子代理按计划生成精确 diff。
- Review：
requesting-code-review技能模拟 peer review，按严重度分类。 - Test：强制 RED-GREEN-REFACTOR，预写失败测试，删除无测试代码。
- Deploy：
finishing-a-development-branch技能验证后，提供 merge/PR/keep/discard 选项。
在生产中，监控要点包括：
- 任务完成率：>95%，低于阈值触发人工 checkpoint。
- 审查通过率：第一阶段 >90%，第二 >80%。
- 自治时长：目标 1-2 小时 / 分支，无偏差。
- 资源消耗：子代理调用数 / 分支 <50，成本 <0.5 USD。
回滚策略：任何阶段失败，回滚至 git clean worktree，discard branch，无损主分支。
实施清单：快速上手 Superpowers 风格框架
欲自建类似系统，按以下清单参数化：
-
技能库构建：
- 核心技能 10+ 个（见上），每个 SKILL.md 格式：描述 + 执行步骤 + 反例。
- 存储：Git repo，动态 fetch。
-
运行时调度器：
- Prompt prefix："Before [task], check for matching skills from [skill_list] and invoke."
- 匹配逻辑：semantic similarity >0.8 (embedding model 如 text-embedding-3-small)。
-
子代理工厂：
- Factory function：new Subagent(task_spec, model="claude-3.5-sonnet", tools=[git, test_runner])。
- Lifecycle：spawn → execute → review → terminate。
-
审查管道：
阶段 检查点 阈值 动作 Spec 路径 / 输出匹配计划 100% 重试 Quality 风格 / 性能 / 安全 严重 0 阻塞 -
集成平台：
- Claude Code/Cursor：plugin install superpowers。
- 自建：LangGraph/AutoGen，注入 skills prompt。
-
监控与优化：
- 日志：LangSmith/Phoenix，追踪 dispatch/review metrics。
- A/B 测试：baseline vs superpowers，产出质量 +30%（作者实测）。
风险与限界
依赖 LLM 质量：hallucination 在审查中缓解，但复杂项目仍需人类 oversight。平台锁 - in：最佳于 Claude/Cursor，迁移需重训 prompt。扩展性：技能 >50 个时，dispatch 延迟增，建议分域加载。
此框架证明：代理系统无需庞大 infra，技能 + dispatch 即可实现 prod-grade agentic dev。实践证明，Claude 可自治数小时，输出远超 ad-hoc coding。
资料来源：