主要观点总结
OpenAI的Codex Agent是一个全新的编程模型，能够并行处理多个任务并独立完成编程全任务流程。它旨在作为“任务委托”的助手，接管整个开发流程，而不仅仅是代码补全。Sam Altman对其赞誉有加，称其让他有“接近 AGI”的感觉。OpenAI致力于让Codex模型与专业软件工程师的品味和偏好对齐，并为其创造一个逼真的训练环境。该模型已通过额外的强化学习进行微调，以解决偏向“定性”的问题，并使其从单纯的“优秀程序员”成长为懂得工程实践的“优秀软件工程师”。Codex在OpenAI内部的使用展示了其作为“富足心态”工具的价值，允许用户并行运行多个任务。OpenAI认为，未来软件开发者的角色将发生变化，专注于审查、验证和高层规划等方面，而实际编码工作将由AI完成。Codex的未来愿景是与所有工具无缝集成，为开发者提供异步和同步的编程体验。
关键观点总结
关键观点1: Codex Agent的特点
Codex是一个全新的编程模型，能够独立完成编程全任务流程，旨在作为“任务委托”的助手，接管整个开发流程。它具备并行处理多个任务的能力，并通过强化学习微调模型，使其更加适合专业软件工程师的品味和偏好。
关键观点2: Codex在OpenAI内部的使用
OpenAI内部使用Codex的示例展示了其作为“富足心态”工具的价值，允许用户并行运行多个任务。这种使用方式提高了工作效率，并显示了Codex在多个编程任务上的出色表现。
关键观点3: 未来软件开发的变革
OpenAI认为，未来软件开发者的角色将发生变化，专注于审查、验证和高层规划等方面，而实际编码工作将由AI完成。这将使软件开发更加高效，并催生更多个性化的软件需求。
关键观点4: Codex的愿景
Codex的愿景是与所有工具无缝集成，为开发者提供异步和同步的编程体验。这将改变开发者与AI的交互方式，使编程变得更加高效和便捷。
正文
对我们来说，Codex 是我们 Agentic 编程的品牌。我们的愿景是，未来会有一个 Agent，它大部分时间在自己的电脑上工作，但也能够在任何你使用的工具中与你协作，无论是在终端、IDE 还是任务管理工具里。Codex CLI 就相当于 Codex 在你终端里的化身。「CLI」代表「命令行界面」，所以你可以在终端这个环境中与 Codex 协同工作。而我们所说的 Codex，或 ChatGPT 中的 Codex，则是在它自己的电脑上工作。目前，这两者是分离的。
顺便说一句，在 OpenAI 工作我最喜欢的一点就是，我们非常乐于精简范围、快速发布产品。但随着时间的推移，我们会将这些产品更紧密地整合起来。所以你可以简单地把它看作是 Codex，它既可以存在于 ChatGPT 中，也可以存在于你的 CLI 中。
Codex 模型跟工程师的偏好更对齐
主持人
：为了让模型不仅仅是写下一行代码，你们在模型
层面
做了哪些不同的工作？
Hanson Wang:
我认为最有趣的进展之一是，如果你回顾我们发布的第一个推理模型 o1，会发现我们强调了它在数学甚至编程竞赛中的出色表现。到目前为止，它在竞赛编程方面的能力比我这个曾经的竞赛程序员还要强，也比 OpenAI 几乎所有人都要强。但我们发现一个问题，尽管它在这些编程竞赛中表现优异，却并不擅长生成能够被直接合并的代码。我们甚至在关于 o3 模型的博客文章中也强调了这一点，它生成的代码往往不符合专业软件工程师的审美或风格。所以，
我们训练这个模型的主要精力，都投入到了让模型与专业软件工程师的品味和偏好对齐上。
这需要大量专门的训练。
Alexander Embiricos:
我有一个非常产品化的比喻。我们最近的模型虽然非常擅长编程，
但它们就像一个早熟的、喜欢竞赛编程的大学毕业生，缺乏在团队中作为专业软件工程师的工作经验。
所以，我们从 o3 到 codex-1 所做的大量工作，实际上就相当于为它补上了最初三年的工作经验，比如：一个好的 PR 描述应该是什么样子？PR 的标题怎么写？如何读懂代码库的风格并确保你的代码与之保持一致？如何做好测试？如何展示你已经做好了测试？诸如此类。
主持人
：
用户在使用 Codex 时，
通常在哪个瞬间会感到「恍然大悟」？
Hanson Wang:
在我们的入门引导流程中，有一个任务是「在代码库中查找并修复一个 bug」。我认为这是 Codex 特别擅长的领域之一，尤其是在修复 bug 方面。因为它不仅能发现看起来不对劲的地方，还能独立地去验证，比如尝试重现某个特定的问题。甚至在 Codex 发布之前，我们自己也遇到过一些棘手的 bug，有时最简单的解决方法就是把问题描述直接粘贴到 Codex 里，我们常常惊讶于它能频繁地给出一个可行的修复方案。
Alexander Embiricos:
是的，这里有个有趣的故事。在发布前一晚的凌晨一点，我们正在处理一个关于 Lottie 动画的 bug。这种情况，我们本可以从发布范围中砍掉它，没有它也能发布。但我们真的很想把它加进去，却一直没能解决。最后，一位工程师描述了 bug 的情况并把它输入到 Codex 中。这里有一个给所有 Codex 用户的小技巧：如果任务非常困难，可以尝试让 Codex 多试几次。于是他把描述粘贴进去，运行了四次，任务大意是：「这里有个 bug，我们不知道问题出在哪。」其中三次运行都失败了。但在发布前的凌晨一点，第四次尝试就修复了我们卡了好几个小时的 bug。于是我们提交了修复，部署了代码，那个动画最终成功地出现在了发布版本中。
主持人
：太棒了。你们在
OpenAI
内部是如何使用它的？现在是每个工程师、每个研究员都在他们的工作流中使用 Codex 吗？
Alexander Embiricos:
当然，不过我要先分享另一个「神奇时刻」。Codex 的一个有趣之处在于，它的形式可能与人们习惯的非常不同。很多人熟悉的 AI 产品，尤其是在软件领域，比如 GitHub Copilot，都是与你协同工作的，你们之间无缝地来回交互，像是在代码补全一样。我们认为这种方式很棒，Codex CLI 也是一个可以这样使用的工具。
但对于 Codex，我们真正想推动的是「委托」这个概念。因为我们设想，未来绝大多数的编程工作将由 Agent 独立完成，而不是由一次只能做一件事的人类在自己的电脑上完成。Agent 将在它们自己的电脑上工作。
委托任务给
Agent
和与你工具中的
AI
模型代码补全是完全不同的。
因此，你也需要用不同的方式去使用它。在发布前的 Alpha 测试阶段，我们把这个 Agent 交给人们，说：「嘿，随便用。」我们注意到，很多试用者觉得它不是特别有用。然后我们想：「嗯，这很有趣。让我们看看 OpenAI 的内部人员是如何使用像 Codex 这样的工具的。」我们发现了一个巨大的差异，那就是使用的心态。
对 Codex 来说，最有效的心态是一种「富足心态」，就是「嘿，让我们尝试任何事情，甚至多次尝试，看看哪个能行，反正它能为我节省时间。」所以我们改变了引导用户进入产品的方式，试图创造这种「恍然大悟」的时刻，也就是并行运行多个任务。对我们来说，如果看到有人在一天或一小时内运行了 20 个任务，那就太棒了，这说明他们基本上已经掌握了如何使用这个工具。
编程本来也不是工程师的主要工作
主持人
：当你需要审查所有这些代码时，人类的角色会发生怎样的变化？如果三个方案中有两个是可行的，
你该如何抉择？
Hanson Wang:
我们非常注重让输出结果易于审查。我们引以为豪的一点，也是在其他工具中很少见到的，就是模型能够引用它自己的工作成果。它不仅会列出修改过的文件，甚至还会提供终端输出。比如，如果它运行了一个测试但没成功，它会告诉你，并给出它运行的确切终端命令和输出结果。这使得验证输出变得容易得多。但这确实是一个很好的问题。
我们正在进入一个代码审查将占据我们过去用于编程的大量时间的世界。
主持人
：
我们真的需要人类来审查代码吗？因为我认为代码是那种「要么编译通过，要么通不过」的东西。一旦编译通过，你就可以去检查它是否实现了预期的功能。
Hanson Wang:
我认为，至少在可预见的未来，答案是肯定的。很大程度上也是为了与早期用户建立信任。人们需要对哪些功能好用、哪些不好用有切身感受。而且，总会有一些关于「为什么这段代码是正确的」的外部上下文信息，而这些信息可能超出了你最初提供给模型的范围。
Alexander Embiricos:
是的。如果你思考开发者的工作，当然这是简化的说法，首先是提出应该做什么，可能与团队讨论，然后决定做什么，这可以称之为「构思」。然后是「设计」，即我们具体要做什么。接着是「规划」，我们将如何实施。然后是「实现」和「验证」，也就是测试这些变更。这基本上是一个循环。而「实现」和「测试」这个小循环，正是 Codex 目前所擅长的，当然我们也可以探讨如何用它来做规划。
