dispatch

name	dispatch
description	当用户提出包含两个以上相互独立、无共享状态或顺序依赖的子任务，或要求并行、同时排查、 分开调查、派发子代理、并行审查、多个失败分开查或分头处理时使用。
metadata	{"openclaw":{"emoji":"⚡"}}

dispatch — 并行子代理派发技能

执行前置

遵循当前目录 AGENTS.md「技能执行公共契约」；仅按需读取技能正文与 reference。

核心原则

1. 一个代理一个独立问题域：2+ 个互不依赖的子任务串行处理浪费时间且挤占主上下文； 并行后各代理隔离执行、互不干扰。独立性判定：无共享状态、无顺序依赖、 互不改动同一文件/资源——三者任一不满足即不算独立。
2. 精确构造上下文，不传会话历史：每个代理的指令必须自包含——问题域/目标/ 约束/预期输出全部写清（吸收 obra/superpowers dispatching-parallel-agents）； 代理绝不继承你的会话上下文，这样它保持专注，你也保留上下文做协调工作。
3. 同一条消息发出全部派发 = 并行：并行是"同响应多 task 调用"，不是"分批先跑完 再发下一批"；所有独立派发一次发出（首批可含探索性任务），防止串行等待。
4. 约束与产出显式化：每个代理必须给出范围约束（"不要改其他文件"等）与 明确的返回格式（根因/改动摘要）——无约束代理可能越界重构，无产出格式 你不知道它改了什么。
5. 整合不豁免验证：代理返回后逐一读摘要 → 冲突检查（是否改同一文件）→ 全量验证（测试/编译/lint）→ 抽查（代理可能犯系统性错误，如只修表象）—— 并行不豁免诚实原则，每个代理结论以其实测输出为证。
6. 不适用判定先行：相关失败（修一个可能带好另一个）→ 先合并调查； 探索性调试（还不知道坏在哪）→ 先定位再拆；共享状态/同文件 → 顺序执行； 判定不适用时转对应技能，不强行并行。

触发时机

• 用户明确要求并行："并行"、"并行处理"、"同时排查"、"分头处理"、"分开查"、"并行审查"
• 任务天然可拆分：多个独立测试失败、多子系统独立排查、多文件/多目录独立调查、 多目标并行审查（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. 整合与验证

代理全部返回后：

1. 逐一读摘要：每个代理的结论与改动记录；
2. 冲突检查：不同代理是否改动了同一文件/资源（git status/diff 核对）；
3. 全量验证：跑完整测试/编译/lint（不只跑各代理声称过的部分）；
4. 抽查：挑 1-2 个代理的输出深入核验（代理可能系统性犯错，如只修表象、 删掉关键逻辑）；核对产物与承诺一致；
5. 有冲突或验证失败 → 按 debug 流程修复，不宣称完成。

Step 6. 总结（结构化输出）

✓ 并行派发完成
   任务:   <任务定义>
   拆域:   N 个独立域（域1: ...; 域2: ...）
   结果:   域1 ✓ <摘要> / 域2 ✗ <失败原因> / ...
   冲突:   无 / <说明>
   验证:   <全量验证命令与输出>
   遗留:   <未解决域/需跟进项，无则省略>

错误处理

场景	处理
子任务其实有依赖（并行后才发现）	合并相关域，按依赖顺序重跑；在终端摘要说明判定修正
代理越界（改了约束外的文件）	用 git diff 定位越界改动，回退或审查后保留，约束收紧后重派
代理输出与承诺不符	以实测为准（git diff/测试输出核对），不采纳口头承诺
多代理改同一文件冲突	冲突域合并重做，先完成依赖方；全量验证防遗漏
代理失败/超时	重派该域（补充上下文），其余域结果保留，不整体重跑
全量验证失败	按 debug 流程定位修复，循环至通过
代理返回无结构（无根因/无改动清单）	下轮派发在预期输出中写明格式，本轮结果按摘要人工归纳
并行与顺序判定摇摆	默认先并行第一批探索性代理，再据结果决定是否继续并行

注意事项

• 并行不豁免验证与诚实原则：每个代理结论以实测输出为证，整合后全量验证才可宣称完成；
• 精确上下文 > 省 token：代理指令写清问题域/目标/约束/产出，宁详勿略；
• 不传会话历史给代理（上下文裁剪纪律，同 review 技能）；
• 代理或整合阶段产生的本次改动按上级公共 Git 契约收尾。