最近用 Codex，我注意到一个变化：它开始处理会话之间的沟通，有时还会建议，把部分工作交给另一个会话继续。
这让我重新看待“多开几个 AI 窗口”这件事。以前，一个窗口查资料，一个窗口写方案，另一个窗口改代码。看起来几件事同时在做，背后却有一个人不停搬运上下文：前面决定了什么，哪里改了，接下来谁来做。
11 月 5 日，LangChain 发布《Agents Are Going Async》，讨论怎样让 Agent 在后台处理长任务，同时继续响应用户。文章也引用了 DeepSeek Harness 的 Super-agent。把它与 DeepSeek 的设计探索、Codex 已公开的机制放在一起，可以看到一个共同的问题：单项工作交出去以后，多项工作仍需要有人协调。LangChain 原文
我对演进方向的判断是：Agent 框架会承担更多调度、上下文衔接和持续跟进。下面先讲三家具体做了什么，再讨论这些机制可能把框架带向哪里。资料核对截至 2026 年 11 月 7 日；SDK 能力、研究原型与产品机制分别看，不把它们放进同一张成熟度排行榜。
这里说的“跨会话工作”，涵盖后台子代理、独立执行会话接收后续事件，以及既有会话的接续。三家的实现和成熟度各不相同，也并非在同一时间推出。
做着一件事，还能不能接住下一句话
先用一个假设任务说明：给产品增加字体设置。Agent 正在改页面、跑检查，这时用户追加：“代码区也要能单独设置字号。”
在常见的单任务循环里，模型判断下一步、调用工具、观察结果，然后继续。这通常被称为 ReAct 循环。一次工具调用如果要等很久，新要求便可能等到这一步结束才被处理。
把工作分给几个子代理，可以并行；但主代理如果仍要等全部结果返回，用户面对的入口依然在等待。并行描述工作是否同时进行，异步描述发出任务后，是否必须等它完成才能继续。
LangChain 的做法，是让协调者派出任务后先拿到任务标识，后台子代理在自己的线程中工作。协调者可以继续交谈，再通过查询、更新、取消等工具管理任务。这里的线程是带有独立状态的工作上下文，不是操作系统线程。Deep Agents 文档
新增字号要求时，协调者能继续接收消息。不过，接到消息和执行者采纳变化是两件事。LangChain 为更新提供两种策略：默认中断当前运行后接着处理新指令，或者让新指令排在当前运行之后。前者适合纠正方向，后者适合追加后续工作；相关更新机制仍在 Beta。更新生命周期
任务完成后也需要把结果送回来。在支持通知的服务端部署中，协调者空闲时可以被唤醒，忙时在后续处理步骤中接收结果；协调者正在等待用户审批时，完成通知会等用户回应后再送达。通知本身仍在 Beta，不能省掉部署条件。异步通知说明
所以，用户得到的是一种更连续的协作体验：长任务在后台推进，对话还可以继续。协调者自身仍可能忙，中断运行也不会自动撤销已经提交的代码或发出的消息。
后续消息，怎样找到原来的任务
把假设场景往下推：字号要求在飞书提出，页面折叠方式在代码评审里讨论，自动检查又返回了一个失败结果。这几条消息来自不同地方，却都属于同一件工作。
DeepSeek 的 Super-agent 设计探索，从这里进一步拆分职责：Router 负责交互和协调，Worker 负责具体执行；每个 Worker 内部仍可以再组织子代理或 Agent Team。
Router 如果要转发每一条后续消息，也会成为繁忙的中转站。原文因此引入订阅直通：同一个群聊话题、代码评审等连续事件构成话题流。Worker 订阅相关话题后，后续事件由程序直接投递；需要判断新任务归属或处理跨任务关系时，再由 Router 协调。DeepSeek 原文 §2—3
这样，字号追加和评审反馈就有了进入已有工作的路径。原文当前采用的简化组合，也没有要求 Worker 彼此直接通信。共享话题的更新能帮助它们发现交集，但看到了同样的消息，并不保证写入不会冲突。
更容易被忽略的一点，是话题、任务和执行会话需要分开。公开原型把一项获准开展的工作称为 Ticket，把它与某次执行器的绑定称为 Assignment。一项任务可以先后由不同执行过程承担，任务状态不必跟着某个执行会话一起结束。原型领域模型
这能解释为什么“再开一个会话”还不够：新会话只是新的执行位置。原来的目标、已有决定、成果版本和待确认事项，仍需要一个明确归属。
任务与执行会话分开管理，后续变化才有明确归属。参考：DeepSeek 领域模型。
信息投递还要与行动权限分开。DeepSeek 原型明确规定，订阅送来的是上下文，不会扩大任务授权；超出范围的要求可以退回重新路由。对于系统推测出的主动任务，默认 observe 模式只记录判断，切换 auto 且匹配规则后才会实际接单。明确请求另有处理路径。原型授权说明
假如评审里有人顺口说“把整套设置页也重做了”，执行者能读到这句话，不代表它已经获得扩展项目的许可。
能保存记录，离持续运行还有多远
字体任务持续到第二天，后台进程重启了。系统应当知道：哪些工作完成了，哪些只是开始了，哪项在等用户回答。
LangChain 把异步任务元数据保存在独立于聊天历史的状态通道里，避免聊天压缩以后连任务标识都找不到。它解决的是任务追踪的一部分，不能据此推断任意工具操作都能恢复。状态管理
DeepSeek 原文则继续讨论两层分离：模型的执行循环与持久状态分离，执行循环再与具体设备环境分离；同时用独立 Watchdog 检查系统故障和任务是否有实质进展。这些是文章的架构描述和团队内部实践，公开原型并未全部实现。DeepSeek 原文 §5—6
公开原型的恢复边界也很具体：进程重启会结束当时的后台工作，忙时中断的执行可以带着恢复说明重新开始。恢复一项任务，不等于从原来的代码执行位置无损续跑。原型执行说明
以字体任务为例，如果代码已提交、结果通知尚未发出，恢复时应当先核对提交，再决定补发通知，不能把整个操作重复一遍。这是我对可靠恢复的要求，不是上述材料已经证明的普遍保证。
看这些设计时，需要保留两条边界。DeepSeek 官方将公开仓库定位为研究原型，说明它与内部版本不同；原文调度实验也使用合成负载和简化的编码工具，不能据此推算真实研发质量、总费用或人力节省。原型定位
Codex 的会话，开始成为可以继续工作的入口
再回到 Codex。这里至少有两类协作，不能混在一起。
一类是主会话临时启动子代理，例如把日志检查交出去，再收回结论。官方文档说明，这种分工也用于隔离大量中间输出，让主会话保留需求和决策；本地委派仍受用户请求或适用指令约束。Codex 子代理说明
另一类是向已经存在的会话发送消息，让它接着工作。我最近留意到的跨会话行为，更值得从这个角度看。不过，具体触发逻辑尚未核实，不能直接归因于某次更新。
公开记录能确认的是：8 月 20 日，CLI 0.149.0 加入 codex queue，可以向既有本地或远程会话发送消息；10 月 29 日，CLI 0.166.0 加入 codex queue --resume，投递后可恢复未加载的会话。这些是 CLI 的能力，不等于桌面端行为的实现说明。官方发版记录
从这些机制出发，我更关注的变化是：一个会话可以成为后续工作再次进入的位置。查过资料的会话、处理过某段代码的会话，有机会被找回和接续，而不必每次从一段新提示词开始。
但给字体开发会话发送“请按新要求调整”，只完成了投递这一步。对方是否采用了新要求，原会话是否仍在继续改同一份文件，最后谁负责验收，都需要额外的任务规则。
如果将来由框架协调交接，我希望它能留下明确记录：交了哪项工作、依据哪个版本、谁接收、原执行者是否停止。否则，消息来往变多以后，人仍要检查有没有两边都在做，或者两边都以为对方会做。
从这些机制，可以推导出怎样的路线
我会按能力之间的依赖，理解 Agent 框架的演进。下面是本文的分析模型，不是厂商共同采用的阶段划分。
已有能力与未来判断分开看；这是一种能力依赖关系，不是统一的厂商升级时间表。
展开文字对照表
| 能力层次 | 框架增加的责任 | 目前能确认到哪里 |
|---|---|---|
| 单任务执行 | 判断下一步、调用工具、检查结果 | 是后续执行单元仍会使用的基础 |
| 异步分工 | 后台运行、途中调整、结果回投 | 已有 SDK 和产品机制，部分通知与更新仍在 Beta |
| 持久任务协调 | 保存归属、状态、依赖，支持接续 | 已有任务状态和领域模型等局部实现，可靠交接仍需验证 |
| 事件驱动的持续工作 | 把外部变化送回任务，处理长期运行异常 | 已有团队实践和研究原型，覆盖与恢复边界各不相同 |
| 跨权限边界协作 | 在不同助手、团队之间交换受限委托与结果 | 本文判断的重要方向，不能由实例内部协作推出它已成熟 |
这些层次会共存。一次短查询适合直接执行；只有确实需要同时推进、途中介入或隔天接续，才值得增加对应机制。原来的 ReAct 循环也可以保留在 Worker 内部。
我认为，接下来的变化会更多发生在三个地方。
首先，任务会成为比聊天记录更稳定的工作单位。用户仍可以通过聊天发起和调整工作，系统则需要独立保存目标、状态、成果与验收条件。“等待评审”“被阻塞”“已停止”应当有不同含义，不能都压成“没有在运行”。
其次，协调会更多依靠确定性规则。已有任务的后续消息怎样路由、重复事件怎样识别、取消后迟到的结果怎样处理，都需要稳定机制。需要语义判断时再找模型，能够减少反复解释和不必要的协调调用。
再往后，协作会跨越权限边界。个人助手可以向团队研发助手查询进展，却未必有权改变发布计划。双方需要交换必要信息，说明委托范围，而非共享全部历史。DeepSeek 也把跨隔离实例的协作列为开放问题；这里的 Agent 间通信不特指某一种协议。DeepSeek 原文 §8
最后，仍要回到那条追加要求
判断一个新框架时，我会把字体任务再走一遍：开发在后台进行，用户追加字号要求，评审提出调整，执行环境中断，最后由人验收。
每一步都能提出具体问题：变化有没有进入正确任务？执行者依据的是不是最新决定？中断后有没有重复操作？等待用户时是否保持等待？结果能否对应到实际版本？
这些问题比“启动了多少个 Agent”更接近使用价值。完成率、成本和需要人介入的次数，也应当放在同一业务负载下检查，不能只看后台任务变多了。
未来再看到“支持异步”或“支持跨会话”，我会先看它接住了工作过程中的哪一种变化。字体要求追加以后，如果人仍要翻聊天、找版本、确认谁在做，系统还有一段协调工作没有接过去。