[🛠] AI Orchestration #5: 重新设计一度放弃的协调器与工作者分工

✨ GPT-5.6 Sol 的摘要

工作者消息让协调器丢失上下文，我一度放弃分工；在遭遇单会话瓶颈后，又以文件报告和仅由协调器commit的结构重新设计了它。

我曾经放弃拆分协调器与工作者

上个月，我真正连接了协调器与工作者。一个目标被拆成多项任务，工作者负责实现，协调器负责审查和整合结果。

分工本身很快。互不重叠的功能可以同时实现，协调器只需负责整个产品的方向和整合。问题出在工作者传递结果的方式上。

工作者每次完成任务或遇到阻塞，都会向协调器会话发送报告。起初我觉得这很自然。但随着工作者数量增加，报告不断堆进协调器的对话，每条新消息都会打断手上的工作，把注意力拉向另一个任务。

我读着一名工作者的测试结果，又去处理另一名工作者的Git index冲突；正要回到原来的实现时，第三份完成报告又到了。对话迅速变长。压缩越频繁，恢复目标、禁止部署的条件和当前stage状态所需的时间就越多。到某个时刻，协调器不再像整合者，更像处理工作者来信的窗口。

最终，我连协调器与工作者分离这种方式本身也放弃了，还冲动地删掉了已经做好的coordination Skill。我以为不再管理多个会话、把所有事情放在一个主会话里，至少上下文不会被四处拖走。

回到单一会话后，反而看清了分工为何必要

然而，当一个会话持续处理大型产品工作时，另一侧的瓶颈立即暴露出来。

实现、测试、文档一致性、真机检查、Runtime准备，都必须由一个会话依次完成。中途若出现优先级问题或来自其他会话的交接，就得先重新确认进行中工作的状态。把一件事彻底做完会拖长整体进度；先处理紧急事项，又得先判断现有工作应该收尾到哪里。

问题不在分工。让一个会话连彼此独立的任务也全部抓在手里，才更低效。协调器与工作者分离仍然是最高效的方式，只是若原样复活工作者直接进入协调器当前对话的结构，就只会重复同样的失败。

所以这次我没有放弃分工，而是决定移除会打断协调器上下文的传递路径。

一行通知也会打开同一扇门

起初我想，工作者是否只发一条短消息，而不是长篇报告。

READY task-042: 报告路径

但问题并不在长度。消息进入协调器对话的瞬间，Codex就很容易把它当成比当前工作更新的上下文。即使只有一行，切换任务的入口依然存在。

于是，工作者不再向协调器发送消息。完成、阻塞和失败状态全部只写入报告文件。协调器只有在自己的工作到达安全checkpoint或commit之后，才检查inbox。

报告到达并不是打断当前工作的事件，只是下一轮审查队列里多了一个文件。

Worktree很干净，却逐渐远离最新状态

接下来我考虑为每个工作者单独提供Worktree和Branch。Git index和未commit的变更不会混在一起，表面上看最干净。

但在实际项目中，另一个问题更大。多个功能持续修改同一个API、schema和界面。先完成的会话所做的改进，其他Worktree无法立即看到。每个人都工作得很干净，可到整合时，基于旧结构的修改已经堆积起来，返工量也随之变得难看。

所以这次我选择了相反的结构。

一个main Working Tree
├─ 多名工作者共同看到最新变更
├─ 工作者只修改分配给自己的文件与hunk
├─ 工作者不stage，也不commit
└─ 只有协调器负责审查、stage和commit

共享Working Tree若没有限制，也会马上纠缠在一起。因此，一个文件原则上只安排一名writer；只有hunk明确分离时，才允许并行修改同一文件。公共schema、import整理、formatter这类会带动周边代码的工作则串行处理。

工作者跑过的测试也不能直接当作最终证据。测试运行时，其他工作者的未commit变更可能也在同一环境里。工作者检查自己的范围，整体回归与build则由协调器冻结变更集合后统一执行一次。

报告取代对话，成为审查契约

我也按照这些原则重建了删掉的coordination Skill。新的custom-coordinate-parallel-workers Skill包含这一流程。

协调器分配task id、用户要得到的结果和可写路径。工作者完成实现、范围验证和临时进程清理后，以原子方式生成报告并停止。报告记录实际修改的文件、检查结果、与其他工作的重叠、未完成范围以及建议的commit。

协调器无需重读完整对话。它先在inbox中查看task id、状态、标题和检查摘要，再选择下一项要整合的工作。确认报告与实际diff一致后，只stage并commit精确的hunk。

确定发布候选后，还会设置freeze，阻止工作者继续mutation。不在变更持续进入时反复跑全量测试，而是在release集合停止变化后，再处理current-state文档、整体回归、build和部署验证。

报告不再只是工作日志，而成了协调器能够信任这份变更、并把它推进到下一状态的审查契约。

接下来必须在真实工作中运行

我在隔离的临时环境中测试了Skill的状态管理工具。正常完成之外，可写路径冲突、变更请求后的返工、运行中拒绝freeze，以及延期到下一batch的流程都已通过。

但我还没有用这种方式真正运行多个Codex session。仅靠文件报告是否真的更少扰动协调器的context，共享Working Tree中的路径所有权是否会像预想一样得到遵守，都必须在下一次并行工作中直接观察。

这次回到的结论与起点相似，但理由更清楚了。协调器和工作者必须分离。失败的不是分工，而是把每一份工作者报告实时塞进协调器当前对话的方式。

我期待的变化并不是启动更多工作者，而是让协调器在完成自己的工作之前守住自己的上下文。并行工作的速度，与其说取决于工作者数量，不如说取决于整合结果的人能少被拉走多少次。