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

在我看来，编写软件越容易，我们能拥有的软件就越多。现在，如果你拿出手机看看——你们几位是投资人，但如果你不是投资人，我敢打赌，你打开手机，上面大多数应用都是由大型团队为数百万用户开发的，而为我们自己量身打造、满足特定需求的应用则少之又少。因此，我认为随着为个人或团队构建定制软件变得越来越可行，我们对软件的需求也会越来越高。欢迎收听 Training Data。今天我们邀请到 OpenAI Codex 团队的 Hansen Wang 和 Alexander Embiricos，一起探讨软件开发的未来。Codex 是 OpenAI 推出的一系列 AI 编程工具，帮助开发者将任务委派给云端和本地的编程 agent。与 2021 年推出的原版 OpenAI Codex（用于自动补全代码行）不同，最新一代 Codex 能够在后台自主完成整个任务。03 与 Codex 的关键区别在于：03 擅长竞技编程，而 Codex 则经过 RL 调优，专注于日常的企业开发任务。Alexander 和 Hansen 将分享 Codex 的幕后故事，以及从快速自动补全到长时间后台运行 agent 的范式转变。此外，他们还将分享一个令人惊讶的愿景：未来开发者如何与 AI 交互，当同步与异步体验融合时——提示一下，它可能更像 TikTok，而不是你现在的 IDE。感谢你们加入，很高兴邀请到你们。嘿，谢谢邀请，很高兴来这里。我们很想多了解一下你们的工作。请介绍一下 Codex 团队和你们的故事。好的，我是 Hansen，是参与训练初代 Codex 模型的研究员之一。我是 Alex，产品负责人。对我来说，Codex 这个名字很好地呼应了最初的 Codex 模型。它刚发布时，对我来说是一个顿悟时刻，因为我觉得 GPT-3 已经很酷了，但 Codex 让我第一次觉得：哇，这真的能做一件将改变世界的事。实际上，这也算是我进入创业圈的契机。我最早做的几个 demo 之一就是用 Codex 做数据分析。说来有趣，我当时来参加 Sequoia 的 Arc 项目，因此认识了 Lauren。我们当时做的一个 demo 其实就用到了 OpenAI Codex 来做数据分析，我就是这样进入创业领域的。随着时间推移，后来 GPT 的后续版本陆续问世，有一点变得非常清晰：将 AI 用于 agentic 场景会是未来趋势。所以我加入 OpenAI，专注于 agentic 编程方向的工作。是的，这也很符合 OpenAI 一贯的风格——我们喜欢让命名尽可能简单易懂。这是 2021 年左右的 Codex。那是在 HBT 之前，对吧？没错。所以它其实就是驱动 GitHub Copilot 的模型。后来，在最近开发这款产品的过程中——我们待会会聊到——我们觉得这是个非常有趣的品牌，名字也很贴切：code、Codex、code execution，所以我们决定重新启用这个品牌，继续使用它。你用了“重新启用”这个词，所以 Codex 是沉寂了一段时间，然后你们为了……？我们最近确实没再用过这个品牌。明白了。非常酷。能介绍一下 Codex agent 是做什么的吗？好的。Codex 本质上是一个编程 agent，它拥有自己的容器和终端，完全运行在云端。你给它一个任务，它会以类似 oneshot 的方式返回一个 PR。实际上我们中途试验过很多不同的产品形态，但最终决定采用这一种。我们一直在开发各种 agent 和编程产品。基本上，在我们看来，Codex 是一个思想实验：如果用 AI 编程会是什么样的体验？我们把全部精力投入到思考一种场景——如果 AI 在你自己的电脑之外独立运行，你向它委派任务，而不是与它结对编程，那会是什么感觉？因此，这次 Codex 发布让我们引以为傲的几个方面包括：计算环境的设计——如何配置环境才能让 agent 真正独立工作且保持高效；以及模型的打造——它不仅能写出看起来不错或能运行的代码，而且能写出对专业软件工程师真正有用、理想情况下无需他们在自己电脑上动手就能直接合并的代码。那么，Codex 和 Codex CLI 有什么区别？是的，我们确实收到了不少相关问题。我保证这些东西随着时间推移会越来越好理解。基本上，Codex 是我们 agentic 编程的品牌。我们的愿景是：这个 agent 大多数时候会在它自己的电脑上工作，但它也应该能出现在你使用的任何工具中，无论是终端、IDE 还是事务管理工具。Codex CLI 基本上就是位于你终端里的 Codex。CLI 代表 command line interface，对吧？也就是说，你在终端里与 Codex 交互，终端就是你的环境；而 ChatGPT 里的 Codex，则是一个在独立电脑上运行的 Codex。目前这两者还是分开的。顺便一提，在 OpenAI 工作我最喜欢的一点就是我们很愿意削减范围、快速发布。但随着时间推移，我们会把这些东西整合得更紧密。你可以把它理解为：它就是 Codex，既可以出现在 ChatGPT 里，也可以出现在你的 CLI 中。非常酷。为了让模型不仅仅能写出下一行代码，而是真正有用，你们做了哪些不同的工作？我觉得最有趣的进展之一在于，如果我们回顾 01——我们发布的首个推理模型——当时我们强调了它在数学甚至编程竞赛上的出色表现。直到现在，我以前也做过竞技编程，但 01 在这方面的水平已经比我高了，也比 OpenAI 几乎所有人都强。但我们发现，尽管它擅长编程竞赛，却不擅长产出可合并的代码。所以我们在博客文章中也提到了这一点：像 03 这样的模型，它生成的代码往往在风格或品味上并不完全符合专业软件工程师的预期。因此，我们在训练这个模型时投入了大量精力，让它与专业软件工程师的品味或偏好对齐，这需要进行大量专门的训练。我对我们的产品有一个很喜欢的类比。如果你拿我们那些擅长编程的推理模型来说，它们确实很会编程，但有点像那种天赋异禀的竞赛型程序员，像是刚毕业的大学生，并没有太多在团队中担任专业软件工程师的实战经验。所以我们从 o3 到 Codex 所做的很多工作，其实就相当于积累最初几年的工作经验——比如，好的 PR 描述应该是什么样的，PR 标题怎么写，如何读懂代码库的风格并确保自己的代码风格一致，如何做好测试，以及如何展示你已经做好了测试，等等。用户在使用 Codex 时，典型的“顿悟时刻”是什么？我觉得我们在引导流程中设置的一个环节就是：在代码库中查找并修复 bug。我认为这是 Codex 真正出彩的领域之一，特别是 bug 修复。因为它不仅能独立地检查哪里看起来不太对劲，还能实际去验证——比如尝试复现某个问题。所以甚至在 Codex 发布前，我们就遇到过几个搞不定的 bug，大家坐在一起琢磨到底是怎么回事，而老实说，有时候最简单的做法就是把问题描述贴到 Codex 里。我们很惊讶地发现，经常能直接得到一个可用的修复方案。这里有个有趣的故事。希望这不会透露太多，但在发布前夜——或者说发布当天凌晨一点——我们在处理一个动画相关的 bug，一个 Lahi 动画。你知道，这种时候你会觉得，好吧，我们可以把它从发布范围里砍掉，没有它也能发布。但我们真的很想把这个功能做进去，而且我们就是搞不定。于是有位工程师把 bug 描述输入到了 Codex 里。实际上，这里有一个给所有 Codex 用户的小技巧：如果任务特别难，让 Codex 多试几次会很有用。所以那位工程师把描述贴进去，跑了四次，说“嘿，这里有个 bug，我们搞不定怎么回事”。其中三次没成功，但四次中的一次刚好解决了我们凌晨一点被卡住好几个小时的那个 bug。于是我们就合入了修复，部署了代码，那个动画也赶上了发布。太棒了。能再多讲讲你们在 OpenAI 内部是怎么用的吗？是不是每个工程师、每个研究员现在都在工作流里用 Codex？可以。实际上，我能再讲讲另一种“魔法时刻”吗？当然。Codex 有一个很有意思的地方，就是它的产品形态可能和大家习惯的很不一样。很多人熟悉的 AI 产品，特别是在软件领域，也许 GitHub Copilot 是第一个真正好用的。那些产品主要是跟你一起流畅协作，你无缝地来回切换，有点像结对编程，对吧？各种形式的结对编程。我们认为这很棒，Codex CLI 也可以这样用。但对于 Codex，我们真的很想推动“委派”这个理念，因为在未来，我们设想实际上绝大部分编码工作都将独立完成，不再依赖那些坐在自己电脑前、一次只能做一件事的人类。基本上，这将由在它们自己电脑上运行的 agent 来完成。所以，把任务委派给 agent，和跟嵌入你工具里的 AI 模型结对编程，是两件非常不同的事。因此你必须以不同的方式使用它。当我们还在发布前做 alpha 测试时，我们只是把这个 agent 交给人们，说“嘿，随便你怎么用”。然后我们注意到，很多试用 Codex alpha 版本的人并没有觉得它特别有用。我们就想，咦，这很有意思。让我们看看 OpenAI 内部的人是怎么用 Codex 这类工具的。然后我们发现了一个很大的区别，那就是使用心态。对 Codex 很有效的心态是一种“富足心态”，就是“嘿，让我们什么都试试，甚至多试几次，看看哪个能成。这能帮我省时间”。所以我们甚至改变了引导用户上手产品的方式，试图创造这种顿悟时刻，也就是并行运行多个任务。对我们来说，如果看到有人试用它，一天或一小时内跑了 20 个任务，那就太棒了，说明他们基本上已经理解该怎么用这个工具了。很有意思。当人类必须审查所有这些代码时，角色会发生怎样的变化？比如三份里有两份能用，你会怎么做？是的。我们在让输出结果易于审查方面也花了很多心思。我们很自豪的一点是——这在其他工具中并不多见——模型能够引用它自己的工作。不仅是修改了哪些文件，甚至还包括终端输出。比如它运行了测试，如果因为某种原因测试没通过，它真的会告诉你，还会说“这就是我运行的具体终端命令，这是输出结果”。这让验证输出变得容易得多。不过你说得很对。我认为我们正在转向一个世界，在这个世界里，我们平常花在写代码上的很多时间，将会转移到审查这些代码上。人类真的需要审查代码吗？因为我觉得代码是那种要么能编译要么不能编译的东西。一旦编译通过了，你就可以去检查它是否做了该做的事。人类甚至有必要做代码审查吗？我认为是的，至少在可预见的未来，我确实认为是这样。我觉得很大一部分原因也是在和早期用户建立信任。人们真的需要有一种感觉，知道哪些东西好用，哪些不好用。而且总有一些外部上下文，关于什么让这段代码正确，这可能超出了你最初提供的上下文范围。是的。如果你想想开发者的工作——这显然过于简化了——但大概是：首先提出哪些事情应该做，和团队讨论，然后决定做什么，你可以称之为构思；然后是设计，好吧我们到底要做什么；接着是规划，我们要怎么做；然后是实现，再是验证，也就是测试这些改动。这基本上是一个循环，而实现和测试这个小循环正是 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 体验将如何展开。真的很感激。谢谢。非常感谢。谢谢邀请我们。谢谢。