从 6 个测试同时报红说起Superpowers 并行代理分发 条件等待实战【免费下载链接】superpowersAn agentic skills framework software development methodology that works.项目地址: https://gitcode.com/GitHub_Trending/su/superpowers凌晨 2 点你盯着终端一次大重构后6 个测试失败散落在 3 个文件里同时报红。这时候Superpowers 的两个技能正好派上用场——并行代理分发和条件等待。️ 第一幕 · 困局串行排查与「猜时间」的代价先说坏消息。串行排查是这样的钻进文件 A修好再跑发现文件 B 的失败点又变了……三个独立的故障就是三轮完整调试2 点不知不觉到 5 点。更糟的是每轮调试还常撞上flaky 测试await new Promise(r setTimeout(r, 50)); // 希望 50ms 够用 const result getResult(); expect(result).toBeDefined(); // 你机器上绿CI 上死50ms 是纯猜。你机器快刚好够CI 一有负载就挂。这类对时序的猜测正是 flaky 测试的头号根源。 第二幕 · 破局并行代理分发 条件等待登场先看并行代理分发。问题6 个失败各有各的根因你只能一次调一个来回切换上下文反复热身。方案每个问题域派一个 AI 代理一次全部发出三路调查同时跑各只管一个测试文件。一句话原理同一次回复里的所有派遣调用并行执行每个代理只携带你为它精确准备的指令和上下文不继承你的会话历史所以不会走神。不过代理们上手后会撞上同一堵墙——flaky 测试还是因为猜时序而挂。这正是第二个功能条件等待登场的地方问题固定延迟在猜操作要多久快机器过、CI 挂。方案用轮询循环替换setTimeout等到你关心的条件真正成立再往下走。一句话原理等待你关心的条件本身而不是等待一个时长猜测。说白了并行代理分发管分头干活负责提速条件等待管把活写牢负责防 flaky。一个提速一个兜底。 实战演示大重构后6 个红色测试怎么修拿一次真实调试记录走流程。第一步按根因给失败分组agent-tool-abort.test.ts3 个失败时序问题batch-completion-behavior.test.ts2 个失败工具没执行tool-approval-race-conditions.test.ts1 个失败执行计数为 0三个文件、三套根因、互不共享状态——符合并行派遣的条件。第二步一口气发出三个代理Subagent (general-purpose): Fix agent-tool-abort.test.ts failures Subagent (general-purpose): Fix batch-completion-behavior.test.ts failures Subagent (general-purpose): Fix tool-approval-race-conditions.test.ts failures三个同时开工。顺手在每个代理的提示词里写一句别只加超时找真正原因。第三步代理内部用条件等待替换猜测延迟// BEFORE: 希望 50ms 够用 await new Promise(r setTimeout(r, 50)); expect(toolResults.length).toBe(2); // flaky // AFTER: 等条件本身成立 await waitForEventCount(manager, threadId, TOOL_RESULT, 2); expect(toolResults.length).toBe(2); // 稳了代理们全部返回后先确认没人改到同一处文件再跑一遍全量测试——全绿。对等待写法还手生这张速查表直接抄场景推荐写法等事件waitFor(() events.find(e e.type DONE))等状态waitFor(() machine.state ready)等计数waitFor(() items.length 5)复杂条件waitFor(() obj.ready obj.value 10)想看完整打法技能定义在skills/dispatching-parallel-agents/SKILL.md全套等待工具waitForEvent、waitForEventCount、waitForEventMatch的实现在skills/systematic-debugging/condition-based-waiting-example.ts。 数据说话一次真实调试记录来自 2025-10-03 的调试会话6 个失败分布 3 个文件 → 3 个代理并行派遣调查同时完成修复 15 个 flaky 测试3 个文件通过率60% → 100%执行耗时提速约40%所有修复零冲突集成失败越独立并行收益越明显等待越扎实CI 的绿灯越可信。️ 避坑 进阶老朋友的几句提醒先说容易踩的坑故障相关时别并行修好一个可能顺带修好另一个就先一起查代理会编辑同一个文件、共享同一份状态时同样别并行。提示词里那句别只加超时别忘了写不写代理的第一反应就是把 50ms 改成 100msflaky 只是换了个姿势。别在循环前缓存数据轮询循环里每次用 getter 取新值。拿着循环前的旧值条件永远不成立。再给几条调参建议轮询间隔取10ms1ms 费 CPU超过 100ms 又多等超时默认5000ms按场景调超时错误信息里一定说清在等什么、等了多久测时序行为本身debounce、节流间隔是固定延迟的正当场景但要用注释写明时长为什么这么选分头去干等到位再断言——速度与稳定一次拿齐。想深入读skills/dispatching-parallel-agents/SKILL.md与skills/systematic-debugging/condition-based-waiting.md全文。【免费下载链接】superpowersAn agentic skills framework software development methodology that works.项目地址: https://gitcode.com/GitHub_Trending/su/superpowers创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 从 6 个测试同时报红说起：Superpowers 并行代理分发 + 条件等待实战
从 6 个测试同时报红说起Superpowers 并行代理分发 条件等待实战【免费下载链接】superpowersAn agentic skills framework software development methodology that works.项目地址: https://gitcode.com/GitHub_Trending/su/superpowers凌晨 2 点你盯着终端一次大重构后6 个测试失败散落在 3 个文件里同时报红。这时候Superpowers 的两个技能正好派上用场——并行代理分发和条件等待。️ 第一幕 · 困局串行排查与「猜时间」的代价先说坏消息。串行排查是这样的钻进文件 A修好再跑发现文件 B 的失败点又变了……三个独立的故障就是三轮完整调试2 点不知不觉到 5 点。更糟的是每轮调试还常撞上flaky 测试await new Promise(r setTimeout(r, 50)); // 希望 50ms 够用 const result getResult(); expect(result).toBeDefined(); // 你机器上绿CI 上死50ms 是纯猜。你机器快刚好够CI 一有负载就挂。这类对时序的猜测正是 flaky 测试的头号根源。 第二幕 · 破局并行代理分发 条件等待登场先看并行代理分发。问题6 个失败各有各的根因你只能一次调一个来回切换上下文反复热身。方案每个问题域派一个 AI 代理一次全部发出三路调查同时跑各只管一个测试文件。一句话原理同一次回复里的所有派遣调用并行执行每个代理只携带你为它精确准备的指令和上下文不继承你的会话历史所以不会走神。不过代理们上手后会撞上同一堵墙——flaky 测试还是因为猜时序而挂。这正是第二个功能条件等待登场的地方问题固定延迟在猜操作要多久快机器过、CI 挂。方案用轮询循环替换setTimeout等到你关心的条件真正成立再往下走。一句话原理等待你关心的条件本身而不是等待一个时长猜测。说白了并行代理分发管分头干活负责提速条件等待管把活写牢负责防 flaky。一个提速一个兜底。 实战演示大重构后6 个红色测试怎么修拿一次真实调试记录走流程。第一步按根因给失败分组agent-tool-abort.test.ts3 个失败时序问题batch-completion-behavior.test.ts2 个失败工具没执行tool-approval-race-conditions.test.ts1 个失败执行计数为 0三个文件、三套根因、互不共享状态——符合并行派遣的条件。第二步一口气发出三个代理Subagent (general-purpose): Fix agent-tool-abort.test.ts failures Subagent (general-purpose): Fix batch-completion-behavior.test.ts failures Subagent (general-purpose): Fix tool-approval-race-conditions.test.ts failures三个同时开工。顺手在每个代理的提示词里写一句别只加超时找真正原因。第三步代理内部用条件等待替换猜测延迟// BEFORE: 希望 50ms 够用 await new Promise(r setTimeout(r, 50)); expect(toolResults.length).toBe(2); // flaky // AFTER: 等条件本身成立 await waitForEventCount(manager, threadId, TOOL_RESULT, 2); expect(toolResults.length).toBe(2); // 稳了代理们全部返回后先确认没人改到同一处文件再跑一遍全量测试——全绿。对等待写法还手生这张速查表直接抄场景推荐写法等事件waitFor(() events.find(e e.type DONE))等状态waitFor(() machine.state ready)等计数waitFor(() items.length 5)复杂条件waitFor(() obj.ready obj.value 10)想看完整打法技能定义在skills/dispatching-parallel-agents/SKILL.md全套等待工具waitForEvent、waitForEventCount、waitForEventMatch的实现在skills/systematic-debugging/condition-based-waiting-example.ts。 数据说话一次真实调试记录来自 2025-10-03 的调试会话6 个失败分布 3 个文件 → 3 个代理并行派遣调查同时完成修复 15 个 flaky 测试3 个文件通过率60% → 100%执行耗时提速约40%所有修复零冲突集成失败越独立并行收益越明显等待越扎实CI 的绿灯越可信。️ 避坑 进阶老朋友的几句提醒先说容易踩的坑故障相关时别并行修好一个可能顺带修好另一个就先一起查代理会编辑同一个文件、共享同一份状态时同样别并行。提示词里那句别只加超时别忘了写不写代理的第一反应就是把 50ms 改成 100msflaky 只是换了个姿势。别在循环前缓存数据轮询循环里每次用 getter 取新值。拿着循环前的旧值条件永远不成立。再给几条调参建议轮询间隔取10ms1ms 费 CPU超过 100ms 又多等超时默认5000ms按场景调超时错误信息里一定说清在等什么、等了多久测时序行为本身debounce、节流间隔是固定延迟的正当场景但要用注释写明时长为什么这么选分头去干等到位再断言——速度与稳定一次拿齐。想深入读skills/dispatching-parallel-agents/SKILL.md与skills/systematic-debugging/condition-based-waiting.md全文。【免费下载链接】superpowersAn agentic skills framework software development methodology that works.项目地址: https://gitcode.com/GitHub_Trending/su/superpowers创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考