OpenAI Codex：从代码补全到异步自主编码智能体

很有意思。当人类必须审查所有这些代码时，角色会发生怎样的变化？比如三份里有两份能用，你会怎么做？

是的。我们在让输出结果易于审查方面也花了很多心思。我们很自豪的一点是——这在其他工具中并不多见——模型能够引用它自己的工作。不仅是修改了哪些文件，甚至还包括终端输出。比如它运行了测试，如果因为某种原因测试没通过，它真的会告诉你，还会说“这就是我运行的具体终端命令，这是输出结果”。这让验证输出变得容易得多。不过你说得很对。我认为我们正在转向一个世界，在这个世界里，我们平常花在写代码上的很多时间，将会转移到审查这些代码上。

人类真的需要审查代码吗？因为我觉得代码是那种要么能编译要么不能编译的东西。一旦编译通过了，你就可以去检查它是否做了该做的事。人类甚至有必要做代码审查吗？

我认为是的，至少在可预见的未来，我确实认为是这样。我觉得很大一部分原因也是在和早期用户建立信任。人们真的需要有一种感觉，知道哪些东西好用，哪些不好用。而且总有一些外部上下文，关于什么让这段代码正确，这可能超出了你最初提供的上下文范围。

是的。如果你想想开发者的工作——这显然过于简化了——但大概是：首先提出哪些事情应该做，和团队讨论，然后决定做什么，你可以称之为构思；然后是设计，好吧我们到底要做什么；接着是规划，我们要怎么做；然后是实现，再是验证，也就是测试这些改动。这基本上是一个循环，而实现和测试这个小循环正是 Codex 目前很擅长的——不过我们也可以聊聊怎么用它来做规划。然后再是实际部署代码，以及维护代码、写文档等等。所以，我忘了确切的数据，但我记得最近看到一个统计，工程师大概只花 35% 的时间在写代码上。这实际上甚至不是工程师工作的主体部分。

所以，我们努力构建的未来是这样的：无论你是软件开发者，还是身处任何行业，所有那些容易被自动化的工作——通常是比较繁琐的脏活——你都不必亲自去做，而是将其委托出去。而那些更有趣的工作，或许是因为它充满模糊性，或许是因为它非常难——这些才是你主导推进的。我们正朝着那样的工作、那样的世界努力。而且我认为我们必须循序渐进地达成目标。

比如现在，作为人类，你写了代码，另一个人会审查这段代码，对吧？所以我们不会一上来就试图改变这个流程，而是说，好，我们先接入进去。因此，目前产品的运作方式是，你作为开发者被工具加速。你让工具写一些代码，你判断代码好不好，再决定是否推送给团队，然后团队进行审查。随着时间的推移，我们会逐步扩展能力边界。所以我们会在规划上提供越来越多的帮助，甚至可能包括设计，甚至可能包括思考如何应对你的 app 或工作中发生的事情。然后我们会推动审查变得越来越容易，就像 Hans 刚才说的那样。

是的。而且我确实能看到这样一个未来：多个 agent 协同工作。比如，codeex agent 负责写代码，然后可能由 operator agent 来测试，公司内部一直在研发的各种 agent 都能汇聚协作。

太棒了。既然现在可以把写代码的工作委托出去，你有没有看到工程团队之外的人也开始使用 codeex？随着我们进入 vibe coding 的世界，你们也在帮我们在这条路上走得更远。

是啊，这其实挺有意思的。答案是肯定的，但我给你讲个故事。当时我们和 Lindsay 一起准备发布的博客文章，聊到要引用客户的哪些话。有个客户想说，我们工程团队很喜欢这个产品，而且它对于 PMs 来说也是个强力工具。我记得看到这句话时，觉得这句 quote 很酷，因为我就在产品团队，我用它就是为了不用事事都去找工程师问问题或找答案。但我转念一想，我们真的要把这句话放进发布博客吗？因为我们构建产品的目标受众是专门针对 professional software engineers 的，不是 vibe coders。所以我觉得最后我们没放那句话。

但随着时间的推移，随着我们有 agent 能帮我们写代码，我相信会有越来越多的人能够为 code base 做贡献。

你觉得 professional software developers 的数量未来会增加还是减少？这只是我个人的看法，但我觉得会大幅增加。

啊。我说的是 professional software developers，不是 vibe coders。

对，我觉得会。在我看来，写软件越容易，我们能拥有的软件就越多。现在，想想看——在座各位是投资人——但如果你不是投资人，我敢打赌你打开手机，上面大多数 app 都是由大型团队为数百万用户开发的。很少有 app 是专门为我们个人以及我们的特定需求而构建的。所以我认为，随着为个人或团队构建 bespoke software 变得越来越实际，我们对软件的需求会越来越高。

是的。就我自己使用它的方式来看，我认为它现在真的更像是一个乘数因子，而不是任何形式的替代，尤其是看看我们内部 power users 的使用模式。codeex 的顶级用户每天能提交 10 多个 PRs，这种差异非常显著。它带来的乘数效应如此之大，以至于我无法想象它会把创造软件的门槛拉低到那种程度。话虽如此，这是一个非常重要的问题，说实话，我们也不知道答案，所以这也是我们公司高度关注的事情。

我想稍微聊聊技术层面幕后发生了什么。你提到模型本身，它与竞技编程不同之处在于，你们让它更擅长做 professional software developer 会做的事情。这是模型层面最大的区别吗？还是说我们应该把它看作 o3 的近亲？

是的。它肯定是在 o3 的基础上增加了 reinforcement fine-tuning 的同一个模型。但即便如此，我认为一部分原因在于，优秀的软件工程师和单纯的优秀 coder 之间，存在一些更偏定性的区别，比如代码风格，甚至写注释的方式。我觉得这是人们在使用其他模型时注意到的问题之一。

此外，我还想强调，一大挑战在于为 agent 构建良好的学习环境。如果你想想现实世界中的 software repositories，它们千差万别且非常复杂。想想看，搭建一个 repo 需要多少 DevOps 工作。这也是我们在环境搭建过程中惨痛学到的。不过，要不要聊聊我昨天给你看的 multi-repo？

哦对。我昨天给 Hansen 看了那家 OpenAI 收购的 startup 的 repo，我们加入后一起在看那个 repo，考虑把它用作环境。Hansen 就问，unit tests 在哪儿？因为 agent 需要用 unit test 来验证。我说，呃，这是家没有 unit test 的 real startup。说实话，我们也一样，所以我没法抱怨。对，就是有各种各样这么 messy 的环境。

所以我们在训练过程中，基本上不得不生成这些非常真实的环境，让 agent 从中学习。我认为我们能够做出这种 end-to-end 产品的原因之一，在于训练时使用的环境，和生产环境中 serving 使用的是同一套 containerization infrastructure。也就是说，我们的用户运行在我们自己的计算环境中，当用户使用 codeex 时，他们运行在和我们训练时完全相同的环境中。

这样 agent 就不会说“但在我机器上能跑”了。

没错。好的。好的。我想这些也是我在 OpenAI 见过的运行时间最长的 agent 了，之前运行时间最长的可能是 Deep Research。据我所知，codeex 有时会在不同任务上花费 30 分钟。要让 inference time 扩展到这么长的查询时间，你们遇到过什么意想不到的挑战吗？

也许我先从产品端说起，模型端当然也有很多，但在产品端，我思考最多的其实是 user intent。实际上，如果你想象有人在 IDE 里使用 autocomplete，这倒不一定有多难。

显然这很难，但要预测它们接下来一瞬间要做什么，也不是特别困难。但要完成一项耗时 30 分钟的任务，其实很难帮用户描述清楚这项工作——他们可能连自己到底想做 30 分钟的什么事都不太确定。所以我们花了很长时间讨论、至今仍在讨论的一个问题是：用户交给 Codex 的任务，合适的粒度到底是什么？以及我们如何让它足够灵活，既能用来做单行修改，也能用来做你目标明确的大型重构，或者你清楚想要什么样的更大功能。又或者，当你并不完全清楚自己想要什么的时候，是否也能用 Codex？也许你应该先问 Codex 要一个计划，让它建议一些任务，然后再去执行这些任务。所以这仍然是我们正在讨论和迭代的话题。

是的，我觉得这实际上是个很好的使用技巧。它确实很擅长自己制定计划，而且有时候你要在一开始就把所有需求都说清楚，真的很繁琐。这也可以说是让模型一次性工作一小时的独特挑战之一——你必须在一开始就说清楚很多内容，也就是说你得先花大概 10 到 20 分钟来构思。但如果你先用 ask 模式，让它生成一个你想要做的高层计划，然后先跟模型迭代完善这个计划，再让它去执行一小时，那真的就像带实习生一样。是的。

那模型这边呢？当它运行很长时间时，模型行为上有什么让你意外的吗？

有的，我觉得我们的模型在保持专注方面已经进步了很多，尤其是在这种长时间运行的情况下。不过我得说，有时候即使是模型，它的耐心也是有限度的，虽然这个限度已经很高了。所以有时候确实挺让人沮丧的。它跑了 30 分钟，然后……这也是我们正在努力改进的一种情况——它就像一个人跑回来跟你说："抱歉，这太多了，我没有足够的时间做这件事。"实际上，这就是它会说的话之一。太搞笑了。就跟实习生一样。所以在某些方面非常像人。

是的。我很好奇你如何看待正确的交互模式，以及这些模式会如何演进，相关产品套件又会如何发展。我们现在有 Codex，有 Codex CLI。你认为在工程和构建产品的设计空间里，还有什么可能性？

我们发布的 Codex 其实只是一个研究预览版。它是一个思想实验，一个有用的思想实验，但仍然非常早期。关于 Codex，我们最自豪的是模型本身，以及这种计算环境基础架构的雏形。我们发布的 UI 是经过迭代确定的，背后还有一些有趣的故事。但它肯定不是最终形态。给听众解释一下，我们发布的 UI 基本上就是 chatbt 里的一个界面，你可以提交任务，让 Codex 回答你的问题或者写代码，然后你会看到一个有点像待办事项列表的东西，上面列着你可以去查看和合并的内容。

其实我们之所以做成这样，是为了极力强化"一个你可以委托任务的异步 agent"这个概念。但我们想要构建的，是一种你无需思考自己到底是在委托任务还是在与 agent 协作的模式。它应该让人感觉就像在跟队友一起工作，而这个队友无处不在，出现在你使用的所有工具中。所以无论你在用什么工具——终端、IDE、问题管理工具、错误告警工具，或者显示错误的工具——你都应该能随时求助。直接问它就好了。甚至有可能你还没到那儿，Codex 已经先看过了，并且有了自己的看法。

你可以问短问题，也可以问长问题。它会自己判断应该花多少时间思考，然后再回答你，然后帮你把这些改动落地。所以基本上，我们是想融合"结对协作"和"委托任务"这两个概念，但我们发布的第一版只是最纯粹的思想实验。

另外还有一点，在 OpenAI 工作的一个独特之处在于，我们是 chatbt 的开发者。它某种程度上是大多数人都在用的 AI 系统。所以我们并不认为未来的日常是你来决定：现在要用 Codex agent，还是用购物 agent，或者叫车 agent。顺便说一下，我只是随便举几个例子。或者营销 agent。实际上，我们认为理想的方式应该是：你只有一个助理，可以问它任何事情，它就能帮你把事情办了。所以 chatbt 就会成为我们的助理。而如果你是某类工具的重度用户，比如你是软件开发者，你花大量时间在某些专业工具上，那你可以进入那个工具，使用一个定制化的界面，有按钮、有列表，让你高效地完成工作。

你觉得我们还会用 IDE 吗？

当然会。但它们会演进，对吧？现在 IDE 非常专注于写代码，而且正如 Hansen 所说，agent 可能会写越来越多的代码，所以重心会转移——转向代码落地、代码审查、代码验证，甚至可能是规划更大的开发蓝图。

是的，我们已经看到团队里很多人早上来上班，先泡杯咖啡，然后启动几个任务作为起点，吃完早餐回来看这些任务，或者看生成的 PR，然后在 IDE 里处理。IDE 大概能帮你完成 80% 甚至更多的工作，但总会存在最后一公里——你进去根据自己的感觉做精细调整。

你如何看待更广泛的市场演变？在 OpenAI 内部，你们在这块有很多不同的策略，无论是异步任务，还是你提到的那些最终会整合进 chat GPT 的功能。我们也看到其他工具和专业模型在爆发式增长。你显然会有偏向，但我很好奇你对整个市场的判断。

是啊，现在当开发者简直是个疯狂的时代。因为有太多新工具了，而且都非常有用。

最近有个挺有意思的事。我之前在飞机上，没有 Wi-Fi。我本来想着可以写点代码、做点东西，结果没网，我就想，算了，现在根本不值得我再花时间尝试写代码了。而很多年前我工作过的那家初创公司，它诞生的契机之一就是我在飞机上没 Wi-Fi 时写了一些代码。现在我根本不会那样做了，因为市场变化太大了。我认为我们将在同样的时间内看到同等量级的转变，未来两年内，编程的样子会完全不同。

我认为，目前人们觉得最有价值的工具，大多是那些在你的开发环境中与你紧密协作的，基本上就像结对编程一样。而我认为我们将看到的转变——虽然我们还必须弄清楚这会如何发生——是实际上大部分代码将由 agent 编写。这些 agent 不会在你一次只能做一件事的环境里工作，而是会在它们自己的环境中运行。它们不会只由你想到某个具体任务时才触发，而是会接入你使用的各种工具，在那里直接干活。所以，我认为我们基本上会看到向 agent 的转变。

我认为我们必须在代码审查方面弄清楚很多事情。正如你问到的，就我个人而言，我不太确定这会怎么运作，但我知道，即使在 OpenAI 内部，我们也已经看到更多代码是由 agent 合并的，而且实际上，由于大家可能会多次启动任务来挑选自己最喜欢的实现方案，由 agent 生成的代码就更多了。所以我们现在还不完全清楚，究竟该如何管理所有这些被写出来的代码。

不过，有些事儿我想说一说，或许对听众有用：你确实可以对代码库做一些调整，让它更容易被 agent 处理。这未必有多新奇，但显然，使用 typed languages 非常有帮助。另一点非常有用的是，拥有更小的模块和更好的测试——我们之前还开玩笑说，能有测试就不错了。对，测试。我们以前还拿我那家初创公司的仓库开玩笑，但我敢打赌，如果今天重写，我们肯定会写得不一样。

甚至还有一些很小的细节。比如这个项目的代号是 WHAM。这是 Codex 的代号，就是 WHAM。我们起名的时候非常刻意，因为我们知道代码会出现在服务器里、网站里和其他各个地方。我们想让 agent 能非常轻松地搜索 WHAM 相关的代码并找到它。所以我们给项目起名叫 WHAM，而且先用 grep 搜了一遍代码库，看看如果叫 code、codeex 或 agent 之类的名字，会出现多少次。你能想象，如果我们当初取名叫 code、codeex 或 agent，agent 现在就很难找了。假如你叫它 codeex，agent 就会搞混。

而在代码里，这其实就是我想说的，对吧？就是有意识的设计。在代码中，我们大量使用 WHAM 这个词，因为这对 agent 来说更容易找到。显然，如果我们不用这样的词，agent 也能自己找到路，但就得花更多时间才能找到正确的文件。

是啊，很酷的一点是，很多能让代码库对人类更友好的做法，往往也能让 agent 更轻松。比如好的测试。写好的文档是另一个很好的例子，我认为现在这样做有了更大的动力，因为这不仅让你的工作更轻松，也让 agent 的工作更轻松。

好的。抱歉要做个烦人的 VC，但 Claude Code 和 Jules 也算其他公司推出的 agentic coding 体验吧。我很好奇，你觉得你们目前的产品体验相比之下如何？另外，你认为市场最终会趋向于同一个愿景吗？就是对于同步和异步编程到底是什么样的，大家会达成共识吗？而在那样的未来版本中，你觉得 OpenAI 会在什么方面胜出？

我觉得我们会看到百花齐放，对吧？就像你提到的，有些工具在你的电脑上运行，有些工具在它们自己的电脑上运行。正如我说的，我认为大部分代码会是在 agent 拥有自己电脑的环境下写出来的，但我们仍然需要大力投入，去加速那些在自己电脑上工作的开发者，对吧？所以理想情况下，我们能两头兼顾。但大部分工作会在 agent compute 中完成。

我的看法是，软件工程最难的部分之一，其实是把世界上所有的上下文信息提取出来，编码到需求文档、设计文档这些里面，然后才是实现。就像我们前面提到的，实际上整个生命周期中花在真正敲代码上的时间并没有那么多。所以我认为 ChatGPT 的优势在于，它是一个助手，现在有记忆功能，还能接入大量不同的连接器，连接到你使用的各种工具。我们有 Operator、Deep Research，具备各种能力。所以我觉得，当这些全部整合到一起，Codex 这样的工具就能真正大放异彩——一旦它能访问所有这些知识，就能加以利用，从而在写代码这件事上做得更高效。

对，想象一下，你招了一个软件工程师，但他只会从你这儿接任务、提 PR，或者只能做那些定义得非常明确的功能。就只做这些事。然后你突然让他干点别的，比如说“嘿，团队要聚一下，你能不能帮忙订个会议室、主持个头脑风暴？”如果你招来的队友拒绝做这种工作，那该多让人沮丧，对吧？所以类似地，我认为我们正在朝这样一个未来努力：你与之协作的 agent 会更加通用化。就像 Hansel 之前提到的，Operator 有网页浏览器，Deep Research 有另一种形式的网页浏览器，Codex 有终端——其实你的队友用的工具和人类队友差不多，对吧？

所以对我们来说，最终的目标是选对领域，针对特定用户群大力投入，以取得快速进展。显然，我们在编程领域就是这么做的，通过 Codex、GPT 4.1，我们为开发者这个群体生成了专门的 evals，然后做出更好的模型。但随着时间推移，我们会把这些能力泛化成人人都能用的简单产品。所以我觉得，在 OpenAI 和 ChatGPT 这边，我们做的产品看起来会和那些只专注于编程的工具非常不同。

你觉得开发者与 Codex 交互的主要 UI 会是什么？你认为会是 ChatGPT、CLI、IDE，还是以上全部？

对，我觉得会是以上全部的混合。

我觉得我们其实就是想在开发者当下的场景中与他们相遇。所以可能甚至不是在编辑器或终端里，可能是在 Slack 上，比如有人发消息给你说“嘿，有个 bug”，然后你就说“嘿，去修一下”。我给你讲一个我觉得有趣的未来界面，完全不算严肃。但也许未来与 agent 协作的方式——如果你是未来的初创公司创始人，团队只有你自己，或者你和几个联合创始人加上很多 agent——实际上看起来会像 TikTok。你知道吗，也许你有一个竖向信息流，基本上就是 agent 生成了一段视频，你可以观看，里面有个想法，比如“嘿，有个客户写了这个需求，我觉得我们应该修一下”，然后你向右滑动表示“好，我们修一下，就这么做”；向左滑动表示“不，我们应该先聊聊”。

抱歉，这……我没说这会很合理。我喜欢……然后你长按来提供反馈，比如“是的，去做吧，但记得把字体设成斜体”。所以基本上，你有很多 agent 订阅了你公司或团队的信息，它们主动提出想法，执行它们，然后给你更新，而你只是在筛选已经完成的工作，它们还会给你展示世界可能是什么样的小小预览。

是啊，这显然有一半是在开玩笑。不过，我觉得那可能是一种与 agent 保持一定距离的工作方式，而且人们肯定还是要能够亲自去做工作，与 agent 结对协作，这一点非常重要。

我知道有一半是玩笑，但这其实是一个很酷的画面，因为我觉得大家在概念上都认同这一点：与 agent 协作并审查它做出的各种改变，看起来会和我们今天写代码的方式非常不同。但还没人真正给过我一个画面，告诉我那可能是什么样子。所以那是个非常酷的想法，我喜欢。太棒了。我们快问快答环节收尾吧？来吧。

好。推荐给 AI 爱好者的一部内容或读物。对我来说脱口而出，就是 Iain Banks 的《The Culture》。你读过吗？读过。太精彩了。是的。这是一部科幻系列，从 80 年代开始写，它对未来的太空航行时代——人类与非人类种族——可能是什么样子的看法异常乐观。而且书中有很多关于当我们拥有 AGI 后，生命的目的和意义是什么的探讨。

对我来说，我会推荐 Richard Sutton 的任何著作。那是我接触强化学习的入门。而且这里有个笑话，就是我们好像每天都在读《The Bitter Lesson》，这某种程度上就是 OpenAI 的哲学。我觉得你知道，即使是 Codex，我们也给它一个终端，而且它真的在使用 POSIX 工具。这大概就是最符合“苦涩的教训”精神与计算机交互的方式了。

你最喜欢的 AI 应用是什么？必须是 ChatGPT。别提了，拜托。我们太无聊了。好吧，要么可以是你们发布的某个新功能，除了 Codex 之外；要么是 OpenAI 之外的东西。好吧。我觉得……有趣的是，我其实不太会把什么当作“AI 应用”。对吧？但我确实喜欢生活变得更轻松的时候。所以，我喜欢的一些东西是，你在使用 AI，但它某种程度上是隐形的。比如，我在做产品，所以我经常提交 bug，而 Linear 有一个非常优雅的集成：当你从 Slack 对话中提交 bug 时，它会直接从 Slack 对话中生成 bug。但他们从不会在任何地方提到 AI。你其实根本注意不到它在用 AI。哦，等等，我想出最喜欢的 AI 应用了：Whimo。啊，这就对了。是的。

我觉得对我来说，Copilot 绝对是我每天都在从中获得价值的东西。

好。机器人技术，看好还是看衰？看好。你认为 2025 年除了编程之外，哪个新应用或应用类别会爆发？我觉得……你们之前请 Issa 和 Josh 来的时候，答案其实差不多，但 2025 年绝对是 agent 之年。我认为我们会看到 agent 在很多不同领域起飞。是的，必须同意。除了编程 agent 之外，你对哪类 agent 最兴奋？

这是个好问题。我的看法是，我知道这本来是快问快答，对吧？但我们对 agent 的理解是，你有推理模型，对吧？然后你给这些推理模型提供行业工具的使用权。接着你再想办法训练这个 agent 去做某种特定功能。所以不只是写作，而是新闻业；不只是编程，而是软件工程，对吧？这基本上就是我们在做的事。在我看来，我今年对 agent 如此兴奋的原因是，我们现在已经有几款 OpenAI 发布的 agent 了，其他公司也在发布 agent。

所以我们开始看清它的形态，开始识别出其中的 primitives。具体来说，让我兴奋的是，当我们把这些整合起来，你会得到一个 agent，你不用为每个功能单独配置一个，而是一个拥有计算机、有浏览器、有终端的 agent，它能做多件事，而你不必精确指定“你是我的编程 agent”之类的。

太酷了。非常感谢你们加入我们。祝贺你们在 Codex 上取得的成绩，也感谢你们让我们提前了解你们如何看待编程市场的演变，以及让我们窥见长期异步的 agentic 体验将如何展开。真的很感激。谢谢。非常感谢。谢谢邀请我们。谢谢。