一键导入
dispatching-parallel-agents
当面临2个或更多可独立执行的、无共享状态或顺序依赖的任务时使用
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
当面临2个或更多可独立执行的、无共享状态或顺序依赖的任务时使用
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
桌面/网关运行时内置的计划创建技能,用于生成可落盘、可调度、可批次执行的结构化计划包。
桌面/网关运行时内置的计划执行技能,用于按批次执行结构化计划包中的单个任务文件。
Use when demonstrating or verifying VibeWindow local plugin packaging, including plugin skills, MCP servers, hook declarations, and interface metadata.
当需要在编码前创建或更新实施计划时使用,尤其适用于多步骤功能开发、重构、包含多个活动部件的缺陷修复,或需要拆分为可独立执行并跟踪进度的任务文件的请求。
当你有书面实现计划需要在单独会话中执行,并带有审查检查点时使用
通过 `rustcodegraph` 命令行界面使用 RustCodeGraph 理解、导航或脚本化操作已索引代码库。当用户要求使用 RustCodeGraph、需要高性能搜索检索代码、需要符号/源码/调用流上下文、调用方/被调用方/影响分析或受影响测试选择时使用。
| name | dispatching-parallel-agents |
| description | 当面临2个或更多可独立执行的、无共享状态或顺序依赖的任务时使用 |
你将任务委派给具有隔离上下文的专业代理。通过精心构建它们的指令和上下文,确保它们保持专注并成功完成任务。它们不应继承你当前会话的上下文或历史——你只需精确构建它们所需的内容。这也为你自己的协调工作保留了上下文空间。
当你遇到多个不相关的故障(不同的测试文件、不同的子系统、不同的缺陷)时,逐一排查是在浪费时间。每个排查任务是独立的,可以并行进行。
核心原则: 每个独立的问题域派遣一个代理。让它们并发工作。
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. 确定根因 - 是时序问题还是实际缺陷?
3. 通过以下方式修复:
- 将任意超时替换为基于事件的等待
- 如发现中止实现中的缺陷则修复
- 如果测试了变更后的行为,调整测试期望
不要只是增加超时时间 - 找到真正的问题。
返回:你发现了什么以及修复了什么的摘要。
❌ 范围过宽: "修复所有测试" - 代理会迷失方向 ✅ 明确具体: "修复 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 个问题并行解决,而非串行
代理返回后:
来自调试会话(2025-10-03):