用途
dispatching-parallel-agents 面向“多个独立问题需要同时排查或处理”的场景。资料说明：当存在多个不相关的失败（不同测试文件、不同子系统、不同缺陷）时，逐个顺序排查会浪费时间；由于每次排查彼此独立，因此可以并行进行。其核心原则是：每个独立的问题域派发一个智能体，让它们并发工作。资料标注的触发条件为“面对 2 个及以上、可以无共享状态或顺序依赖地处理的独立任务”。
何时使用
资料给出的使用判断流程为：是否有多处失败 → 这些失败是否相互独立 → 是否能并行工作。仅当失败相互独立、且可以并行时，才进行并行派发；若失败互相关联，则由单个智能体统一排查；若存在共享状态，则采用顺序智能体。
具体适用情形：
- 3 个及以上测试文件失败，且根因各不相同
- 多个子系统各自独立地损坏
- 每个问题无需借助其他问题的上下文即可被理解
- 各次排查之间没有共享状态
主要能力与模式
技能描述的并行调度模式分为四步：
- 识别独立问题域：按“哪里坏了”对失败分组。资料示例中，文件 A 测试工具审批流程、文件 B 测试批量完成行为、文件 C 测试中止（abort）功能，三者彼此独立。
- 创建聚焦的智能体任务：每个智能体获得明确范围（一个测试文件或子系统）、清晰目标（让这些测试通过）、约束（不要改动其他代码）、期望输出（说明发现与修复内容的总结）。
- 并行派发：资料给出调用示例，三行 Task 调用会并发运行。
- 审阅与集成：读取每个总结、确认修复之间不冲突、运行完整测试套件、集成全部改动。
使用方式与提示词结构
资料强调良好的智能体提示词应是：聚焦（一个明确的问题域）、自包含（包含理解问题所需的全部上下文）、对输出有明确要求。
资料给出的提示词示例要求智能体：读取测试文件并理解每个测试在验证什么；判断根因是时序问题还是真实缺陷；通过用基于事件的等待替代任意超时、修复中止实现中的缺陷（如发现）、或在测试行为已变化时调整测试预期来修复；并明确要求“不要只是增大超时，要找到真正的问题”，最后返回发现与修复的总结。
资料要求向智能体提供具体测试文件名、错误信息与测试名称，并给出约束示例，例如“不要改动生产代码”或“只修测试”。
常见错误（资料列举）
- 范围过宽，如“修复所有测试”，智能体会迷失；应具体到某个测试文件。
- 缺乏上下文，如“修复竞态条件”，智能体不知道在哪里；应粘贴错误信息和测试名称。
- 缺少约束，智能体可能大范围重构；应写明“不要改动生产代码”或“只修测试”。
- 输出要求含糊，如“修好它”，你不知道改了什么；应要求返回根因与改动的总结。
不适用的情况
- 失败相互关联：修复一个可能顺带修好其他，应先一起排查。
- 需要完整上下文：理解问题必须看到整个系统状态。
- 探索性调试：尚不清楚哪里坏了。
- 共享状态：智能体会互相干扰（编辑相同文件、使用相同资源）。
真实示例与效果
资料记录了一次会话场景：一次大规模重构后，3 个文件共出现 6 个测试失败——agent-tool-abort.test.ts 有 3 个失败（时序问题），batch-completion-behavior.test.ts 有 2 个失败（工具未执行），tool-approval-race-conditions.test.ts 有 1 个失败（执行计数为 0）。判断为相互独立的问题域后，并行派发 3 个智能体分别处理。结果显示：智能体 1 用基于事件的等待替代超时；智能体 2 修复了事件结构缺陷（threadId 放错位置）；智能体 3 增加了对异步工具执行完成的等待。集成后所有修复相互独立、无冲突，完整测试套件通过。
资料总结的主要收益为：并行化（多个排查同时进行）、聚焦（每个智能体范围窄、需跟踪的上下文少）、独立性（智能体互不干扰）、速度（3 个问题以 1 个问题的时间解决）。验证环节要求：审阅每份总结、检查是否存在冲突（是否编辑了相同代码）、运行完整套件确认所有修复协同工作，并进行抽查，因为智能体可能产生系统性错误。
限制
资料未提供该技能的安装命令、具体平台支持范围、收费或价格信息，暂未提供。使用时应以其并列出的“不适用”条件为边界，且最终必须由人工审阅、核对冲突并跑完整测试套件验证。