Agent 方法论框架 superpowers 怎么划并发派发的准入线
本文基于 superpowers 仓库 commit 44c9b2d（2026-07-27）梳理，该项目仍在持续迭代，具体行为以仓库 https://github.com/obra/superpowers 最新代码与文档为准。
并发派 Agent 不是一个性能选项，是一次关于”这些任务真的互不相干”的赌注；superpowers 把这个赌注的准入线写死在两句话上——无共享状态、无先后依赖——然后在自己的另一个技能里，用一条硬禁令告诉你这条线有多窄。
那条禁令原文是 Never dispatch multiple implementation subagents in parallel (conflicts).，出现在 skills/subagent-driven-development/SKILL.md。同一个仓库，一边有个技能叫 dispatching-parallel-agents，专门教你怎么把活拆开同时派出去；另一边执行实施计划的技能却规定实现者只能一个一个来。这不是自相矛盾，而是把判据用到了实处：并发的准入条件不看任务在语义上像不像独立，看它们会不会往同一处写。
站内已有的 Agent 并发编排、多会话并发冲突、Claude Code subagent 用法 讲的是通用方法论和平台机制，本篇不重复那些；这里只盯一件事——一个真实开源项目把这套判据固化成了哪些文件、哪些脚本、哪些不许越过的红线，以及你照着划线时会在哪里划错。
一、这条判据拦的是什么
skills/dispatching-parallel-agents/SKILL.md 的开头讲清了并发的动机：你把任务委派给上下文隔离的专门 Agent，通过精确构造它们的指令和上下文让它们保持专注，它们不应该继承你这一轮会话的上下文与历史——你要给的是它们恰好需要的东西。顺带的好处是，你自己的上下文被留给协调工作。
注意这段话的重心不在”更快”，在”隔离”。并发只是隔离带来的副产品：既然每个 Agent 的上下文是你亲手构造的、互不相通的，那它们同时跑和先后跑对结果没有区别——前提是它们在会话之外的世界里也互不相通。文件系统就是那个”会话之外的世界”。
技能里给出的适用场景很具体：3 个以上测试文件因为不同根因失败、多个子系统各自坏掉、每个问题不看别的问题也能理解、几处调查之间没有共享状态。反过来，不适用的场景写得同样直白：几处失败是相关的（修好一个可能顺带修好另几个）、需要理解整个系统状态、Agent 之间会互相干扰。
技能末尾的 When NOT to Use 又补了一条容易被忽略的：探索性调试——你还不知道哪儿坏了。这条值得单拎出来。并发的成本在你派出去那一刻就已经付掉了（每个 Agent 都要重新建立上下文），而收益只有在”每个 Agent 确实找到了自己那份问题”时才兑现。你连问题域怎么划都还没搞清就先并发，等于花了 N 份建立上下文的钱，买回 N 份对同一片迷雾的猜测。
二、决策图上的三道闸门
技能里那张 when_to_use 决策图不长，但每个菱形都是一道独立的闸门，顺序不能换：
第一道是 Multiple failures? ——有没有多个失败。只有一个问题就没有并发的余地，这道是废话，但它把后面两道的适用范围框住了。
第二道是 Are they independent? ——它们独立吗。图上给”否”的分支标了 no - related，走向 Single agent investigates all：由一个 Agent 把全部问题一起查。这里的判断标准是文档正文那句”每个问题不看别的问题也能理解”。相关的失败合并给一个 Agent，不是为了省钱，是因为分开查会让每个 Agent 都只看到症状的一角，然后各自给出一个局部的、可能互相冲突的修法。
第三道是 Can they work in parallel? ——它们能同时干吗。这一道的”否”分支标签是 no - shared state，走向 Sequential agents：还是分成多个 Agent，但串行派。这是整张图里信息量最大的一处。前两道过了、第三道没过，结论不是”合并成一个”，是”仍然一人一份，只是排队”。也就是说，任务的独立性和执行的并发性在这个框架里是两个正交的判断：拆不拆是按问题域拆，同不同时是按共享状态定。
很多人在真实项目里划错线，就错在把这两道并成了一道——觉得任务既然独立就该同时上。superpowers 把它们分成两个菱形，就是要你在”我已经拆好了”之后再单独问一遍：“它们会碰同一份文件吗。“
三、同一个仓库里的反例：实现者为什么不并发
回到开头那条禁令。subagent-driven-development 这个技能做的事是：拿一份写好的实施计划，每个任务派一个全新的实现者 Agent，任务做完立刻派一轮任务评审（规范符合性 + 代码质量），全部任务做完再派一次覆盖整个分支的评审。
计划里的任务通常是独立的——技能自己的决策图里就有 Tasks mostly independent? 这个菱形，“否”分支标 no - tightly coupled，直接劝退到手工执行或先做头脑风暴。既然任务大体独立，为什么实现者不能并发？
因为它们要写同一个 git 工作树。技能开头就要求工作发生在隔离工作区（用 using-git-worktrees 建一个或确认已有的），并明确”没有你的人类搭档明确同意，绝不在 main/master 分支上开始实现”。一个工作树，多个实现者同时改文件、同时跑测试、同时提交——这正是决策图第三道闸门里的 shared state。任务独立，写入目标不独立，于是只能串行。
而任务评审是可以从容并发的：评审读的是一份已经生成好的评审包文件，不写代码。技能里 review-package 脚本的作用就是把 commit 列表、git diff --stat 摘要和带扩展上下文的 diff 写进一个文件，让评审一次 Read 读完，而这份输出永远不进入协调者自己的上下文。读者天然无冲突，写者天然有冲突——这就是那条线在这个项目里的真实位置。
顺带说一句，subagent-driven-development 和另一个技能 executing-plans 的分工也在这条线上：前者留在当前会话，后者是另开一个会话执行计划。决策图里 Stay in this session? 的”否”分支写着 no - parallel session，指向 executing-plans。会话级别的并行和任务级别的并发不是一回事，别混着用。想细看工作区隔离这一层，可以对照 Agent 工作区隔离。
四、这套判据落在仓库里的哪些地方
| 组成部分 | 它负责什么 | 对应仓库位置 | 你什么时候会碰到它 |
|---|---|---|---|
dispatching-parallel-agents 技能 | 判定 2 个以上任务能否并发，给出 Agent 提示词结构与常见错误清单 | skills/dispatching-parallel-agents/SKILL.md | 手里有一批互不相干的失败要同时查 |
subagent-driven-development 技能 | 按计划逐个任务派实现者、每任务一轮评审、末尾一次全分支评审 | skills/subagent-driven-development/SKILL.md | 有写好的实施计划要在当前会话执行 |
| 实现者提示词模板 | 实现者的派发模板，含自审清单和四种状态的回报契约 | skills/subagent-driven-development/implementer-prompt.md | 要派一个 Agent 真的动代码时 |
sdd-workspace 脚本 | 解析并创建”每份计划独占”的工件目录，放台账、简报、报告、评审包 | skills/subagent-driven-development/scripts/sdd-workspace | 开始执行一份计划的第一步 |
task-brief 脚本 | 把单个任务的全文从计划里抽成一个文件，让任务文本不必穿过协调者的上下文 | skills/subagent-driven-development/scripts/task-brief | 每次派实现者之前 |
review-package 脚本 | 把 commit 列表、stat 摘要、带上下文的 diff 写成一个文件交给评审 | skills/subagent-driven-development/scripts/review-package | 每轮任务评审和复评之前 |
using-git-worktrees 技能 | 先检测是否已在隔离工作区，再优先用平台原生工具，最后才回落到 git worktree add | skills/using-git-worktrees/SKILL.md | 动手之前确认写入目标互不重叠 |
这张表里三个脚本值得多看一眼，它们是”无共享状态”这条判据的物理实现。sdd-workspace 的脚本注释写得很清楚：一份计划一个目录（.superpowers/sdd/<plan-basename>/），这样同一个工作树里的后续计划永远不可能读到或覆盖另一份计划的工件；把陈旧台账误读成当前进度会让协调者跳过整段任务序列，按计划分目录从结构上消除了这个故障。注释里还解释了工作区为什么放在工作树里而不是 .git/ 下面——Claude Code 把 .git/ 当受保护路径、拒绝 Agent 写入，而实现者需要往里写自己的报告文件。
隔离粒度到哪儿为止，task-brief 脚本自己的头部注释交代得更直白：默认输出路径按计划和工作树划分，同一个工作树里对同一份计划的并发运行会共享同一个文件。也就是说，隔离做到”一份计划一个目录”就停了，再往下没有。这句话本身就是一条并发准入线的注脚——脚本层给你的保证只到计划级，你要是自作主张在同一份计划上并发跑两路，工件互相覆盖，脚本不会拦你。
review-package 的注释里还藏着一处容易被忽略的设计：默认文件名带上 base 与 head 的短哈希，按 diff 区间命名，所以一轮修复之后的复评拿到的是一个全新文件，而不是被覆盖过的旧包。评审这条链路上之所以敢并发，正因为每一份输入都是只读的、名字唯一的、不共享的。反过来看，实现者那条链路上的所有产物——工作树里的源码、测试状态、git 索引——没有一样满足这三条。
五、边界与代价
这套设计放弃了几样东西，你在决定要不要照搬之前该先看清楚。
它放弃了实现阶段的并发收益。 一份十个任务的计划，实现者只能一个一个派，串行的墙钟时间是跑不掉的。subagent-driven-development 换回来的是每个任务一轮独立评审加末尾一次全分支评审——质量换时间，不是时间换时间。如果你的十个任务是十个互不相干的小脚本，这套流程明显是过度设计。
它会让整个开发过程变慢、变啰嗦。 每个任务要跑 task-brief 生成简报、要记录 BASE、要生成评审包、要往台账追加一行完成记录；评审提出问题就进修复循环，一轮修复等于一次修复派发加一次限定范围的复评，每任务最多五轮。技能里自己列了一张”常见借口”表，其中一条借口是”评审拖慢了循环”，对应的回应是没有评审的循环只是未经验证的空转。这话没错，但代价是真实的：改一行配置也走完整套，纯属浪费。
它明确不管的事情也不少。 dispatching-parallel-agents 不负责帮你判断问题域该怎么划，它只在你划好之后给出”独立吗、能并行吗”两问；探索阶段它直接把你排除在外。using-git-worktrees 在遇到沙箱拒绝创建工作树时的处理是：告诉用户沙箱挡住了，然后就地工作——它不会替你想别的隔离办法。subagent-driven-development 的修复循环撞上五轮上限后也不会继续想办法，规则是停止派发、由协调者对每条未决结论逐条裁定，承重的问题直接报 BLOCKED 给人类。
它假定了一个有 subagent 能力的平台。 executing-plans 开头那段提示写得直接：如果有 subagent 可用，就该用 subagent-driven-development 而不是它。反过来，平台没有 subagent 时这套判据的大半都落不了地。仓库里 skills/using-superpowers/references/pi-tools.md 就写明，pi 核心不自带标准的 subagent 工具，没有 subagent 工具时不要伪造调用，老老实实在当前会话串行执行或者说明这项可选能力没装。这是个诚实的边界声明，值得抄。
六、上手与避坑清单
把”独立”和”能并行”分成两问，别合并。 会踩是因为任务在需求文档上看起来毫不相干，你就顺手同时派了；真正冲突发生在文件层，而需求文档不描述文件。避法是在派发前把每个任务将要写入的路径列出来，有交集就退回串行——决策图第三道闸门的 no - shared state 分支就是给这种情况准备的。
并发派发要在同一条回复里发完。 会踩是因为一次发一个感觉更稳，结果全成了串行。dispatching-parallel-agents 里写死了这个机制：一条回复里多次派发就是并发执行，一条回复一次派发就是串行。这是平台行为不是建议，你以为在稳妥地推进，实际只是把并发退化成了串行还多付了上下文钱。
给每个 Agent 划死范围和约束，别只给目标。 会踩是因为提示词只写了”修好这个”，Agent 就顺手重构了半个仓库，回来之后你分不清哪些改动是必要的。技能的 Common Mistakes 一节把四类错误配了正误对照：范围太宽（“修好所有测试”）对具体范围（“修好某个测试文件”）、没有上下文对贴出报错和用例名、没有约束对明确写”不要改生产代码”、输出含糊对指定”返回根因和改动的摘要”。
别把会话历史粘进派发提示词。 会踩是因为你觉得多给点背景总没错。subagent-driven-development 的任务循环一节给了个反面记录：一次真实会话的派发提示词达到 42k 字符，其中 99% 是粘贴进去的历史。规则是新的 Agent 只需要它的任务、它要碰的接口、以及全局约束，别的都不要。更根本的原因写在任务循环开头——你粘进派发提示词的一切、以及 Agent 打印回来的一切，会在这一整轮会话里常驻你的上下文，并在之后每一次轮次被重新读一遍。所以工件要用文件交接，不要用文本传递。上下文预算这笔账不新鲜，新鲜的是这里给了个具体数字。
派发时永远显式指定模型。 会踩是因为不填也能跑。subagent-driven-development 的模型选择一节点破了后果：省略模型会静默继承你这轮会话的模型——往往是能力最高也最贵的那个——于是整节模型选择形同虚设。它还补了一条反直觉的经验：轮次数比 token 单价更要紧，最便宜的模型在多步任务上常常要花 2 到 3 倍的轮次，总账反而更贵，所以评审者和只拿到散文描述的实现者用中档模型托底。
并发回来之后必须做整合验证，这一步不能省。 会踩是因为每个 Agent 都回报成功，你就默认整体也成功。技能的 Verification 一节给了四步：逐份读摘要弄清改了什么、检查是否有 Agent 改了同一处代码、跑完整测试套件确认这些修复放在一起仍然成立、再抽查——Agent 会犯系统性的错误。第二步是并发独有的：串行时冲突会当场暴露，并发时冲突要等到汇合才现形。
别在协调者会话里自己动手修。 会踩是因为问题看着很小，派一次显得笨重。subagent-driven-development 末尾的借口对照表里正好有这条，回应是协调者自己修会污染你的上下文，而且绕过了评审。这条对人也成立：你在主会话里顺手改的那一行，没有任何人复核过。
收尾
这条线的划法可以压成三个问题，派发之前对着问一遍：这几件事分开看还能不能各自讲清楚（不能就合并成一个 Agent）；它们会不会写到同一处（会就串行）；回来之后我打算用什么把它们的成果合到一起验证（答不上来就先别派）。
想继续往下读，路径是清楚的：从 skills/dispatching-parallel-agents/SKILL.md 起步看判据本身，再读 skills/subagent-driven-development/SKILL.md 看这条判据在有写入行为时如何收紧，最后翻 skills/subagent-driven-development/scripts/sdd-workspace 的脚本注释——那几十行讲清了工件目录为什么按计划分、为什么不能放进 .git/，是整套隔离设计里最实在的一段。任务拆到多细才算合适，可以再对照 任务分解粒度 一起看。
这个仓库以 MIT 许可证开放，判据、模板和脚本都能直接打开核对。你不一定要照单全收整套流程——串行实现加逐任务评审对小改动确实偏重——但”独立性”和”可并发性”分成两问这一点，成本极低，值得先搬进你自己的工作方式里。
本文属于 superpowers 方法论专题（共 30 篇，含三篇与其它开源 Agent 项目的对照）。想看把资产铺满的另一种取向，见 ECC 开源 Agent 套件专题。