开发与工程 workflowsubagentsparallelismsuperpowers

Dispatching Parallel Agents(并行子代理调度)

面对多个互不依赖的问题时,一次性并行派发多个子代理分别处理,而不是串行排队

FollowSkills 评估 · FSRS-1.0
不推荐
58/ 100
价值适配17 / 20

目标明确:在多个彼此独立、无共享状态的故障或任务上,为每个问题域派遣一个专门代理,以减少串行调查时间。适用条件、禁用条件、任务边界和预期输出均有说明,对使用编码代理的受众具有实际价值。证据缺口是没有量化收益,也未说明代理数量、并发额度或不适合并行化的更细致边界。

可靠性11 / 20

流程包含识别独立域、构造自包含提示、并行派遣、汇总审查、冲突检查和运行完整测试等步骤,能支持一定程度的一致性和可复现性。主要证据缺口是没有针对本技能的可执行测试、失败重试或超时策略,也依赖未定义的具体代理运行时语义;示例中的成功结果不能在静态审查中独立验证。

安全性13 / 25

技能要求隔离上下文、限制每个代理的范围、避免修改其他代码,并要求返回结果后审查冲突和运行完整测试,这些措施降低了上下文泄漏和未经约束的改动风险。仍缺少对代理权限、文件写入、命令执行、网络或敏感数据流的明确限制,也没有用户确认、取消、回滚、资源配额和并发冲突恢复机制。未发现足以构成红线的恶意或破坏性默认行为。

证据6 / 15

技能提供了决策图、具体任务提示模板、反例和验证清单,能追溯到文档内的工作方法。但“Real Example from Session”和“Real-World Impact”只有叙述性结果,没有日志、测试文件、提交或独立来源支持;没有把事实、经验性推断和可验证指标清楚分开,因此证据强度有限。

易用性7 / 10

“When to Use”和“Don't use”部分帮助用户判断输入条件,任务提示结构明确了范围、目标、约束和输出,整合阶段也给出了退出前检查。证据缺口包括未说明不同代理平台的兼容性、并发成本和失败诊断方式,没有定义取消或部分完成时的标准输出,也未提供资源不足、代理冲突或无法确认独立性时的具体处置步骤。

维护性4 / 10

仓库提供MIT许可证,源文件有固定评估修订,且上下文显示包版本为6.1.1;但这些信息主要是仓库级别而非该技能自身的维护元数据。未验证发布者身份,技能没有版本、变更记录、责任人、发布责任或明确的更新响应路径,因此维护与治理支持有限。

证据充分度: 评估于 2026年7月15日 审查版本 d884ae04edeb
使用前请注意
  • 仅在任务确实没有共享状态、顺序依赖或共同编辑资源时并行派遣;文档中的独立性判断需要人工复核。
  • 并行代理可能同时修改相同文件或使用相同测试、端口和外部资源;在实际运行前应设置隔离工作区、权限边界和资源配额。
  • “Real Example from Session”和“Real-World Impact”未提供可独立核验的测试或日志,不应视为已验证的性能或成功率证据。
  • 技能没有明确取消、超时、重试、回滚和部分失败处理;不要仅凭“full test suite”步骤假定并发改动可安全恢复。
评估证据 [1][2][3][4][5][6][7]
查看完整评分方法 →

它能做什么 & 适用场景

教 Claude 识别「多个独立失败/任务」的场景(比如三份不同测试文件各自失败、原因互不相关),把它们拆成互不干扰的子代理任务,在同一条回复里一次性并行派发,而不是一个一个顺序调查。每个子代理拿到的是精心构造的独立上下文(不继承主会话历史),避免互相污染,也节省主会话自己的上下文。

先判断多个问题是否真正独立(不共享状态、互不依赖);按问题域分组(比如按测试文件/子系统分组);为每个子代理写清楚范围、目标、约束和期望输出格式;在同一条回复里发出多个子代理调用实现真正并行(而不是分多条消息变成串行);子代理返回后逐一阅读摘要、检查改动是否冲突、跑一次完整测试套件确认整体没问题。

  1. 一次改动后 3 个不同测试文件各自出现互不相关的失败,分别派 3 个子代理并行修复
  2. 重构后发现多个子系统各自出问题,且互相之间没有共享状态,可以并行排查
  3. 需要保留主会话上下文做协调工作时,把耗上下文的调查任务甩给独立子代理

优缺点一览

优点
  • 明确区分「并行安全」和「应该串行」的判断标准(是否共享状态、是否互相依赖),不是无脑并行
  • 给出了具体的 agent prompt 结构模板(范围、目标、约束、期望输出),减少子代理跑偏的概率
  • 包含一个真实调试会话的完整案例(6 个失败分 3 组并行修复),可以直接照搬套用
局限
  • 只在会自动读取和遵循 SKILL.md 指令的 harness 里可靠工作(Claude Code、Codex CLI 等);纯聊天式界面里等于一份说明文档,需要人工照做。
  • 如果任务边界判断错误(本以为独立实际上有隐藏依赖),并行执行反而会产生冲突需要人工排查
  • 依赖 harness 本身支持子代理/多任务并发调度,纯单线程对话式工具用不上

如何安装

作为 obra/superpowers 插件的一部分安装,不能单独安装某一个 skill:

  1. Claude Code:官方市场 /plugin install superpowers@claude-plugins-official;或先注册 Superpowers 自建市场 /plugin marketplace add obra/superpowers-marketplace,再 /plugin install superpowers@superpowers-marketplace
  2. 也支持 Antigravity、Codex App/CLI、Cursor、Factory Droid、GitHub Copilot CLI、Kimi Code、OpenCode、Pi 等 harness,具体命令见仓库 README

装好后这个 skill 会和其余 13 个 Superpowers skill 一起启用,由 using-superpowers 统一引导、按场景自动触发,无需单独调用。

如何使用

当你的任务出现多个明显互相独立的问题时,Claude 会评估是否满足并行派发条件,然后在一条回复里同时发出多个子代理调用,例如同时派发「修复 A 测试文件」「修复 B 测试文件」「修复 C 测试文件」三个子代理。

对比同类

跟不做任何调度指导、靠模型自行决定是否并行相比,这个 skill 把「什么时候并行」「怎么写子代理 prompt」「派发后怎么整合」变成了显式检查项,降低了乱并行导致冲突、或者该并行却串行浪费时间的概率。

常见问题

「一条回复里发多个调用」和「分几条消息发」有什么区别?
SKILL.md 里明确指出:同一条回复里的多次子代理派发是并行执行,分成多条消息发送则会变成顺序执行——这是决定是否真正省时间的关键细节。

同仓库的其他 Skills

均来自 obra/superpowers

开发与工程

Test-Driven Development(测试驱动开发)

铁律:没有先写失败测试就不能写生产代码,写了也要删掉重来,不允许「补测试」

开发与工程

Brainstorming(需求澄清与设计)

写代码前先把需求逼问清楚,禁止在没有确认设计前直接动手实现

开发与工程

Verification Before Completion(完成前必须验证)

没有当次运行过的验证证据,就不能说「完成了」「测试通过了」——包括「应该」「看起来」这类措辞

开发与工程

Finishing a Development Branch(收尾开发分支)

开发完成后先验证测试通过,再用固定的 4 选项菜单让人决定合并/PR/保留/丢弃,并按规则清理 worktree

开发与工程

Receiving Code Review(接收代码评审反馈)

禁止「你说得对!」式的表演性附和,要求先核实反馈再决定实施还是据理反驳

开发与工程

Requesting Code Review(发起代码评审)

派一个独立上下文的评审子代理来审查改动,而不是让主会话自己一边写一边给自己打分

开发与工程

Systematic Debugging(系统化调试)

任何 bug 都必须先完成根因排查再提修复方案,明确禁止「先随手改一下试试」

开发与工程

Writing Plans(撰写实现计划)

把需求拆成假设执行者对代码库一无所知也能照做的、每步 2-5 分钟的具体任务,杜绝「TBD」「补充细节」类占位符

开发与工程

Subagent-Driven Development(子代理驱动开发)

同一会话内为每个任务派发全新子代理实现,配两阶段审查,用进度台账防止压缩后重复劳动

开发与工程

Executing Plans(分会话执行实现计划)

在没有子代理能力的场景下,按人工检查点批量执行一份已写好的实现计划

开发与工程

Using Git Worktrees(隔离工作区管理)

开始新功能开发前,优先用平台原生隔离工具,没有的话再退回手动 git worktree

开发与工程

Writing Skills(撰写与测试 Skill 本身)

把 TDD 的红绿重构套用到「写 Skill 文档」这件事上:先用无 skill 基线测试暴露真实失败模式,再针对性写文档,而不是凭直觉写

开发与工程

Using Superpowers(Superpowers 入口引导)

整套 Superpowers 方法论的启动引导 skill,规定「只要有 1% 可能相关就必须调用对应 skill」

相关 Skills