Codex智能体执行机制演进，从ReAct单线程到V2信箱驻留式多进程架构

OpenAI Codex作为面向开发者的AI编程助手，其底层智能体执行机制在命令行版本（CLI）中已开源实现，并经历了从V1到V2的明确迭代。这一演进并非简单功能叠加，而是对传统ReAct范式在多智能体场景下的系统性重构——从单线程同步闭环，走向异步、隔离、可恢复的多进程协作架构。

基线：ReAct是智能体的通用底座

理解Codex的改进，必须先厘清ReAct的基本逻辑。ReAct将多步任务拆解为“思考→行动→观察”循环：模型基于上下文推理，输出工具调用请求或最终答案；运行时执行工具并将结果追加为新消息；模型再据此继续推理，直至得出结论。该机制具备三大特征：单线程顺序执行、共享单一上下文、工具结果同步内联回填。例如修改配置文件的任务，需依次判断路径、调用编辑工具、验证结果，每一步都依赖前一步输出。

图1清晰展示了这一闭环结构：用户输入启动流程，模型推理生成工具调用，运行时执行后反馈结果，驱动下一轮推理；最大步数限制防止死循环。这是当前绝大多数智能体（包括Codex初版）的基础框架。

V1：异步派生，但父Agent仍需阻塞等待

Codex V1首次引入多智能体概念，采用“父Agent派生子Agent”的模式。当主任务需分解为多个子任务时，父Agent通过spawn_agent立即返回一个ID，不阻塞自身执行；子Agent在独立线程中启动各自的ReAct循环，后台运行。

关键限制在于：子Agent完成时仅向父Agent发送一条“状态通知”，父Agent仍需主动调用wait读取子线程结果，才能继续后续推理。这意味着尽管子任务并行执行，父Agent在关键节点仍处于同步等待状态，无法真正释放计算资源。

更进一步，V1的“完成通知”仅包含子Agent路径与状态（如Completed/Errored），不携带实际输出内容；父Agent需额外读取历史记录获取结果。这种设计虽实现初步解耦，但信息传递效率低，且缺乏错误隔离——若某子Agent崩溃，整棵树可能被误判为失败。

图3详细呈现了V1的8个步骤：从父Agent派生开始，经独立后台任务、子线程并行运行、终态判定、监工过滤、组装通知、写入历史，最终父Agent才读取结果。其中第⑦步“只写历史不唤醒”成为性能瓶颈：父Agent无法被子任务主动唤醒，只能轮询或被动等待。

V2：信箱+驻留，实现可唤醒的异步协同

Codex V2的核心突破在于引入“信箱”（Inbox）与“驻留”（Stay）机制，彻底改变父子Agent间的通信范式。父Agent在派生子Agent时不再仅返回ID，而是为其分配一个专属信箱；子Agent执行完毕后，将完整结果（含输出内容）投递至该信箱，并可选择“驻留”——即保持进程活跃，等待后续指令。

此时父Agent无需阻塞等待：它可继续处理其他任务，待需要子结果时，通过read_inbox主动拉取，或由信箱在有新消息时触发唤醒（如事件驱动）。更重要的是，驻留机制允许子Agent在完成首轮任务后暂不退出，后续若父Agent发出新指令（如“重试”“补充分析”），可直接复用已有上下文与状态，避免重复初始化开销。

图2直观对比了三者差异：ReAct为单线程内联；V1为异步派生+单向通知+父等待；V2则升级为“信箱寻址+可唤醒驻留”，形成真正的异步事件驱动模型。V2中fork_turns=none参数表明：父Agent仅下发指令，不参与子任务的推理轮次控制，职责边界更清晰。

实际影响：从工程实践看架构价值

这一演进对开发者意味着什么？以Codex处理Git仓库变更为例（图4所示界面）：用户要求“检查并修复所有未提交的代码风格问题”，系统可派生多个子Agent分别扫描不同目录。在V1下，主Agent需等待全部子任务返回状态后才开始汇总；而在V2中，首个子Agent发现严重问题即可立即投递高优消息至信箱，主Agent收到后可中断其他扫描、优先生成修复建议，大幅缩短响应延迟。

此外，驻留机制显著提升容错性。若某子Agent因网络波动暂时失败，其进程仍在驻留状态，父Agent可发送重试指令而非重启整个任务树；信箱中的历史消息也便于调试与审计——这正是图4中“AssistantSession”类封装get_sync_analysis等方法的底层支撑。

值得注意的是，Codex App端虽未开源，但官方说明其底层执行逻辑与CLI一致。这意味着上述机制不仅适用于命令行工具链，也延伸至图形化IDE插件等生产环境。

行业启示：多智能体架构的通用趋势

Codex的V1→V2演进，折射出当前智能体系统设计的共性方向：

解耦通信：从“调用-返回”同步模型转向“发布-订阅”异步模型，降低耦合度；
状态持久化：子Agent结果不再仅存于内存，而是通过信箱实现轻量级持久化，支持断点续跑；
资源复用：驻留机制减少进程创建/销毁开销，对高频调用场景（如代码审查、测试生成）尤为关键。

类似思路已在其他框架中出现：LangChain的AgentExecutor支持子链异步执行；Microsoft AutoGen引入“GroupChat”协调多Agent，亦强调消息队列与状态隔离。Codex的贡献在于将这一抽象理念落地为可工程化的Rust实现，并通过版本对比清晰呈现权衡取舍。

需要指出，多智能体并非万能解法。对于简单任务（如单文件修改），ReAct单线程反而更高效；V2的优势集中在高并发、长周期、强依赖的复合任务中。开发者应根据场景选择适配机制，而非盲目追求“多”。

图5所示的“TRAe AI编程”品牌定位，恰反映了此类技术的落地价值：响应式编码助手需在毫秒级延迟内完成多步骤推理与工具调用，而V2架构正是支撑这一体验的底层保障。

Codex智能体执行机制的迭代表明，当AI从“单步回答”迈向“自主执行”，其运行时架构必须同步进化——从模拟人类思维的ReAct闭环，走向更接近分布式系统的信箱-驻留模型。这不仅是OpenAI的内部优化，也为行业提供了可复用的工程范式。