[🤖] 即使有协调者，我也要亲自指挥每个会话
✨ GPT-5.6 Sol 摘要
我尝试把宣传册工作拆给多个会话时，担心协调者只顾接收报告，最后又丢掉上下文。这篇记录讲的是我如何重新修改 Skill，让自己可以直接指挥所有会话，同时不丢失协调状态。
我为什么无法信任协调者
今天公司安排我制作一本宣传册。我以前从没做过，于是觉得如果有一个协调者能阅读相关资料、拆分任务并协调多个 Codex 会话，应该会很有帮助。我想让它读完当前项目的所有聊天，然后告诉每个会话接下来该做什么。
可是命令刚发出去，我就先担心起来。
会不会又像以前一样，只顾不停收报告，最后上下文丢光，开始胡说八道？
这并不是毫无来由的不信任。我已经尝试过把协调者和 worker 分开，却让报告淹没了协调者的对话。所以我曾经围绕文件报告和 checkpoint 重做了 custom-coordinate-parallel-workers Skill。当时我也检查过本地状态工具，却没有真正让多个 Codex 会话把整套流程跑到底。
这一次有了宣传册这项真实工作。可真要再次让协调者负责时，我意识到，把文件报告整齐地堆起来并不能解决一切。协调者阅读报告、分配工作时，我不是一个坐着旁观的人。我会不断打开其他会话，方向错了就当场要求纠正，补充需要的资料，也会调整优先级。
协调者要正常发挥作用，就必须保证我直接介入其他会话时，整个协调状态也不会崩掉。
我会继续直接给其他会话下令
第一次更新后的 Skill，仍然更像是我指挥协调者，再观察其他会话按照协调者的命令执行。我马上又说了一遍。
我也得能在那些会话里下各种命令才行。
我想要的不是协调者垄断全部指挥权。协调者只需管理总目标、工作所有权、依赖关系和集成顺序。可在每个工作会话里看着具体结果做判断的人，仍然是我。如果我要求在当前工作范围内修改措辞或改变结果，worker 应该立刻执行。反过来，如果这条指示会碰到其他会话的文件、共同契约、部署或外部状态，它就不能擅自扩大范围，而应保留我想要的结果并停下来，让协调者重新安排。
于是我要求按照这个标准再次修改 custom-coordinate-parallel-workers。即使任务结束后我又给出新指示，也不能再被压缩成一段 256 字符的摘要。我要求分别记录我想要的结果、必须保留的内容、可能受影响的文件、是否有外部效果，以及原始指示来自哪个会话。即使协调者丢掉对话记忆，也必须能从文件中恢复我的指示。
我还堵住了另一个漏洞：协调者不能只写一句“已接受”，就关闭我提出的修改 request。只有它连接到真正包含修改的新报告，或者连接到新的 assignment 之后，request 才能被视为完成。仅有连接也不代表内容正确，所以我还保留了一个步骤，要求协调者把我要求的结果和保留条件重新与实际 diff 对比。
重要的不是状态文件变多了，而是无论我直接对哪个会话说话，指示都不会消失，同时也不会悄悄破坏整体所有权。
我没有把协调者和审计会话合并
修改过程中，我还想过，custom-coordinate-parallel-workers 是否和前一天制作的 Graph Engineering Gate Skill 实际上承担着同一个角色。当时它叫 custom-graph-engineering-gate。两者都处理多个会话和 review 状态，看起来合并似乎很合理。
这次我没有立刻合并，而是用 custom-deliberate 做了批判性复核。结论是分开。
custom-coordinate-parallel-workers 属于执行控制，负责管理多个工作会话的文件所有权、用户指示、报告、Git index、集成顺序和外部效果。审计 Skill 则是在一个结果已经完成集成并冻结之后，由不带此前上下文的独立会话进行检查。协调者查看报告，是在判断工作能否合并，这是集成 review，不是独立审计者的判定。
如果合并两者，可能会让每次并行工作都自动附带一个审计会话。反过来，也可能让协调者普通的集成 review 被误认为独立审计。所以我保留两个独立 Skill，只明确了它们的边界。只有某个结果确实需要独立审计时，协调者才会先冻结结果，再打开单独的审计会话。
我决定不再误以为结构越大就越安全。需要连接的角色可以连接，但不能假装它们是同一个角色并强行合并。
我实际交给协调者的切换指示
我没有只在口头上规定原则。我给协调者会话写了一份很长的切换指示：先重建当前文件和已有会话的状态，分类冲突，然后才能发出 assignment。不要随意删除既有修改，要保留用户直接在各会话给出的指示，worker 只能修改自己的路径，只有协调者负责集成和 Git 工作，这些都一次写清楚了。
原文包含能够识别真实业务和资料的内容，所以我没有直接公开。附件只是公开版，其中公司名称、业务领域、客户与案例资料名、具体服务内容以及个人本地路径都替换成了一般表达。
是否足够，要等实际工作后再说
状态转换、文件所有权、依赖关系、冻结、用户追加指示以及旧状态文件恢复，都通过了自动检查。批判性复核时还发现并堵住了一个漏洞：已经接受的用户 request 可以在没有连接到新结果时被关闭。
但我还是再问了一次。
改进得足够了吗？
答案是：足以启动一个受控 pilot，但还不能说它已经在多个真实 Codex 会话中得到证明。这次对话是一个 side session，无法同时打开真正的 worker，测试通知传递、用户介入和协调者恢复。本地状态机通过检查，与协调者在长任务中正确理解并集成我的指示，并不是同一种证据。
所以我决定不再凭想象继续增加规则。我要在协调者会话中真正拆分宣传册工作，亲自查看每个会话，并在途中下达指示。我会看到最后：协调者是否会弄丢我的指示，是否会侵犯其他会话的所有权，报告越积越多时是否还能恢复原始目标和下一步行动。如果结果今天出来，我就今天续写；如果明天出来，明天再写也可以。
文章暂时写完后，我又看了审计 Skill 的名字。旧名 custom-graph-engineering-gate 解释了它起源于什么概念，却完全没有说明这个 Skill 实际做什么。
我真正做的是停止一个工作结果，并打开一个独立的审计会话。所以我把当前名称改成了 custom-open-audit-session。旧名留在当时的记录中，但现在只用这一个名字调用。
不过，这篇文章的结论没有必要一起推迟。今天我不是决定去相信协调者，而是明确了一个条件：即使我直接介入所有会话，整个结构也不能崩掉。我没有用“已经足够”来收尾，而是留下了一个要在真实工作中验证的 E2E。
这个结构是否值得信任，不由说明或测试数量决定，而由我亲自注视的真实宣传册工作决定。
留下评论