用途
当面对多个互不相关的失败（不同测试文件、不同子系统、不同缺陷）时，逐个顺序排查会浪费时间。每个排查彼此独立，可以并行进行。本技能的核心原则是：为每个独立问题域派发一个智能体，让它们并发工作。
何时使用
适用场景：
- 3 个以上测试文件因不同根因失败
- 多个子系统独立损坏
- 每个问题无需其他问题的上下文即可理解
- 各排查之间没有共享状态
不适用场景：
- 失败彼此相关（修好一个可能连带修好其他）
- 需要理解整个系统状态
- 智能体之间会相互干扰
资料中给出的判断流程为：先判断是否存在多个失败；若存在，判断它们是否独立；若不独立，则由单个智能体统一排查；若独立，再判断能否并行；若存在共享状态则顺序执行，否则并行派发。
主要能力与模式
- 识别独立问题域：按“坏在哪里”对失败分组，例如文件 A 测试工具审批流程、文件 B 测试批量完成行为、文件 C 测试中止功能，每个域相互独立。
- 创建聚焦的智能体任务：每个智能体获得具体范围（一个测试文件或子系统）、清晰目标（让这些测试通过）、约束（不要改动其他代码）、预期输出（发现与修复的总结）。
- 并行派发：在 Claude Code / AI 环境中通过 Task 调用同时运行多个任务，例如：
Task("Fix agent-tool-abort.test.ts failures")
Task("Fix batch-completion-behavior.test.ts failures")
Task("Fix tool-approval-race-conditions.test.ts failures")
// All three run concurrently
- 审查与集成：智能体返回后，阅读每份总结、验证修复不冲突、运行完整测试套件、集成所有改动。
使用方式：智能体提示词结构
好的智能体提示词应当聚焦（一个清晰问题域）、自包含（包含理解问题所需的全部上下文）、对输出有明确要求（智能体应返回什么）。资料给出的示例提示词要求修复 src/agents/agent-tool-abort.test.ts 中 3 个失败测试，列出每个测试的期望与实际，说明属于时序/竞态问题，并要求：阅读测试文件理解每个测试验证的内容、识别根因（时序问题还是真实缺陷）、通过用基于事件的等待替换任意超时、修复中止实现中的缺陷、或在测试行为已变化时调整测试期望来修复，明确要求“不要只是增加超时——找到真正的问题”，最后返回发现与修复的总结。
常见错误
- 范围过宽：“修复所有测试”会让智能体迷失；应具体到某个测试文件。
- 缺少上下文：“修复竞态条件”让智能体不知从何下手；应粘贴错误信息和测试名称。
- 没有约束：智能体可能重构一切；应写明“不要改动生产代码”或“只修测试”。
- 输出含糊：“修好它”让你不知道改了什么；应要求返回根因与改动的总结。
何时不要使用
- 失败相关：修好一个可能修好其他，应先一起排查。
- 需要完整上下文：理解问题需要看到整个系统。
- 探索性调试：尚不知道哪里坏了。
- 共享状态：智能体会相互干扰（编辑同一文件、使用同一资源）。
真实示例
场景：一次重大重构后，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 个问题的时间解决）。
验证
智能体返回后：审查每份总结了解改动、检查是否冲突（是否编辑了同一代码）、运行完整套件验证所有修复协同工作、抽查（智能体可能犯系统性错误）。
实际影响
资料记录的一次调试会话（2025-10-03）中：3 个文件 6 个失败，并行派发 3 个智能体，所有排查并发完成，所有修复成功集成，智能体改动之间零冲突。
限制
资料未提供该技能的安装命令、收费方式、支持平台等具体信息。