子代理驱动开发指南:Superpowers 如何把一份计划拆给一群子代理干完

📅 发布时间:2026/8/28 9:56:38
子代理驱动开发指南:Superpowers 如何把一份计划拆给一群子代理干完 子代理驱动开发指南Superpowers 如何把一份计划拆给一群子代理干完【免费下载链接】superpowersAn agentic skills framework software development methodology that works.项目地址: https://gitcode.com/GitHub_Trending/su/superpowers你在会话里让 AI 执行一份十步的实现计划它跑到第四步开始失忆把已经做完的任务重做一遍还顺手踩坏了上一轮改好的地方。Superpowers 里的子代理驱动开发Subagent-Driven Development下称 SDD就是冲着这类翻车现场设计的目标是让计划执行全程少返工。本文按痛点驱动的路子写先摆两个真实的故障模式再拆开它的机制最后给最小上手路径和踩坑清单。先说两个让人头疼的故障现场上下文被自己撑爆一个会话从头干到尾所有 diff、审查报告、来回对话全堆在同一个上下文里。会话一长就会触发压缩compaction把早期对话压成摘要腾空间。压缩一发生指挥官controller负责调度的主代理经常忘了自己推进到哪一步——技能文档里直接承认重发整串已完成任务是观察到的最贵的一次性故障。一个工人干所有活没有分工时写代码的代理同时背着全部历史它改函数 A 的时候上下文里还飘着任务 B 的报错日志和任务 C 的设计讨论。注意力被稀释质量跟着漂而且没有任何角色专门盯着做出来的东西是否就是计划要的东西。解法一个指挥官一群一次性工人子代理驱动开发的做法可以一句话概括指挥官不写代码只发任务每个任务派一个全新的实现子代理只给它这个任务所需的信息干完即弃。子代理subagent你可以理解成一次性临时工它有独立上下文不继承主会话的历史。派活时你构造了它看到的全部世界——任务原文、接口约定、全局约束——它就只知道这些。好处有两个任务之间互相不串味。第 12 个任务的工人看不到前 11 个任务的残留信息也不会被它们带偏。指挥官的上下文只留协调记录撑爆的概率大幅下降。注意一次性的边界实现者绝不并行派会互相冲突审查可以独立进行。每个计划还有自己的独立工作目录.superpowers/sdd/计划名/由 skills/subagent-driven-development/SKILL.md 里的脚本生成账本、任务简报、审查包全放里面不同计划互不碰。每个任务要过的三道关第一关实现者先问再做派活前指挥官先把计划中该任务的完整原文抽成一个简报文件brief连同接口上下文交给实现者。模板要求它开工前把疑问一次性问出来——SKILL.md 示例里那个任务实现者开口就是hook 该装到用户级还是系统级。答完才开始写代码、跑测试、提交最后返回一个状态完成、带疑虑完成、需要补充上下文、被卡住。后两种必须处理不允许硬着头皮继续。第二关审查只看 diff且必须给两个结论审查子代理拿到的就三样任务简报、实现者的报告、一个打好的 diff 包提交列表 统计摘要 带上下文的完整 diff一次读完。它必须给出两个独立结论规格是否符合要求不多做、不少做、代码质量是否达标。模板里有句狠话不要相信报告——报告是未经验证的声明一切以 diff 为准。上面那个 hook 任务就是现成例子审查给出规格 ❌缺了计划里要求的每 100 项汇报一次进度外加一个 Important 级问题100 是魔法数字。两条全进修复流程一条没放过。第三关修复循环带保险丝修复不是无限磨。规则写死每个任务最多 5 轮。第 1~3 轮让原实现者接着修它还记得自己为什么这么写第 4~5 轮换新实现者且模型升一档——三轮都修不好通常说明它自己看不到问题换眼睛比加指令有用。每轮修完只审修复引入的那段 diffscoped re-review范围受限的复审防止审查范围漂移。第 5 轮后仍有未决问题就触发保险丝指挥官逐条裁决——审查者判错的记账挂起真实但不影响后续的也挂起并注明理由真实且后续任务要依赖它的整个流程停在那儿报 BLOCKED停摆需要你介入。每一次裁决都写进账本禁止悄悄丢弃。子代理驱动开发里的任务循环长这样贯穿三道关的是账本progress.md。每完成一个任务、每修一轮都追加一行。它不是官僚主义会话压缩之后代理只信账本和 git log不信自己的记忆。最小上手路径从计划到交付装好 Superpowers准备一份够具体的计划安装方式按你用的宿主不同Claude Code 可以走官方插件市场其他宿主见仓库 README。如果走 git 安装git clone https://gitcode.com/GitHub_Trending/su/superpowers然后是前提条件一份任务彼此独立的实现计划。计划质量决定全局——技能文档的原话是计划要清晰到一个热情但没判断力、没项目背景、还讨厌写测试的初级工程师都能照着做。skills/writing-plans/SKILL.md 就是负责产出这种计划的技能。启动之后你只需要做三件事对代理说一句原文示例I want to execute the plan at docs/plans/xxx.md using the subagent-driven-development skill.它就连续执行中间不问你要不要继续——这是设计不是 bug。你要做的回答实现者的澄清问题一次答到位开工前它会一次性抛出计划里自相矛盾的地方比如计划强制要求的东西恰好是审查标准里的缺陷你只裁决以哪边为准中途不再逐个打断你等它全部跑完。最后它会派一次整分支的最终审查用最强的可用模型修完残留问题后交给 finishing-a-development-branch 收尾再删掉本计划的临时工作区——记录从此留在 git 里。什么时候不该用任务紧耦合互相牵动或者你想开两个会话并行推进就别套 SDD先回退到头脑风暴或换用 executing-plans 技能。几条从失败里换来的经验 指挥官自己下场修 污染 逃审。你的上下文是为协调留的自己一改就绕过了审查。修复永远派回给实现者。改动就一行跳过重审吧是回归的入口。每一轮修复结束都必须有一次范围受限的重审没有例外。派子代理时必须写明模型。不写会静默继承会话里最贵的那个模型省钱策略直接失效。而且看轮数不看单价最便宜的模型在多步任务上常要 2~3 倍轮数总账更贵。别给审查者预置结论。提示词里出现不要标记 X最多算小问题之类的话说明你在替它下判断省下的只是一个循环。Minor 问题走账本不走循环。小的发现逐条记下交给最终审查统一分诊哪些必须合并前修掉——没人读的分诊清单等于悄悄丢弃。下一步挑一份 3~5 个任务的小计划把子代理驱动开发从头到尾跑一遍全程盯住.superpowers/sdd/里的账本和审查包比读十遍文档更有感觉。跑顺之后值得花时间改的是三个提示词模板实现者、任务审查者、复审者把你们团队的质量标准写进去这套机制才开始真正属于你。再往后可以调的是模型分级策略和修复轮数阈值——这两个旋钮直接决定你的花费曲线。【免费下载链接】superpowersAn agentic skills framework software development methodology that works.项目地址: https://gitcode.com/GitHub_Trending/su/superpowers创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考