两个 Codex 会话第一次能直接对话：@提及与原生 worktree 如何补齐并行协作

Thu, 01 Oct 2026 07:20:00 +0800

两个终端，一个仓库

并行跑 Agent 的第一天通常很爽，第二天开始难受。

爽的部分很直观：一个会话在查一个诡异的线上报错，另一个会话在写新功能，互不等待，吞吐翻倍。难受的部分往往在某个具体时刻才浮现：屏幕上两条命令的输出开始交错，两个 Agent 都在动同一批文件，git status 里混着两段来路不同的改动，你分不清哪一行属于谁。

于是你退回到单线程。理由也很充分：混乱的成本超过了并行的收益。

这里真正缺的东西有两样，而且它们看起来是互相矛盾的。第一样是隔离，让两个会话在文件层面彻底不共享。第二样是通信，让它们还能交换结论、对齐接口、传递契约。只做隔离，就得到两个互不知情的孤岛，最后还是要人来当信使；只做通信，就得到两双手抢同一个键盘。

2026 年 8 月到 9 月之间，Codex CLI 用两个分别发布的原语，把这两半凑齐了。有意思的是，它们单独看都不算革命性，合起来才产生了新东西。

原语一：把会话变成可寻址的对象（v0.150.0）

2026 年 8 月 26 日发布的 v0.150.0 里，有一条很不显眼的特性说明：可以用 @ 提及其他 Codex 任务，也可以让 Agent 在终端里读取、创建或给任务发消息。

这条说明之所以不显眼，是因为它太像聊天软件的功能。但在 Agent 语境里，「可寻址」是一个结构性变化。

在此之前的跨会话协作，只有三条路，每条都有味道：

共享文件：会话 A 把结论写进一个临时文件，会话 B 去读。问题是两份工作流的文件边界开始重叠，孤儿文件堆积，而且谁写谁读的时序完全靠约定。
手工轮询：会话 B 反复检查某个状态文件是否更新。浪费 turn，而且延迟不可控。
底层消息总线：codex queue 提供的消息通道能工作，但需要额外脚本，属于工程师专属工具，团队里推广不开。

@task-name 把这件事降级成了一个名字。会话 B 想知道会话 A 查到了什么，直接 @investigate 提问，对方的状态、输出和历史都是可读的。没有文件被创建，没有时序竞争，没有共享的可写介质。

这里有个容易被忽略的设计细节：它把「对方的上下文」也变成了可查询资源。过去在终端之间传递结论，你复制的是对方的文字总结，而总结是人写的，或者是被压缩过的，信息在搬运过程中掉了一层。命名通道拿到的是会话自己的状态与历史，信息衰减更少。

同时发布的还有 Interrupt 钩子，能在顶层 turn 被打断时执行命令或 MCP 处理器。单独看是可靠性增强，放在并行场景里，它意味着「被中断」不再等于「状态不明」。

原语二：worktree 从手工脚本变成受管资源

隔离这件事，社区早就用 git worktree 解决了。问题在于解决得很不好用。

先做对前两步：四阶段编码 Agent 工作流，以及它在 Codex CLI 里的落法

Wed, 23 Sep 2026 07:50:00 +0800

你一定见过这个场景。规划阶段里，某个人对架构做了一条看起来无关紧要的假设。实现阶段，Agent 忠实地沿着这条假设往前走了几个小时。你在中途或者最后发现了问题，让它改。它给你回来一个补丁，叠在原来的结构上。

结果是代码里同时躺着原来的错误和后来的修正，逻辑重复，归属模糊。你评估这个 diff 花费的时间，比重新写一遍还长。

大多数人对这个场景的归因是：模型不够强，换一个就好了。Infobip 的 AI 研究团队在 CIKM ‘26 上发表的论文（arXiv:2608.30701）直接挑战了这个假设。他们的原话是：非平凡任务上的效果，取决于实践者如何配置 Agent 的运行环境与协作方式，而不是取决于基础模型的选择。

这句话值得停下来读两遍。我们花了两年时间在模型排行榜上追逐几个百分点的差距，而论文说真正的变量在别处。

一、上游错误会复利，下游补丁只会堆积

论文里有一个关于错误传播的判断，和绝大多数团队的实际做法相反。

研究阶段与规划阶段的错误，会跨阶段复利。而实现阶段生成的代码出了问题，你打的补丁带来的是臃肿和脆弱，不是干净的修复。

这两件事的性质不同。研究阶段的一个错误事实，会变成规划阶段的一个错误前提，再变成任务定义里的一段错误验收标准，最后变成整个模块的错误结构。四个阶段跑完，错误已经被固化进了骨架。

而实现阶段的错误，至少在结构层面是局部的，你能看见它在哪里。

所以论文给出的答案不是「更仔细地 review 实现」，而是把人力投入到研究与规划上，投入到一个足以让实现环节几乎不需要人工介入的强度。

这就是所谓的前置加载（front-load）。真正被前置的不是工作量，是判断力。

二、四个阶段，以及每一步的 Codex CLI 对应物

论文描述的流程分四步，人力参与程度逐级下降，产物则逐级固化。

阶段一：研究，只读，必须有验证门

实践者和 Agent 一起探索问题空间，但访问权限被限制在只读操作上：检索代码库、拉取文档、调用领域工具。不写文件，不改环境。

关键约束在最后一条：所有发现都要经过实践者验证，才能进入下一步。产物是一份经过整理的调研文档，不是一段对话记录。

在 Codex CLI 里，这一步靠沙箱和审批策略来强制。你可以用 --approval-policy on-failure 起一个研究会话，更稳的做法是给它一个专门的 profile，把可写根目录设为空：

# ~/.codex/config.toml
[profiles.research]
model = "gpt-5.6-sol"

[profiles.research.sandbox]
writable_roots = [] # 不允许任何文件系统写入
network = true # 允许检索文档

会话结束时把调研结论导出成文件。文件取代对话，成为持久的产物。对话本身是可以丢掉的。

阶段二：规划，迭代讨论，手工归档

拿调研文档作为输入，实践者和 Agent 通过多轮讨论确定方案。

这里论文有一个明确的反对意见，反而和很多人的直觉相悖：这个阶段不要使用专门的「规划模式」，它会导致过早定稿，方案还没被真正理解就被锁死了。

在 Codex CLI 上对应的是：让模型保持在默认模式，把调研文档作为上下文带进来，一轮一轮讨论设计，然后由人手工把结论整理成规划产物。论文特别提醒，不要让模型替你总结规划会话，它会把你推理过程中的分支和权衡全部压平。

也就是说，规划产物里应该包含架构决策记录，包括「为什么否决了另外两个方案」，而不只是「最终定了什么」。

阶段三：任务定义，机器可读，按会话大小切分

任务被定义为机器可读的单元，每张任务卡包含六个字段：稳定标识符、目标陈述、依赖关系、相关代码路径、验收标准、验证方法。

最容易被忽略的是切分约束：每个任务必须能在一个全新的会话里完成。如果定义一个任务所需的前后文超过了 Agent 的有效工作区间，就把它再切开。

Codex CLI on Codexer