规则 1：一人一活#

1
✅ Agent A → 任务 1
2
   Agent B → 任务 2
3

4
❌ Agent A → 任务 1 + 任务 2（并发）

不允许多任务。听起来低效，但它消灭了一整类上下文切换的 bug 和半成品。

翻车案例：一个 agent 同时被两个群派了不同任务。它在两个任务间切换，两个都做了一半，两个都不能用。修复成本远高于串行。

规则 2：并发派工，串行执行#

可以同时给多个 agent 派工。但每个 agent 同一时间只做一件事。并行发生在 agent 之间，不在 agent 内部。

1
时间 →
2
Agent A: [====任务 1====][====任务 3====]
3
Agent B: [====任务 2====][====任务 4====]
4
Agent C: [========任务 5========]

规则 3：自动队列出清#

以下任何事件发生时，立刻检查空闲 agent 并从队列派工：

• 新任务入队
• 某个 subagent 完成
• 收到新消息 / heartbeat
• 任何新派工前

绝不让空闲 agent 干等着，而队列里有任务。

翻车案例：subagent 完成任务后，PraestoClaw 在处理其他消息，没有及时检查队列。agent 空闲了一段时间，而队列里有待派任务在等。

规则 4：依赖感知并行#

并行前先画依赖图。只有独立的任务才能并行。

1
✅ 任务 A ──→ 任务 C
2
   任务 B ──→ 任务 C    （A 和 B 并行，C 等待）
3

4
❌ 任务 A ──→ 任务 B    （B 依赖 A 的输出）
5
   任务 A ──→（立刻派 B）

翻车案例：T1.3 和 T1.1 并行派出，但 T1.3 实际依赖 T1.1 的输出。白跑 3 次。

规则 5：失败恢复#

subagent 失败（超时、LLM 报错）时：

1. 自动重派一次，优先升级模型（如换 GPT-5.4）
2. 重派仍失败则升级给人类
3. 永远不能静默丢弃失败任务

翻车案例：一个修复任务超时了，PraestoClaw 没注意到，继续往下走。后续 PR 审查时才发现这个修复没做，整个 PR 要打回。

规则 6：Gateway 重启协议#

Gateway 重启会断开所有正在运行的 subagent。重启后必须立刻：

1. subagents list — 识别谁在跑
2. kill 已断连的 session
3. 重新派发所有被中断的任务

翻车案例：openclaw gateway restart 后，subagent 状态仍显示 running，但实际已断连，不再推进。直到发现输出长时间无变化才意识到。

规则 7：队列是唯一事实源#

• 运行中任务：看 subagents list（活跃 session）
• 排队中任务：看 DISPATCH-QUEUE.md（持久化文件）
• 看板/面板：仅供人类阅读，不作为派工决策依据

翻车案例：DISPATCH-BOARD 显示某个 agent 在忙，但实际上该 subagent 已经完成。新任务一直排队等待，而 agent 其实空闲。

默认：一个任务一个文件#

每个子任务最多改 1 个文件（强耦合时最多 2 个）。超过 100 行就再拆。

为什么小任务更好：

• 审查更容易
• 失败重试更快
• 和并行任务冲突更少
• 验证更简单

拆分流程#

1. 架构师分析完整改动范围
2. 映射文件间依赖关系
3. 强耦合的改动放在一起
4. 拆成单文件单元
5. 画依赖图
6. 独立单元并行派出

翻车案例：一个任务改 4 个 service + main.py，当成一个单元派出去。连续超时 3 次才意识到需要拆。拆成单文件任务后，超时问题消失。