用途
本技能用于调试场景下的并行代理调度。当你面对多个互不相关的失败（不同测试文件、不同子系统、不同缺陷）时，顺序排查会浪费时间；每个排查相互独立，可以并行进行。核心原则是：为每个独立问题域派发一个代理，让它们并发工作。
何时使用
适用条件：
- 3个以上测试文件因不同根因失败
- 多个子系统独立损坏
- 每个问题无需其他问题的上下文即可理解
- 各排查之间没有共享状态
不适用条件：
- 失败彼此相关（修好一个可能连带修好其他）
- 需要理解整个系统状态
- 代理之间会互相干扰
判断流程可用有向图表示：是否存在多个失败→它们是否独立→能否并行→并行派发或顺序代理。
模式步骤
- 识别独立问题域：按损坏对象对失败分组，例如文件A测试涉及工具审批流程、文件B测试涉及批量完成行为、文件C测试涉及中止功能，每个域相互独立。
- 创建聚焦的代理任务：每个代理获得具体范围（一个测试文件或子系统）、清晰目标（让这些测试通过）、约束（不要改动其他代码）、期望输出（所发现和修复内容的摘要）。
- 并行派发：在AI环境中使用Task调用，例如同时派发三个任务分别修复三个测试文件的失败，三者并发运行。
- 审查与集成：当代理返回后，阅读每份摘要、验证修复之间不冲突、运行完整测试套件、集成所有更改。
代理提示词结构
好的代理提示词应当是聚焦的（一个清晰问题域）、自包含的（包含理解问题所需的全部上下文）、对输出有明确要求（代理应返回什么）。示例提示词会列出失败测试名称与期望行为，说明属于时序/竞态问题，并要求：阅读测试文件、识别根因、通过用基于事件的等待替换任意超时或修复中止实现等方式修复，明确要求不要只是增加超时、要找到真正问题，最后返回发现与修复摘要。
常见错误
- 范围过宽：如“修复所有测试”会让代理迷失；应具体到某个测试文件。
- 缺少上下文：如“修复竞态条件”代理不知道位置；应粘贴错误信息和测试名称。
- 缺少约束：代理可能重构一切；应写明“不要改动生产代码”或“只修测试”。
- 输出模糊：如“修好它”；应要求返回根因与更改摘要。
不应使用的情况
相关失败（修一个可能修好其他，应先一起排查）、需要完整上下文（理解需查看整个系统）、探索性调试（尚不知何处损坏）、共享状态（代理会互相干扰，如编辑同一文件、使用同一资源）。
实际案例
场景：一次大规模重构后，3个文件共6处测试失败——agent-tool-abort.test.ts 3处（时序问题）、batch-completion-behavior.test.ts 2处（工具未执行）、tool-approval-race-conditions.test.ts 1处（执行计数为0）。判断为独立问题域后派发三个代理分别处理。结果：代理1用基于事件的等待替换超时；代理2修复事件结构缺陷（threadId 位置错误）；代理3增加等待异步工具执行完成。集成时所有修复相互独立、无冲突，完整测试套件通过。相比顺序处理节省了时间。
关键收益与验证
收益：并行化、聚焦（每个代理范围窄）、独立性（互不干扰）、速度（3个问题以1个问题的时间解决）。验证：代理返回后审查每份摘要、检查是否冲突（是否编辑了同一代码）、运行完整套件、抽查（代理可能犯系统性错误）。资料记录的一次调试会话（2025-10-03）中，3个文件6处失败由3个代理并行处理，所有排查并发完成、所有修复成功集成、代理更改之间零冲突。