Superpowers 实战并行代理分发与条件等待一次清掉 6 个红灯和 15 个不稳定测试【免费下载链接】superpowersAn agentic skills framework software development methodology that works.项目地址: https://gitcode.com/GitHub_Trending/su/superpowers一次大重构6 个测试同时变红还在 CI 上反复抖动——这是用 Claude Code 的 Superpowers 项目的人常遇到的两种问题。并行代理分发负责多个独立故障并发排查条件等待负责测试时序抖动两者都是修 flaky tests 的核心手段。重构后 6 个测试失败分散在 3 个文件现场是这样的agent-tool-abort.test.ts3 个失败时序问题batch-completion-behavior.test.ts2 个失败工具根本没执行tool-approval-race-conditions.test.ts1 个失败执行计数恒为 0逐个串行排查意味着 3 倍的等待时间而这三个文件恰好互不牵连——abort 逻辑、批量完成行为、竞态条件是三块独立的代码。这就是下面两个解法的用武之地。多文件测试失败如何并行排查拆法很直接按独立问题域分组一个代理只领一个文件。每个代理的提示词里写清三件事——具体范围哪个测试文件、明确目标让这些测试通过、约束不许改其他代码并要求返回发现了什么、改了什么的摘要。三个 subagent 的分发放在同一条回复里发出它们就并行运行每个回复只发一个就是串行。代理回来后做四步整合读每个摘要、检查有没有改到同一段代码、跑全量测试、抽查系统性错误。什么情况下能并行3 个以上测试文件因不同根因失败、各子系统独立损坏、每个问题不需要其他问题的上下文就能看懂。反过来这几类情况不要并行故障相互关联修一个可能连带修好其他几个必须看到完整系统状态才能定位代理会编辑同一文件、抢占同一资源这套判断逻辑完整写在技能文档 skills/dispatching-parallel-agents/SKILL.md 里里面有决策流程图和提示词模板可以直接抄。用 waitFor 替代 sleep 的写法上面 6 个失败里有 3 个是时序问题根子在于测试在猜时间// 猜时序希望 50ms 足够 await new Promise(r setTimeout(r, 50)); const result getResult(); expect(result).toBeDefined();在快机器上 50ms 够用一到 CI 或高负载就挂。条件等待的思路是等待真实条件成立而不是猜测耗时// 等真实条件轮询检查成立即返回 await waitFor(() getResult() ! undefined); const result getResult(); expect(result).toBeDefined();它不再抖动的原理每 10ms 轮询一次条件条件成立立即返回默认 5000ms 超时并抛出带描述的错误——测试要么确定通过要么报一个能看懂的超时不存在赌时间的灰色地带。项目里还有现成的领域工具集可以省事waitForEvent()等特定类型事件、waitForEventCount()等指定数量、waitForEventMatch()按自定义谓词匹配参考实现在skills/systematic-debugging/condition-based-waiting.md和同目录的示例文件里。一个边界要记住如果你测的就是时序行为本身debounce、throttle 的间隔带注释说明为什么是这个值的固定延迟反而是对的。实战数据通过率 60% 到 100%以上都来自 2025-10-03 的真实调试会话结果如下3 个代理并行派遣调查同时完成修复 15 个不稳定测试分布在 3 个文件通过率 60% → 100%执行时间缩短 40%所有修复独立零冲突集成全量测试一次转绿两项技术各自的适用边界并行代理分发只在你确认故障互不牵连、无共享状态时收益最大一旦存在关联就先串行查清再谈并行条件等待适用于一切等异步操作完成的场景唯一例外是测试对象本身就是时间间隔。一句话口诀故障互不牵连就并行时序不确定就等待。【免费下载链接】superpowersAn agentic skills framework software development methodology that works.项目地址: https://gitcode.com/GitHub_Trending/su/superpowers创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Superpowers 实战：并行代理分发与条件等待，一次清掉 6 个红灯和 15 个不稳定测试
Superpowers 实战并行代理分发与条件等待一次清掉 6 个红灯和 15 个不稳定测试【免费下载链接】superpowersAn agentic skills framework software development methodology that works.项目地址: https://gitcode.com/GitHub_Trending/su/superpowers一次大重构6 个测试同时变红还在 CI 上反复抖动——这是用 Claude Code 的 Superpowers 项目的人常遇到的两种问题。并行代理分发负责多个独立故障并发排查条件等待负责测试时序抖动两者都是修 flaky tests 的核心手段。重构后 6 个测试失败分散在 3 个文件现场是这样的agent-tool-abort.test.ts3 个失败时序问题batch-completion-behavior.test.ts2 个失败工具根本没执行tool-approval-race-conditions.test.ts1 个失败执行计数恒为 0逐个串行排查意味着 3 倍的等待时间而这三个文件恰好互不牵连——abort 逻辑、批量完成行为、竞态条件是三块独立的代码。这就是下面两个解法的用武之地。多文件测试失败如何并行排查拆法很直接按独立问题域分组一个代理只领一个文件。每个代理的提示词里写清三件事——具体范围哪个测试文件、明确目标让这些测试通过、约束不许改其他代码并要求返回发现了什么、改了什么的摘要。三个 subagent 的分发放在同一条回复里发出它们就并行运行每个回复只发一个就是串行。代理回来后做四步整合读每个摘要、检查有没有改到同一段代码、跑全量测试、抽查系统性错误。什么情况下能并行3 个以上测试文件因不同根因失败、各子系统独立损坏、每个问题不需要其他问题的上下文就能看懂。反过来这几类情况不要并行故障相互关联修一个可能连带修好其他几个必须看到完整系统状态才能定位代理会编辑同一文件、抢占同一资源这套判断逻辑完整写在技能文档 skills/dispatching-parallel-agents/SKILL.md 里里面有决策流程图和提示词模板可以直接抄。用 waitFor 替代 sleep 的写法上面 6 个失败里有 3 个是时序问题根子在于测试在猜时间// 猜时序希望 50ms 足够 await new Promise(r setTimeout(r, 50)); const result getResult(); expect(result).toBeDefined();在快机器上 50ms 够用一到 CI 或高负载就挂。条件等待的思路是等待真实条件成立而不是猜测耗时// 等真实条件轮询检查成立即返回 await waitFor(() getResult() ! undefined); const result getResult(); expect(result).toBeDefined();它不再抖动的原理每 10ms 轮询一次条件条件成立立即返回默认 5000ms 超时并抛出带描述的错误——测试要么确定通过要么报一个能看懂的超时不存在赌时间的灰色地带。项目里还有现成的领域工具集可以省事waitForEvent()等特定类型事件、waitForEventCount()等指定数量、waitForEventMatch()按自定义谓词匹配参考实现在skills/systematic-debugging/condition-based-waiting.md和同目录的示例文件里。一个边界要记住如果你测的就是时序行为本身debounce、throttle 的间隔带注释说明为什么是这个值的固定延迟反而是对的。实战数据通过率 60% 到 100%以上都来自 2025-10-03 的真实调试会话结果如下3 个代理并行派遣调查同时完成修复 15 个不稳定测试分布在 3 个文件通过率 60% → 100%执行时间缩短 40%所有修复独立零冲突集成全量测试一次转绿两项技术各自的适用边界并行代理分发只在你确认故障互不牵连、无共享状态时收益最大一旦存在关联就先串行查清再谈并行条件等待适用于一切等异步操作完成的场景唯一例外是测试对象本身就是时间间隔。一句话口诀故障互不牵连就并行时序不确定就等待。【免费下载链接】superpowersAn agentic skills framework software development methodology that works.项目地址: https://gitcode.com/GitHub_Trending/su/superpowers创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考