con un clic
dispatching-parallel-agents
当面临 2 个以上可以独立工作且没有共享状态或顺序依赖关系的任务时使用
Menú
当面临 2 个以上可以独立工作且没有共享状态或顺序依赖关系的任务时使用
在进行任何创造性工作之前,你必须使用此功能——创造特性、构建组件、添加功能或修改行为。在实施之前探索用户意图、需求和设计。
当你有一份书面的实施 plan 要在单独的会话中执行,并带有审查检查点时使用
当实施完成,所有测试通过,你需要决定如何集成工作时使用 - 通过提供合并、PR 或清理的结构化选项来指导开发工作的完成
当完成任务、实施主要功能或在合并之前验证工作是否符合要求时使用
当在当前会话中执行具有独立任务的实施 plans 时使用
当遇到任何 bug、测试失败或意外行为时使用,在提出修复之前
| name | dispatching-parallel-agents |
| description | 当面临 2 个以上可以独立工作且没有共享状态或顺序依赖关系的任务时使用 |
当你有多个不相关的 failures(失败)(不同的测试文件、不同的子系统、不同的 bug)时,按顺序调查它们会浪费时间。每个调查都是独立的,可以并行进行。
核心原则: 为每个独立的问题 domain(领域)dispatch 一个 agent。让它们并发工作。
digraph when_to_use {
"Multiple failures?" [shape=diamond];
"Are they independent?" [shape=diamond];
"Single agent investigates all" [shape=box];
"One agent per problem domain" [shape=box];
"Can they work in parallel?" [shape=diamond];
"Sequential agents" [shape=box];
"Parallel dispatch" [shape=box];
"Multiple failures?" -> "Are they independent?" [label="yes"];
"Are they independent?" -> "Single agent investigates all" [label="no - related"];
"Are they independent?" -> "Can they work in parallel?" [label="yes"];
"Can they work in parallel?" -> "Parallel dispatch" [label="yes"];
"Can they work in parallel?" -> "Sequential agents" [label="no - shared state"];
}
使用场景:
不使用场景:
根据损坏的内容将 failures 分组:
每个 domain 都是独立的 - 修复工具批准不会影响中止测试。
每个 agent 获得:
// In Claude Code / AI environment
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
当 agents 返回时:
好的 agent prompts 是:
Fix the 3 failing tests in src/agents/agent-tool-abort.test.ts:
1. "should abort tool with partial output capture" - expects 'interrupted at' in message
2. "should handle mixed completed and aborted tools" - fast tool aborted instead of completed
3. "should properly track pendingToolCount" - expects 3 results but gets 0
These are timing/race condition issues. Your task:
1. Read the test file and understand what each test verifies
2. Identify root cause - timing issues or actual bugs?
3. Fix by:
- Replacing arbitrary timeouts with event-based waiting
- Fixing bugs in abort implementation if found
- Adjusting test expectations if testing changed behavior
Do NOT just increase timeouts - find the real issue.
Return: Summary of what you found and what you fixed.
❌ 太宽泛: "Fix all the tests" - agent 会迷失方向 ✅ 具体: "Fix agent-tool-abort.test.ts" - 专注的 scope
❌ 无上下文: "Fix the race condition" - agent 不知道在哪里 ✅ 上下文: 粘贴错误消息和测试名称
❌ 无约束: Agent 可能会重构所有内容 ✅ 约束: "Do NOT change production code" 或 "Fix tests only"
❌ 模糊输出: "Fix it" - 你不知道改变了什么 ✅ 具体: "Return summary of root cause and changes"
相关 failures: 修复一个可能会修复其他 - 先一起调查 需要完整上下文: 理解需要查看整个系统 探索性调试: 你还不知道哪里坏了 共享状态: Agents 会相互干扰(编辑相同的文件,使用相同的资源)
场景: 重大重构后,3 个文件中有 6 个测试失败
Failures:
决定: 独立 domains - abort 逻辑与批量完成和 race conditions 分离
Dispatch:
Agent 1 → Fix agent-tool-abort.test.ts
Agent 2 → Fix batch-completion-behavior.test.ts
Agent 3 → Fix tool-approval-race-conditions.test.ts
结果:
集成: 所有修复独立,无冲突,完整套件变绿
节省时间: 并行解决 3 个问题 vs 顺序解决
Agents 返回后:
来自调试会话 (2025-10-03):