القائمة
当面对 2 个以上可以独立进行、无共享状态或顺序依赖的任务时使用
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
当你有一份书面实现计划需要在单独的会话中执行，并设有审查检查点时使用
在开始任何对话时使用——确立如何查找和使用技能，要求在任何响应（包括澄清性问题）之前调用 Skill 工具
在任何创造性工作之前必须使用此技能——创建功能、构建组件、添加功能或修改行为。在实现之前先探索用户意图、需求和设计。
当实现完成、所有测试通过、需要决定如何集成工作时使用——通过提供合并、PR 或清理等结构化选项来引导开发工作的收尾
当需要开始与当前工作区隔离的功能开发，或在执行实现计划之前使用——通过原生工具或 git worktree 回退机制确保隔离工作区存在
中文 review 沟通参考——话术模板、分级标注（必须修复/建议修改/仅供参考）、国内团队常见反模式应对。仅在用户显式 /chinese-code-review 时调用，不要根据上下文自动触发。
| name | dispatching-parallel-agents |
| description | 当面对 2 个以上可以独立进行、无共享状态或顺序依赖的任务时使用 |
| version | 1.0.0 |
| license | MIT |
| metadata | {"hermes":{"tags":["agents","parallel"]}} |
你将任务委派给具有隔离上下文的专用智能体。通过精心设计它们的指令和上下文，确保它们专注并成功完成任务。它们不应继承你的会话上下文或历史记录——你要精确构造它们所需的一切。这样也能为你自己保留用于协调工作的上下文。
当你遇到多个不相关的失败（不同的测试文件、不同的子系统、不同的 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）：