Codex子代理配置致会话断开，修改参数即可解决

背景

在 AI 编程助手 Codex 的使用场景中，用户通过修改配置文件来调整模型的行为模式，以适配高强度的开发需求。近期，部分用户参考 codex-turbo 的配置方案，启用了子代理（Sub-agents）功能，并开启了 V1 和 V2 两个版本的多代理支持。然而，在 Codex 进行版本更新后，这种高强度配置导致了系统稳定性问题。具体表现为新创建的会话无法正常启动，而旧会话则能正常运行，且错误日志中频繁出现连接中断和上游请求失败的提示，严重影响了开发效率。

核心内容

该问题主要源于 Codex 更新后，其多代理（Multi-agent）机制在 V2 版本下的兼容性与稳定性表现不佳，特别是在配合高强度子代理配置时。

症状表现： 当用户尝试在新会话中执行任务时，系统会陷入持续的 work（工作）状态并不断重试。最终，操作失败并抛出以下错误信息： stream disconnected before completion: Upstream request failed 这表明在流式传输完成之前，与服务器的上游连接意外断开，导致请求失败。值得注意的是，之前创建的旧会话不受此影响，仍能正常运行，说明问题主要出在新会话初始化的流程或新配置与当前版本的冲突上。

解决方案： 通过修改 Codex 的配置文件，禁用多代理 V2 版本，仅保留基础的多代理功能，即可解决该问题。具体配置修改如下：

[features]
multi_agent = true
multi_agent_v2 = false

将 multi_agent_v2 设置为 false 后，系统回退到更稳定的 V1 多代理实现方式，从而避免了因 V2 版本潜在的不稳定或兼容性问题导致的连接中断。

关键要点

• 问题根源：Codex 版本更新后，multi_agent_v2 功能在高强度子代理使用场景下存在稳定性缺陷，导致新会话流式连接中断。
• 错误特征：新会话卡死在 work 状态并无限重试，最终报错 stream disconnected before completion: Upstream request failed；旧会话不受影响。
• 修复方法：在配置文件的 [features] 部分，显式设置 multi_agent_v2 = false，同时保持 multi_agent = true 以启用基础多代理功能。
• 配置参考：此方案基于用户参考 codex-turbo 配置后的实际测试反馈，适用于遇到类似连接失败问题的用户。

意义与影响

这一解决方案揭示了 AI 工具在快速迭代过程中，新功能（如多代理 V2）在特定高负载场景下的成熟度问题。对于重度依赖 Codex 子代理进行复杂任务分解的开发者和 AI 工程师而言，保持配置的稳定性和兼容性至关重要。

该案例也提醒用户，在应用社区推荐的“高强度”或“优化”配置时，需密切关注官方更新日志和社区反馈。当遇到版本更新后的回归问题时，通过降级或禁用存在争议的新特性（如 V2 多代理），往往是一种快速恢复生产力的有效手段。这也为后续 Codex 团队优化 V2 多代理的健壮性提供了来自真实用户场景的宝贵反馈。