OpenAI Codex 源码研究(七):多代理——从持久化历史分叉,用消息通道协作

“创建一个子代理”看似只是再开一个会话，真正困难的问题却是：父子代理从哪一个历史时刻分开？它们共享多少上下文？如何交换结果？同时修改工作区时又如何避免冲突？

Codex 的实现给出了三个明确答案：持久化分叉、显式上下文范围和结构化消息协作。

分叉前先固定历史

spawn_subagent 会先物化并刷新父线程的 rollout，再读取包含历史的持久化线程记录。子线程的初始历史通过 ForkSnapshot::Interrupted 构造，给分叉边界添加中断语义。

这并不表示父线程必然停止；它表示子代理获得的历史在分叉点有清晰的结束标记。相比直接复制仍在变化的内存对象，这个分叉点更容易恢复和审计。

Multi-agent V2 的三个协作原语

默认使用提示中定义了三个动作：

• spawn_agent：创建新代理；
• followup_task：向已有代理发送新任务并触发回合；
• send_message：发送消息，但不主动触发新回合。

消息使用结构化格式，包含消息类型、任务名、发送方和正文。子代理还可以继续派生子代理，因此委派关系可以形成树。

fork_turns 用于显式控制向子代理传递多少历史。完整历史分叉默认继承父代理的模型与推理强度；非完整历史分叉在特定配置下可以使用模型覆盖。因此，“所有代理始终使用完全相同的模型”不是不可变的运行时事实，更准确的说法是：默认协作契约将各代理视为能力对等，并允许通过上下文范围控制任务隔离。

多代理共享的另一面

同一团队中的代理共享工作目录和文件系统。好处是，一个代理的修改可以立即被其他代理看到；风险是，如果两个代理同时编辑同一文件，就可能发生覆盖或语义冲突。

因此，多代理并发不应只考虑“任务能否拆分”，还应检查：

• 子任务是否边界清晰；
• 是否会写同一组文件；
• 汇总结果前是否需要重新读取共享状态；
• 是否需要限制并发数量。

与 rollout 的闭环

每个子代理拥有独立 thread 和 rollout。线程管理器还能列出委派子树的 thread ID。结合父线程元数据和各自的 rollout，可以重建“谁委派了谁、每个代理执行了什么”的关系。

这为审计提供了基础，但仍需上层系统补充身份、权限、保留期限和敏感数据处理。

对自建团队的启示

1. 在明确分叉点创建子代理，不要复制不稳定的内存历史；
2. 把上下文范围设为任务参数，避免默认全量继承；
3. 区分任务消息与普通消息，是否触发执行应有明确语义；
4. 把共享工作区视为并发资源，提前设计冲突检测和合并策略。

本文基于 OpenAI Codex commit 343074d 的静态源码分析。文中的架构判断不等同于对安全性、性能或生产成熟度的背书。