多编程代理协作：隔离代码与明确验收

多开几个 Claude Code 或 Codex 终端，写代码的人可能更忙了：这个会话等决策，那个已经改完，还有一个仍在执行过期要求。asklog 作者做了一个名叫 Chief 的协调者，负责拆任务、启动 worker、收集结果，把需要人判断的事集中送回来。

这篇开发者自述最有用的部分，是它讲清了并行工作的边界：代码怎么隔离，指令怎样确认送达，终端中断后能恢复什么，以及凭什么认定任务完成。它没有提供效率对照数据，但其中几次具体故障，很适合拿来检查自己的 AI 编程流程。

多个 agent 开工前，先写清谁能改什么

Chief 接收一个需求，再拆给 Claude Code 或 Codex worker。每个 worker 拿到独立的仓库副本，Chief 跟踪结果并汇总决策。

但拆成多个任务，不代表它们就能独立推进。修改 schema 和修改消费它的客户端有先后关系；两个 worker 同时调整同一个抽象，也可能各自写得合理，放到一起却不兼容。

作者要求任务说明提前写清三件事：负责什么、交回什么证据、遇到什么情况必须提问。下面这段示例，把一个重连修复限制在明确范围内：

Goal: make reconnect recover the session list.
Own: the reconnect handler and its browser journey.
Constraints: no protocol change; preserve existing credentials.
Evidence: reproduce the disconnect, reconnect, and show the session.
Ask: if the fix requires changing credential renewal.

最后一行尤其关键：一旦修复涉及凭据续期，worker 就需要回来问。它定义了自主执行的终点，避免 agent 为了完成目标顺手扩大改动。

asklog 使用 Git worktrees 隔离工作副本。它们共享 Git 对象存储，但检出的文件和分支分开，因此一个 worker 尚未提交的修改，不会悄悄变成另一个 worker 的起点。

这层隔离有明确上限。数据库、云账号、端口和生产环境仍可能共享，需要在任务说明中指定负责人。worktree 也不是安全沙箱，同一操作系统用户运行的代码仍需额外约束。

分支能干净合并，只能证明文本没有冲突，不能证明功能组合后正确。

关掉窗口以后，agent 到底还在不在

作者把终端引擎拆成两个进程：一个持有伪终端（PTY）和运行中的 shell，另一个管理客户端连接。桌面和手机都只是连接这些会话的客户端。

这样拆，是为了让窗口关闭或更新时，worker 的 shell 可以继续运行。但「恢复」需要分情况：PTY 进程还活着，新的连接层可以重新接管；宿主机已经重启，原进程就消失了。恢复屏幕历史、启动新 shell，属于恢复现场，不能算执行从未中断。

手机访问也有同样的前提：agent 仍在宿主机上运行，宿主机必须保持唤醒并且网络可达。

作者披露的两次故障，比架构描述更有参考价值。

第一次发生在新连接层接管旧 PTY 进程时。新版本发送了一个可选请求字段，旧 schema 丢弃未知字段后仍返回成功。终端进入了正确目录，却丢失了预期的工作区关联。问题在于，被忽略的字段改变了用户要求。此时旧进程应明确拒绝，或提供兼容升级路径。

第二次发生在终端冷恢复时。保存的屏幕可能带着旧 TUI 留下的 mouse reporting、bracketed paste、focus reporting 或隐藏光标状态。把这些模式回放进新 shell，会让显示或交互异常，因此历史回放后必须显式重置终端模式。

这两类问题都发生在生命周期切换处。只验证「正常启动一个终端」，很容易漏掉。

指令提交成功，为什么还不能算送达

作者区分了 pending、submitting、submitted、acknowledged、uncertain 五种投递状态。

原因很直接：写入成功，只能证明某处接收了字节，不能证明目标 worker 已经读到要求。如果中断后无法确认是否送达，直接重发可能让同一项工作执行两遍。

asklog 的做法是保留持久化收件箱，让下一次会话能够检查记录并确认。需要人回答的问题也单独保存，在获得答案前保持未关闭状态，不会被后续进度消息淹没；问题发生变化后，旧问题对应的答案应被拒绝。

验收遵循同一套思路。worker 回复「done」只是汇报，必须继续检查实际分支、提交头、可审阅的改动，以及任务要求的检查。没有检查套件，不能算检查通过。

对于用户可见的 bug，作者要求先端到端复现，再在修复后走一遍相同路径。涉及状态机，还要覆盖「操作已经提交但响应丢失」「投递中途进程重启」「问题更新后旧答案才到达」等中断场景。

Chief 能集中任务和决策，但成功标准与验收证据仍要事先定义。

我的判断

我认同作者把注意力放在边界和故障恢复上。并行 agent 容易增加产出，也容易增加整合成本。任务说明、独立副本、持久化问题和外部验收，至少让这些成本有地方落地处理。

不过，这是 asklog 开发者的设计经验。原文没有给出任务耗时、返工率或成功率对照，也没说清 Chief 如何处理复杂依赖、最终由谁合并。因此，不能据此认定它一定比人工协调更快，或把作者的验收要求理解成产品已经自动完成了全部验收。

如果只有少量任务，手动维护 worktree、任务说明和检查记录，也能实践这些原则。Chief 的价值要看团队是否频繁遇到会话切换、决策遗失和指令过期，而不只是看能同时开多少个终端。

购买条件也需要单独看。asklog 使用用户自己的 agent 账号，是付费软件；三天试用需要绑卡，不包含 Chief，未取消会按月续费。月付和终身方案包含 Chief，终身方案的 20% 优惠截止于 2026 年 11 月 5 日 23:59 IST。试用无法直接验证文章主打的协调能力，这是评估时的实际限制。

能拿来做什么

• 给 Claude Code 或 Codex 分配前端修复时，照着示例写出 Goal、Own、Constraints、Evidence、Ask，尤其明确协议、凭据等改动何时必须回来确认。
• 并行处理客户端和接口相关任务时，先固定接口约定，再分配 worktree；共用的数据库、端口和测试账号也要指定负责人。
• 修复重连、会话恢复或消息投递问题时，把断线、重启、响应丢失和重复投递写进验收路径，要求交回修复前后的证据。
• 收到 agent 的完成汇报后，检查实际分支和提交头，审阅 diff，并重跑关键用户路径；把「尚无检查」如实记录为未验证。