当你面临 2 个及以上可独立推进、无共享状态或顺序依赖的任务时使用。
你将任务委派给具有隔离上下文的专职代理。通过精确编写指令与上下文，确保他们专注并成功完成任务。他们不应继承你本会话的上下文或历史——你只构造他们所需的信息。这也为你保留自身上下文以做协调。
当你有多个互不相关的失败（不同测试文件、不同子系统、不同 bug）时，顺序排查浪费时间；每次排查彼此独立，可并行进行。
核心原则： 每个独立问题域派发一个代理，让他们并发工作。
digraph when_to_use {
"多个失败？" [shape=diamond];
"彼此独立？" [shape=diamond];
"单代理排查全部" [shape=box];
"每问题域一代理" [shape=box];
"能并行？" [shape=diamond];
"顺序代理" [shape=box];
"并行派发" [shape=box];
"多个失败？" -> "彼此独立？" [label="是"];
"彼此独立？" -> "单代理排查全部" [label="否 - 相关"];
"彼此独立？" -> "能并行？" [label="是"];
"能并行？" -> "并行派发" [label="是"];
"能并行？" -> "顺序代理" [label="否 - 共享状态"];
}
适用于：
按「什么坏了」分组失败：
各域独立——修审批不会影响中止测试。
每个代理获得：
// 在 Claude Code / AI 环境中
Task("修复 agent-tool-abort.test.ts 的失败")
Task("修复 batch-completion-behavior.test.ts 的失败")
Task("修复 tool-approval-race-conditions.test.ts 的失败")
// 三者并发运行
代理返回后：
好的代理提示具备：
修复 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. 识别根因 — 时序问题还是真实 bug？
3. 修复方式：
- 将任意超时替换为基于事件的等待
- 若中止实现有 bug 则修复
- 若测试的是已变更行为则调整期望
不要只增大超时 — 找到真正原因。
返回：你发现并修复了什么的摘要。
❌ 过宽：「修所有测试」— 代理会迷失
✅ 具体：「修 agent-tool-abort.test.ts」— 范围聚焦
❌ 无上下文：「修竞态」— 代理不知道在哪
✅ 有上下文： 粘贴错误信息与测试名
❌ 无约束： 代理可能重构一切
✅ 有约束：「不要改生产代码」或「只修测试」
❌ 输出模糊：「修好它」— 你不知道改了什么
✅ 输出明确：「返回根因与变更摘要」
相关失败： 修一个可能修好别的 — 先一起排查
需要完整上下文： 理解依赖看到整个系统
探索式调试： 还不清楚哪里坏了
共享状态： 代理会互相干扰（编辑同一文件、争用同一资源）
场景： 大重构后 3 个文件共 6 个测试失败
失败：
决策： 独立域 — 中止逻辑、批完成、竞态彼此分离
派发：
代理 1 → 修 agent-tool-abort.test.ts
代理 2 → 修 batch-completion-behavior.test.ts
代理 3 → 修 tool-approval-race-conditions.test.ts
结果：
集成： 修复彼此独立、无冲突，全绿
节省时间： 3 个问题并行解决 vs 顺序
代理返回后：
来自调试会话（2025-10-03）：