Home / Newsletters / Featured / Codex 是如何诞生的

Codex 是如何诞生的

Dan ShipperEveryOctober 15, 2026View original
technologyAIproduct
  • 核心主张: OpenAI 的 Codex 之所以成功,并非坚持最初的云端智能体愿景,而是转向本地、终端优先的智能体,并建立专门的编码模型线,随后打造桌面应用,最终成为 ChatGPT 的基础。
  • 具体证据: Codex Cloud 于 2025 年 5 月 16 日发布,但因设置繁琐、用户无法中断智能体而未能找到产品市场契合点;转向后,VS Code/Cursor 扩展使使用量到 2025 年 10 月增长超过 10 倍,到 2026 年 6 月 Codex 每周活跃用户超过 500 万,其中约五分之一是知识工作者。
  • 重要限定: GPT-5 最初与 Claude Code 相比显得胆怯且受沙箱限制,桌面应用也因省略内置代码编辑器而险些被质疑,且模型直到 GPT-5.1 Codex Max 和 GPT-5.2 Codex 才足够好。
  • 关键推动因素: 在 OpenAI 的 monorepo 上训练的独立 Codex 模型线、融合产品与研究的多学科团队,以及优先考虑真实开发者工作流而非基准分数的反馈循环。
  • 结论: 到 2026 年 7 月 9 日,Codex 桌面应用成为新的 ChatGPT 桌面应用,Codex 负责人 Thibault Sottiaux 被提升为所有核心产品与平台负责人;Codex 与 ChatGPT for Work 合计每周活跃用户达 4000 万。

Codex 是如何诞生的


我清楚地记得自己是从什么时候开始觉得 OpenAI 将失去天命——自 ChatGPT 最初走红以来,他们在 AI 编程领域建立起的看似不可逾越的领先优势。那是 2025 年夏天,在 OpenAI 的 Mission Bay 办公室,GPT-5 发布的前一晚。

大楼里弥漫着一种兴奋的气氛。头顶的灯光像舞台灯一样明亮,人们走过那些暖锈色和棕色的走廊时,步伐似乎都比平时快了一点。连重力都显得更沉——仿佛第二天发布会的规模之大,已经把整个世界都拉入了它的轨道。

这让我要说的话显得有些尴尬。

我经营的 Every 公司,已经因为用真实工作来测试新 AI 模型、并解释它们能做什么、不能做什么而逐渐有了名气。OpenAI 在发布前大约一个月给了我们 GPT-5 的访问权限,让我们帮他们了解模型的优缺点,并在发布当天发表我们的 Vibe Check——一篇详细评测。

我们十个人在纽约州北部的一栋房子里待了一周,进行团队静修,围坐在一张长木桌旁吃饭、工作,聚在大屏幕前的沙发上测试这个期待已久的模型。我们尤其兴奋地想试试它在编程上的表现,因为 AI 在这个领域进步最快。但虽然我们喜欢它的日常使用,它在 Codex 里的表现却让我们反应平淡。

如今,Codex 是 OpenAI 东山再起的核心——这个产品已经从内部吞掉了 ChatGPT,成为公司接下来要构建的一切的基础。但那个夏天,它还只是一个打造 AI 软件工程师的草创项目。几个月前发布的云端版本没有找到产品市场契合点,团队正处于转型中期,转向一个在开发者电脑上、在终端和代码编辑器中运行的新版本。

在 Codex 里,GPT-5 很快,看起来也很聪明。我们最技术化的工程师之一 Naveen Naidu 曾用它追踪他语音听写应用 Monologue 中一个困扰他多日的神秘卡死问题。但它似乎也停得太早,仿佛过于谨慎,不敢越出它被允许做的事情的边界。感觉它被设计成结对程序员的角色。

作为一个团队,我们正在超越与 AI 模型一步步协作的方式。使用 Anthropic 的终端智能体 Claude Code,由 Kieran Klaassen 带领的一群人已经开始把整个任务交给 Opus 4,然后走开,直到一个完整的功能——有时甚至是整个应用——被做出来。在工程师的极少帮助下,特约撰稿人 Katie Parrott 在几天内构建并部署了自己的 AI 内容管理系统。它有一些 bug,但以前构建它是不可能的。

在 Claude Code 里的 Opus 4 旁边,Codex 里的 GPT-5 显得束手束脚。

分享我们在测试中的发现,让我来到了 OpenAI 办公室的一间会议室,与传播团队的 Lindsay McCallum 和 Codex 团队的 Alexander Embiricos 坐在一起。我感觉到 McCallum——她对市场氛围的转变有着敏锐的雷达——安排了这次对话,好让我向 Embiricos 解释为什么我突然对这种新的工作方式喋喋不休。

McCallum 坐在会议桌对面,全神贯注地在笔记本电脑上打字。Embiricos 坐在我旁边,一边说话一边写代码,我觉得这是个好兆头。他正赶着完成一个 GPT-5 发布功能,让智能体可以暂停并请求人类许可,以访问文件或在其沙箱外运行命令。

“用 Claude Code,你就直接放手让它跑,”我告诉 Embiricos。“GPT-5 感觉有点胆怯——像是被沙箱束缚住了,似乎害怕使用自己的力量。”

McCallum 敲键盘的声音慢了下来。“跟 Alexander 讲讲你那个新的工程工作流,”我记得她说着,目光没有离开笔记本电脑。

Embiricos 把椅子转过来,完全面向我。

“我们甚至都不怎么看代码了,”我开始说。但说这话时我脸红了。向 Embiricos 解释智能体委托让我觉得自己很可笑——毕竟构建自主编程智能体就是他的工作。而且当时我也不确定,我们的工程方法在我们这个小团队之外是否行得通。

一条 Slack 提示点亮了 Embiricos 的屏幕,打破了会议室里突然的安静。他把电脑静音,把盖子合上四分之三——刚好让他的 Codex 智能体继续思考。

那晚离开 Mission Bay 时,我想 OpenAI 是不是在为一个正在消亡的工作流打造完美的工具。被失败的云端智能体灼伤过一次后,公司看起来正在退回到代码编辑器,在那里 AI 帮助程序员一步步工作。与此同时,Claude Code 在那些把整个任务交出去然后走开的人中间迅速流行起来。

留在编辑器里有充分的理由。GPT-5 发布后,Codex 团队推出了一个扩展,把 Codex 塞进 Microsoft 的 Visual Studio Code(VS Code)和 Cursor 等代码编辑器的侧边栏——程序员在这些编辑器里编写、运行和调试代码。到去年十月,使用量增长了 10 倍以上,编辑器扩展迅速超过终端,成为 Codex 最常用的界面。[1]

在大多数公司,这本来是会加倍投入的业务。但 Embiricos 和 OpenAI 内部一小群工程师、设计师和研究员有着更大的野心。

在接下来的几个月里,Codex 团队训练并快速改进了一条专门的编程模型线,独立于驱动 ChatGPT 的模型,并构建了一个桌面应用来同时管理多个智能体。到 2026 年 6 月,Codex 的周活跃用户超过 500 万,并从编程扩展到其他类型的知识工作。

到2026年7月,Codex已并入旗舰版ChatGPT桌面应用。其负责人Thibault Sottiaux已升任OpenAI所有核心产品与平台的主管,统管ChatGPT、Codex和API。如今,Codex与ChatGPT for Work合计拥有4000万周活跃用户。

不到一年时间,Codex团队从一次失败的云端发布,蜕变为OpenAI旗舰产品的基石——并在此过程中帮助重塑了这家公司。

这就是Codex诞生的故事。

思考中……

有些不对劲。一年前的那个线索没有出现在结果里……

问题似乎比我预想的更早出现……

回到最初……

思考中……

OpenAI的逆袭始于一行简单的文字:“思考中……”

2026年,无论你何时与AI模型交互、提出任何复杂请求,你都会看到那个词——思考中——在你即将看到回复的位置闪烁。

这看似微不足道:不过是用一个词替代macOS上旋转的沙滩球,或Windows光标旁旋转的蓝色圆环——那些都是计算机忙得无法响应的标志。

但在这一语境下,“思考中”代表了一种全新的计算方式,没有它,Codex就永远不会诞生。

第一代大语言模型是外部处理器。它们没有为内部推理设置闪烁的状态标签;相反,它们通过直接回复你来完成思考。无论你让它们写一封邮件还是一行代码,它们都必须逐词推敲答案,没有机会提前规划或事后修改。

如此一来,早期的聊天模型就像即兴演员,观众给出一个提示,他们便以此为基础当场编出一幕戏。这些工具边想边说,结果可能令人惊艳——有时也会无意中引人发笑。(它们会坚称“strawberry”里有两个r,拼出来证明给你看,最后还自我表扬一番。)

这些模型的早期用户注意到,如果你让模型在回答之前逐步写出推理过程,它往往能得出更好的答案。这种技巧——与小学数学老师给学生的建议如出一辙——被称为思维链提示。

思维链提示催生了第二代AI模型和闪烁的“思考中”用户界面。OpenAI不再要求用户让模型逐步解决问题,而是将这种行为训练进了模型本身。在回复之前,推理模型会在一块草稿区——称为推理轨迹——中工作,从不同角度攻克问题,从死胡同中退回,选择更可能成功的路径。只有在确定答案后,它才会做出回复。

OpenAI将这类模型中的第一个命名为o1,并于2024年9月发布了预览版。在此之前,进步主要依赖于训练更大的模型、训练更长时间。有了o1,OpenAI发现同一个模型只需在难题上花更多时间,就能改进答案。

有一种工作最能从中获益:编程。编程与推理模型天然契合,因为它提供了一个闭环:模型可以编辑代码、运行代码,几秒钟内就能看到修改是否奏效,从而自主测试和修正,无需人工检查。

理论上,只要给推理模型足够长的思考时间,它就能独立完成任何编程任务。

多次起点

构建AI程序员一直是OpenAI的目标,由来已久,以至于Codex有过许多个起点——从它的名字开始。[2]

第一个Codex于2021年发布,是在公开代码上微调的GPT-3版本,为最初的GitHub Copilot提供支持。三年后,在o1预览版展示了推理模型的能力之后的几周里,领导层的一项指令让OpenAI多个团队从不同方向再次追逐这个梦想。

其中一个起点来自2024年底的Embiricos。

“对我来说,第一个真正大规模的‘感受AGI’时刻,是[当我]看到有人运行一个连接了终端的推理模型,”[3]他告诉我,指的是AI不再像工具、而开始像一台能思考和行动的机器的时刻。“我知道[这]现在听起来不刺激,”但看着它读取文件、运行命令、自行处理错误,“真他妈酷。”

Embiricos——我在GPT-5发布前夜见到的产品负责人——于当年早些时候加入OpenAI,当时公司收购了Multi,一款他联合创办的面向程序员的多人在线屏幕共享工具。在OpenAI,他追寻一个相关的想法:让人类和智能体在他们使用的应用内协同工作。他先在ChatGPT桌面应用上追逐这一愿景,随后又尝试了Atlas——一款AI驱动的浏览器,[4],但当时的模型在读取用户屏幕方面太慢太笨拙,无法实用。

然而在终端里,模型不必读取屏幕——它们可以直接处理文本和代码。在终端中看到早期推理模型的表现,让Embiricos确信它们能够驱动一款真正的编程产品。编程还不是他的全职工作,但他立刻开始勾画起来。他认为,要让产品奏效,用户需要每30秒、至多每分钟就能看到模型在做什么。

速度再次成为问题。当时大多数 AI 编程产品都围绕 VS Code 生长。GitHub Copilot 通过扩展加入 AI 自动补全;Cursor 和 Windsurf 则基于 VS Code 的开源代码打造自己的编辑器,在程序员工作的地方加入 AI 聊天。

这些工具依赖紧密的反馈循环。Copilot 补全你正在输入的那一行;Cursor 和 Windsurf 在几秒内回答问题。它们都不要求模型长时间自主工作,因为模型做不到。OpenAI 早期的推理模型恰恰相反:一旦思考时间被压缩,它们就既慢又弱。

他能否把它们的缺陷——获得响应所需的时间——变成优势?

打造构建者的人

与此同时,在 OpenAI 的另一个部门,人称 Tibo 的 Sottiaux 正试图让推理模型反过来作用于自身:用它们的能力帮助研究人员构建下一代模型。

“我在 2024 年 12 月左右开始参与编程智能体,”他告诉我。[5] 我们坐在 OpenAI 的自助餐厅里。他光泽的棕色头发垂向一侧,戴着细金属框眼镜,镜片映着午后的光。如果说鼻子以上让他看起来像建筑师,鼻子以下则完全是程序员:棕色胡茬,深棕色连帽衫,上面印着“Research and Deployment Co”,手里还拿着一片意大利辣香肠披萨。

他一边吃披萨一边告诉我,目标是“帮助我们更快地编写基础设施代码和做研究”。[6]

Sottiaux 职业生涯的大部分时间都在为研究人员构建基础设施,先是在 DeepMind,后来在 OpenAI。研究基础设施——AI 研究人员用来运行、评估、复现和部署实验的共享代码——对于一个最终领导 Codex 的人来说,似乎是个奇怪的出身故事。提到基础设施,你可能会想到服务器和海底电缆,相当于科技世界里的管道:必要,但在管道漏水之前一直隐形。

不过在 AI 世界里,基础设施——尤其是研究基础设施——正是许多事情发生的地方。如果你能缩短运行一次实验所需的时间,你就能运行更多实验,更快得到更好的模型。

“你们是什么时候把模型线拆出来的?”我问。“你们是怎么决定的?”我想快进到关键情节。拥有自己的模型线似乎是 Codex 魔力的核心,我想象着 OpenAI 内部的一场会议,Sottiaux、总裁兼联合创始人 Greg Brockman 或 CEO Sam Altman 做出了一个有远见的决定,把 Codex 与 ChatGPT 的其余部分分开——让团队可以自由快速发布,并从内部颠覆公司。

“并没有决定要拆出模型线,”Sottiaux 平静地说。他说,一开始,“这是一次研究探索,也是对速度的优化。”

Sottiaux 的团队并没有为公众消费构建模型,而是在 OpenAI 的 monorepo[7] 上训练内部编程智能体,那是该组织所有代码所在的单一仓库。这些智能体编写 OpenAI 研究人员所需的 Python 代码,用来运行和改进构建新模型的系统。那些研究人员每天都在使用这些智能体,给了团队一个紧密的反馈循环。

“我们看到编程方面进展迅速,”Sottiaux 说。他的团队频繁训练模型,所用技术与更大组织为公众训练模型的方式不同——而且在一段时间内,两者很难协调。

Sottiaux 和 AI 实验室里的每个人一样,对这些训练技术守口如瓶。但很明显它们奏效了:他的团队成功让模型反过来作用于创造它们的研究过程,研究人员正在用这些模型制造下一代模型。[8]

工程师把这称为自举。做一个擅长帮助研究人员运行实验的模型,研究人员就能用它构建一个更强大的模型,后者能运行更好的实验,进而带来更好的模型,如此循环。

这项工作提供了后来成为 Codex 的一半:能够改进基础设施、用于构建新模型的智能体。要成为公司其他部门也能使用、并最终走出 OpenAI 边界的产品,它还需要另一半:Embiricos 关于人们应该如何与这些智能体协作的论点。

思考中……

目前有三种方案……

其中两种有重叠……

我会把它们合并,然后继续采用有效的部分……

收敛

探索之后是收敛。

我们可以从高处想象 2024 年末到 2025 年初的 OpenAI。编程成为公司顶层目标之后,[9] 包括 Sottiaux 和 Embiricos 在内的几个个人团队,已经开始从不同角度研究同一个问题。

Brockman 告诉我,悬而未决的问题是合适的“形态”:智能体应该待在开发者执行命令的终端里,待在开发者写代码的编辑器里,还是待在云端、在自己的计算机上工作。其中一些路径是死胡同,但当时没人知道是哪些。

“从某种意义上说,OpenAI 是在押注一系列创业公司,只不过它们都是内部的,”Altman 在 2025 年接受 Ben Thompson 采访时表示。在我交谈过的几位内部人士看来,公司内部这种并行探索的精神有时显得混乱而浪费。谁愿意去那个在 OpenAI 内部做出第三好 agent 产品的团队工作呢?我自己公司也推行过类似的策略,深知在留出探索空间和搞得一团糟之间,只有一线之隔。

但在观察 OpenAI 的过程中——尽管我也听到了内部的抱怨——我逐渐认识到,当前沿不断推进时,这种做法是必要的。在 AI 领域,模型层面快速的“延续性”进步——借用已故哈佛教授 Clayton Christensen 的说法——不断催生出新类型的应用,同时持续颠覆此前的应用。

一个能补全一行代码的模型,适合做自动补全工具;一个能思考 30 秒的模型,可以在聊天侧边栏里回答问题;而一个能工作一小时的模型,想要成为的则是完全不同的东西。围绕上一代模型做出成功的产品,并不意味着你知道下一步是什么。你需要多个团队尝试不同的想法,然后在看清什么有用之后,再把他们的工作整合起来。

到 2025 年初,OpenAI 已经准备好这样做了。“最终,我们认为应该与另一项名为 Scientist Assistant 的工作合并力量,”[11] Sottiaux 告诉我——这次合并让他与 Embiricos 走到了一起。Brockman 说,在内部各个编程方向的努力中,“我们最终合并了其中两个。然后又合并了另外两个。”[12] 合并后的团队是一支小型多学科队伍,既有 Embiricos 这样的技术产品思考者,也有 Sottiaux 这样的基础设施和工程奇才,还有 Mia Glaese 这样的研究人员。

Glaese 从 DeepMind 来到 OpenAI,此前她在 DeepMind 从事 Gemini 和模型对齐方面的工作。在 OpenAI,她负责模型训练和对齐所用的数据,[13]也就是说,她专长于获取和使用能够塑造模型具体行为的数据。

在某个层面上,她是一个彻底不带感情色彩的实证主义者。在我们的采访中,她毫不掩饰对量化的重视:“在研究里,只靠感觉没什么用,”她说。然而,当她谈到制作模型的过程时,她又会立刻笑着承认,其中很大一部分是跃入未知。

“每次我们训练一个模型,都像是踏上一场神奇的冒险,我们会想,‘我们到底要怎么做到这件事?’”她说。

这种多学科团队——产品人员和研究人员并肩工作——在 AI 领域多少有些不同寻常。AI 历来是一个研究驱动的领域,最优秀的研究人员能拿到数百万美元、堪比 LeBron James 的合同,而其他人则拿着行业标准的工程薪资。(AI 实验室长期以来一直试图抵消这种被神化的超级明星效应,办法是给大多数技术员工——无论是不是研究人员——都冠以“Member of Technical Staff”的头衔。)

与产品团队一起工作,让 Glaese 和其他研究人员有机会看到自己的模型是如何被使用的——并听到人们希望模型接下来能做什么。产品人员可以问:“如果模型能做到这件事,那岂不是太棒了?”然后研究人员就可以把它变成现实。这又是 Sottiaux 的自举循环,只不过这一次是在模型和基于它构建的产品之间运转。

OpenAI 终于有了自己的 Codex 团队——产品、设计和研究——全部协同工作。现在,他们只需要决定要构建什么。

思考中……
我可以试试终端、编辑器,或者云端……

哪种方式适合我手头的模型?

我们的研究人员在云端工作。其他开发者也能在那里工作吗?

云端及其局限

在 Anthropic,一条有前景的路径已经开始起飞。

2025 年 2 月 24 日,该公司发布了 Claude 3.7 Sonnet,同时推出了 Claude Code 的研究预览版。与 Cursor 及类似工具不同,Claude Code 没有内置代码编辑器。它运行在终端中,直接操作你自己电脑上的文件:你告诉它你想要什么,它就会读取代码、进行修改并运行。

由于它运行在你自己的电脑上,它的工作成果会落到你本来就在使用的同一批文件中,使用你已经安装好的同一批工具,并且带着你们此前共同积累的全部上下文。你可以在任务进行到一半时打断它。你也可以把一次会话中学到的经验带入下一次,让你的系统随时间不断改进和累积——而 Codex Cloud 那种短暂的云端计算机则做不到这一点。

开发者很快就接受了 Claude Code。例如在 Every,Edmar Ferreira 在 2025 年 3 月的一篇 Vibe Check 中写道:“Claude Code 比我在 agent 方面用过的任何东西都好。”团队其他成员也开始认同这一点。

到2025年春天,合并后的Codex团队——Embiricos、Sottiaux、Glaese以及其他几个人——将目光投向了软件工程未来的另一番愿景:Codex Cloud。他们设想的是一个云端代理,拥有自己的计算机,专为异步工作而设计,让用户可以从电脑或手机上委派编码任务。他们给自己大约七周时间来构建并发布它。[14]

你可以在ChatGPT的侧边栏中点击Codex,打开一个工作区,在其中描述任务并点击“Code”。任务会进入队列,提示框随即清空,可以输入下一个任务。Codex会将你的代码库复制到一台隔离的云机器上,编辑文件,并运行测试和linter——即扫描代码中常见错误的工具。它会返回一份摘要、一份变更diff,以及一个打开pull request的按钮。

Codex Cloud于2025年5月16日发布,比我与McCallum和Embiricos在Mission Bay见面的那个夜晚早了近三个月。Sottiaux告诉我,它在“内部非常成功”[15]。在OpenAI之外,它的发布引起了兴趣,但几乎没有持续使用。[16]

要让它运转起来,开发者必须在云端重建自己笔记本电脑上的软件、权限和设置[17]——这个过程可能耗时数小时,因为你需要复制凭证并安装关键软件包。一旦设置完成,它可以完成一个定义明确的任务。但你无法打断它来纠正方向,甚至一个后续提示也会启动一台全新的云计算机。

“如果你是一位技术负责人,要在现有代码库上添加功能或修复bug,这是一个你会用到的工具。如果你想凭感觉编码,创办一家新的一人十亿美元SaaS公司,那就另寻他处吧,”我在发布当天的Vibe Check中写道。

在OpenAI内部,标准化的开发环境让设置自动完成,研究人员也有明确定义的工作可以交接。团队自身的工作环境掩盖了他们对外界提出的要求有多高。

拖累Codex Cloud的不只是产品本身。“它出现得太早了,因为模型还不够聪明,”[18]Embiricos说。

“我们当时是带着一种更偏向未来的愿景来推进这件事的,”Glaese告诉我。“我们并没有采取那种‘让我们去人们所在的地方’的做法,”而人们所在的地方“就是他们的笔记本电脑上”。

那么,OpenAI为什么跳过了终端这一形态——而它后来在Anthropic那里开始奏效?

“我们并没有跳过它,”Sottiaux在我们于自助餐厅的谈话中告诉我,他指的是一个未发布的内部原型。“我们构建了一个那样的版本,然后在一个月后将其丢弃,转而去做完整的云端版本。”

“为什么?”我问。我知道,在我四周那些巨大的落地窗外,某个地方,如果我认真看,也许能在地平线上找到Anthropic的办公室。我肯定可以不费什么力气就走到那里。旧金山是个小城。

“因为我们在优化我们认为自己最可能从中受益的东西——前提是我们愿意在设置上投入大量资源,”[19]他说。

这个答案背后,是我从OpenAI内部人士那里一次又一次听到的信念。对他们来说,AI代理的理想形态始终是在云端为你自主工作,不会因为你合上笔记本电脑而停止响应。Brockman在我们的采访中也说过同样的话:“如果你向未来推演,正确的形态就是云端拥有自己笔记本电脑的AI。所以我们实际上就是这么构建的。”[20]

这一选择也是与模型局限之间的一种妥协。团队围绕那些能在任务上花费更长时间的模型构建了第一款Cloud产品,[21]而不是对程序员的需求作出逐刻响应。

问题在于,它没有奏效。Cloud产品未能找到产品市场契合点。团队的工程经理离职去了Cursor——AI编码领域的领跑者,估值90亿美元。大约在这段时间,据报道OpenAI达成了一项30亿美元的协议,收购Cursor最接近的竞争对手Windsurf。那笔交易在7月破裂。

“最具挑战性的时期,是我们感觉自己不知道该怎么办的时候。或者我们知道该怎么办,但很难看到[进展]真的在发生,”Embiricos告诉我。

Codex团队——在某种程度上也包括OpenAI更广泛的编码雄心——第一次迷失在荒野之中。

思考中……

嗯,这在我们的环境里行得通。为什么对用户就不行?

也许我试图修复的是错误的东西……

回到我搁置一旁的本地方案……

这里有些东西。但我需要重建它……

另一条路

一个推理模型之所以强大,在于它能够回溯。如果它认为 bug 位于代码的某个特定部分并重写了那段代码,却发现 bug 依然存在,它通常不会继续自信地沿着错误方向前进。它能够重新审视自己的假设,扩大搜索解决方案的范围,并根据所学到的东西决定一条新的、更有希望的路。

正是这种利用错误来纠正方向的能力,让推理模型能够找到一开始并不明显的答案。

Cloud 发布之后,在 2025 年春末和夏季,Codex 团队准备尝试另一条路。当时,这个项目正处于设计师 Ed Bayes——他最近刚加入团队——所回忆的 OpenAI“后院”位置。“如果你想当性感的设计师,”他告诉我,“你就去搞 ChatGPT。”

就在这个被忽视的前哨,Sottiaux 以团队工程经理的身份走马上任。“我接管了团队,然后我把方向改变了不少,”[22]他告诉我。“我们转向了本地。”

“本地”意味着在开发者自己的电脑上运行 agent,就像 Claude Code 那样,而不是在云端。他们从本地 Codex CLI开始,正如 Embiricos 提到的,这个项目是作为两人副项目“英勇地”做出来的。Sottiaux 没有立刻给它添加功能——那样会很快形成势头——而是采取了不同的策略。他决定重写这个 agent。[23]

“我们在拥有真正好的 CLI 功能方面有点慢,”[24]他告诉我,“因为我们太忙于开发 agent 了。”

CLI 是用户交互的界面,但 Sottiaux 的优先事项是底层的机制:读取文件、运行命令等等的 agent。他想改进它,并将它与终端界面分离,这样它就可以存在于任何地方——代码编辑器、桌面或移动应用、云端,或者 ChatGPT 本身。

团队用 Rust 重写了这个 agent,[25]这种语言是为速度和安全性至关重要的系统而设计的。同样的机制随后可以同时驱动终端 CLI,以及后来的编辑器扩展。

不过,他们仍然缺少一个足够好、能够驱动它的模型。

当 Codex 团队在 Sottiaux 的领导下重建其 agent 时,Michelle Pokrass 正在努力让 GPT-5 更擅长真实世界的编程。

Pokrass 曾领导 GPT-4.1 的研究,她负责后训练——优化一个已经训练好的模型的行为,使其能够处理真实编程工作——重点放在那些要求更好交互式编程的客户身上。[26]

一个编程模型可能就像一个 SAT 满分却从未工作过的学生。OpenAI 的模型在编程竞赛中表现出色,但这些成绩并没有延续到日常工程中。“它们从未见过混乱的代码库,也没见过程序员可能如何在中途打断它,”Brockman 告诉我。

为了让这些书本知识丰富的模型获得真实世界经验,Pokrass 和她的团队坐在程序员旁边,观察他们工作,看看模型在哪里出问题,并把那些失败转化为可重复的训练任务。

这就是 OpenAI 如何得到那个模型——以及那个时刻——在 2025 年 8 月把我带到 Mission Bay 那间会议室。

从 Codex 团队那个动荡的夏天内部来看,我那天晚上在 GPT-5 中感受到的谨慎是合理的。由于试图用 Codex Cloud 直接跃向完全自主而受挫,再加上客户要求更好的交互式协作者,OpenAI 构建了一个擅长与人类程序员一步步协作的模型。它能够理解一个混乱代码库的各部分如何组合在一起,解释自己的计划,调查 bug,并在越界之前停下来询问。

与 Claude Code 相比,在我们 Every 看来,Codex CLI 中的 GPT-5 仍然落后。Kieran 在我们的发布日 Vibe Check中写道:“GPT-5 是 Sonnet 3.5 杀手,而不是向未来的飞跃。”但对当时绝大多数软件工程师来说,一个谨慎的协作者正是他们想要的。把生产代码委托给自主 agent,仍然常被那些习惯亲手写每一行代码的程序员嗤之以鼻。

“我不让它驱动我的代码,”Ruby on Rails 的创造者、工程社区中颇具影响力的声音 David Heinemeier Hansson 在 GPT-5 发布前后说。“程序员——作为程序员的我——的快乐,就是自己输入代码。”此外,他说,当 agent 驱动时,“我真的能感觉到能力从我的手指中流失。”

当 Codex 团队在 8 月底 GPT-5 发布后推出 VS Code 和 Cursor 扩展时,那些开发者蜂拥而至。他们的热情给了 OpenAI 充分理由继续改进这个扩展。每一个新用户和功能请求都把团队拉向帮助程序员一步步工作,并远离构建能够承担完整任务的 agent。

不过,对 Embiricos 来说,同一次发布意味着团队可以追求他们更大的雄心。在荒野中数月之后,重建后的本地 agent 终于有了一个能够驱动它的模型。

一旦他们带着改版后的 CLI 发布 GPT-5,他告诉我,“它创造了一个自我实现的飞轮。”

他记得自己当时想:“现在我们终于可以战斗了。”

思考中……
CLI 和编辑器扩展终于开始起飞了……

客户很喜欢侧边栏,而 Claude Code 是终端里要打败的产品……

让我们加倍投入编辑器扩展,并在终端里追赶上去……

被 Tibo 打断

桌面端的赌注

随着 Codex CLI 和 VS Code 扩展的人气暴涨,合乎逻辑的选择应该是继续在这两者上投入。

然而,Codex 团队却做了出人意料的事。

“ 我们决定应该继续维护 CLI,但下一个最大的即时投入应该是一款原生桌面应用,”Sottiaux 告诉我。

在 OpenAI 内部,他可以看到模型正在完成更长的任务,并从代码库之外获取信息,语音和图像也即将到来。人们很快就会同时运行多个 agent,并整天与它们相伴。“如果你要整天待在里面,它就必须是一个非常丰富的界面,”他说。在他看来,试图在一个建于 1970 年代的纯文本窗口里,同时应付六个通过文本、图像、语音和视频交流的 agent,简直是荒唐。

对 Embiricos 来说,本地桌面应用也指向了 Codex Cloud 未能实现的工作流——在 Codex Cloud 中,用户无法在任务执行中途打断 agent。他认为,有了装在自己电脑上的应用,人们可以先与 agent 紧密协作,然后像带新队友一样,逐渐学会哪些任务可以放手交给它。[27] 同一个界面最终还可能让 Codex 走出开发者群体,触达那些永远不会打开终端的人。

为了帮助设计和构建它,Sottiaux 请来了 Andrew Ambrosino——一位设计师、程序员,也是前创业公司创始人。

Ambrosino 让我想起《办公室》里 B.J. Novak 饰演的角色:深色头发、浓密的眉毛,还有一个小小的、抿着嘴的微笑。无论是当面还是在网上,他都给人一种 内心始终在暗自好笑 的感觉;别人是否和他一起笑,是一个他会考虑的因素,但往往似乎没那么重要。

任何关注他、想从中了解人工智能未来的人,翻看他的动态,可能会发现一条有 617 个赞的帖子,内容只有一个词:“ai。”另一条帖子则神秘地写着 “tibo”(1000 多个赞)。

当 Ambrosino 加入这个开发应用的小团队时,他们知道自己想做一款桌面应用,但不知道它该是什么样子。[28] 团队唯一确定的是,他们想做出一个自己会用的东西。

Ambrosino 告诉我,他们的第一个任务,就是让这款应用成为自己日常工作的主要工具。[29] “我们知道想要一个能当日常主力用的界面,但 [一个] 比 IDE 更轻量的界面,”他说。

随着 Claude Code 起飞,已经有一些应用开始尝试探索:在终端之外,编码 agent 的家园可能是什么样子。Conductor 是一款用于运行编码 agent 的 Mac 应用,它有一个任务侧边栏,每个任务都有自己的 agent 和聊天,你可以在其中给出指令并跟进工作。ChatGPT 提供了另一个参照:侧边是一列对话,中间是单个线程。Codex 应用“更多是从聊天中汲取灵感,而不是从 VS Code 中”,[30] Ambrosino 在谈到他们的设计过程时说。到那时,Anthropic 也已经有了 Claude 桌面应用。

团队工作得很快,回答了那些基本问题:用户如何跟踪自己的工作(每个任务都有自己的 agent 对话)、侧边栏应该如何组织(对话按项目分组),以及基本界面应该如何布局(所选对话旁边是任务侧边栏)。

然后是一个更难的问题:当 agent 出错时,你能不能在 Codex 里手动修复代码?团队决定给出一个冒险的答案:不内置代码编辑器。如果你想对代码做任何修改,就必须让 agent 来做。

“我们特意想让它 [与代码编辑器] 成为不同的东西,”Ambrosino 告诉我。如果让开发者在应用里输入代码,他们就会期待编辑器该有的一切——撤销、搜索、键盘快捷键——从而注意到 Codex 缺少什么。要满足、更不用说超越这些期待,对他们这个四人团队来说需要付出巨大的努力。

Codex 不可能靠做一个糟糕的代码编辑器取胜。用 agent 编码必须好到让开发者不会想念编辑器。

唯一的问题是,他们仍在用 VS Code 来构建一个 VS Code 的替代品。

“每天 Alexander 都会进来,说:‘我们挨个问一圈。你在主用这个应用吗?你在主用这个应用吗?’” [31] Ambrosino 说。

起初,答案全是“没有”——他们中没有一个人把 Codex 当作主要编码工具。没有代码编辑器,哪怕只是一个小修正,也需要和 agent 对话。从事开发者体验工作的 Dominik Kundel 在早期的一条 Slack 消息中写道,“仅仅为了替换一句话,就必须提示 Codex,感觉太笨重了。”

就连 Ambrosino 也有疑虑:“我认为‘不能编辑文件’是我最怀疑的发布范围,”他在 11 月给团队写道。

外部市场的动向,让不做代码编辑器的决定显得更加冒险。2025 年 11 月,Google 发布了 Antigravity,这是另一款基于 VS Code 构建的编程工具,将 AI agent 与完整的编辑器结合在一起。

“我们只是互相看了看,”Ambrosino 回忆道。“我们不分叉 VS Code 是不是犯了一个巨大的错误? 我们对此感到非常矛盾,我觉得团队内部甚至都没有达成一致。”

驱动这款应用的模型也是个问题。OpenAI 在 9 月推出了专门的 Codex 模型系列,但到了 11 月,这些模型对于他们正在构建的桌面产品来说仍然不够好。Ambrosino 告诉我,即使是一款功能齐全的应用,也会“因为当时模型的质量而无法发布”。[32]

在接下来的几周里,情况开始发生变化。11 月 19 日,OpenAI 发布了 GPT-5.1 Codex Max,它可以连续编程数小时。GPT-5.2 Codex 于 12 月 18 日跟进,在跨大型代码库进行修改方面带来了进一步改进。

Glaese 与 Codex 团队的其他成员直接合作,进一步缩短开发者反馈与模型改进之间的反馈循环。至关重要的是,他们专注于让 Codex 更好地服务于使用它的人,而不仅仅是提高模型在热门基准测试上的分数。而且由于 Codex 模型系列独立于主 ChatGPT 模型,他们可以更快地推进,而不必担心这些改动会如何影响使用 ChatGPT 的 8 亿用户。

到了 12 月,团队中更多人开始使用 Codex 应用,而不是他们的代码编辑器。“我最初渴望的是一个代码编辑器,”Kundel 在 Slack 中写道。“现在我的大部分修改都只是留下行内评论,速度非常快。”Ambrosino 发现他仍然需要引导模型,但不再需要手动编辑它的代码。[33] Glaese 也意识到内部的风向已经改变。“5.2 是一个转折点,我当时想,‘哇,我对它能为我做的事情感到非常兴奋,’”她说。[34]

在整个行业中,假期成了一个拐点,开发者在圣诞假期里用 Anthropic 的 Opus 4.5 和 OpenAI 的 GPT-5.2 端到端地构建完整应用,一行代码都不用碰。

到 1 月初,整个团队都在使用 Codex 应用。现在他们需要弄清楚 OpenAI 的其他员工是否也会使用它。Ambrosino 说,如果不会,那就“回到画板前重新来过”。[35]

到 2 月,Codex 桌面应用在工程和研究团队中获得了广泛采用。OpenAI 研究员 Noam Brown 表示他已经“完全切换”到了这款应用,而 Brockman——终端和 Emacs 编辑器的忠实用户——也同样如此。他说回到旧的工作流程“感觉像是回到了过去”。Altman 后来形容它是“我们有史以来最受内部喜爱的产品”。

Codex 团队打造出了 OpenAI 内部开发者喜爱的东西。但 Codex Cloud 也曾在 OpenAI 内部受到欢迎,却在发布后一败涂地。这一次会有所不同吗?

思考中……

这里很多人都在用它……

但我以前也把这种情况误认为成功……

这一次,它在用户已经工作的地方发挥作用……

是时候到外部去测试了……

Codex 应用

Codex macOS 桌面应用于 2026 年 2 月 2 日向公众发布。它看起来更像一个聊天应用,而不是代码编辑器:侧边栏列出进行中和历史任务,点击其中一个就能看到 agent 做了什么,并可以向它发送进一步的指令。

你可以让一个 agent 修复 bug,派另一个去构建功能,然后在它们之间切换来回答问题或审查改动。每个 agent 都可以在自己的代码副本上工作,而不会覆盖其他 agent 的成果。你可以保持近距离引导,也可以让多个任务同时运行,等它们需要你时再回来。

在当时,这些都不算什么特别具有突破性的东西。例如,Claude 桌面应用已经让技术用户和非技术用户都能做同样的事情好几个月了。但 Claude 桌面应用是一步步构建起来的,先是 Chat,然后加入 Code,再加入 Cowork——这让它的界面显得令人困惑、像是拼凑而成。很难弄清楚哪个标签页该用于哪项任务,以及每个标签页中会有哪些功能或权限。

Codex 应用身上没有这些伤疤。我第一次使用时——与几天后发布的新 Codex 模型 GPT-5.3 Codex 一起——它快速、简单,而且完全以智能体为核心。整个体验有一种流畅感,一种当产品所有细节都恰到好处时才会有的感觉。由于团队早期坚持不加入代码编辑器,他们确保 Codex 智能体在应用内几乎能完成用户能做的任何事情。这意味着你不必翻遍设置去,比如说,连接一个新工具。相反,你直接问智能体就行。

GPT-5.3 Codex 也是 OpenAI 模型能力的一个转折点。据 Glaese 说,这是他们第一次开始为 Codex 系列跳出编程专用训练。他们仍然把它命名为 Codex,她也没有声称它在所有方面都更好。但团队已经开始追问:一个编程智能体还需要知道什么,才能对各种知识工作都有用。

对我的工作流影响立竿见影:我从几乎只用 Claude,转向在大部分工作中使用 Codex。在我正在构建的文档编辑器 Proof 上,我看着 Codex 在几乎没有干预的情况下自主修复复杂 bug。很快,我开始让它通宵处理难题,而每当我面对特别棘手的任务时,我都会先找 Codex。

GPT-5.4 在 3 月初的到来,让 Codex 坐稳了我的日常主力工具。它仍然是专家级编程助手,但现在能清楚地解释自己,也更好地理解我想要什么。而且因为 Codex 应用界面干净、速度快,我开始把所有工作都放在里面做。

到那时,Every 的许多人也每天都在使用 OpenAI 的工具和模型——这与几个月前相比完全反转,当时 Claude 是遥遥领先的主导选择。正如我们在 GPT-5.4 Vibe Check 中所写:OpenAI 回来了。

同样的事情也发生在 Every 之外很远的地方。到 3 月 19 日,OpenAI 表示 Codex 已突破每周 200 万用户,而整体使用量自年初以来增长了五倍。4 月,OpenAI 加入了应用内浏览器,因此智能体可以查资料,并在实时网页上核对自己的工作。它还可以跨其他 Mac 应用工作,并显示文档、幻灯片和电子表格的预览。即使是从未写过代码的人,也可以要求生成演示文稿或预算报告,并在不离开应用的情况下看到结果。

到 6 月,Codex 每周用户已超过 500 万,其中大约五分之一是知识工作者。7 月 9 日,OpenAI 将 Codex 桌面应用变成新的 ChatGPT 桌面应用,聊天功能也在其中。[36] 在底层,新的 ChatGPT 仍然告诉你的 Mac,它的名字是 com.openai.codex。

Codex Cloud 曾作为 ChatGPT 内的一个标签页发布。现在,ChatGPT 运行在 Codex 之上。

Ed Bayes 记得自己走出宣布合并的全员大会时,想着团队已经走了多远。最初只是“角落里的一小群人”,如今已成为“ChatGPT 的未来”。

“这就像美国企业史的一部分,”他告诉我。

Dan Shipper 是 Every 的联合创始人兼 CEO,他在那里撰写 Chain of Thought 专栏,并联合主持 The Every Podcast。

How Codex Happened