Codex 是如何诞生的

原文：https://every.to/p/how-codex-happened

我至今仍能准确记起，自己是从哪一刻开始觉得 OpenAI 会失去「天命」（mandate of heaven）的——那是它自 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 解释「代理式委派」（agentic delegation），尤其是向他解释，我感觉有点滑稽——造一个自主编程代理本来就是他的工作。而且当时我也不确定，我们的这套工程方法在这么小的团队之外是否也行得通。

一条 Slack 提示点亮了 Embiricos 的屏幕，打破了会议室里突然的安静。他把电脑静音，把屏幕压到四分之三合上——刚好够让他的 Codex 代理继续思考。

那天晚上离开 Mission Bay 时，我在想，OpenAI 是不是正在为一个垂死的工作流打造一件完美的工具。被失败的云端代理烧过一次之后，这家公司看起来正在退回到代码编辑器里，那里 AI 帮助程序员一步步工作。而与此同时，Claude Code 正在那些「把整个任务交出去然后走开」的人群中起飞。

留在编辑器里是有充分理由的。GPT-5 发布后，Codex 团队发布了一个扩展，把 Codex 塞进微软 Visual Studio Code（VS Code）——程序员写代码、跑代码、调试代码的地方——以及 Cursor 这类代码编辑器的侧边栏。到去年十月，使用量增长了十倍以上，这个编辑器扩展很快超过终端，成为 Codex 最常用的界面。

在大多数公司，这本该是值得加倍押注的生意。但在 OpenAI 内部，Embiricos 和一小群工程师、设计师、研究员有着更大的野心。

在随后的几个月里，Codex 团队训练并快速改进了一条专门的编程模型线——独立于驱动 ChatGPT 的那些模型——还做了一款用于同时管理多个代理的桌面应用。到 2026 年 6 月，Codex 每周活跃用户超过 500 万，并且正从编程扩散到其他类型的知识工作。

到 2026 年 7 月，Codex 已并入旗舰版 ChatGPT 桌面应用。它的负责人 Thibault Sottiaux 被提拔为 OpenAI 全部核心产品与平台（包括 ChatGPT、Codex 和 API）的主管。今天，Codex 与面向工作场景的 ChatGPT 加起来，每周活跃用户达 4000 万。

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

这就是 Codex 诞生的故事。

思考中……

有点不对劲。一年前我建立起来的领先优势，并没有体现在结果里……

看起来问题比我以为的还要更早出现……

回到最开始……

OpenAI 的这场回归，始于简单的一行字：「思考中……」（Thinking....）

到 2026 年，每当你在任何复杂的请求上与一个 AI 模型交互，你都会看到那个词——思考中——在你即将得到回答的位置闪闪发亮。

它看起来也许无关紧要：不过是替换 macOS 那个旋转的沙滩球、或 Windows 光标旁那圈转动的蓝色圆环的一个词，都是电脑太忙、无法立即响应的标志。

但在这个语境里，「思考中」意味着一种全新的计算方式，没有它，Codex 根本不可能出现。

第一代大语言模型是「外部处理器」。它们内部推理时并没有那个闪烁的状态标签；相反，它们是通过回应你来直接完成思考。无论你让它们写一封邮件还是一行代码，它们都必须一个字一个字地把答案推出来，没有机会提前规划，也无从事后修改。

从这个意义上说，早期的聊天模型就像即兴演员，拿到观众给的一个提示，就得当场编出一幕戏。这些工具边想边说，结果有时令人惊艳——有时则不经意地好笑。（它们会坚称 「strawberry」有两个 r，把它拼出来证明自己，然后在结尾自我庆贺一番。）

这些模型的早期用户注意到，如果你让模型在回答之前把推理一步步写出来，它往往能得到更好的答案。这个技巧——和小学数学老师给学生的建议一模一样——被称为思维链提示（chain-of-thought prompting）。

思维链提示引出了第二代 AI 模型，以及那个闪烁的「思考中」用户界面。OpenAI 不再需要用户请求模型一步步解决问题，而是把这种行为直接训练进了模型本身。在回应之前，一个推理模型会在一块草稿区里工作，这块区域叫做「推理轨迹」（reasoning trace），它可以在这里从不同角度进攻问题、从死胡同里退出来、再选一条更可能成功的路。只有当它敲定答案时，才给出回应。

OpenAI 把它的第一款这类模型命名为 o1，并在 2024 年 9 月发布了预览版。在那之前，进步主要靠把模型训练得更大、更久。有了 o1，OpenAI 发现同一个模型只要在一道难题上花更多时间，就能把答案改得更好。

有一种工作最能从中获益：编程。编程特别适合推理模型，因为它提供了一个闭环：模型可以修改代码、运行代码，并在几秒内看到改动是否奏效，从而让它自己测试并修订，无需人来做检查。

理论上，只要让它思考得足够久，一个推理模型就能独自完成任何编程任务。

打造一个 AI 程序员，一直是 OpenAI 长久以来的目标，以至于 Codex 有过许多个起点——从它的名字开始。

第一款 Codex 发布于 2021 年，是一个在公开代码上微调过的 GPT-3 版本，它驱动了最初的 GitHub Copilot。三年后，在 o1 的预览展示了推理模型能做什么之后的几周里，来自高层的一个指令，让 OpenAI 内部的几个小组从不同方向再次追逐这个梦想。

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

「对我来说，第一个真正、大规模的『感受到 AGI』时刻，是[当我]看到有人跑一个连接到终端的推理模型，」他告诉我——他指的是 AI 不再像一个工具，而开始像一台能像人一样思考和行动的机器。「我知道[这]现在听来一点都不刺激，」但看着它自己读文件、运行命令、从错误中摸索出来，「真的太酷了（was fucking cool）。」

Embiricos——我在 GPT-5 前夜见到的那位产品负责人——是在那年早些时候 OpenAI 收购 Multi 时加入的，那是一款他为程序员共同创办的多人屏幕共享工具。在 OpenAI，他追寻着一个相关的想法：让人和代理在他们常用的应用里协同工作。他先在 ChatGPT 桌面应用上追逐这个愿景，接着又在一款 AI 驱动的浏览器 Atlas 上尝试，但当时的模型在读取用户屏幕时太慢、太笨拙，派不上用场。

不过在终端里，模型不必读取屏幕——它们可以直接在文本和代码里工作。看到早期推理模型在终端里的表现，让 Embiricos 确信它们能驱动一款真正的编程产品。编程当时还不是他的全职工作，但他立刻开始勾勒一款这样的产品。他认为，要让它能用，用户需要每 30 秒、最多每分钟就能看到模型在做什么。

速度又成了问题。当时大多数 AI 编程产品都围绕 VS Code 生长。GitHub Copilot 通过一个扩展加入 AI 自动补全；Cursor 和 Windsurf 则在 VS Code 的开源代码上自建编辑器，在程序员的工作旁边加入 AI 对话。

这些工具依赖一个紧凑的反馈回路。Copilot 补全你正在敲的那一行；Cursor 和 Windsurf 在几秒内回答问题。它们都不要求模型独自工作很久，因为模型做不到。OpenAI 的早期推理模型恰恰相反：一旦思考时间被截短，它们就又慢又弱。

他能不能把这个缺陷——获取回答所需的时间——变成一种优势？

与此同时，在 OpenAI 的另一个角落，人称 Tibo 的 Sottiaux 正试图让推理模型反过来作用在自己身上：用它们的能力帮助研究员打造下一代模型。

「我大约是在 2024 年 12 月开始参与编程代理的，」他告诉我。我们坐在 OpenAI 的自助餐厅里。他光泽的棕色头发垂向一侧，戴着细金属框眼镜，镜片映着午后的光。如果说他鼻子以上像一位建筑师，那么鼻子以下则全是程序员的味道：棕色胡茬配一件深棕色连帽衫，上面印着「Research and Deployment Co」，手里还拿着切片意大利香肠披萨。

他一边咬着披萨一边告诉我，目标「是帮我们更快地编写基础设施、做研究」。

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

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

「你们是什么时候把模型线分出去的？」我问。「你们是怎么决定的？」我想快进到最精彩的部分。拥有一条自己的模型线，在我看来是 Codex 魔力的核心，我脑海里浮现出 OpenAI 内部的一场会议：Sottiaux、总裁兼联合创始人 Greg Brockman，或者 CEO Sam Altman 做出一个高瞻远瞩的决定，把 Codex 从 ChatGPT 的其余部分里分离出来——给这个团队自由，让它们快速发布，从内部颠覆这家公司。

「并没有一个『把模型线分出去』的决定，」Sottiaux 平静地说。他说，一开始「这是一次研究探索，也是对我们速度的一次优化。」

Sottiaux 的小组并不是为面向大众的产品训练模型，而是在 OpenAI 的 monorepo——存放整个组织全部代码的那个单一仓库——上训练内部编程代理。这些代理编写 OpenAI 研究员所需的 Python 代码，用来运行和改进那些构建新模型的系统。那些研究员每天都在用这些代理，从而给团队带来了一个紧凑的反馈回路。

「我们在编程上看到了快速的收益，」Sottiaux 说。他的团队频繁训练模型，所用的技术既不同于、且在一段时间内难以与更大组织训练面向公众模型的方式相调和。

和所有 AI 实验室的人一样，Sottiaux 对这些训练技术守口如瓶。但很明显它们奏效了：他的小组成功地把模型反过来作用在创造它们的研究过程上，而研究员们又在用这些模型去打造下一代。

工程师把这种做法叫做「自举」（bootstrapping）。做出一个擅长帮助研究员跑实验的模型，研究员就能用它造出一个更强的模型，后者跑出更好的实验，进而带来更好的模型，如此循环。

这项工作提供了后来成为 Codex 的一半：能够改进构建新模型的基础设施的代理。要成为一款公司其他部分都能用——并最终走出 OpenAI 边界——的产品，它还需要另一半：Embiricos 关于人应该如何与这些代理协作的论点。

思考中……

目前有三种方案……

其中两种有重叠……

我会把它们合并，然后沿着可行的方向继续……

探索之后，是收敛。

我们可以从高处俯瞰 2024 年末到 2025 年初的 OpenAI。在编程成为公司层面的顶级目标之后，包括 Sottiaux 和 Embiricos 在内的几个个人团队，开始从不同角度攻克同一个问题。

Brockman 告诉我，悬而未决的问题是合适的「形态」（form factor）：这个代理到底该待在开发者执行命令的终端里、在他们写代码的编辑器里，还是在一台自己干活的云端电脑上。其中一些路径是死胡同，但当时没人知道哪条是。

「某种意义上，OpenAI 是在同时押注一系列创业公司，只不过它们都是内部的，」Altman 在 2025 年接受 Ben Thompson 采访时说。这种公司内部并行探索的精神，在我采访的少数内部人士看来，有时显得混乱而浪费。谁愿意待在一个造出 OpenAI 内部第三好的代理产品的团队里？我自己公司也推行过类似策略，所以我很清楚，在「留出探索空间」和「搞得一团糟」之间，只有一线之隔。

但在观察 OpenAI 的过程中——尽管我也听到过内部的抱怨——我逐渐认识到，当前沿不断移动时，这是必要的。在 AI 里，模型层面快速的「延续性」（sustaining）进步——借用已故哈佛教授 Clayton Christensen 的说法——让新类型的应用成为可能，并不断颠覆此前的应用。

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

到 2025 年初，OpenAI 准备好了做这件事。「最终，我们认为应该和另一个叫 Scientist Assistant 的项目合兵一处，」Sottiaux 告诉我——这次合并让他和 Embiricos 走到了一起。Brockman 说，在各条内部编程尝试中，「我们最终把其中两个合并了。然后又合并了另外两个。」合并后的团队是一支小型、多学科的人马：有 Embiricos 这样的技术型产品思考者，有 Sottiaux 这样的基础设施与工程奇才，还有 Mia Glaese 这样的研究员。

Glaese 从 DeepMind 来到 OpenAI，在那里她做过 Gemini 和模型对齐（alignment）的工作。在 OpenAI，她负责用于模型训练和对齐的数据，也就是说，她专长于获取并使用那些会塑造模型具体行为的数据。

在某个层面上，她是个彻头彻尾不带感情的实证主义者。在我们的采访中，她毫不掩饰地强调量化：「只靠相信直觉（vibes），在研究里没那么有用，」她说。但当谈到造模型的过程时，她又会立刻笑说，其中有多少是一次跃入未知。

「每次我们训练一个模型，都像是踏上一场神奇的冒险，我们会想，『这到底要怎么做？』」她说。

这种产品人员与研究员并肩工作的多学科团队，在 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 比我在代理这块用过的任何东西都好。」团队其余人也开始认同。

到 2025 年春天，合并后的 Codex 团队——Embiricos、Sottiaux、Glaese 以及其他几个人——把目光投向了一个关于软件工程未来的不同愿景：Codex Cloud。他们设想一个待在云端的代理，拥有自己的一台电脑，为异步工作而设计，让用户可以从电脑或手机上委派编程任务。他们给自己定了大约七周的时间来构建并发布它。

你可以点击 ChatGPT 侧边栏里的 Codex，打开一个工作区，在那里描述一个任务，然后按下「Code」。这个任务会被丢进一个队列，清空提示框以便处理下一个。Codex 把你的代码库复制到一台隔离的云机器上，编辑文件，运行测试和 linter——那些扫描代码里常见错误的工具。它返回一份摘要、一份改动 diff，以及一个打开 pull request 的按钮。

Codex Cloud 于 2025 年 5 月 16 日发布，比我与 McCallum、Embiricos 在 Mission Bay 见面的那一夜早了将近三个月。它「在内部非常成功」，Sottiaux 告诉我。但在 OpenAI 之外，它的发布引来了一些兴趣，却没能带来持续的使用。

要让它跑起来，开发者得在云端重建自己笔记本电脑上的软件、权限和设置——这个过程可能要花上几个小时，因为你需要拷贝凭据、安装关键的软件包。一旦配置好，它能把一个定义明确的任务完成得很好。但你没法打断它来纠正方向，哪怕只是一个后续提示，也会启动一台全新的云电脑。

「如果你是技术负责人，要在现有代码库上加功能或修 bug，它是你会伸手去用的工具。如果你想靠 vibe coding 从零做一家单人十亿美元 SaaS 公司，那还是另寻他处吧，」我在发布当天的 Vibe Check 里写道。

在 OpenAI 内部，标准化的开发环境让配置变得自动，研究员们也有定义清晰的工作可以交出去。团队自己的工作环境，掩盖了他们其实在要求外部用户做多少事。

拖累 Codex Cloud 的不只是产品本身。「它来得太早了，因为模型还不够聪明，」Embiricos 说。

「我们当时是用一种更偏向未来的眼光去做这件事，」Glaese 告诉我。「我们没做那种『走到人们所在的地方去』的事，」而人们所在的地方「就是他们的笔记本电脑上」。

那么，OpenAI 为什么跳过了那个在 Anthropic 那里开始奏效的终端形态？

「我们没有跳过它，」Sottiaux 在我们餐厅的对话里告诉我，他指的是一个未发布的内部原型。「我们做了这样一个版本，然后一个月后把它丢掉了，转去做完整的云端版本。」

「为什么？」我问。我知道，如果我真正去看，窗外四周那些落地大玻璃之外，我大概能在天际线上找到 Anthropic 的办公室。我当然也能不太费力地走过去。旧金山是个小城。

「因为如果我们愿意在配置上投入很多，我们就是在优化那个我们认为最能让我们受益的东西，」他说。

这个回答背后，是我从 OpenAI 内部人士那里一遍又一遍听到的一个信念。对他们来说，AI 代理的理想形态从来都是一个在云端为你自主工作、不会因为你合上笔记本盖子就停止响应的代理。Brockman 在我们的采访里也说过同样的话：「如果你把眼光投向未来，正确的形态是一个待在云端、拥有自己笔记本电脑的 AI。所以我们实际上造的就是那个。」

这个选择也是与模型局限的一种妥协。团队把第一款 Cloud 产品围绕那些能在一个任务上花更长时间工作的模型来构建，而不是围绕那种逐刻响应程序员的方式。

实际上，OpenAI 确实在 4 月 16 日发布过一个小型的、开源的 Codex 命令行界面（CLI），很像 Claude Code——恰好比 Codex Cloud 早一个月。它又是 Codex 众多起点中的一个。

Embiricos 把那个公开的 CLI 形容为一个独立的副项目，是「由大概两个人英雄般地（heroically）」做出来的。但这个 CLI 并不是 OpenAI 投入大部分资源的地方——也不是它正在为 Codex Cloud 训练的那个专用模型所在的地方。「你甚至没法在 CLI 里用 Codex 模型，」他说。

在用户自己的电脑上运行代理，还带来了安全问题。一个编程代理能做的，远不止给出代码建议：它可以在用户的电脑上编辑文件、运行命令。「作为一家公司，我们有着非常保守的安全立场，」Embiricos 说。「我们实际上做了大量工作，才想清楚如何能放心地部署这种级别的能力。」早期用户只能用通用模型——默认是 o4-mini——来运行那个 CLI，而这个模型并不是为编程代理而打造的。CLI 是存在了，但团队——以及它最好的模型——的注意力都在 Cloud 上。

问题在于，它没成功。Cloud 产品没能找到产品与市场的契合。团队的工程经理跳槽去了 Cursor——AI 编程领域的领跑者，估值 90 亿美元。大约就在这时，据报道 OpenAI 达成了一项 30 亿美元的协议，要收购 Cursor 最接近的竞争对手 Windsurf。这笔交易后来在 7 月告吹。

「最艰难的时候，是我们感觉不知道该怎么办。或者我们知道自己该做什么，但很难看到[进展]真的发生，」Embiricos 告诉我。

这是第一次，Codex 团队——乃至某种程度上 OpenAI 更大的编程野心——在荒野中迷失了方向。

思考中……

嗯，这在我们自己的环境里行得通。为什么在用户那里就不行？……

也许我在试图修错东西……

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

这里面有点东西。但我得重建它……

让一个推理模型强大的，正是它回溯的能力。如果它认定某个 bug 藏在代码的某处并重写了它，结果发现 bug 还在，它通常不会继续信心十足地朝着错误的方向前进。它可以重新审视自己的假设，扩大寻找解法的范围，并根据学到的东西决定一条新的、更有希望的路。

这种「用错误来纠偏」的能力，正是让推理模型能找到那些一开始并不明显的答案的原因。

Cloud 发布之后的余波里，也就是 2025 年晚春到夏天，Codex 团队准备好去试另一条路。当时，这个项目占据的，用最近刚加入团队的设计师 Ed Bayes 的话说，是 OpenAI 的「死水一角」（the backwaters）。「如果你想当那个时髦的设计师，」他告诉我，「你就去做 ChatGPT。」

就在这个被忽视的前哨，Sottiaux 升任为团队的工程经理。「我接手了这个团队，然后我把方向改了相当多，」他告诉我。「我们转向了本地。」

「本地」意味着把代理跑在开发者自己的电脑上，像 Claude Code 那样，而不是在云端。他们从那个本地的 Codex CLI 起步——正如 Embiricos 提到的，它是作为两个人「英雄般」做出的副项目。Sottiaux 没有立刻给它加功能——那会很快带来势头——而是采取了另一种做法。他决定重写这个代理。

「我们在真正好用的 CLI 功能上进展有点慢，」他告诉我，「因为我们太忙于开发这个代理了。」

CLI 是用户交互的界面，但 Sottiaux 的优先项是底下的那套机械：那个读取文件、运行命令等等的代理。他想改进它，并把它与终端界面分离，好让它能住在任何地方——代码编辑器里、桌面或移动应用里、云端，或者 ChatGPT 本身。

团队用 Rust 重写了这个代理，这是一门为速度和安全至关重要的系统而设计的语言。这样一来，同一套机械就能同时驱动终端 CLI，以及后来的编辑器扩展。

不过，他们仍然缺一样东西：一个足够好、能驱动它的模型。

当 Codex 团队在 Sottiaux 的带领下重建其代理时，Michelle Pokrass 正在努力让 GPT-5 在真实世界的编程上表现更好。

Pokrass 曾领导 GPT-4.1 的研究，她负责后训练（post-training）——精调一个已经训练好的模型的行为，好让它能应付真实的编程工作——重点放在那些要求更好交互式编程体验的客户身上。

一个编程模型可能像一个 SAT 满分却从没工作过的学生。OpenAI 的模型在编程竞赛上表现出色，但这些成绩并没有延续到日常工程里。「它们从没见过一个乱糟糟的代码库，也没见过程序员可能会怎么在中途打断它，」Brockman 告诉我。

为了给这些「书本型聪明」的模型一点真实世界的经验，Pokrass 和她的团队坐在程序员身边看他们工作，找出模型在哪里掉链子，再把这些失败转化成可重复的训练任务。

OpenAI 正是这样，才得到了那个模型——以及那个时刻——把我带到了 2025 年 8 月 Mission Bay 的那间会议室里。

从 Codex 团队那个动荡的夏天内部来看，我那一夜在 GPT-5 身上感受到的谨慎就说得通了。被试图一步跨向完全自主的 Codex Cloud 烧过一次，又被要求更好交互式协作的客户所引导，OpenAI 造出了一个擅长与人类程序员一步步协同工作的模型。它能理解一个乱糟糟代码库的各部分如何拼在一起、解释自己的计划、调查 bug，并在越界之前暂停下来先问一声。

和我们 Every 的观察相比，Codex CLI 里的 GPT-5 仍然落后于 Claude Code。Kieran 在我们的发布当天 Vibe Check 里写道：「GPT-5 是一个 Sonnet 3.5 杀手，而不是一次跃向未来的飞跃。」但对当时绝大多数软件工程师来说，一个谨慎的协作者正是他们想要的。把生产代码委派给自主代理，当时还常常被习惯了手敲每一行代码的程序员嗤之以鼻。

「我不会让它来开我的代码，」Ruby on Rails 的创造者、工程界一位有影响力的声音 David Heinemeier Hansson 在GPT-5 发布前后说。「程序员的乐趣，我作为一个程序员的乐趣，就在于亲手敲代码。」而且当代理在开车时，他说，「我能真切地感觉到能力正从我指尖流失。」（到 2026 年 1 月，他会写道，AI 代理「完全有能力为真实代码库贡献生产级别的代码」，并在 9 月的 Rails World 上宣布，在他的公司里手写代码的时代结束了。）

当 Codex 团队在 8 月底为 GPT-5 发布跟上一个面向 VS Code 和 Cursor 的扩展时，那些开发者蜂拥而至。他们的热情给了 OpenAI 充分的理由继续改进这个扩展。每一个新用户、每一个功能请求，都把团队拉向「帮助程序员一步步工作」，而远离「打造能承担整个任务的代理」。

不过对 Embiricos 来说，同一次发布意味着团队可以追求更大的野心。在荒野中待了几个月后，重建后的本地代理终于有了一个能驱动它的模型。

他告诉我，一旦他们带着焕然一新的 CLI 发布 GPT-5，「它创造了一个自我实现的飞轮」。

他记得自己当时想：「终于，我们可以开打了。」

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

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

那就加倍押注编辑器扩展，在终端里追上去……

[被 Tibo 打断]

随着 Codex CLI 和 VS Code 扩展的人气爆棚，合乎逻辑的选择本该是继续在这两者上投入。

可 Codex 团队反而做了件出人意料的事。

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

在 OpenAI 内部，他能看到模型正在完成更长的任务，并从代码库之外获取信息，语音和图像也即将到来。人们很快会同时运行好几个代理，一整天都跟它们待在一起。「如果你要把全部时间都花在里面，它就必须是一个内容非常丰富的界面，」他说。在他看来，试图在一个建于 1970 年代、只能处理文本的窗口里，同时驾驭六个用文字、图像、语音和视频交流的代理，显得很荒唐。

对 Embiricos 来说，一款本地桌面应用还指向了 Codex Cloud 未能实现的那个工作流——在 Cloud 里，用户没法在任务中途打断代理。他想，有了一个跑在自己电脑上的应用，人们可以先与代理紧密协作，然后，就像带一位新队友上手一样，逐渐学会哪些任务可以放手交给它。同一个界面最终还能把 Codex 带出开发者群体，带给那些永远不会打开终端的人。

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

Ambrosino 让我想起《办公室》（The Office）里 B.J. Novak 演的那个角色：深色头发、浓密眉毛、一个小小的、抿着嘴的微笑。无论是当面还是网上，他都给人一种「永远在心里自得其乐」的感觉；别人是否也加入他的玩笑，是一个考量，但常常显得次要。

任何关注他以获取人工智能未来洞见的人，翻开他的信息流，可能会看到一条有 617 个赞、内容完全只有一个词的帖子：「ai」。另一条帖子则神秘兮兮，写着「tibo」（1000 多个赞）。

（如果你好奇「tibo」是什么意思，我可以报告说，Sottiaux 似乎一直挂在他心上。当我问他欣赏谁的喜剧时，他回答：「Tibo 是我的喜剧偶像。」这到底澄清了多少，就留给读者自己判断吧。）

当 Ambrosino 加入这个做应用的小组时，他们知道自己想做一款桌面应用，但不知道它会是什么样子。团队唯一确定的是，他们想做一样自己会用起来的东西。

Ambrosino 告诉我，他们的第一个任务，就是让这款应用成为自己日常工作的主要工具。「我们知道我们想要一个能当『日常主力车』（daily driver）的界面，但[一个]比 IDE 更轻量的，」他说。

随着 Claude Code 起飞，已有几款应用开始试验「终端之外的编程代理之家」会是什么样。Conductor 是一款在 Mac 上运行编程代理的应用，它有一个任务侧边栏，每个任务都有自己的代理和聊天，你可以在那里下达指令、跟进工作。ChatGPT 提供了另一个参照：侧边一排对话列表，中间一条单一的线程。Codex 应用「从聊天里获得的灵感，比从 VS Code 里获得的更多」，Ambrosino 谈到他们的设计过程时说。到那时，Anthropic 也已经有了 Claude 桌面应用。

团队动作很快，回答了一些基本问题：用户如何跟踪自己的工作（每个任务都有自己与一个代理的对话）、侧边栏该如何组织（对话按项目分组）、基本界面该如何布局（选中对话旁边是一列任务）。

然后是一个更难的问题：当代理做错了什么，你能不能在 Codex 里亲手改代码？团队决定了一个有风险的答案：不内置代码编辑器。如果你想对自己的代码做任何改动，你必须去问代理。

「我们特意想让它成为[不同于代码编辑器的]另一个东西，」Ambrosino 告诉我。一旦让开发者能在应用里敲代码，他们就会期待编辑器该有的一切——撤销、搜索、快捷键——进而注意到 Codex 缺了什么。要满足、更别说超越这些期待，对他们四个人组成的团队来说，意味着巨大的工作量。

Codex 不可能靠「当一个糟糕的代码编辑器」来取胜。用代理编程这件事必须好到让开发者根本不怀念编辑器。

唯一的问题是，他们当时其实是在用 VS Code 造一个 VS Code 的替代品。

「每天 Alexander 都会进来问，『我们挨个说说吧。你在主用这个应用吗？你在主用这个应用吗？』」Ambrosino 说。

起初所有答案都是「没有」——他们中没有人把 Codex 当作主要的编程工具。没有代码编辑器，哪怕一个很小的修正，也得跟代理进行一场对话。在开发者体验部门工作的 Dominik Kundel 在早期一条 Slack 消息里写道，「光是替换一句话就得去 prompt Codex，感觉太笨重了。」

连 Ambrosino 也有疑虑：「我觉得『不能编辑文件』是我最怀疑的发布范围，」他在 11 月给团队写道。

外部市场让「不要代码编辑器」这个决定显得更加冒险。2025 年 11 月，Google 发布了 Antigravity，又一个建在 VS Code 上的编程工具，把 AI 代理和完整的编辑器结合在一起。

「我们只是互相看了看，」Ambrosino 回忆道。「我们是不是犯了个大错，没有去 fork VS Code？我们为此非常纠结，我觉得团队里甚至都各执己见。」

驱动这款应用的模型也是个问题。OpenAI 在 9 月发布了它专门的 Codex 模型线，但到 11 月，它还不够好，撑不起他们正在构建的桌面产品。Ambrosino 告诉我，哪怕是一款功能齐全的应用，也会因为「当时模型的水平」而「无法发布」。

在接下来的几周里，情况开始改变。11 月 19 日，OpenAI 发布了 GPT-5.1 Codex Max，它能连续编程好几个小时。GPT-5.2 Codex 紧随其后，于 12 月 18 日发布，在跨大型代码库做改动方面带来了进一步的提升。

Glaese 直接与 Codex 团队其余成员合作，进一步缩短开发者反馈与模型改进之间的回路。关键在于，他们专注于让 Codex 对使用者更好用，而不只是提高模型在流行基准上的分数。而且因为 Codex 模型线独立于 ChatGPT 主模型，他们可以更快推进，不必担心这些改动会如何影响 8 亿 ChatGPT 用户。

到 12 月，团队里更多人开始用 Codex 应用，而不是他们的代码编辑器。「我原本很渴望有一个代码编辑器，」Kundel 在 Slack 里写道。「现在我的大多数改动，我只是留个行内评论，就快得飞起。」Ambrosino 发现，他仍然需要给模型掌舵，但不再需要亲手编辑它的代码。Glaese 也意识到，内部的风向变了。「5.2 是一个转折点，当时我想，『哇，我对它能为我做的事感到非常兴奋，』」她说。

整个行业里，这个假期成了一个拐点：开发者们利用圣诞假期，用 Anthropic 的 Opus 4.5 和 OpenAI 的 GPT-5.2 端到端地造出整个应用，一行代码都没碰。

到 1 月初，整个团队都在用 Codex 应用了。现在他们需要弄清楚，OpenAI 的其余部分是否也会用它。如果不会，Ambrosino 说，那就「回到画板前」。

到 2 月，Codex 桌面应用在工程和研究团队里获得了广泛采用。OpenAI 研究员 Noam Brown 说他已经「完全切换」过去，而 Brockman——一位终端和 Emacs 编辑器的忠实用户——也切换了。他说回到旧工作流「感觉像穿越回了过去」。Altman 后来会形容它是「我们内部有史以来最受喜爱的产品」。

Codex 团队造出了让 OpenAI 内部开发者喜爱的东西。但 Codex Cloud 也曾被 OpenAI 内部拥抱，却在发布后一败涂地。这一次会不一样吗？

思考中……

这里很多人都在用它……

但我以前也把这种情况误当成过成功……

这一次，它跑在用户本来就在工作的地方……

该到外面去测一测了……

Codex macOS 桌面应用于 2026 年 2 月 2 日向公众发布。它看起来更像一个聊天应用，而不是代码编辑器：一个侧边栏装着进行中和历史的各项任务，点开其中一项，就能看到代理做了什么，并向它发送进一步的指令。

你可以让一个代理去修 bug，派另一个去构建一个功能，然后在它们之间来回切换，回答问题或审阅改动。每个代理都可以在自己那份代码副本上工作，不会覆盖别人的成果。你可以守在旁边掌舵，也可以同时留下好几个任务，等它们需要你时再回来。

在当时，这一切都算不上特别具有开创性。比如 Claude 桌面应用，已经让技术和非技术用户做了好几个月同样的事。但 Claude 桌面应用是一步步堆起来的：先是 Chat，再加 Code，然后再加 Cowork——这让它的界面显得令人困惑、拼凑感十足。很难弄清楚哪个标签页该用来做哪种任务、每个标签页里又会有哪套功能或权限。

Codex 应用身上没有这些疤痕。当我第一次用它时——配上几天后发布的新 Codex 模型 GPT-5.3 Codex——它又快、又简单、彻底「代理原生」（agent-native）。整个体验有一种流畅感，是当一个产品的所有细节都恰到好处时你才会有的感觉。正因为团队早期坚持不要代码编辑器，他们才确保了 Codex 代理在应用里几乎能做到用户能做的任何事。这意味着你不必去设置里翻找，比如说，连接一个新工具。相反，你直接问代理就行。

这有一部分是「后来者优势」。因为 OpenAI 团队是在 Claude 桌面应用加入 Claude Code 和 Claude Cowork 标签页之后才启动它的桌面应用，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 桌面应用，聊天功能就在里面。在底层，这个新的 ChatGPT 仍然告诉你的 Mac，它的名字是 com.openai.codex。

Codex Cloud 当初是作为 ChatGPT 里的一个标签页发布的。现在，ChatGPT 跑在 Codex 之上。

Ed Bayes 记得，在宣布合并的那场全员大会结束后走出来时，他想着这个团队一路走了多远。最初只是「角落里的一小群人」，如今变成了「ChatGPT 的未来」。

「这就像一段美国企业史，」他告诉我。

GPT-5 发布十个月后，我又回到了与 Alexander Embiricos 同在的一间会议室里。

「我就完全实话实说了，行吗？」Embiricos 问。

「请便，」我说。

那是 6 月初，距离如今炙手可热的 Codex 并入 ChatGPT 还有一个月，我们坐在 OpenAI 位于曼哈顿市中心的办公室。他穿着一件灰色拉链外套，袖子撸了起来。他的角色最近从 Codex 代理的产品负责人，变成了 OpenAI 的企业产品主管。他身后是一块白板。

我来是想问 Embiricos，他的团队是如何从 Codex Cloud 的失败，走到构建出后来成为 ChatGPT 基础的东西——以及他们是如何避免陷入我在 Mission Bay 担心的那个「结对编程陷阱」的。大多数团队会建立在已经奏效的东西上。Codex 团队没有。是什么让他们能持续前进？

Embiricos 拿起一支黑色马克笔，在白板上画出 Codex 的增长曲线。他先画了一条短的上升曲线，代表 Codex Cloud。那是一个漂亮的尖峰，但很快就变平了。

接着，他为 GPT-5 之后的 CLI 画了一条更陡、更大的曲线；再为编辑器扩展画了一条更高的。最后是 5.3 Codex 和桌面应用，一条让前面几条都相形见绌的曲线。最初那个标记，如今看起来就像白板底部附近的一道刮痕。

他画在白板上的那些曲线，看起来就像是 Christensen《创新者的窘境》里的一张图。

Christensen 曾著名地梳理出，硬盘和处理器稳步的进步如何驱动了从大型机到小型机，再到台式 PC、笔记本电脑，最终到手机的转变——底层硬件的每一次飞跃，都催生出一种更简单的形态，解锁了一个更大、更不技术的市场，并取代了上一个。

在传统计算领域，这个花了半个世纪、由一连串新公司接力完成的模式，在 OpenAI 内部以微缩形式上演了：只用 10 个月，只有一小撮人。模型上 relentless 的飞跃，不断让围绕它们搭建的界面显得过时——逼着 Codex 团队从一个代码编辑器侧边栏，走到终端，再走到一款彻底砍掉代码编辑器的轻量桌面应用。

在 Christensen 的书里，搭上一条获胜曲线的团队，几乎从不搭下一条曲线；现有产品的成功会扼杀接替它的一切。Codex 团队之所以避开了这个命运，部分是因为 OpenAI 的高管们是在创业世界里长大的，研究过这个陷阱。这家公司的结构，就是像一个并行下注的投资组合那样运作，而 Codex 团队被给予了空间，让它能在 ChatGPT 那庞大的规模和用户基数之外，迭代自己的产品和模型线。

用 AI 来造 AI，也改变了产品开发的物理规律。在一家传统公司，启动一个新产品需要几个月的会议去争取预算和工程师——而在这种争论里，那个正在蓬勃发展的现有产品几乎总是赢。在 OpenAI，因为团队是用 Codex 来造 Codex，一小撮人就能在几周内搭起一个新的界面。

「现在要说服别人，需要说的话少多了，」Sottiaux 曾告诉我。

看着白板，Embiricos 还有一条新曲线要画。既然已经有数百万人信任这个代理在各自的电脑上工作，下一步就是回到那个去年春天失败过的愿景——一个在你走开很久之后仍继续工作的代理。

「我们要走向异步，」他说，「这意味着我们得重新把它抬回云端。」

这一次，我忍不住注意到，他的笔记本电脑就放在会议桌上，盖子紧紧地合着。

核心启示：Codex 的崛起，并非源于某一次正确的赌注，而是源于模型能力的持续跃迁不断让既有界面过时——而一支敢于一次次放弃已被验证的成功产品、重建自我的小团队，抓住了每一次跃迁。