如果你同时面对3个完全不相关的bug，为什么要傻乎乎地一个个排查？
这个故事 + 原理 + 时序图，帮你像AI架构师一样思考。
🎪 一、先听一个故事：大厨的平行厨房
想象你是一家超忙餐厅的主厨（主AI） 。
有一天晚餐高峰期，你收到三张退单投诉：
- 冷盘厨房：沙拉里有虫子（测试文件 A 崩溃）
- 热炒厨房：宫保鸡丁太咸（测试文件 B 断言失败）
- 甜点厨房：冰淇淋化了（测试文件 C 超时）
普通主厨的做法 ：
👉 冲到冷盘厨房，检查10分钟 → 修好 → 再去热炒厨房20分钟 → 修好 → 再去甜点厨房15分钟。
总耗时 = 45分钟，而且中间自己累得半死，还要记住每个厨房的细节。
聪明主厨的做法（并行派发特工） ：
👨🍳 喊来三个副厨（子Agent） ：
- "小王，你去搞定冷盘！记住：只动沙拉台，别碰别的。回来告诉我：什么虫子？怎么杀的？"
- "小李，你去搞定热炒！只改宫保鸡丁的配方。回来告诉我：盐放了多少？"
- "小张，你去搞定甜点！只检查冰淇淋机。回来告诉我：压缩机坏没坏？"
结果 ：三个人同时干活，10分钟后全部回来汇报。
总耗时 = 10分钟，而且主厨轻松做统筹。
这就是 dispatching-parallel-agents 的核心：
把多个独立任务，同时派给多个专注的AI，每个AI只负责自己的小世界，互不干扰。
🧩 二、实现原理：拆解AI大脑的「分身术」
1. 核心组件
2. 关键技术点
| 技术名词 | 大白话解释 |
|---|---|
| 隔离上下文 | 每个子Agent不知道你之前聊过什么，也不看到别人的工作。就像小王不知道小李在炒菜。 |
| 独立环境 | 它们可以同时读代码、改文件，只要修改范围不冲突（比如不同文件）。 |
| 精准指令 | 你给的任务必须像"只修冷盘沙拉"一样明确，不能是"让厨房变好"。 |
| 异步并行 | 它们真的同时运行（AI模型支持并行调用），不是轮流。 |
3. 什么时候触发这个技能？
SKILL.md 里用了一个决策流程图，我帮你翻译成人话：
- ✅ 有 3+ 完全不相关的测试挂了 → 用！
- ✅ 不同子系统坏了，修A不影响B → 用！
- ✅ 每个问题都能独立理解（不需要先知道另一个的结果） → 用！
- ❌ 所有失败都是同一个bug引起的 → 别用，先一起修。
- ❌ 你需要看全局状态才能下手 → 别用，自己先探索。
- ❌ 子Agent会改同一个文件，导致冲突 → 别用，或者划分更细。
🚀 三、最佳用法：写好「特工任务书」的4个黄金法则
根据 SKILL.md 的实战经验，一个优秀的任务指令长这样：
markdown
修复 src/agent-tool-abort.test.ts 中的 3 个失败测试：
1. "should abort tool with partial output" → 期望消息里包含 'interrupted at'
2. "should handle mixed completed and aborted tools" → 快速工具被错误中断
3. "should properly track pendingToolCount" → 期望3个结果却得到0
这些是竞态条件问题。你的任务：
- 读测试文件，理解每个测试想测什么
- 找出根本原因（是代码bug还是时序问题？）
- 用"事件驱动等待"替换"固定延时"，不要只加大timeout
- 如果发现实现bug，就修；如果测试预期不合理，可以调整
不允许修改其他测试文件。
返回：你发现了什么根因？你改了哪些代码？法则拆解（对照故事里的副厨指令）
| 黄金法则 | 故事版 | 技术版 |
|---|---|---|
| 1. 聚焦一个领域 | "小王只去冷盘" | 指定单个测试文件或模块 |
| 2. 给足上下文 | "沙拉里有虫子，投诉单在这里" | 贴上具体错误信息和测试名称 |
| 3. 设边界约束 | "别碰其他台子" | "不要修改生产代码 / 不要改其他文件" |
| 4. 明确输出格式 | "回来告诉我：什么虫子？怎么杀的？" | "返回根因 + 修改摘要" |
❌ 错误示例（太宽泛）：
"帮我修好所有测试"
→ 子Agent会迷茫，可能重写整个项目。
❌ 错误示例（没给错误信息）：
"修一下那个race condition"
→ 子Agent不知道"那个"是哪个。
⏱️ 四、时序图：从主AI派发到集成，一步步动画
关键点解释：
par块表示三个子Agent 真正并行发起（不是顺序）。- 每个子Agent有自己的代码读写权限，但只改自己负责的部分。
- 主AI等待所有返回后再做整合------这比顺序快3倍。
🎯 五、什么时候不要用？（来自SKILL.md的真实教训）
| 场景 | 为什么不合适 | 那应该怎么做？ |
|---|---|---|
| 三个测试失败都是同一个函数改坏了 | 修一个可能全好 | 只派一个Agent去修那个函数 |
| 你需要先看日志A才能理解日志B | 有依赖 | 顺序派发（先A再B） |
两个Agent都会改 config.ts |
合并冲突 | 手动拆分任务，或者自己改 |
| 你还不确定问题范围 | 探索阶段 | 自己先快速定位，再派发 |
🌟 六、真实世界效果：来自2025-10-03的案例
某次大重构后，6个测试失败，分布在3个文件。
主AI判断：每个文件的失败原因不同（竞态、事件结构、异步等待）。
并行派发3个Agent。
10分钟后全部返回，各自给出根因和修复。
合并后全量测试通过，零冲突 。
节省时间：原本40分钟 → 实际12分钟（含写指令）。
💡 七、总结成三句话
- 遇到多个不相关的麻烦 → 像餐厅主厨一样，同时派三个副厨去修。
- 给每个副厨写清楚"修哪里、不许碰哪里、回来告诉我什么" → 这是任务卡。
- 他们同时干活，你最后拼结果 → 时间变短，脑子不累。
终极心法
并行派发特工的本质不是"更努力"，而是放弃控制细节，相信专注的AI小分队 。
你只需要当一个会写"好指令"的协调者。
现在，你也是半个AI马车夫了 🎉 下次遇到多测试失败，记得试试这个超级技能。