OpenAI 5 月份推出的 Codex Agent 跟其他 Coding 产品不太一样。
全新的 codex-1 编程模型，可以并行处理多个任务，而且能够独立完成编程全任务流程，目标是可以作为「任务委托」的助手，接管整个开发流程，而不只是编码补全。
Sam Altman 对这个产品颇多赞誉，说这是第一次让他有 「接近 AGI」 感觉的产品之一。
从「代码补全」到「任务委托」，AI 编程正在朝着新的，更能解放生产力的方向发展。
OpenAI 是如何思考这个产品的，为什么要单独出一个编程模型？未来 AI Coding 的想象力在哪里？
Codex 的研究员 Hanson Wang 和产品负责人 Alexander Embiricos 近期在接受红衫资本的专访中分享了关于 Codex 的核心理念、技术演进、以及对于未来 AI 编码工具交互方式的设想等内容。
TLDR:
-
未来最高效的 AI 编程模式，不是 AI 在开发者电脑上进行实时代码补全（结对），而是开发者将整个任务打包委托给在云端拥有独立环境的 AI Agent，由其异步完成并交付完整方案。
-
高效使用 Codex 的关键在于「富足心态」，即尝试并行运行多个任务，以「委托」的思路，而不是用「补全」的线性思维来协同工作。
-
Codex 模型和 o3 同源，但通过额外的强化学习进行了微调。微调的重点是解决偏向「定性」的问题，即如何让它从一个单纯的「优秀程序员」，成长为一个懂得工程实践的「优秀软件工程师」。模型需要学习专业开发者的「品味和偏好」。
-
为编程模型创建一个逼真的训练环境是一个难题。现实世界的代码库缺乏一致的测试框架、文档标准和开发实践，Agent 难以依赖。OpenAI 采用通过在训练和生产中使用完全相同的容器化环境的方法来解决这个问题。
-
AI 不会减少软件工程师的数量，反而会因为降低了软件开发门槛、催生更多个性化软件需求而大幅增加开发者数量。开发者的日常工作将从实际编码，转向更侧重于审查、验证和高层规划等方面。
-
OpenAI 的愿景是，未来将只有一个通用助手（ChatGPT），它能根据需要访问各种专用工具和接口，而非为不同功能构建单独的智能体。
-
未来开发者与 AI 的交互方式将同步与异步体验相结合，交互方式可能看起来更像 TikTok，而不是现在的集成开发环境（IDE）。
超 6000 人的「AI 产品市集」社群！不错过每一款有价值的 AI 应用。
-
最新、最值得关注的 AI 新品资讯；
-
不定期赠送热门新品的邀请码、会员码；
-
最精准的AI产品曝光渠道
Codex 的目标是能完全独立编程的 Agent
主持人：介绍下 Codex 吧。
Hanson Wang：对我来说，「Codex」这个名字很好地呼应了最初的 Codex 模型。当它首次亮相时，我有一种恍然大悟的感觉，因为 GPT-3 已经非常出色了，但 Codex 是第一个让我觉得「哇，这真的能改变世界」的东西。这其实也算是我进入创业圈的一个契机。我最早做的几个演示中，有一个就是利用 Codex 进行数据分析。
Alexander Emgiricos: 是的，这很符合 OpenAI 的一贯风格，我们喜欢让命名尽可能简单易懂。这是 2021 年的 Codex。
主持人：是的，那应该是在 ChatGPT 问世之前，对吧？
Alexander Embiricos: 完全正确。它其实就是驱动 GitHub Copilot 的模型。最近，在我们开发这款产品时，我们觉得这是一个非常有趣的品牌，名字也很贴切——Code、Codex、Code Execution（代码执行）。所以我们决定重新启用这个品牌。
主持人：你提到「重新启用」，所以 Codex 这个品牌是沉寂了一段时间，然后才被你们为新产品重新启用吗？
Alexander Embiricos: 是的，我们近期没有使用过这个品牌。
主持人：好的，能给我们介绍一下作为 Agent 的 Codex 是做什么的吗？
Hanson Wang: Codex 是一个在云端拥有专属容器和终端的编程 Agent。你交给它一个任务，它会以一次性交付的方式，直接返回一个拉取请求（PR）。我们其实尝试了很多不同的交互形式，但最终确定了这一种。
Alexander Embiricos: 我们一直在开发一系列 Agent 和编程产品。
在我们看来，Codex 就像一个思想实验：如果 AI 在它自己的电脑上独立于你工作，那么与 AI 共同编程会是怎样的体验？这意味着你是将任务「委托」给它，而不是与它「组队」编程。在这次的 Codex 发布中，我们引以为豪的几个方面包括对计算环境的思考，如何设置才能让 Agent 独立高效地工作；以及模型的创建，这部分 Hanson Wang 可以谈得更多。这个模型不仅擅长编写看起来不错或功能正常的代码，更擅长编写对专业软件工程师有用的代码，理想情况下甚至无需他们在本地修改就能直接合并。
主持人：那么 Codex 和 Codex CLI 有什么区别呢？
Alexander Embiricos: 对我们来说，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 目前所擅长的，当然我们也可以探讨如何用它来做规划。
之后是实际部署代码，可能还包括维护代码、编写文档等等。我忘了确切的统计数据，但我记得最近有个数字说，工程师大约只花 35% 的时间在写代码上，这甚至不是他们工作的大部分内容。我们努力构建的未来是，无论你是软件开发者还是从事任何职业，所有容易自动化的工作，通常是那些比较繁琐的工作，你都不必亲自去做，而是可以委托出去。而那些更有趣的工作，可能因为它们比较模糊，或者因为它们真的很有挑战性，那才是由你来主导的。
我们正朝着那个世界努力，而且我认为我们必须通过迭代的方式去实现它。例如，现在如果一个人写了代码，另一个人会来审查。我们不会一上来就试图改变这一点，而是说：「好的，让我们融入这个流程。」所以，产品目前的工作方式是，你作为开发者，被这个工具赋能提速。你提出编写代码的需求，然后你来决定它是否足够好并推送给团队，接着你的团队可以审查它。随着时间的推移，我们会逐步扩展我们能做的事情，比如更多地帮助进行规划，甚至设计，或者根据应用或工作中发生的事情来思考应该做什么。然后，我们会像 Hanson Wang描述的那样，努力让审查变得越来越容易。
Hanson Wang: 是的，我确实预见到未来会有多个 Agent 协同工作的场景。比如，Codex Agent 编写代码，然后可能有 Operator Agent 来测试它，我们在公司开发的所有不同 Agent 都可以协同工作。
主持人：太棒了。既然现在可以委托编写代码，你有观察到工程团队之外的人也开始使用 Codex 吗？随着我们进入「凭感觉编程」（vibe coding）的时代，你们正在帮助我们在这条路上走得更远。
Alexander Emgiricos: 是的，这其实非常有趣。答案是肯定的，但我可以给你讲个故事。当时我们和 Lindsey 一起为发布会的博客文章工作，讨论要引用哪些客户的评价。有一个客户想说：「我们工程团队非常喜欢这个工具，而且它对产品经理来说也是一个强大的工具。」我记得看到那句引言时，心想：「这话听起来真酷。」因为我就是产品团队的，我经常用它来避免因一些小事或问题去打扰工程师。但我当时看着那句话，又在思考：「我们真的想把这句放在发布会的博客里吗？」因为我们构建的产品目标受众是专业的软件工程师，而不是「凭感觉编程」的人。所以我想我们最后没有采纳那句话。但我认为，随着时间的推移，当我们有了能帮助我们编程的 Agent 后，我预计会有越来越多的人能够为代码库做出贡献。
主持人：你认为专业软件开发者的数量会随着时间增加还是减少？
Alexander Embiricos: 这只是我的个人观点，但我认为会大幅增加。
主持人：不是「凭感觉编程」的人，而是专业的软件开发者？
Alexander Embiricos: 是的，我认为是这样。在我看来，编写软件越容易，我们就能拥有越多的软件。现在，如果我们拿出手机——当然，你们是投资者，但如果不是，我敢打赌，你手机上的大多数应用都是由大团队为数百万用户构建的。而很少有应用是专为我们个人或特定需求量身打造的。所以我认为，随着为个人或团队构建定制化软件变得越来越可行，我们对软件的需求最终会越来越高。
Hanson Wang: 当我思考我如何使用它时，我认为它目前确实是一个效率倍增器，而不是任何形式的替代品。特别是观察我们内部重度用户的使用模式，差异非常显著，顶尖的 Codex 用户每天能完成 10 个以上的 PR。这真是一个巨大的效率倍增器，以至于我无法想象一个它会降低软件创造门槛的世界。
Alexander Embiricos: 话虽如此，我认为这是一个非常重要的问题。坦白说，我们并不知道答案。所以这是我们公司非常关注的一件事。
可以运行半小时的 Agent，怎么做出来的？
主持人：谈谈技术层面底层发生的事情。你提到，模型本身的一个不同之处在于，你们让它更擅长专业软件开发者会做的事情，而不是竞赛编程。这是模型方面最大的区别吗？还是我们应该把它看作是 o3 的「近亲」模型？
Hanson Wang: 是的，它和 o3 模型同源，但我们通过额外的强化学习进行了微调。这次微调的重点，更多是解决那些偏向「定性」的问题，即如何让它从一个单纯的「优秀程序员」，成长为一个懂得工程实践的「优秀软件工程师」。这包括了代码风格、注释规范等许多方面，而这些恰恰是其他模型容易忽略的。
除此之外，我还想强调另一个巨大的难题是，为 AI Agent 创造一个足够逼真的学习环境。现实世界的软件仓库极其多样和复杂，光是搭建和维护一个仓库就需要大量的 DevOps 工作。」
Alexander Embiricos: 这点深有体会，以我昨天给 Hanson Wang 看的多仓库项目为例。我当时在给 Hanson 展示了我们被 OpenAI 收购的那家初创公司的代码仓库。我们一起看着那个仓库，考虑把它用作一个训练环境。Hanson 问：「单元测试在哪里？」
因为 Agent 需要用单元测试来验证。我当时就说：「这是一个真实的初创公司，它没有单元测试。」
Hanson Wang: 是的，你会遇到各种这样混乱的环境。所以在训练过程中，我们基本上必须为 Agent 生成这些非常真实的环境来供其学习。我认为，我们之所以能做出这样一个端到端的产品，原因之一是我们拥有在训练和生产环境中使用的相同环境，以及相同的容器化基础设施。我们的用户在使用 Codex 时，他们运行在与我们用于训练的完全相同的环境中。
主持人： 所以 Agent 不会说：「但在我的机器上是好的。」
Hanson Wang: 完全正确。
主持人：我认为这些也是我见过的 OpenAI 推出的任务运行时间最长的 Agent 了。Deep Research 可能是之前运行时间最长的。我的理解是，Codex 有时可以在不同的任务上花费 30 分钟。在让推理时间扩展到如此长的查询上，你们有没有遇到什么出乎意料的挑战？
Alexander Embiricos: 我先从产品方面谈起，模型方面也有很多挑战。在产品方面，我思考最多的是用户意图。如果你想象一个人在他的 IDE 里使用自动补全，预测他在下一微秒想做什么并不一定非常困难。但是对于一个需要 30 分钟才能完成的任务，帮助用户描述这个任务实际上相当困难。他们自己可能都不知道在这 30 分钟的工作里具体想要什么。
所以我们花了很长时间辩论，并且现在仍在持续辩论的一个问题是：用户交给 Codex 的任务，合适的粒度是什么？我们如何能让它变得简单，让 Codex 足够灵活，既可以用于单行修改，也可以用于你明确知道要做什么的大型重构，或是你知道想要什么的大型功能开发。或者，当你不太确定自己想要什么时，是否也能使用 Codex？也许你应该先让 Codex 给你一个计划，然后让它建议一些任务，你再执行这些任务。这仍然是我们正在辩论和迭代的主题。
Hanson Wang: 我认为这其实是一个使用它的小技巧。它非常擅长制定自己的计划。有时候，预先详细指定你想要的一切会非常繁琐。如果你想让它工作一个小时，你就必须预先规定很多东西，这意味着你可能要花 10 到 20 分钟来构思。但如果你先使用「提问模式」生成一个你想要做的高级计划，然后你可以在把它派出去工作一小时之前，与模型一同迭代这个计划。
主持人：这真的像在和一个实习生一起工作。
Hanson Wang: 是的。
主持人：模型方面呢？随着运行时间变长，模型行为上有什么令人意外的地方吗？
Hanson Wang: 我们的模型在长时间执行任务时，保持「专注」的能力确实提高了很多。不过，确实有些情况下，即使是模型，它的耐心也是有限的。有时这会让人感到沮丧，比如它运行了 30 分钟后，就会像人一样告诉你：「抱歉，这个任务太重了，我实际上没有足够的时间来完成。」这是我们正在努力改进的一个方面。
主持人：就像是一个实习生一样。
Hanson Wang: 在很多方面都非常像人。
编程的「最后一公里」，还是需要人类的
主持人：你们如何怎么看正确的交互模式及其演变，以及围绕于此的产品套件未来如何发展？在工程和产品构建方面，除了 Codex 和 Codex CLI，还有哪些可能性？
Alexander Embiricos: 我们发布的 Codex 只是一个研究预览版，一个有用的实验，但仍处于非常早期的阶段。我们最自豪的是它的模型以及为计算环境打下的基础。我们发布的 UI 是我们迭代出来的，虽然其中有些有趣的故事，但它绝不是最终形态。
对于听众来说，我们发布的 UI 是 ChatGPT 中的一个界面，你可以在那里提交任务，让 Codex 回答问题或编写代码。然后你会看到一个有点像待办事项列表的界面，可以查看并决定是否合并。我们构建这个界面的初衷是为了深入探索「异步 Agent」和「委托」这一理念。
但我们想要构建的未来是，你无需去思考你是在委托还是在与 Agent 代码补全。它应该感觉就像与一个无处不在的队友一起工作，这个队友存在于你使用的所有工具中。你应该能在任何你正在使用的工具里——无论是终端、IDE、任务管理工具，还是警报或错误监控工具——随时寻求帮助。甚至可能在你到达之前，Codex 就已经看过了问题并有了自己的见解。你可以问任何问题，无论是长是短，它会恰当地决定花多少时间来回答你，并帮助你完成这些变更。所以，我们基本上想融合「补全」和「委托」这两个概念，但我们首先发布的是这个理念最纯粹的思想实验。
另外我想补充一点，在 OpenAI 工作的独特之处在于，我们是 ChatGPT 的创造者，这是大多数人使用的 AI 系统。所以我们并不认为未来你会每天在决定是使用 Codex Agent、购物 Agent 还是打车 Agent。我们认为它应该是一个你可以与之交谈的、统一的助手，你可以问它任何关于任何事情的问题，它都能帮你完成。那就是 ChatGPT，它将成为我们的助手。然后，如果你是某一类工具的重度用户，比如软件开发者，你花大量时间在特定的功能性工具上，那么你就可以进入那个工具，使用一个带有按钮、列表的定制化界面，高效地完成你的日常工作。
主持人：你认为我们还会使用 IDE 吗？
Alexander Embiricos: 当然会，但它们会进化。现在这些工具专注于编写代码。而正如 Hanson 所说，未来可能会有越来越多的代码由 Agent 编写。因此，重点将会转向「落地代码」、审查代码或验证代码，甚至可能会转向规划更大的项目。
Hanson Wang: 是的，我们已经看到团队里的很多人，他们早上第一件事就是来公司，冲杯咖啡，然后启动几个任务来获得一个初步方案。等他们吃完早餐回来，看看生成的 PR，然后再接手处理。IDE 就像是那个你接手的地方，它可能会帮你完成 80% 甚至更多的工作，但总有那「最后一公里」，需要你亲自上手并根据自己的感觉进行微调。
主持人：结合 OpenAI 内部策略的演变（如异步任务整合到 ChatGPT）以及外部工具和模型的爆发式增长，你怎么看当前的市场趋势？
Alexander Embiricos: 是的，对于开发者来说，现在是一个疯狂的时代。有太多新工具都非常有用。最近有个有趣的故事，我在飞机上没有 Wi-Fi，本想写点代码做个东西。但因为没有 Wi-Fi，我就想：「算了，现在花时间去尝试写代码根本不值得。」然而，我多年前做的那个初创公司，其部分起源就是我在一架没有 Wi-Fi 的飞机上写代码。现在我根本不会再那样做了，因为市场已经变化太大了。
我认为在接下来的两年里，我们将看到同样程度的转变，编程将变得完全不同。现在，人们觉得最有价值的工具大多是那些与你紧密协作的，基本上是在你的开发环境中进行代码补全的工具。我认为我们将看到的转变是大部分代码将由 Agent 编写。而这些 Agent 不会在你的环境中工作，因为那里一次只能做一件事，它们将在自己的环境中工作。它们也不会仅仅在你想到具体任务时才被触发，而是会连接到你使用的工具中，在那里完成工作。
所以我认为我们会看到向 Agent 的转变。我们将不得不解决很多关于代码审查的问题，就像你之前问的。我个人并不确切知道那会如何运作，但我知道，即使在 OpenAI 内部，已经有越来越多的代码由 Agent 合并，甚至有更多的代码由 Agent 生成，比如人们会一次性启动四次任务，来挑选他们最喜欢的实现方式。所以，我们该如何管理所有这些被编写出来的代码，目前还不是百分之百清楚。
但是，我可以分享一些对听众可能有用的东西：你确实可以对你的代码库做一些事情，让它更容易被 Agent 处理。这不一定特别新颖，但使用类型化的语言会非常有帮助。另一件很有帮助的事情是，拥有更小、测试得更好的模块。
Hanson Wang: 或者说，有好的测试就行。
Alexander Embiricos: 是的，我们开玩笑说我那家初创公司的代码库，但如果放到今天来写，我敢打赌我们会写得完全不同。甚至还有一些小细节，比如我们这个项目的代号是 WHAM。这是 Codex 的代号。我们当初命名时是经过深思熟虑的，因为我们知道代码会存在于服务器、网站以及其他各种地方。我们希望 Agent 能够轻松地搜索与 WHAM 相关的代码并找到它。所以我们将项目命名为 WHAM，并事先在代码库中检查了这个词出现的频率。如果当时我们叫它「code」、「Codex」或者「agent」之类的名字，你可以想象 Agent 要找到相关代码会有多困难。
主持人：结果你们现在叫它 Codex，所以 Agent 现在要困惑了。
Alexander Embiricos: 这正是我要说的重点，有意识地设计。在代码中，我们大量使用 WHAM 这个词，因为这对 Agent 来说更容易找到。当然，即使我们不用这样的词，Agent 也能找到路径，但它需要花费更多时间来定位正确的文件。
Hanson Wang: 是的，很酷的一点是，很多让代码更好懂、更好用的办法，对 AI 工具来说也一样管用。比如，完善的测试和清晰的文档就是很好的例子。现在，我们更有动力去做好这些，因为它不仅能让自己的工作更轻松，也能让 Agent 的工作更轻松。
OpenAI 关注的是通用和泛化场景的 Agent
主持人：跟 Claude Code 和 Jules 这些 Agent 式编程体验相比，你们有什么优势？市场最终会趋向于同一个关于同步和异步编程的愿景吗？如果会，未来 OpenAI 的优势在哪里？
Alexander Embiricos: 我认为我们会看到各种各样的形态。就像你提到的，有在你的电脑上工作的工具，也有在它们自己电脑上工作的工具。我认为多数工作会由独立计算的 Agent 承担，但帮助开发者提升本地工作效率依然至关重要。理想情况下，我们能两全其美，但大部分工作会在 Agent 的计算环境中完成。
Hanson Wang: 我的看法是，软件工程中最困难的部分之一，实际上是吸收来自外部世界的所有上下文信息，并将其编码成需求和设计文档。而实现过程，正如我们前面提到的，在整个生命周期中，实际编码所占的时间并不多。我认为 ChatGPT 的优势在于，它是一个拥有记忆、能够连接到你使用的各种不同工具的助手。我们有 Operator、Deep Research 等具备各种不同能力的工具。我认为，当这一切融合在一起时，像 Codex 这样的工具一旦能够获取所有这些知识并加以利用，它就能在编码这个环节上做得更出色。
Alexander Embiricos: 是的，想象一下，你雇佣一个软件工程师，而他唯一能做的事就是从你这里接一个任务然后生成一个 PR。他只能精确地做那些定义好的事情。然后你让他做一件随机的事情，比如：「嘿，团队要开会，你能不能帮忙订个会议室并主持一下头脑风暴？」如果你雇的队友拒绝做这类工作，那会非常令人沮丧。同样，我们正在构建的未来是，与你合作的 Agent 会更加通用。就像 Hanson 提到的 Operator 和 Deep Research，Operator 有一个网络浏览器，Deep Research 有另一种形式的网络浏览器，Codex 有一个终端。实际上，你的一个人类队友也拥有类似的工具。
我们最终的目标是选择一些我们想要重点投入的特定领域，来取得快速进展。我们正在通过 Codex 在编程领域这么做，我们为开发者生成了特定的评估标准，然后为他们制作了更好的模型。但随着时间的推移，我们会将这些能力泛化为每个人都能使用的简单工具。所以，对于我们 OpenAI 和 ChatGPT 来说，我们构建的产品将与那些仅仅专注于特定领域（如编程）的产品非常不同。
主持人：你认为开发者与 Codex 交互的主要 UI 会是什么？会是 ChatGPT、CLI、IDE，还是以上全部？
Hanson Wang: 我认为是以上全部的混合体。我们只是想在开发者需要的时候出现在他们所在的地方。所以可能甚至不是在编辑器或终端里，而是在 Slack 上。有人给你发消息说：「嘿，这里有个 bug。」你就可以直接回复：「嘿，去把它修好。」
Alexander Embiricos: 我来给你描绘一个我有趣的、不完全严肃的未来 UI 设想。如果你是未来的一个创业创始人，你的团队只有你或者你和几个联合创始人，外加许多 Agent，那么与 Agent 的工作方式可能看起来就像 TikTok。你可能有一个垂直信息流，上面是 Agent 生成的视频，展示一个想法，比如：「嘿，一个客户提出了这个请求，我认为我们应该修复它。」然后你向右滑动表示：「好，我们来做这个。」向左滑动表示：「不，我们不能做。」
主持人：是 Tinder 还是 TikTok？
Alexander Embiricos: 抱歉，是个混合体。我没说这个设想会很有逻辑。
主持人：我喜欢这个想法。
Alexander Embiricos: 然后你长按来提供反馈，比如：「是的，做吧，但要确保字体是斜体的。」基本上，你拥有所有这些订阅了你公司或团队信息的 Agent，它们会主动提出想法并执行，然后给你更新，而你只是在管理正在进行的工作。
主持人：我很喜欢这个设想。
主持人：它们还会向你展示世界可能变成什么样的小预览。
Alexander Embiricos: 是的。这只是个半开玩笑的说法。我认为那将是与 Agent 保持一定距离的工作方式，同时，让人们能够亲自上手、与 Agent 在各种环境中结对工作也仍然非常重要。
主持人：你们认为哪种新的应用或应用类别会在 2025 年爆发？除了编程之外。
Hanson Wang: 我觉得，2025 年绝对是 Agent 之年。我们会看到 Agent 在很多不同领域起飞。
Alexander Embiricos: 是的，我同意。
主持人：你们对哪种类型的 Agent 最感兴趣？
Hanson Wang: 除了编程 Agent 之外？
主持人：是的。
Alexander Embiricos: 我的看法是，我们思考 Agent 的方式是，你有一个推理模型，然后你给它接入行业的工具，接着你弄清楚如何训练这个 Agent 去执行特定的职能。所以这不仅仅是关于写作，而是关于新闻业；不仅仅是关于编码，而是关于软件工程。这就是我们正在做的事情。
在我看来，我今年对 Agent 如此兴奋的原因是，我们现在已经有几个来自 OpenAI 的 Agent 发布了，其他公司也在发布 Agent。所以我们开始看到这个领域的轮廓，并开始识别出一些基本要素。我特别兴奋的是，当我们将这些整合起来，你得到的 Agent 就不再需要为每个功能单独配置，而是一个拥有计算机、浏览器和终端的 Agent，它可以做多种事情，而无需你精确地指定「你是我的编程 Agent」之类。
（文：Founder Park）