https://codexer.com/tags/worktree/Recent content in Worktree on CodexerHugozh-cnThu, 01 Oct 2026 07:20:00 +0800https://codexer.com/posts/2026-10-01-codex-task-mentions-native-worktrees/Thu, 01 Oct 2026 07:20:00 +0800https://codexer.com/posts/2026-10-01-codex-task-mentions-native-worktrees/<h2 id="两个终端一个仓库">两个终端，一个仓库</h2> <p>并行跑 Agent 的第一天通常很爽，第二天开始难受。</p> <p>爽的部分很直观：一个会话在查一个诡异的线上报错，另一个会话在写新功能，互不等待，吞吐翻倍。难受的部分往往在某个具体时刻才浮现：屏幕上两条命令的输出开始交错，两个 Agent 都在动同一批文件，<code>git status</code> 里混着两段来路不同的改动，你分不清哪一行属于谁。</p> <p>于是你退回到单线程。理由也很充分：混乱的成本超过了并行的收益。</p> <p>这里真正缺的东西有两样，而且它们看起来是互相矛盾的。第一样是<strong>隔离</strong>，让两个会话在文件层面彻底不共享。第二样是<strong>通信</strong>，让它们还能交换结论、对齐接口、传递契约。只做隔离，就得到两个互不知情的孤岛，最后还是要人来当信使；只做通信，就得到两双手抢同一个键盘。</p> <p>2026 年 8 月到 9 月之间，Codex CLI 用两个分别发布的原语，把这两半凑齐了。有意思的是，它们单独看都不算革命性，合起来才产生了新东西。</p> <h2 id="原语一把会话变成可寻址的对象v01500">原语一：把会话变成可寻址的对象（v0.150.0）</h2> <p>2026 年 8 月 26 日发布的 v0.150.0 里，有一条很不显眼的特性说明：可以用 <code>@</code> 提及其他 Codex 任务，也可以让 Agent 在终端里读取、创建或给任务发消息。</p> <p>这条说明之所以不显眼，是因为它太像聊天软件的功能。但在 Agent 语境里，「可寻址」是一个结构性变化。</p> <p>在此之前的跨会话协作，只有三条路，每条都有味道：</p> <ul> <li><strong>共享文件</strong>：会话 A 把结论写进一个临时文件，会话 B 去读。问题是两份工作流的文件边界开始重叠，孤儿文件堆积，而且谁写谁读的时序完全靠约定。</li> <li><strong>手工轮询</strong>：会话 B 反复检查某个状态文件是否更新。浪费 turn，而且延迟不可控。</li> <li><strong>底层消息总线</strong>：<code>codex queue</code> 提供的消息通道能工作，但需要额外脚本，属于工程师专属工具，团队里推广不开。</li> </ul> <p><code>@task-name</code> 把这件事降级成了一个名字。会话 B 想知道会话 A 查到了什么，直接 <code>@investigate</code> 提问，对方的状态、输出和历史都是可读的。没有文件被创建，没有时序竞争，没有共享的可写介质。</p> <p>这里有个容易被忽略的设计细节：<strong>它把「对方的上下文」也变成了可查询资源</strong>。过去在终端之间传递结论，你复制的是对方的文字总结，而总结是人写的，或者是被压缩过的，信息在搬运过程中掉了一层。命名通道拿到的是会话自己的状态与历史，信息衰减更少。</p> <p>同时发布的还有 Interrupt 钩子，能在顶层 turn 被打断时执行命令或 MCP 处理器。单独看是可靠性增强，放在并行场景里，它意味着「被中断」不再等于「状态不明」。</p> <h2 id="原语二worktree-从手工脚本变成受管资源">原语二：worktree 从手工脚本变成受管资源</h2> <p>隔离这件事，社区早就用 git worktree 解决了。问题在于解决得很不好用。</p>