本文永久链接 – https://tonybai.com/2026/10/29/how-openai-reinvented-codex
大家好，我是Tony Bai。
【导读】
2025 年夏天，OpenAI 的 Codex 一度显得落后于 Anthropic 的 Claude Code。
它曾经押注云端 Agent，却没能让大多数开发者持续使用。随后，一个规模不大的团队选择重新出发：重写 Agent、转向本地执行、改进编程模型，并最终推出支持多个 Agent 并行工作的桌面应用。
不到一年，这个曾经不被看好的项目，逐渐成为 OpenAI 的核心产品之一，甚至反过来改变了 ChatGPT 的产品形态。
Every 对 OpenAI 核心成员的采访，揭示了这场逆袭背后的真正逻辑：模型进步固然重要，但更关键的是，团队如何找到适合 Agent 的工作方式，并让产品、模型和组织形成一个持续进化的系统。
【文章要点】
- 产品失败不等于技术路线错误。Codex Cloud 的问题，不只是模型能力不足，还包括环境配置复杂、缺乏交互式纠偏等真实使用障碍。
- Agent 不应被单一界面束缚。先打造可复用的 Agent 引擎，再连接 CLI、IDE、桌面应用和云端，有助于降低后续产品创新的成本。
- 真实工作流是模型训练的重要来源。竞赛表现不能完全代表真实工程能力，模型需要学习复杂代码库、测试、调试和开发者的中途干预。
- 多 Agent 并行改变了人的角色。开发者开始从逐行编写代码，转向拆解任务、分配工作、审查结果和控制风险。
- 组织结构决定创新速度。小团队的自主权、跨职能协作和短反馈周期，使产品能够快速试错，而不是被已有成功路径束缚。
2025 年夏天，OpenAI 的编程产品 Codex 正处于一个尴尬的时刻。
几个月前，OpenAI 把 Codex Cloud 推向市场，希望用户能够像给同事分配工作一样，把编程任务交给云端 Agent，随后等待它完成代码修改、测试和交付。
这个愿景听起来相当超前。
但现实并不理想。开发者需要在云端重新配置开发环境，Agent 的工作过程也缺少足够灵活的交互与纠偏能力。产品引起了关注，却没有形成预期中的持续使用。
与此同时，Anthropic 的 Claude Code 正在开发者群体中迅速走红。
OpenAI 面临的挑战已经不只是模型排行榜上的竞争：如果用户开始把完整的开发任务交给另一个 Agent，那么传统的 AI 编程助手是否正在走向过时？
几个月后，局面发生了反转。
2026 年 2 月，OpenAI 发布 Codex 桌面应用，支持多个 Agent 并行处理任务。6 月，OpenAI 宣布 Codex 的周活跃用户超过 500 万，其中约 20% 已经是非开发者用户。Codex 开始从编程工具扩展为更广泛的知识工作平台。
根据 Every 创始人 Dan Shipper 对 OpenAI 核心团队成员的深度采访，这场逆袭并不是一条预先规划好的路线。
它更像一次连续的工程实验：失败、重新设计、重建模型能力，再寻找下一种产品形态。
真正值得研究的问题是：OpenAI 究竟在哪些地方改变了思路，才让 Codex 从一次不成功的发布，走向更广泛的 Agent 产品？
第一步就走错了吗？Codex Cloud 的教训
2025 年 5 月，OpenAI 发布 Codex Cloud。
它的工作方式与传统编程助手不同。用户不必始终守在编辑器旁边，而是可以提交任务，让云端环境独立完成代码修改、运行测试和静态检查，最后返回变更摘要和差异，供开发者审查。
这其实是一个重要的产品判断：未来的编程 Agent 不应该只是帮助人写代码，还应该能够独立执行完整任务。
问题在于，愿景走在了现实能力前面。
云端环境并没有想象中简单
真实软件项目通常依赖复杂的本地环境，包括编译工具、系统库、环境变量、认证凭据、私有依赖和各种开发约定。
把代码仓库复制到云端，并不意味着把整个开发环境也复制了过去。
开发者可能需要花费大量时间配置环境。即使任务已经启动，Agent 也难以像本地结对编程一样，在执行过程中接受及时纠正。
如果用户发现 Agent 理解错了需求，或者想补充一个关键约束，重新开始一次云端任务并不总是方便。
这意味着产品试图减少的工作，反而可能以另一种形式重新出现。
OpenAI 的内部环境掩盖了问题
Codex Cloud 在 OpenAI 内部表现不错，一个重要原因是内部开发环境相对标准化，研究人员也有明确的任务可以交给 Agent。
但外部用户面对的是各种不同的代码库、工具链和开发习惯。
内部环境越顺畅，团队就越容易低估外部用户的迁移成本。
这是一种常见的工程陷阱：产品团队在自己熟悉的环境中验证了技术可行性，却没有充分验证用户能否以合理的成本持续使用它。
模型能力也没有准备好
OpenAI 团队成员在采访中还指出，当时的模型能力不足以支撑他们设想的自主工作方式。
这与环境问题相互叠加。
一个不够可靠的 Agent，如果又缺少便捷的中途干预机制，就很难让用户放心地把复杂任务交给它。
Codex Cloud 的问题不是简单的“云端路线错误”，而是产品所要求的自主程度，超出了当时模型与交互机制能够稳定支持的范围。
失败迫使团队重新思考：如果不能一步跨入完全自主的云端软件工程，下一步应该从哪里开始？
关键转向：从云端任务转向本地 Agent
2025 年夏天，Codex 团队开始转向本地执行。
这并不是放弃自主 Agent 的愿景，而是重新选择实现它的路径。
本地 Agent 可以直接使用开发者已有的代码仓库、工具链和工作环境。它能在熟悉的上下文中读取文件、执行命令、修改代码，并在需要时接受人类指导。
这也是 Claude Code 当时展示出来的一条有效路径。
对于 OpenAI 而言，真正重要的变化还不止于此。
不急着堆功能，而是重写 Agent
团队开始围绕 Codex CLI 重新构建底层 Agent。
这看起来并不符合常见的产品增长直觉。
既然已经有了可用的终端工具，为什么不赶紧增加功能、优化界面、争取用户？
原因在于，CLI 只是用户与 Agent 交互的一种方式，而不是 Agent 本身。
Agent 的核心能力包括理解任务、读取代码、调用工具、执行命令、检查结果，以及根据反馈调整计划。如果这些能力与某个界面深度耦合，那么每次扩展产品形态，都可能需要重新实现大量底层逻辑。
Codex 团队希望解决的是更基础的问题：构建一个能够被不同产品界面复用的 Agent 引擎。
Rust 重写背后的架构意义
根据 Every 的采访，团队使用 Rust 重建了 Agent 的核心实现。
这里值得关注的并不是语言之争，而是架构边界的重新划分。
当 Agent 的执行与推理机制独立出来之后，同一套底层能力便可以服务于不同的入口：
- CLI：面向熟悉终端的开发者。
- IDE 扩展：融入既有编码流程。
- 桌面应用：管理多个 Agent 和长时间运行的任务。
- 云端环境：执行不依赖本地电脑持续在线的任务。
其逻辑可以概括为：
这是一种比单纯开发某个编程助手更具扩展性的设计思路。
产品界面可以变化，模型也可以升级，但只要核心 Agent 能够稳定执行任务，团队就不必每次都从头搭建一套系统。
当竞争从“谁的聊天界面更好用”转向“谁能更可靠地执行任务”，Agent 引擎就成为产品真正的基础设施。
模型如何进化？答案藏在真实工程里
仅仅重写 Agent 还不够。
执行框架再好，如果模型不能理解复杂项目、合理调用工具、处理失败并根据反馈调整计划，Agent 仍然无法完成真正有价值的工作。
OpenAI 在这一阶段的另一项关键工作，是改进模型在真实软件开发场景中的表现。
从研究基础设施开始
Every 的采访揭示了一个有意思的起点。
Tibo Sottiaux 早期参与编程 Agent 工作，并不是为了打造一个面向公众的编程产品，而是希望帮助 OpenAI 的研究人员更快地构建基础设施、运行实验和改进模型。
团队在 OpenAI 内部代码仓库上训练和使用 Agent，让研究人员在日常工作中使用它们。
这形成了一种特殊的反馈循环：
研究人员使用 Agent 完成工作，使用过程中暴露的问题成为新的改进目标；模型能力提升后，又可以帮助研究人员更快地开展下一轮实验。
这就是一种自举式改进机制。
它并不意味着模型可以无条件地自我进化，更不意味着人类工程师可以退出整个过程。真正重要的是，模型参与了生产和改进自身所依赖的工程工具，而人类仍然负责提出目标、评估结果和控制风险。
编程竞赛高手，不一定是优秀的软件工程师
另一个关键问题是：模型在编程测试中表现出色，为什么到了真实项目里，仍然可能表现不佳？
因为真实工程远比写出一个正确的算法复杂。
一个实际的软件任务可能要求 Agent：
- 理解规模庞大、历史包袱沉重的代码库。
- 找出跨越多个模块的故障原因。
- 修改代码后运行测试，并分析失败原因。
- 在用户补充需求或中途打断时调整计划。
- 在权限、安全和兼容性约束下完成任务。
这些能力很难通过单一的竞赛成绩衡量。
据采访，Michelle Pokrass 领导的团队在改进编程模型时，会观察程序员的真实工作方式，将模型遇到的问题转化为可以反复训练和评估的任务。
这种做法将模型优化从抽象的能力竞赛，拉回到实际的工作流中。
模型真正需要学习的，不只是如何生成正确代码，而是如何在不完美的信息和复杂的工程约束下，把任务推进到可交付的状态。
从编程助手到多 Agent 工作台
当底层 Agent 与模型逐步成熟之后，Codex 的产品形态再次发生变化。
2026 年 2 月，OpenAI 发布 Codex macOS 桌面应用。
它没有试图重新打造一个完整的代码编辑器，而是把重点放在任务管理上。
用户可以让一个 Agent 修复缺陷，让另一个 Agent 开发功能，再让第三个 Agent 调查问题。不同任务能够在相互隔离的工作区中运行，用户可以在它们之间切换，检查进展并提供进一步指导。
这改变了人和 AI 的协作方式。
从结对编程到任务委托
传统 AI 编程助手的主要工作模式是：
人写一点代码，AI 提供建议；人再修改一点，AI 再次响应。
这种模式有价值，但它仍然要求开发者持续参与大量细节。
Agent 工作流则把协作单位从代码片段提升到完整任务。
开发者可以提出目标、明确约束、授权工具使用，然后让 Agent 自主执行多个步骤。人类的注意力更多地集中在任务拆解、过程监督和结果审查上。
二者并不是非此即彼。对高风险、需求模糊或需要精细控制的工作，交互式协作仍然重要；对目标明确、验证手段充分的任务，委托式执行则能释放更多生产力。
为什么要让多个 Agent 并行？
软件工程中的许多工作天然可以并行。
例如，在开发一个新功能时，可以让不同 Agent 分别调查现有实现、研究测试覆盖率、探索不同的实现方案，或者处理互相独立的模块。
但并行也带来了新的挑战：多个 Agent 可能修改相同文件、产生冲突，或者沿着不同的假设重复劳动。
因此，多 Agent 产品不仅需要模型智能，还需要任务隔离、状态管理、变更审查和资源协调。
Codex 桌面应用将这些能力整合到一个工作台中，使用户能够同时管理多个任务，而不是在多个聊天窗口之间手工搬运上下文。
这也解释了为什么一个看起来并不复杂的桌面应用，可能成为整个产品体系中的关键节点。
它不是简单地换了一种界面，而是将 Agent 的能力组织成一种新的工作方式。
为什么 Codex 最终反过来改变了 ChatGPT？
Codex 的增长并非只来自界面设计。
模型能力的提升、Agent 执行框架的成熟，以及多任务工作流的建立，共同改变了它可以承担的任务范围。
2026 年 2 月，OpenAI 发布 GPT-5.3-Codex。官方介绍称，该模型融合了此前 Codex 系列的编程能力，以及通用推理与专业知识能力，并能够承担更长时间运行、涉及研究与工具使用的复杂任务。
OpenAI 还披露，Codex 团队曾使用早期版本的 GPT-5.3-Codex 调试训练流程、管理部署和分析评估结果。这进一步体现了 Agent 参与自身研发流程的趋势。
到了 2026 年 6 月，OpenAI 宣布 Codex 周活跃用户超过 500 万，约 20% 的用户已经来自非开发者群体。这些用户开始用它制作报告、电子表格、演示文稿，开展研究和数据分析，并自动化日常工作。
这意味着 Codex 的能力边界正在从软件开发扩展到更广泛的知识工作。
为什么编程 Agent 能够做到这一点？
因为计算机上的大量知识工作，本质上都涉及信息读取、数据处理、文件操作、工具调用和结果验证。代码是组织这些操作的一种通用方式，而软件工程训练出的任务规划、工具使用与迭代执行能力，也可以迁移到其他领域。
从这个角度看，编程并不是 Codex 能力的终点，而是一个极具价值的起点。
当 Agent 可以稳定地操作文件、调用工具、生成交付物并检查结果时，它就不再只是一个回答问题的聊天机器人，而开始成为能够完成工作的执行系统。
Codex 逆袭背后的三条规律
回顾这段历程，OpenAI 的经验至少带来三点启示。
规律一：不要让当前的成功，限制下一代产品
Codex 团队并没有因为编辑器扩展的用户增长，就停止探索更大的产品形态。
这并不意味着已有产品不重要，而是说，当模型能力发生跃迁时，原有的交互方式可能不再是最佳选择。
聊天窗口适合回答问题，编辑器适合辅助编码，任务工作台则更适合管理多个持续执行的 Agent。
不同阶段需要不同的产品形态。
规律二：Agent 的核心竞争力是闭环，而不是单次生成
一个真正有用的 Agent，需要完成一整条链路：
理解目标、获取上下文、执行操作、观察结果、识别失败、调整策略，最终交付可验证的成果。
模型决定了这条链路的能力上限，但执行环境、权限管理、任务状态、测试机制和反馈渠道，决定了能力能否稳定地转化为生产力。
这也是为什么优秀的 Agent 产品，越来越像一套完整的工程系统，而不是一个接入大模型的聊天界面。
规律三：AI 时代，产品开发本身也在被 Agent 改造
Codex 团队利用 Agent 辅助构建和改进产品，这使得开发者可以更快地尝试新的功能和交互方式。
当团队能够以更低成本创建原型、运行测试、发现问题并迭代时，产品创新就不再完全依赖漫长的立项和资源协调过程。
当然，速度并不自动等于质量。安全、可靠性、用户价值和工程治理仍然不可或缺。
但当试验成本下降，团队就有机会同时探索更多路径，而不是过早押注于单一方案。
小结：真正的胜负手，是持续重新定义问题
Codex 的故事并不是一个简单的“后来者逆袭”。
它更像是一次关于 AI 产品如何进化的实验。
云端 Agent 暴露了环境与自主执行的障碍，本地 Agent 提供了更贴近开发者工作流的路径，底层架构重写带来了多种产品形态的可能，真实工程反馈则推动了模型能力的持续改善。最终，多 Agent 桌面应用把这些进步组织成一种更接近任务委托的工作方式。
这条路径最值得借鉴的地方，是 OpenAI 没有把第一次产品选择当成最终答案。
对于正在构建 AI Agent、AI 编程工具乃至内部 AI 软件工厂的团队而言，重要的不是照搬 Codex 的某个功能，而是建立同样的学习机制：
让 Agent 进入真实工作流，用真实结果暴露能力缺口，让模型、执行环境和产品设计共同迭代，并允许新的产品形态挑战已经取得的成功。
因为在 AI 时代，今天最先进的交互方式，很可能只是下一轮能力跃迁之前的过渡形态。
而真正的竞争优势，属于那些能够更快发现这一点，并且有能力重新开始的团队。
参考资料：
- Dan Shipper，Every，How Codex Happened - https://every.to/p/how-codex-happened
- OpenAI，Introducing the Codex app - https://openai.com/index/introducing-the-codex-app
- OpenAI，Introducing GPT-5.3-Codex - https://openai.com/index/introducing-gpt-5-3-codex
- OpenAI，Codex is becoming a productivity tool for everyone - https://openai.com/index/codex-for-knowledge-work/
- OpenAI，Codex for (almost) everything - https://openai.com/index/codex-for-almost-everything
还在为写 Agent 框架频频死循环、上下文爆炸而束手无策？我的新专栏 《从0 开始构建 Agent Harness》 将带你：
- 抛弃臃肿框架，回归“驾驭工程 (Harness Engineering)”的第一性原理
- 用 Go 语言手写 ReAct 循环、并发拦截与上下文压缩引擎等，复刻极简OpenClaw
- 构建坚不可摧的 Safety Middleware 与飞书人工审批防线
- 在底层实现 Token 成本审计、链路追踪与自动化跑分评估
- 从“调包侠”进化为掌控大模型边界的“AI 操作系统架构师”
扫描下方二维码，开启从 0 开始构建Agent Harness 的实战之旅。
还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：
- 告别低效，重塑开发范式
- 驾驭AI Agent(Claude Code)，实现工作流自动化
- 从“AI使用者”进化为规范驱动开发的“工作流指挥家”
扫描下方二维码，开启你的AI原生开发之旅。
商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。
