[🛠] 实际连接协调器与工作单元

✨ GPT-5.6 Sol 的总结

记录一次实际运行：把一个目标拆成多个 Work Item，交给不同工作单元，再由协调器验证并整合结果。

从重复型工作单元转向基于 Work Item 的工作单元

以前做数据收集项目时，我也把工作单元和协调器分开使用。不过那时的工作单元只是按照固定 goal 重复同一批 batch，协调器则定期整理积累下来的结果。

这次不一样。我用自然语言交给协调器一个目标，它先确定完成条件和 Work Item，再给各个工作单元分配文件和工作范围。

-W- 工作单元完成并验证自己的任务后，交出 commit。-C- 协调器检查这些结果，逐个整合，再从整体状态重新验证。

工作单元越多，整合成本也越高

流程本身很简单。

提交目标
→ 拆分 Work Item
→ 各工作单元执行并验证
→ 移交 commit
→ 协调器检查并整合
→ 重新验证整体状态

最好的地方是每项工作的归属变得清楚。一个任务失败时，不会连带影响其他任务；每个结果也能以 commit 为单位检查。

问题也马上出现了。工作单元开得太多，报告会一次性涌进来；重复会话又让管理更加复杂。并行并不是越多越好，拆分规模必须控制在协调器真正能够处理的范围内。

当天我还一起完善了 Orchestrator 与 Acceptance 基线、通用 Workflow 与 Skill，以及工作单元和协调器会话的运营规则。

想在 OpenClaw 中自动化的部分

我并不想把今天使用的会话、Worktree 和 Branch 原样复制进产品。真正想自动化的是背后的判断。

• 目标应该拆到什么程度
• 谁拥有哪一项结果
• 要检查什么才能算完成
• 失败后应该从哪里重新开始

OpenClaw 真正需要的不是更多工作单元，而是一个能管理结果所有权、验证与重启位置的协调器。