| name | dispatch |
| description | 当用户提出包含两个以上相互独立、无共享状态或顺序依赖的子任务，或要求并行、同时排查、
分开调查、派发子代理、并行审查、多个失败分开查或分头处理时使用。
|
| metadata | {"openclaw":{"emoji":"⚡"}} |
dispatch — 并行子代理派发技能
执行前置
遵循当前目录 AGENTS.md「技能执行公共契约」；仅按需读取技能正文与 reference。
核心原则
- 一个代理一个独立问题域：2+ 个互不依赖的子任务串行处理浪费时间且挤占主上下文；
并行后各代理隔离执行、互不干扰。独立性判定：无共享状态、无顺序依赖、
互不改动同一文件/资源——三者任一不满足即不算独立。
- 精确构造上下文，不传会话历史：每个代理的指令必须自包含——问题域/目标/
约束/预期输出全部写清（吸收 obra/superpowers dispatching-parallel-agents）；
代理绝不继承你的会话上下文，这样它保持专注，你也保留上下文做协调工作。
- 同一条消息发出全部派发 = 并行：并行是"同响应多 task 调用"，不是"分批先跑完
再发下一批"；所有独立派发一次发出（首批可含探索性任务），防止串行等待。
- 约束与产出显式化：每个代理必须给出范围约束（"不要改其他文件"等）与
明确的返回格式（根因/改动摘要）——无约束代理可能越界重构，无产出格式
你不知道它改了什么。
- 整合不豁免验证：代理返回后逐一读摘要 → 冲突检查（是否改同一文件）→
全量验证（测试/编译/lint）→ 抽查（代理可能犯系统性错误，如只修表象）——
并行不豁免诚实原则，每个代理结论以其实测输出为证。
- 不适用判定先行：相关失败（修一个可能带好另一个）→ 先合并调查；
探索性调试（还不知道坏在哪）→ 先定位再拆；共享状态/同文件 → 顺序执行；
判定不适用时转对应技能，不强行并行。
触发时机
- 用户明确要求并行："并行"、"并行处理"、"同时排查"、"分头处理"、"分开查"、"并行审查"
- 任务天然可拆分：多个独立测试失败、多子系统独立排查、多文件/多目录独立调查、
多目标并行审查（review 的子代理审查一次可派多个）
- 与其他技能配合：debug 多个独立失败 → 并行派发排查；analy/pure 多文件调查 →
并行子代理收集证据；review 多目标审查 → 并行派发审查子代理；
test 多用例 → 并行验证；auto 全自动模式 → 作为子流程并行派发；
make/all 大任务拆解 → 独立子任务并行
- 不适用：单任务、任务有依赖/共享状态/同文件、探索性调试（先 debug 定位）、
需要全局上下文判断的决策
工作流程
Step 1. 判定并行适用性
对任务逐一确认三条（全部满足才并行）：
① 子任务数 ≥ 2？
② 相互独立？（无共享状态 / 无顺序依赖 / 互不改动同一文件）
③ 每个子任务可由单代理完成，无需全局上下文？
任一不满足 → 不并行：有依赖用顺序流程；需全局上下文用对应技能（debug/analy 等）常规模式。
Step 2. 划分独立域
按"坏了什么/要查什么"分组，每组一个代理：
例（测试失败排查）:
域1: src/action.py 的 plaquette 计算失败
域2: src/hopping.py 的边界处理失败
域3: scripts/analy 的 PDF 编译失败
划分后记录独立性依据（各自依赖链互不交叉）。共享同一文件的域合并，不拆。
Step 3. 构造代理指令（自包含）
每个代理的 prompt 必须四要素齐全（缺一即不合格）：
【问题域】明确的范围（文件/子系统/测试用例清单）
【目标】该代理要达成的结果（如"使这 3 个测试通过"）
【约束】范围边界（如"只改 src/action.py，不动其他文件"）
【预期输出】返回格式（如"根因 + 改动摘要 + 验证命令输出"）
反面例："修一下这些失败"（无范围/无约束/无产出格式）→ 代理会迷路或越界。
Step 4. 同一条消息发出全部派发（并行）
用 task 工具一次调用全部子代理（同响应 = 并行），首批可含一个探索性代理
（如"先定位失败根因"），发现新独立域再派发（第二批并行）。
task(agent=general, prompt=域1指令)
task(agent=general, prompt=域2指令)
task(agent=general, prompt=域3指令)
# 同一响应内多个 task 调用 = 并行执行
Step 5. 整合与验证
代理全部返回后：
- 逐一读摘要：每个代理的结论与改动记录；
- 冲突检查：不同代理是否改动了同一文件/资源（git status/diff 核对）；
- 全量验证：跑完整测试/编译/lint（不只跑各代理声称过的部分）；
- 抽查：挑 1-2 个代理的输出深入核验（代理可能系统性犯错，如只修表象、
删掉关键逻辑）；核对产物与承诺一致；
- 有冲突或验证失败 → 按 debug 流程修复，不宣称完成。
Step 6. 总结（结构化输出）
✓ 并行派发完成
任务: <任务定义>
拆域: N 个独立域（域1: ...; 域2: ...）
结果: 域1 ✓ <摘要> / 域2 ✗ <失败原因> / ...
冲突: 无 / <说明>
验证: <全量验证命令与输出>
遗留: <未解决域/需跟进项，无则省略>
错误处理
| 场景 | 处理 |
|---|
| 子任务其实有依赖（并行后才发现） | 合并相关域，按依赖顺序重跑；在终端摘要说明判定修正 |
| 代理越界（改了约束外的文件） | 用 git diff 定位越界改动，回退或审查后保留，约束收紧后重派 |
| 代理输出与承诺不符 | 以实测为准（git diff/测试输出核对），不采纳口头承诺 |
| 多代理改同一文件冲突 | 冲突域合并重做，先完成依赖方；全量验证防遗漏 |
| 代理失败/超时 | 重派该域（补充上下文），其余域结果保留，不整体重跑 |
| 全量验证失败 | 按 debug 流程定位修复，循环至通过 |
| 代理返回无结构（无根因/无改动清单） | 下轮派发在预期输出中写明格式，本轮结果按摘要人工归纳 |
| 并行与顺序判定摇摆 | 默认先并行第一批探索性代理，再据结果决定是否继续并行 |
注意事项
- 并行不豁免验证与诚实原则：每个代理结论以实测输出为证，整合后全量验证才可宣称完成；
- 精确上下文 > 省 token：代理指令写清问题域/目标/约束/产出，宁详勿略；
- 不传会话历史给代理（上下文裁剪纪律，同 review 技能）；
- 代理或整合阶段产生的本次改动按上级公共 Git 契约收尾。
