当面对 2 个以上可以独立进行、无共享状态或顺序依赖的任务时使用

并行分派智能体概述你将任务委派给具有隔离上下文的专用智能体。通过精心设计它们的指令和上下文，确保它们专注并成功完成任务。它们不应继承你的会话上下文或历史记录——你要精确构造它们所需的一切。这样也能为你自己保留用于协调工作的上下文。当你遇到多个不相关的失败（不同的测试文件、不同的子系统、不同的 bug），逐一排查会浪费时间。每个排查都是独立的，可以并行进行。核心原则：每个独立问题域分派一个智能体，让它们并发工作。何时使用适用场景： 3 个以上测试文件因不同根因失败多个子系统独立出现故障每个问题无需其他问题的上下文即可理解排查之间无共享状态不适用场景：失败是相关的（修复一个可能修复其他的）需要理解完整的系统状态智能体之间会互相干扰模式 1. 识别独立的问题域按故障分组：文件 A 测试：工具审批流程文件 B 测试：批量完成行为文件 C 测试：中止功能每个问题域是独立的——修复工具审批不会影响中止测试。 2. 创建聚焦的智能体任务每个智能体获得：明确范围：一个测试文件或子系统清晰目标：让这些测试通过约束条件：不修改其他代码预期输出：你发现和修复内容的总结 3. 并行分派 4. 审查与集成当智能体返回时：阅读每个总结验证修复之间没有冲突运行完整测试套件集成所有更改智能体提示词结构好的智能体提示词应该是： 1. 聚焦的一个清晰的问题域 2. 自包含的包含理解问题所需的所有上下文 3. 明确输出要求智能体应该返回什么？常见错误错误做法：太宽泛： "修复所有测试" 智能体会迷失方向正确做法：具体明确： "修复 agent tool abort.test.ts" 聚焦的范围错误做法：无上下文： "修复竞态条件" 智能体不知道在哪里正确做法：提供上下文：粘贴错误信息和测试名称错误做法：无约束：智能体可能会重构所有代码正确做法：设置约束： "不要修改生产代码" 或 "只修复测试" 错误做法：模糊的输出要求： "修好它" 你不知道改了什么正确做法：明确要求： "返回根因和修改内容的总结" 不适用的场景关联性失败：修复一个可能修复其他的——先一起排查需要完整上下文：理解问题需要看到整个系统探索性调试：你还不知道什么坏了共享状态：智能体会互相干扰（编辑同一文件、使用同一资源）实际案例场景：大规模重构后，3 个文件中出现 6 个测试失败失败情况： agent tool abort.test.ts：3 个失败（时序问题） batch completion behavior.test.ts：2 个失败（工具未执行） tool approval race conditions.test.ts：1 个失败（执行计数 = 0）决策：独立的问题域——中止逻辑、批量完成、竞态条件各自独立分派：结果：智能体 1：用基于事件的等待替换了超时智能体 2：修复了事件结构 bug（threadId 位置不对）智能体 3：添加了等待异步工具执行完成的逻辑集成：所有修复互相独立，无冲突，完整测试套件全部通过验证智能体返回后： 1. 审查每个总结理解改了什么 2. 检查冲突智能体是否编辑了同一段代码？ 3. 运行完整套件验证所有修复协同工作 4. 抽查智能体可能犯系统性错误

dispatching-parallel-agents