并行代理调度Skill：让 3 个独立 Bug 在 1 个 Bug 的时间里被修好
- 一句话定位：当你有多个互不相关的失败（不同测试文件、不同子系统、不同报错）时，不要一个接一个查，而是「一个独立问题领域派一个代理」，让它们同时干活。
- 核心机制：先判断失败之间是否独立、能否并行，再为每个领域生成「范围明确、上下文自包含、输出格式固定」的代理任务，最后统一审查与集成。
- 适用边界清晰：相关失败、需要完整系统上下文、代理会互相干扰（改同一个文件或抢同一份资源）时，明确不建议并行。
- 真实收益：官方给出的会话实录中，3 个测试文件共 6 个失败，通过 3 个代理并行调查，同时完成、零冲突集成。
- 上手门槛低：不需要新语言或新框架，本质是一套「怎么拆分任务、怎么写代理提示词」的调度方法论，AI 编程环境里可直接用
Task()派发。
1. 该技能叫什么？如何下载安装 AI 技能提升开发效率？
技能基本信息
| 项目 | 内容 |
|---|---|
| 中文名 | 并行代理调度Skill |
| 英文名 | dispatching-parallel-agents |
| 技能ID | 12208 |
| 类型 | 调试/任务编排类 AI 技能 |
它到底解决什么问题？
日常开发中最浪费时间的场景之一，就是「一次重构后，好几个地方同时炸了」。比如 3 个测试文件各挂了几条用例，原因完全不同：一个卡在时序上、一个是事件结构写错了字段位置、一个是异步执行没等待完成。
如果按传统做法顺序排查，你需要反复切换上下文：读完 A 文件的失败、改完、跑一遍、再切到 B 文件……每一次切换都要重新建立心智模型，而这几件事本来毫无关系。
并行代理调度Skill 给出的答案很直接：每个独立问题领域派遣一个代理，让他们并发工作。它不是一个软件包，而是一套被沉淀下来的调度模式——判断条件、拆分方法、提示词结构、审查流程都写清楚了。
如何安装（一键引入）AI 技能
该技能以「技能（Skill）」的形式分发，安装步骤取决于你使用的 AI 编程环境。以下为通用思路，具体命令、入口与目录规范以官方说明为准：
- 确认安装前提
- 你使用的 AI 编程环境需要支持技能加载（Skill）与子任务派发（如
Task()这类并行调用能力）。 - 环境中需要有可运行的测试套件（能独立跑单个测试文件），这样才能验证修复效果。
- 你使用的 AI 编程环境需要支持技能加载（Skill）与子任务派发（如
- 获取技能包
- 从技能市场/技能仓库中按名称
dispatching-parallel-agents或技能ID12208检索并添加；具体检索入口与安装命令以官方说明为准。
- 从技能市场/技能仓库中按名称
- 放置与启用
- 通常需要把技能放入客户端的技能目录并在配置中启用，路径与配置字段请以官方说明为准。
- 验证是否生效
- 在对话中提出一个「多个独立失败」的调试请求，观察 AI 是否先做「独立性判断」，再输出拆分后的多个代理任务；如果它按这个套路走，说明技能已生效。
- 也可以直接问一句「这个场景该用并行代理调度吗」，看它是否给出「是否独立 / 能否并行」的判断依据。
提示：如果环境不支持并行派发，这套方法论依然可用——你可以把三个「代理任务」当成三份独立提示词，依次喂给 AI，虽然不并行，但「专注范围 + 自包含上下文 + 固定输出」的结构依然能显著降低混乱。
2. 该技能的主要功能和特点
- 内置「何时用 / 何时不用」判断树：技能先问四个问题——是否存在多个失败？它们是否独立？能否并行？有没有共享状态？据此决定是单代理统一调查、并行派遣，还是顺序执行。这条判断链是它最有价值的部分，避免了「为并行而并行」。
- 按「问题领域」切分而不是按「文件数量」切分：技能要求按「坏了什么」分组，例如工具批准流程、批量完成行为、中止功能，每个领域独立成一块。判断标准是：修好 A 不影响 B。
- 强约束的代理提示结构：一个好的代理提示必须同时满足三点——专注（一个清晰问题领域）、自包含（理解问题所需的全部上下文，包括错误消息和测试名）、输出具体（明确要求返回根原因与改动摘要）。
- 显式反模式清单：技能明确列出四类常见错误——太宽泛（“修复所有测试”）、无上下文（“修复竞争条件”）、无约束（代理可能顺手重构整个项目）、模糊输出（"修好了"但你不知道改了什么），并逐条给出正确写法。
- 派发-审查-集成闭环：代理返回后不是直接收工，而是要求逐个阅读摘要、检查是否编辑了同一段代码、跑完整测试套件、再做抽查（因为代理可能犯系统性错误）。
- 反对"加超时"式假修复：示例中特别强调"不要只是增加超时——找到真正的问题"，引导代理用基于事件的等待替代随意超时。
- 与普通工具相比强在哪：普通测试运行器只能告诉你"哪些测试挂了"，但它不解决"谁来修、怎么并行修、怎么防止打架"。这个技能补的正是任务拆分与协同这一层。
3. 如何使用该技能？
步骤一：先判断该不该并行
对着技能给出的判断链自问：
- 失败数量是否 ≥ 2，且通常达到「3 个或更多测试文件因不同根原因失败」的规模？
- 每个问题能否在不了解其他问题的前提下被理解？
- 修复过程之间是否存在共享状态（同一文件、同一资源、同一份数据）？
任意一条不满足，就应该退回单代理或顺序模式。
步骤二：按「损坏内容」分组，而不是按「报错时间」分组
技能里的分组示例：
- 文件 A 测试 → 工具批准流程
- 文件 B 测试 → 批量完成行为
- 文件 C 测试 → 中止功能
三个领域互不相干，修好工具批准不会影响中止测试，因此可以并行。
步骤三：为每个代理写一份「专注 + 自包含 + 输出明确」的任务
参考技能中的提示模板（示意）：
修复 src/agents/agent-tool-abort.test.ts 中的 3 个失败测试：
1. "should abort tool with partial output capture" - 期望消息中有 'interrupted at'
2. "should handle mixed completed and aborted tools" - 快速工具中止而不是完成
3. "should properly track pendingToolCount" - 期望 3 个结果但得到 0
这些是时序/竞争条件问题。你的任务：
1. 阅读测试文件并理解每个测试验证什么
2. 识别根原因——时序问题还是实际错误？
3. 通过以下方式修复：用基于事件的等待替换任意超时 / 修复中止实现中的错误 / 调整测试期望
不要只是增加超时——找到真正的问题。
返回：你发现和修复的内容摘要。
注意这份提示里包含了四要素：具体文件与用例名、原始期望与实际行为、可用手段、明确禁止项。
步骤四：并行派遣
在支持子任务的环境里一次性派发多个任务：
Task("修复 agent-tool-abort.test.ts 失败")
Task("修复 batch-completion-behavior.test.ts 失败")
Task("修复 tool-approval-race-conditions.test.ts 失败")
// 三个任务同时运行
步骤五：审查、验证、集成
代理返回后按四步走：
- 逐个读摘要：确认每个代理到底改了什么、根原因是什么。
- 检查冲突：是否有两个代理编辑了同一段代码。
- 跑完整测试套件：确保三个修复放在一起仍然全绿。
- 抽查：防止代理犯系统性错误（比如统一加了
sleep）。
输入输出示例说明
- 输入：一组失败测试的文件名、用例名、实际 vs 期望行为描述。
- 输出：每个代理一份「根原因 + 修改内容」摘要，供你集成。
- 技能中的真实会话结果显示：代理一用事件等待替换了超时，代理二修正了事件结构（threadId 放错位置），代理三补上了等待异步工具执行完成的逻辑，三处改动零冲突。
4. 同类型竞品对比分析
| 方案名称 | 定位 | 核心功能 | 安装/使用门槛 | 适用场景 | 优势与不足 |
|---|---|---|---|---|---|
| 并行代理调度Skill（dispatching-parallel-agents） | 面向 AI 编程环境的多代理调试调度方法论 | 独立性判断、领域拆分、提示词结构、并行派发、集成审查 | 需要有支持技能加载与子任务派发的 AI 环境；无需新语言（以官方说明为准） | 一个仓库内多个测试文件因不同根原因失败、多子系统同时损坏 | 优势：分工清晰、有反模式清单、强调集成验证；不足：不适用于相关失败，依赖环境支持并行派发 |
| 顺序单代理调试 | 传统做法：一个 AI 会话依次排查所有失败 | 逐个定位、逐个修复 | 门槛最低，任何对话式 AI 都能做 | 失败之间存在关联，或问题根因尚不明确 | 优势：上下文连贯、不易冲突；不足：多问题场景下上下文越滚越脏，耗时线性叠加 |
| 并行测试运行器（如测试框架自带的多进程/分片执行） | 加速「跑测试」，不负责「修测试」 | 多进程/分片执行用例、汇总报告 | 需配置运行参数，通常开箱即用 | 测试执行时间长、想缩短反馈周期 | 优势：成熟稳定、纯提速；不足：只告诉你哪里挂了，修复环节仍需人工或单代理串行处理 |
| 通用多智能体编排框架 | 通用型 agent 编排 | 自定义角色、通信、工作流 | 需要编写编排代码与配置，学习成本较高 | 复杂业务流程、跨系统自动化 | 优势：灵活可扩展；不足：没有内置「独立失败」这类具体调试场景的判断规则与提示模板，容易过度设计 |
选型建议：如果你的痛点是「多个独立 bug 排队修」，优先用本技能；如果痛点是「测试跑得慢」，用并行测试运行器；如果失败彼此相关，老老实实单代理顺序排查。
5. 该技能的典型应用场景与实际体验情况
场景一：大重构后的多文件测试失败
- 角色：后端/全栈开发工程师。
- 痛点：一次重构后 3 个文件里 6 条用例挂掉，逐条排查要来回切换上下文，一下午就没了。
- 使用方式：确认三处失败互不相关后，派发 3 个代理，各自只负责一个测试文件。
场景二：多子系统同时报警
- 角色：SRE / 值班工程师。
- 痛点：发布后多个独立子系统出现不同错误，逐个查会拖长故障窗口。
- 使用方式：按子系统切分，每个子系统一个代理，并明确「不要改动其他子系统代码」的约束。
场景三：代码库级批量修复
- 角色：负责代码质量的工程师。
- 痛点：类型检查、Lint 在不同模块里报出成批互相独立的错误。
- 使用方式：按目录/模块分片派发，每个代理返回「根原因 + 改动摘要」，最后统一跑全量检查。
场景四：竞态与时序问题分头定位
- 角色：测试工程师。
- 痛点：多个用例都表现为"偶发失败"，看起来像一类问题，实际根因各不相同。
- 使用方式：技能会提醒先做独立性判断——如果只是表象相似，仍可并行；但如果共享同一段被测逻辑，则应合并调查。
实际体验情况
- 上手难度：低。不需要安装复杂依赖，核心是"照着判断树问自己几个问题"，再按模板写提示词。第一次用可能觉得提示词写得太啰嗦，但正是这些细节（用例名、期望值、禁止项）让代理不再跑偏。
- 效果：从技能记录的会话看，3 个代理并行调查、全部修复成功集成、代理改动之间零冲突，多个问题在约一个问题的等待时间内解决。
- 注意事项：
- 不要跳过集成验证。单个代理跑绿不等于合起来跑绿，必须跑完整套件。
- 警惕系统性错误。如果三个代理都选择"加超时"这种偷懒方案，抽查时能一眼看出。
- 共享状态是红线。两个代理同时改同一个文件，冲突成本可能高于并行节省的时间。
6. 该技能能为用户带来的价值
- 把等待时间从"相加"变成"取最大值"：3 个独立问题并行处理，实际耗时接近 1 个问题的时间，这是最直接的效率收益。
- 降低上下文负担：每个代理只看一小块，不需要把整个仓库的问题都塞进一个会话里，AI 的判断质量更稳定，人也更容易 review。
- 把"经验"变成"流程"：什么时候该并行、什么时候千万别并行、提示词要写哪几项、返回后要检查什么——这些原本靠老手直觉的东西，被固化成了可复用的判断树与模板，新人也能照着做。
- 减少返工：明确要求代理返回「根原因 + 改动摘要」，配合冲突检查与全量测试，避免了"修好了但不知道为什么好了"这种技术债。
- 长期价值：这套模式并不局限于调试测试，凡是「可以拆成多个无共享状态的独立子任务」的工作——批量迁移、多模块排查、文档分片处理——都能套用同一套拆分与派发思路。
7. 常见问题 FAQ
Q1：这个技能怎么安装？需要额外付费吗？ A：它是以技能包形式分发的，安装方式取决于你使用的 AI 编程环境，具体命令、放置目录与启用方式以官方说明为准；是否收费同样取决于所在平台的规则，请以官方说明为准。如果环境不支持并行派发，也可以把它当作一套提示词方法论，手工拆分任务使用。
Q2：是不是所有多失败场景都该用并行代理？ A：不是。技能明确列出四种「不要使用」的情况：失败彼此相关（修一个可能修好其他）、需要理解完整系统状态、仍处于探索性调试阶段（还不清楚什么坏了）、代理之间会互相干扰（改同一文件或用同一资源）。这些情况下顺序调查反而更快更稳。
Q3：并行代理会不会改出冲突？ A：技能对此有三重防护：一是任务提示里写明"不要更改其他代码"之类的约束；二是派发前按独立领域切分，从源头避免重叠；三是代理返回后逐项检查是否编辑了相同代码，并跑完整测试套件验证。技能记录的真实案例中，3 个代理的改动最终零冲突集成。
Q4：适合谁用？ A：最适合经常面对「一堆互不相关的失败」的开发者、测试工程师和值班运维；对希望把多智能体协作真正用起来的团队也有参考价值。如果你是单文件小改动、或者失败之间存在明显因果链，用它的收益有限。
Q5：怎么判断一个失败领域是不是真的"独立"？ A：技能给了一个简单判据：修复 A 是否可能顺带修复 B。如果会，说明相关，应先合并调查；如果修好工具批准流程完全不影响中止功能的测试，那就是独立领域，可以并行。