文：Web3天空之城| 未经许可不得转载
【城主说】在AI重塑软件开发领域的浪潮中，除了风头正劲的Cursor和最近有点不顺的Windsurf，OpenAI的AI编码工具Codex绝对是一个不容忽视的后起之秀。它不再仅仅是一个用于代码自动补全的模型工具，而是朝着一个更宏大的目标迈进：成为一个能够在后台自主完成开发任务的智能代理。考虑到最近Windsurf被OpenAI收购，如果Codex模型和Windsurf整合在一起，Cursor可能要睡不着觉了，这恐怕也是Anthropic 忽然背刺Windsurf的原因之一吧。
在最近一次深度访谈中，来自Codex团队的产品负责人亚历克斯（Alexander M. Burikos）和研究员汉森（Hanson Wang）详细阐述了这一转变背后的理念、挑战与未来图景。他们指出，软件开发的核心范式正在从开发者与AI的同步“结对编程”，转向异步的“任务委派”。这一转变不仅将根本性地改变开发者的工作流程，甚至可能重塑我们与AI协作的交互界面。
核心观点
• 范式转变 ：软件开发正从与 AI 同步结对编程，转向将任务异步委派给 AI 代理，这代表了生产力的根本性变革。
• 智能体核心理念 ：Codex 的目标是成为一个能在独立环境中工作的编码代理，开发者向其委派任务，而非进行实时协作，从而实现大规模并行工作。
• 专业工程优化 ：新版 Codex 模型经过特别训练，不仅能编写功能代码，更注重生成符合专业软件工程师品味和规范（如代码风格、测试、PR描述）的代码。
• 开发者角色的演进 ：未来开发者的工作重心将从编写代码转向审查、规划、验证和管理由 AI 代理完成的工作。
• 软件开发的普及化 ：通过降低编程门槛，AI 代理将使更多人能够构建定制化软件，从而可能导致专业开发者数量的大幅增加。
• 未来交互形态 ：与 AI 代理的交互将无处不在，从 IDE、终端到 Slack，甚至可能演变成类似“抖音”式的信息流，用于快速审批和指导 AI 的工作。
核心范式转变：从“结对编程”到“任务委派”
Codex团队明确指出，他们正在探索一种与现有AI编程助手截然不同的工作模式。当前主流的AI工具（如GitHub Copilot）更像是与开发者并肩作战的“结对伙伴”，在实时编码中提供辅助。而新一代Codex的核心理念，则是成为一个独立工作的智能代理。
在我们看来，Codex就像是一个思想实验，旨在探讨如何与AI一起编码，我们为此投入了所有精力，去思考如果AI独立于你，在它自己的电脑上工作，那会是怎样的一种体验。因此，你是在向它委派任务，而不是与它结对工作。
这意味着开发者不再需要全程监督AI的每一步操作，而是可以将一个完整的、耗时较长的任务（如修复一个bug、实现一个新功能）直接交给Codex。Codex将在其独立的云端环境中自主执行、测试、验证，并最终以一个拉取请求（Pull Request）的形式交付成果。这种异步协作模式，旨在将开发者从繁琐的实现细节中解放出来，专注于更高层次的构思与决策。
专业的工程品味：训练AI像资深工程师一样思考
一个关键的挑战是如何让AI生成的代码真正可用。早期的模型虽然能在编程竞赛中表现出色，但其生成的代码往往不符合专业软件工程的规范和“品味”。Codex团队投入了大量精力，通过强化学习（RL）对模型进行微调，使其不仅仅能编写功能代码，更能像一位经验丰富的工程师一样工作。
如果你拿我们的推理模型，它们在编程方面非常出色……但它有点像一个非常早熟的、像竞技程序员一样的大学毕业生，他还没有多年的团队专业软件工程师的工作经验。……我们从o3版本到Codex 1版本所做的大量工作，实际上就相当于那些最初几年的工作经验，比如：“嘿，一个好的PR描述应该是什么样子？”……你如何能做好测试？你如何展现你的测试成效？
这种对“专业工程品味”的追求，意味着Codex不仅关注代码本身，还注重代码风格的一致性、测试用例的编写、PR标题和描述的规范性等一系列软技能，从而确保其交付物能够更容易地被人类同事审查和合并。
开发者角色的演进：从“编码者”到“审查者”和“规划者”
随着AI代理承担越来越多的编码工作，人类开发者的角色将发生根本性转变。据统计，工程师实际花在写代码上的时间仅占约35%。AI代理的出现，将进一步放大这一趋势，让开发者将更多精力投入到那些更具创造性和战略性的工作中。
我们正在转向一个世界，在这个世界里，我们通常用于编写代码的大部分时间，将转移到实际审查代码上。 我们正在努力构建的未来是这样的：……所有那些容易自动化的工作，通常是那种更基础、更繁琐的工作，你都不会亲自去做，而是将其委派出去。而那些更有趣的工作，也许是因为它们含糊不清，也许是因为它们确实非常困难，那才是你主导的工作。
未来的开发者，其工作重心将从埋头编写实现代码，转向：
• 审查 由AI完成的工作，确保其质量和方向正确。
• 规划 更大、更复杂的项目，进行系统设计和架构决策。
• 验证 和 构思 ，将模糊的想法转化为清晰的任务，并管理多个并行工作的AI代理。
交互的未来：无处不在的AI与“抖音”式的工作流
Codex团队认为，未来与AI代理的交互将是无处不在的，它会深度融入开发者的每一个工作场景，无论是IDE、终端，还是Slack。当有bug报告时，开发者可能只需在聊天窗口中对AI说一句“去修复它”。
亚历克斯甚至提出了一个更大胆、半开玩笑的设想：未来的工作流可能看起来更像抖音或Tinder。
或许未来与代理人协作的方式……实际上会像抖音（TikTok）一样。比如说，你可能有一个垂直信息流，它基本上是代理人制作的视频，你可以观看，其中包含一个想法，比如：“嘿，有客户提出了这个请求，我觉得我们应该修复它。”然后你向右滑动，表示“好的，我们来修复它，我们来做这件事。”你向左滑动，表示“不，我们不应该那样做。”
这个看似戏谑的构想，背后揭示了一个深刻的趋势：人机交互的未来，将朝着更高效、更直观、信息流化的方向发展。人类将以一种管理者和策划者的身份，快速地对AI代理提出的想法和工作成果进行审批、反馈和指导。
一个属于AI智能体的新时代
一个由AI智能体深度参与，人类开发者负责审查、规划和创意的“后编码时代”正悄然来临。尽管通往这个未来的道路上还充满挑战，例如如何高效地审查海量AI生成的代码，以及如何构建一个能无缝融合“结对”与“委派”的终极交互界面，但方向已经无比清晰。正如Codex团队所展望的，2025年将是“智能体的元年”，一场由AI驱动的生产力革命，才刚刚拉开序幕。
=附：天空之城全文书面版=
主持人Sonya: 欢迎收听红杉资本《训练数据》播客。今天，我们有幸邀请到来自 OpenAI 的 CodeX 团队的 Hanson Wang 和 Alexander M. Burikos，共同探讨软件开发的未来。CodeX 是 OpenAI 旗下的一系列 AI 编码工具，旨在帮助开发者将任务委托给云端和本地编码代理。与最初于 2021 年开发、用于自动补全代码行的 OpenAI CodeX 不同，CodeX 的最新演进版本能够在后台自主为你完成整个任务。O3 和 CodeX 之间的主要区别在于，尽管 O3 擅长竞技编程，但 CodeX 经过强化学习（RL）调优，擅长日常企业开发任务。亚历山大和汉森分享了更多关于 CodeX 的背景故事，以及从快速自动补全到长期运行的后台代理这一更广泛的范式转变。此外，他们还分享了他们对未来开发者将如何与人工智能交互的惊人愿景，随着同步和异步体验的融合。提示一下，它可能看起来更像抖音，而非你当前的集成开发环境。
主持人Lauren: 感谢各位的加入。很高兴能邀请到你们。
汉森: 很高兴来到这里。
主持人Lauren: 我们很乐意听你们多讲讲你们的工作。请给我们讲讲 CodeX 团队的故事。
汉森: 嗯，是的，我是汉森。我是协助训练 CodeX 1 模型的研究人员之一。
亚历克斯: 我是亚历克斯，产品负责人。
汉森: 对我来说，CodeX 这个名字是对初代 CodeX 模型的绝佳呼应。当它首次问世时，那对我而言就像是一个顿悟时刻，因为我认为 GPT-3 确实很酷，但 CodeX 是我第一次觉得“哇，这真的能做一些改变世界的事情”的时刻。实际上，这也是我进入整个初创企业领域的方式。我最早做的几个演示之一就是使用 CodeX 进行数据分析。我认为这实际上是一个很有趣的故事。我当时在这里，是红杉资本 ARC 项目的一部分。我就是这样认识了劳伦。然后在我们做的演示中，我们实际使用了 OpenAI CodeX 来做数据分析。于是我便开始涉足创业领域。随着时间的推移，GPT 的后续版本相继发布，将人工智能用于智能体用例将是未来的趋势，这一点变得异常清晰。因此，我加入了这家公司，从事智能体编码方面的工作。
亚历克斯: 是的，这是一种典型的 OpenAI 风格，我们喜欢让命名尽可能简单易懂。这是 CodeX，我记得是 2021 年。
主持人Sonya: 是的，这是在 ChatGPT 之前，对吗？没错，是的。
亚历克斯: 所以，它实际上是为 GitHub Copilot 提供支持的模型。而最近，在我们开发这个产品（我们稍后会讨论）的时候，我们觉得，你知道，这是一个非常有趣的品牌，也是一个非常恰当的名字，你知道，Code（代码），CodeX，Code Execution（代码执行）。所以，我们决定某种程度上“复活”这个品牌并继续使用它。
CodeX 是什么：一个全新的编码代理
主持人Sonya: 你说是让它恢复活力。那么，CodeX 是不是沉寂了一段时间，然后你们为了这个代理应用而重新启用它了呢？我们最近没有使用这个品牌。好的，好的，真的很棒。你能简单介绍一下 CodeX，这个代理以及它的功能吗？
汉森: 是的，我认为，基本上 CodeX 是一个编码代理，它拥有自己的容器和自己的终端，类似于完全在云端运行。你给它一个任务，它会以这种“一次性”的方式向你返回一个 PR。实际上，我们在此过程中尝试了许多不同的形式，但最终决定采用这一种。
亚历克斯: 是的，你知道，我们一直在开发许多代理，也一直在开发许多编码产品。基本上，在我们看来，CodeX 就像是一个思想实验，旨在探讨如何与 AI 一起编码，我们为此投入了所有精力，去思考如果 AI 独立于你，在它自己的电脑上工作，那会是怎样的一种体验。因此，你是在向它委派任务，而不是与它结对工作。因此，你知道，在这次 CodeX 发布中，我们真正引以为豪的一些事情，包括思考计算环境，以及我们如何设置它，以便代理能够真正独立工作，同时保持高效。还有创建模型，稍后我会详细谈论，这个模型基本上不仅擅长编写看起来良好或具有功能的代码，而且非常擅长编写对专业软件工程师有用的代码，理想情况下甚至无需触碰他们自己的电脑即可合并。
主持人Lauren: 那么 CodeX 和 CodeX CLI 之间有什么区别呢？
亚历克斯: 是的，我们确实收到了一些关于这方面的问题。我保证这一切会随着时间的推移变得更加清晰明了。因此，对我们而言，CodeX 基本上是我们代理式编码的品牌。我们的愿景是，你知道，我们将拥有这个代理，它主要将在其自己的计算机上工作，但它也应该能够在你使用的任何工具中与你协同，无论你在哪里工作，无论是你的终端、你的集成开发环境 (IDE) 还是你的问题管理工具。所以 CodeX CLI 基本上就是你终端中的 CodeX。所以 CLI 代表的是命令行界面，对吗？那么就像在你的终端里，你可以使用 CodeX。那就像是你的开发环境。那么 CodeX，或者说在 ChatGPT 中的 CodeX，本质上就是 CodeX 在它自己的计算机上运行。目前，这些只是相互独立的事物。顺便一提，我在 OpenAI 工作最喜欢的一点是，我们非常乐意削减范围，并迅速推出产品。但随着时间的推移，我们实际上会把这些事物更紧密地结合起来。所以你真的可以把它看作是，它就像 CodeX，而且，你知道，它可以在 ChatGPT 中，也可以在你的命令行界面（CLI）中。
模型的演进：从竞技编程到专业品味
主持人Lauren: 非常棒。那么，为了让模型不仅仅是编写下一行代码，还能发挥其他作用，你们需要做出哪些不同的调整呢？
汉森: 是的，我认为最有趣的一个进展是，如果你回顾一下，你知道，就像我们推出的第一个推理模型 o1，我们当时强调了它在数学方面以及甚至在编程竞赛中的表现有多出色。就像现在，我以前是一名竞技程序员，而且它在竞技编程方面比我更强。在这方面，它比 OpenAI 的大多数人，几乎所有人都要强。但dinitro 为我们发现的一点是，尽管它在这些编程竞赛中表现出色，但它实际上并不擅长生成可合并的代码。所以我们在博客文章中也强调了这一点，对于像 o3 这样的模型，它生成的代码通常不符合专业软件工程师的品味或风格。因此，我们在训练这个模型上投入了大量精力，主要是让模型与专业软件工程师的品味或偏好保持一致。我想，这需要大量的专业训练。
亚历克斯: 是的，我有一个我很喜欢的、非常产品化的类比，那就是，如果你拿我们的推理模型，它们在编程方面非常出色，确实很擅长编程，但它有点像一个非常早熟的、像竞技程序员一样的大学毕业生，他还没有多年的团队专业软件工程师的工作经验。是的，所以我们从 o3 版本到 Codex 1 版本所做的大量工作，实际上就相当于那些最初几年的工作经验，比如：“嘿，一个好的 PR 描述应该是什么样子？”还有 PR 标题，比如你如何理解代码库的风格，然后确保你的代码也符合相同的风格？你如何能做好测试？你如何展现你的测试成效？诸如此类的事项。
用户的“顿悟时刻”与实战案例
主持人Sonya: 用户在使用 Codex 时，通常会在何时产生顿悟时刻？
汉森: 是的，我认为我们在新用户引导中会做的一件事，就是让用户在代码库中发现并修复一个错误。我认为，这是 Codex 真正大放异彩的领域之一，尤其是在错误修复方面。因为它实际上可以独立尝试，不仅能判断是否存在异常，而且还能进行验证，例如：‘好的，我可以尝试复现一个特定的问题。’因此，我认为，甚至在 Codex 发布之前，我们就遇到了一些错误，当时我们对此感到有些困惑。说实话，有时最简单的做法就是将问题的描述粘贴到 Codex 中。我们惊讶地发现，云端竟能如此频繁地提供可用的修复方案。
亚历克斯: 是的，这里有个趣闻。希望这不会泄露太多，但在凌晨一点，在发布前夜，或者说发布当天凌晨一点钟的时候，我们正在处理一个与动画相关的错误，一个 Lottie 动画的错误。而且你知道，这类事情就是那种，好吧，我想我们可以把它从发布范围中剔除。没有它也能正常发布。但我们真的很想把它加进去，而且我们就是搞不明白如何解决。于是，一位工程师最终描述了这个错误的具体情况，并将其输入到 Codex 中。实际上，对于任何使用 Codex 的人来说，一个有趣的专业提示是，如果遇到一个非常困难的任务，让 Codex 进行多次尝试会很有用。于是，他们把那段描述粘贴进去，并运行了四次。就像是，嘿，有个 bug，我们搞不清楚是怎么回事。而其中三次推出都未能成功。然后，四次中的一次，恰好就是我们凌晨 1 点被卡住数小时的那个 bug 的修复。在发布前。于是，修复成功落地，代码也已部署，动画也赶在发布时上线了。
主持人Sonya: 这太棒了。也许可以多告诉我们一些你们 OpenAI 内部是如何使用它的，比如现在是不是每位工程师、每位研究人员都在他们的工作流程中使用 Codex 了？
亚历克斯: 是的，实际上我能再给你分享一个类似的“魔法时刻”吗？
主持人Sonya: 哦，当然，请务必。
亚历克斯: 所以说，关于 Codex 一个有趣的地方在于，它的形态与人们可能习惯的非常不同，对吗？像许多人们习惯使用的 AI 产品一样，特别是在软件领域，也许 GitHub Copilot 是第一个真正优秀的产品。它们实际上是那种让你在工作中保持顺畅流转，并且能够无缝地与你来回协作的事物。你有点像在结对协作，对吧？并且这是结对协作的各种变体。我们认为这很棒。同样，Codex 命令行接口（CLI）也是一种你可以通过这种方式使用的工具。但对于 Codex，你知道，我们真正想要推动的是你正在“委派”的这种理念。因为在未来，我们设想，你知道，绝大多数的编程工作实际上将独立于人类完成，独立于那些一次只能做一件事、在自己电脑上工作的人。所以，你知道，它基本上将由在自己电脑上工作的“代理”来完成。
因此，将任务委派给一个代理，与在你的工具中与某种 AI 模型进行结对协作，是截然不同的两件事。因此，你必须以一种不同的方式来使用它。所以，当我们实际在发布前开发一个阿尔法版本时，我们会直接把这个代理交给人们，并告诉他们：“嘿，你们想怎么用就怎么用。”我们注意到，许多尝试使用我们的 Codex 阿尔法版的用户，并没有真正觉得它非常有用。于是我们心想：“嗯，这很有趣。”让我们审视一下 OpenAI 的内部人员是如何使用像 Codex 这样的内部工具的。我们意识到存在一个巨大的差异，那就是使用它的思维模式。适用于 Codex 的良好思维模式是一种“富足心态”，即“嘿，什么都尝试一下”。即使是多次，也要尝试任何可能性，看看什么有效，这能节省我的时间。因此，我们已经略微调整了引导用户开始使用产品的方式，以试图创造这种“顿悟时刻”，即并行执行多项任务。所以对我们而言，如果我们看到有人试用它，并且他们在一天或一小时内运行了大约 20 个任务，那真是太棒了。而且，他们基本上已经明白了如何使用这个工具。
人机新分工：从编码到审查
主持人Lauren: 引人入胜。当你必须审查所有这些代码时，这会如何改变人的角色？比如如果三个中有两个能用，那你怎么办？
汉森: 是的，我认为我们也非常注重让输出结果易于人们审查。所以我们引以为豪的一件事是，我们还没在其他很多工具中看到过，那就是模型能够引用自己的工作。所以不只是被更改的文件，甚至还包括终端输出。所以如果它运行了一个测试，而且你知道，比如由于某种原因测试无法运行，它实际上会告诉你，而且会告诉你：“这是我运行的具体终端命令，这是输出结果。”这使得验证输出结果变得容易得多。但这是一个很好的观点。我认为我们正在转向一个世界，在这个世界里，我们通常用于编写代码的大部分时间，将转移到实际审查代码上。
主持人Sonya: 需要人类来审查代码吗？因为我认为代码是那种，要么能编译，要么不能编译的东西。一旦它编译通过，你就可以去检查它是否完成了它应该做的事情。那么，你甚至还需要人类来做代码审查吗？
汉森: 我认为，是的，我的意思是，至少在可预见的未来，我确实认为情况会是这样。我的意思是，我认为其中很大一部分也只是与早期用户建立信任。我认为人们确实需要感受到，哪些地方运行良好，哪些地方不尽如人意。我认为总会有一些外部背景信息，关于是什么让这段代码正确，而这些信息可能超出了你最初提供的背景。
亚历克斯: 是的，如果你想想开发人员所做的事情——这显然是过于简化了——但比如说，首先是想出可能应该做什么，也许与团队讨论，决定要做什么，你会把这称为构思。嗯，然后可能就是设计了，比如，我们到底在做什么？然后就像规划，我们要怎么做？接下来是实施，然后是验证，你知道，测试这些改动。这，你知道，这基本上就是一个循环，而这种实施和测试的小循环正是 CodeX 目前擅长的。尽管我们也可以谈谈如何用它来规划。然后是实际部署代码，以及可能维护代码、编写文档等等。所以，你知道，我忘了具体的数字，但我最近记得的一个统计数据显示，工程师可能只有大约 35% 的时间在编写代码。这实际上甚至不是工程师工作的大部分。
所以，你知道，我们正在努力构建的未来是这样的：无论你是软件开发人员，还是从事任何其他职业，所有那些容易自动化的工作，通常是那种更基础、更繁琐的工作，你都不会亲自去做，而是将其委派出去。而那些更有趣的工作，也许是因为它们含糊不清，也许是因为它们确实非常困难，那才是你主导的工作。所以我们正努力构建那种工作模式、那个世界。我认为我们必须循序渐进地实现它。举例来说，现阶段，如果你是人类并编写代码，另一个人会审查你的代码，对吧？因此，我们不会贸然介入并试图改变这一点。于是我们想，好吧，让我们与此对接。因此，目前这款产品的工作原理是：作为开发者，你通过工具获得效率提升。你请求工具编写一些代码。你决定它是否合格，是否要将其发布给你的团队，然后你的团队可以进行审查。然后随着时间的推移，我们将逐步扩展我们的能力范围。因此，我们将越来越多地协助您进行规划，甚至可能是设计，甚至是在您的应用程序或工作中出现情况时思考应对策略。然后我们会推动让审查变得越来越容易，正如汉森所描述的。
汉森: 是的，我确实认为我看到了一个未来，在那里会有多个智能体协同工作。所以你会有，比如 Codex，Codex 智能体编写代码，然后可能像操作智能体，它是负责测试的，以及所有我们在公司一直在开发的各种不同智能体都可以协同工作。
赋能更多人：软件开发的普及化
主持人Lauren: 太棒了。你有没有看到，现在你可以委托编写代码了，工程团队以外的人也开始使用 Codex？当我们进入“氛围编码”的世界时，你们正在帮助我们在这个方向上走得更远。
亚历克斯: 是的，这实际上非常有趣。我们当时在做... 所以答案是肯定的，但我给你讲个故事。我们当时正和这里的林赛一起撰写我们的发布博客文章。我们当时正在讨论要引用客户的哪些话。我们有一个客户想说，嗯，我们工程团队很喜欢这个。并且它对于产品经理们来说就像一件利器。我记得当时看到那句话时心想，这句话真酷，因为我身在产品团队，我用它来避免为了一些事情去打扰工程师或者去回答问题。但我记得当时看到那句话时心想，我们想把它放在发布博客文章里吗？因为我们正在构建的东西，其目标受众是专业的软件工程师，而不是玩票性质的编程者。所以我想我们最终没有包含那句原话。但dinitro为随着时间的推移，就像，你知道的，当我们有能够帮助我们编写代码的代理时，我会期待越来越多的人能够为代码库贡献力量，是的。
主持人Sonya: 你认为专业软件开发人员的数量会随着时间推移而增加还是减少？
亚历克斯: 这只是我的个人看法，但我认为它会大幅增加。
主持人Sonya: 嗯。
亚历克斯: 我认为……
主持人Sonya: 不是凭感觉编程的人，而是专业的软件开发者。
亚历克斯: 是的，我这么认为。但是，你知道，是的，在我看来，软件越容易编写，我们就能拥有越多的软件。现在，我们可以想象一下，我敢打赌，如果我们拿出手机看一看——嗯，你们各位都是投资者。但如果你不是投资者，我敢打赌，如果你拿出手机，手机上的大多数应用程序都是由大型团队为数百万用户开发的。并且很少有应用程序是专门为我们个人和我们所需要的特定功能而开发的。因此我认为，随着为个人或团队构建定制软件变得越来越可行，我们最终将对软件产生越来越高的需求。
汉森: 是的，当我思考我如何使用它时，我认为它现在确实是一个倍增效应，而不是任何形式的替代。就像，特别是观察我们内部高级用户的使用模式时，存在着巨大的差异：Codex 的顶级用户每天都在完成 10 次以上的 TRs。它确实是一个如此巨大的倍增效应，以至于我无法想象一个……的世界。这就像是极大地降低了软件开发的门槛。
亚历克斯: 话虽如此，我认为这是一个非常重要的问题，而且坦白说，我们也不知道。因此，这是我们公司非常重视的一点。
技术深潜：长时程代理与环境挑战
主持人Sonya: 我想简单谈谈技术层面内部的运作情况。你提到模型本身，使其与竞技编程不同的一点是，你让它更...擅长专业软件开发人员会做的事情。这是模型方面最大的区别吗？还是我们应该将其视为 O3 的近亲？
汉森: 是的，所以它绝对是与 O3 相同的模型，并进行了额外的强化微调。话虽如此，是的，我认为其中一部分就是这些更偏向于定性的方面，即是什么造就了一个优秀的软件工程师，而不仅仅是一个优秀的，比如说，编码员。你知道的，比如代码风格，甚至是它如何编写注释。我认为，这正是人们在其他模型上注意到的一个特点。
除此之外，我还想强调一个重大挑战是为智能体（agent）创建良好的学习环境。那么，如果你考虑一下真实的软件代码库，它们是如此多样且复杂。比如，想想看设置一个代码库需要投入多少开发运维（DevOps）工作。而这正是我们在设置环境时，通过实践痛苦地学到的。但是……我们要不要谈谈我昨天给你看的那个多代码库？
亚历克斯: 哦，对了。我当时在给汉森看 OpenAI 收购的那家初创公司的代码库，我们因此也加入了。于是我们一起查看了那个代码库，考虑将其用作一个环境。汉森就问：“那单元测试在哪里？”要知道，因为智能体是使用单元测试来验证的。我当时就想：“这可是一家真正的初创公司，竟然没有单元测试。”
汉森: 我的意思是，说实话，我也一样。所以我没什么好抱怨的。嗯，所以，你们有所有这些非常混乱的环境。所以我们，嗯，在训练过程中，我们基本上必须生成这些非常真实的环境，供智能体学习。我认为我们之所以能够让这样一个端到端的产品得以运作的原因之一是，我们拥有与训练时使用的相同环境，以及用于生产服务的相同，嗯，基本上就是这个容器化基础设施。所以，嗯，我们的用户是，你知道的，就像我们正在运行我们自己的计算环境一样。当用户使用 Codex 时，他们运行在与我们在训练时使用的完全相同的环境中。
主持人Sonya: 所以你不会听到那个智能体说：“但在我的机器上运行正常。”
汉森: 没错。
亚历克斯: 好的，好的，好的。
主持人Sonya: 我认为这些也是我见过来自 OpenAI 的运行时间最长的智能体，也许之前运行时间最长的是 Deep Research。我的理解是，Codex 有时会在不同的任务上花费 30 分钟。在使推理时间能够支持如此长时间的查询方面，你们遇到过哪些令人惊讶的挑战和问题？
亚历克斯: 也许我先从产品方面谈起，模型方面也有很多，但在产品方面，我实际上思考最多的是用户意图。实际上，如果你想象一下有人在他们的集成开发环境中（IDE）使用自动补全功能，这不一定非常困难。我的意思是，它显然是困难的，但预测他们接下来几微秒内想做什么，这并不算特别难。但是对于一个需要 30 分钟才能完成的任务，帮助用户描述任务内容实际上是相当困难的。比如他们甚至可能不知道 30 分钟工作量具体需要什么。因此，我们花了一段时间讨论，并且仍在讨论的一件事是，用户交给 Codex 的任务，其合适的粒度应该是什么？并且，我们如何才能使其变得容易，让 Codex 能够非常灵活，你可以用它来做单行修改，也可以用它来做你知道自己确切想要什么的大型重构，或者你知道自己想要什么的更大功能。或者，当你不知道自己确切想要什么时，能否使用 Codex？所以，也许你应该让 Codex 提供一个计划，然后你可以让 Codex 建议一些任务，之后再执行这些任务。所以这仍然是一个争论的焦点，对我们来说是一个迭代过程。
汉森: 是的，我认为这实际上对你使用它来说是一个很好的专业技巧。它实际上非常擅长制定自己的计划。然后，你知道，有时预先详细说明所有你想要的东西非常繁琐。而这正是这种工作方式所面临的独特挑战之一。比如，如果你想每次工作一小时，那么你确实需要提前明确很多事情。这意味着你可能需要花 10 到 20 分钟来构思。但是，如果你实际使用“提问模式”来首先生成一个你想要做的事情的概要计划。然后你可以和模型一起对该计划进行迭代，在你将其运行一小时之前。
主持人Sonya: 这真的就像是和一名实习生一起工作。
亚历克斯: 是的。
主持人Sonya: 那么在模型方面呢？当模型开始长时间运行时，它的行为有没有什么令人惊讶的地方？
汉森: 是的，我认为我们的模型在保持任务专注方面已经好多了，尤其是在这种更长时间的运行中。我会说，有些情况下，即使模型的耐心程度很高，它也是有限度的。所以有时会令人沮丧，你知道，就像它会中断大约 30 分钟。然后，你知道，这是一个我们正在努力改进的案例，它会像，你知道，有点像一个人，他会回来告诉你，对不起，我不能，这太多了。我没有足够的时间来做这件事。实际上，它会这样说。这很滑稽。
主持人Lauren: 就像一个实习生。
汉森: 所以在许多方面都非常、非常地像人类。
未来展望：融合的交互与市场演变
主持人Lauren: 是的。我很好奇您是如何看待适当的交互模式，以及它们如何演变，以及围绕此的一系列产品如何随着时间推移而演变。我们有 Codex，我们有 Codex CLI。
亚历克斯: 在工程和产品构建的设计空间中，你认为还有哪些可能性？是的，我们发布的 Codex，你知道，它真的只是一个研究预览版。它是一个思想实验，一个有用的思想实验，但仍处于非常早期的阶段。而我们对 Codex 最引以为傲的，是其模型以及作为计算环境基础的开端。我们发布的用户界面（UI）是我们不断迭代的成果，这其中有一些有趣的故事，但它绝不是最终的形态。对于听众而言，我们发布的用户界面基本上是 Chat GPT 中的一个接口，你可以在其中提交任务，并要求 Codex 回答你的问题或编写代码。然后你会得到一个有点像待办事项列表的东西，列出了你可以查看并考虑合并的内容。实际上，我认为我们构建它的目的，是大力推崇这种“可供你委托的异步代理”的理念。
但我们希望构建的是这样一种设置：你无需思考自己是在委托任务还是与代理协作。它应该就如同与一位队友协作，而这位队友则普遍存在于你使用的所有工具中。因此，你应该能够调出你正在使用的任何工具，无论是你的终端、你的集成开发环境（IDE）、你的问题管理工具，或许还有你的告警工具、你的错误，你知道的，那个显示错误的工具，然后直接寻求帮助。甚至可能在你到达之前，Codex 就已经查看过了。并且它对此已经有了自己的见解。你可以提出问题，无论是简短的问题还是冗长的问题。它会恰当地决定在回答你之前需要花费多少时间。并帮助你顺利地落实这些变更。所以，我们基本上想融合这种“结对”和“委托”的理念。但我们发布的首个成果，只是一个最纯粹的思想实验。
我要补充的另一点是，在 OpenAI 工作的一个独特之处在于，我们是 ChatGPT 的创造者，它就是，你知道的，大多数人都在使用的那种人工智能系统。因此，我们实际上不认为未来会是这样：当你度过一天的时候，你得决定是使用像 Codex 代理，还是，我不知道，像购物代理，或者像打车代理。顺便说一句，我只是在这里随口说一些东西。或者你像是一个营销代理人。实际上，我们认为它应该这样运作：你只需要有一个助手与你对话，你可以向它询问任何事情、任何方面，它就可以为你完成你需要的事情。所以，你知道，那就是 ChatGPT，它将成为我们的助手。然后，如果你是某种工具的高级用户，比如说你是一名软件开发人员，你在某些功能性工具上花费大量时间，那么你可以进入那个工具，拥有一个定制化的界面，其中有按钮、有列表，你可以使用它们来高效地完成你的日常工作。
主持人Sonya: 你认为我们还会使用 IDE 吗？
亚历克斯: 是的，当然会。但它们会演变，对吧？比如现在，它们非常专注于编写代码。而且，正如 Hanson 所说，可能代理会编写越来越多的代码。所以，它会变成，重点会转向提交代码、评审代码或验证代码，甚至可能转向规划更大的项目里程碑。
汉森: 是的，我认为我们团队中很多人已经这样了。他们就像，早上第一件事，来到办公室，泡杯咖啡，然后启动一些任务，只是为了获得一个起点。然后，你知道的，他们早餐后回来，查看生成的任务，或者生成的拉取请求（PRs），然后他们会处理这些。综合开发环境（IDE）有点像你进行工作的地方，你知道，它也许能让你完成 80% 的工作，希望如此，甚至更多。但总是有这“最后一公里”，你需要深入进去，根据你自己的直觉进行精细调整。
主持人Lauren: 你如何看待整个市场的发展？比如在 OpenAI 内部，你们有这么多不同的策略。当你想到异步任务，想到你提到的一些转向 ChatGPT 的事情时，我们看到其他工具和专用模型正在爆发式增长。你显然有偏见，但我很好奇你对整个市场的看法。
亚历克斯: 是的，现在对于开发者来说是一个疯狂的时代。比如说，现在有太多非常有用的新工具了。举个有趣的例子，最近我在飞机上，没有 Wi-Fi，我本来以为我能写些代码，做个东西，结果却没 Wi-Fi。然后我就想，你知道吗，算了吧。根本不值得我再花时间去尝试写代码了。然而，你知道，多年前我参与的那个初创公司，它诞生的部分原因正是我在飞机上，在没有 Wi-Fi 的情况下写了一些代码。而我现在甚至都不会再那么做了，因为市场已经，它真的改变太多了。我认为，我们将在同样的时间内看到一次类似的转变。所以，在接下来的两年里，编码将会看起来完全不同。
我认为目前，人们投入精力最多并从中获得最大价值的工具，都是那些与你紧密协作的工具，比如在你的开发环境中，你知道，就像是结对编程。我认为我们将看到一个转变，但我们必须弄清楚这将如何发生。但我们即将看到的转变是，实际上，大部分代码将由代理（agents）编写，并且这些代理不会在你一次只能做一件事的环境中工作，而是会在它们自己的环境中工作。它们不会仅仅在你想到特定任务时被触发，而是会连接到你使用的工具中，在那里执行工作。因此，我认为我们将基本看到向代理的这种转变。我认为我们将不得不弄清楚很多事情，尤其是关于代码审查的很多事情，正如你所问的。就我个人而言，我并不确切知道那将如何运作，但我确实知道，即使在 OpenAI，我们已经看到更多的代码是由代理合并的，实际上，甚至有更多的代码是由代理生成的，因为人们，比如说，会多次启动任务以选择他们最喜欢的实现方式。因此，目前并不完全清楚我们应该如何管理所有这些正在编写的代码。
不过，我将说几件事，以防对听众有用，那就是你确实可以对你的代码库做一些事情，使其更易于代理处理。这不一定特别新颖，但显然，使用类型化语言非常有帮助。另一件非常有帮助的事情是拥有经过更好测试的更小模块。就像我们开玩笑说的——能有好的测试用例，对。是的，有测试用例。就像我们拿我创业公司的代码仓库开玩笑一样，但我敢打赌，如果现在让我们来写，我们肯定会以不同的方式来写。甚至还有一些小细节，比如这个项目的代号是 WAM。这是 Codex 的代号。它是 W-H-A-M。而且我们给它命名的时候，是深思熟虑的，因为我们知道代码会存在于服务器、网站以及其他各种地方。我们希望代理能够很容易地搜索与 WAM 相关的代码并找到它们。所以我们把项目命名为 WAM，而且我们首先在代码库中用 grep 搜索，以了解这个名称出现的频率。比如，如果我们把它命名为 "code"、"Codex" 或 "agent" 这样的词，你可以想象代理会很难——它会变得非常困惑。
主持人Sonya: 你现在称之为 Codex，所以现在代理会感到困惑。嗯，所以在代码中，这算是我的观点，对吗？
亚历克斯: 就像是刻意设计。就像在代码中，我们大量使用“WAM”这个术语，因为那实际上让代理更容易找到。显然，如果我们不使用这样的词语，代理仍然可以找到路径，但它将不得不花费更多时间来找到正确的文件。
汉森: 是的，这很棒，你知道，很多实际上也让人类更容易理解代码库的事物，也倾向于让代理更容易理解。比如良好的测试，编写好的文档是另一个很好的例子，在这种情况下，我认为现在甚至有更多的动力去做这些，因为它不仅让你的生活更轻松，它也让代理的生活更轻松。
主持人Sonya: 好的，抱歉我像个烦人的风险投资人，但 Claude Code 也像是，我认为其他人提供的代理式编码体验。你认为市场，我很好奇你认为你们的体验今天相比如何？那么你认为市场可能会趋向于相同的愿景吗，关于，你知道，同步和异步编码是什么样子？在那种未来的设想中，你认为 OpenAI 会在哪些方面胜出？
亚历克斯: 我认为我们会看到各种情况并存，不是吗？就像你刚才提到的，有些工具是在你的电脑上运行的。也有工具是在它们自己的电脑上运行的。就像我之前提到的，我认为我们将看到大多数工作由代理在其自己的电脑上完成，但我们仍然需要非常重视投入，以加速那些也在自己电脑上工作的开发者，不是吗？因此理想情况下，我们可以在这方面两全其美，但大多数工作将通过代理计算完成。
汉森: 此外，我认为软件工程中最困难的部分之一确实是获取所有外部环境的上下文，并将其编码到这些需求和设计文档中。而之后的实现阶段，就像我们之前提到的那样，生命周期中用于实际编写代码的时间并没有那么多。因此，我认为 ChatGPT 的优势在于，它是一个助手，它现在具备记忆功能，并且能够通过各种连接器访问你使用的所有不同工具。我们拥有诸如操作员、深度研究等具备所有这些不同能力的功能。因此我认为，当所有这些融合在一起时，其愿景就是像 Codex 这样的工具真正能够大放异彩的地方，一旦它能够获取并利用所有这些知识。而且我认为，有了这些，它应该能够更有效地完成仅限于编码部分的工作。
亚历克斯: 嗯，就好比想象一下，你雇佣了一名软件工程师，而那名软件工程师唯一能做的就是从你那里接收任务并提交一个 PR，对吗？或者，你知道，它拥有这些非常明确的功能，而且它能精确地完成这些事情。然后你提出一个随机的要求，比如，嘿，团队要聚在一起了。比如，你介意也帮忙，嗯，预订一间会议室并主持一次头脑风暴吗？如果你雇佣了一位队友，而他们却拒绝做那种工作，那样会非常令人沮丧，对吗？因此类似地，我认为这确实是，我们正在构建一个未来，在那里，你正在合作的智能体将更加通用化一些。比如，你知道，参照 Hanson 所谈论的，比如说，operator 和 deep research，就好比如果你认为 operator 拥有一个网页浏览器，deep research 拥有另一种类型的网页浏览器，Codex 拥有一个终端，真的，你的队友拥有的工具与人类队友的工具非常相似，就像人类队友一样，对吗？
因此，我们最终的目标是选择我们希望真正投入特定受众的领域，以便取得快速进展。很显然，我们正在通过编码方面来做这件事，借助 Codex 或类似 GPT 4.1 的工具，我们为特定受众生成了专门的评估，然后为他们，也就是为开发者，构建了一个更好的模型。但随着时间的推移，我们将这些东西通用化，成为人人都能使用的简单工具。所以我认为，再次重申，就我们而言，你知道，对于 OpenAI 和类似 Chachapiti 的产品，我觉得我们所构建的产品将会与那些仅专门用于编码的产品大相径庭。
激进的未来 UI：给 AI 代理刷Tiktok
主持人Sonya: 你认为开发者与 Codex 交互的主要用户界面会是什么？你觉得会是 Chachapiti、命令行界面（CLI）、集成开发环境（IDE），还是以上所有呢？
汉森: 是的，我认为是以上所有方式的结合。我想我们只是希望在开发者所处的环境中，在那一刻满足他们的需求。所以它可能甚至不在编辑器或终端中，而是在 Slack 上。比如，有人给你发消息说：“嘿，有 bug 了。”然后你就回复说：“嘿，去修复它。”
亚历克斯: 我来告诉你一个我构想的有趣的未来用户界面，它一点都不严肃。但或许未来与代理人协作的方式，如果你是未来的初创公司创始人，你的团队只有你一个人，或者你和几位联合创始人，以及许多代理人，实际上会像TikTok一样。比如说，你可能有一个垂直信息流，它基本上是代理人制作的视频，你可以观看，其中包含一个想法，比如：“嘿，有客户提出了这个请求，我觉得我们应该修复它。”然后你向右滑动，表示“好的，我们来修复它，我们来做这件事。”你向左滑动，表示“不，我们不应该那样做。”是 Tinder 还是TikTok？抱歉，它是一个混合体，一个混合体。我没说这会很有道理。
主持人Sonya: 我喜欢它。
亚历克斯: 然后你长按以提供反馈。所以你会说：“是的，做吧，但是，你知道，确保字体是斜体的。”基本上，你拥有所有这些智能体，它们订阅了你公司或团队的信息，会主动提出想法、付诸实施，并向你提供更新，而你则有点像是在组织和管理正在进行的工作。
主持人Lauren: 它们还会向你展示世界可能样貌的小型预览。
亚历克斯: 是的，当然这只是个半开玩笑。我认为那将是一种与智能体保持一定距离的合作方式。此外，人们能够亲自去做工作并与智能体配合，这肯定会非常重要。
主持人Sonya: 我知道这是个半开玩笑，但这确实是一个非常酷的画面，因为我认为大家都在概念上同意这个想法，即与智能体协作并审查它们所做的各种变更，这将会与我们今天的编程方式截然不同。但似乎没有人真正给我一个这会是什么样子的画面。所以那是一个非常棒的想法。我很喜欢。太棒了。
快问快答
主持人Sonya: 我们是否以快速问答环节收尾？
亚历克斯: 那就这么办吧。
主持人Sonya: 好的。有什么推荐给人工智能爱好者的内容或读物吗？
亚历克斯: 对我来说，这答案立刻浮现。那就是伊恩·班克斯所著的《文明》系列。你读过吗？是的，它令人惊叹。是啊。它是一个科幻系列，始于二十世纪八十年代创作。它对未来星际航行中类人与非人类种族可能呈现的面貌，持有异常积极乐观的视角。并且有很多疑问，比如当我们拥有通用人工智能（AGI）之后，生命的意义和目的何在？
汉森: 嗯，我觉得对我来说，就像理查德·萨顿的任何作品一样。我想那就像是我对强化学习的入门。我觉得它就像是，这里有个笑话，就是我们每天都在读“痛苦的教训”（The Bitter Lesson）。那有点像 OpenAI 的哲学。就像我觉得，你知道的，即使是 Codex，我们给它一个终端，它真的在使用 POSIX 工具。那就像是与电脑交互最符合“痛苦的教训”理念的方式。
主持人Lauren: 你最喜欢的 AI 应用呢？
汉森: 必须是 ChatGPT。
主持人Lauren: 不是 ChatGPT，拜托。我们真是超级无聊，太无聊了，我是说。好的，要么它可能是你们发布的一个新功能，除了 Codex 之外，或者是 OpenAI 之外的东西。
亚历克斯: 好的，所以我猜我没有，这很有趣。我并没有真的去想 AI 应用，对吧？但我确实喜欢我的生活变得更轻松。所以，你知道，我喜欢的一些事情是当你使用 AI 时，但它有点隐形。所以就像，我做产品，所以我经常提交 bug。Linear 就有一个非常优雅的集成，当你从 Slack 对话中提交一个 bug 时，它就会直接从 Slack 对话中生成这个 bug。但他们从不在任何地方提及 AI。就好像你甚至没有注意到它正在使用 AI。哦等等，我想到了一个我最喜欢的 AI 应用的答案，Waymo。啊，是的。
汉森: 嗯，我的意思是，对我来说，Copilot 绝对是那个每天都持续为我带来价值的东西。
主持人Sonya: 好的，机器人技术，看涨还是看跌？
汉森: 看涨？是的。
主持人Lauren: 你认为哪种新的应用或应用类别会在 2025 年爆发？除了编程之外？
汉森: 嗯，我的意思是，我觉得当你请到 Yusa 和 Josh 的时候，答案其实是一样的，但 2025 年绝对是代理（Agent）的元年。我想我们会看到代理（Agent）在许多不同的类别中兴起。是的，我不得不认同这一点。
主持人Sonya: 哪种类型的智能体最让你感到兴奋？
汉森: 除了编程智能体之外吗？这是个好问题。
亚历克斯: 嗯，我的意思是，我的看法是，你知道，如果我们——我知道这本来是快速问答，对吧，但我们看待智能体的方式是，你拥有推理模型，对吗？然后你给予这些推理模型访问行业工具的权限。然后你想办法训练那个智能体去执行某种特定功能，对吗？所以它不仅仅是关于写作，而是关于新闻业；或者不仅仅是关于编码，而是关于软件工程，对吗？所以这有点像我们正在做的事情。在我看来，我今年对智能体如此兴奋的原因是，我们现在已经有几款由 OpenAI 发布的智能体，其他公司也正在发布智能体，所以我们开始看到智能体的大致形态，并开始识别出其基本要素。因此，我特别兴奋的是，当我们将其整合起来，并提出一个智能体时，你无需为每个单独的功能分别配置它，而它是一个带有计算机、拥有浏览器和终端的智能体，并且它能做多件事情，而你无需明确指定，比如“你就是我的编程智能体”之类的。
主持人Sonya: 非常棒。非常感谢您的加入。祝贺您在 Codex 所取得的成就，并感谢您向我们预告了您认为编程市场将如何演变，此外，也让我们一窥了长期运行的、异步的、智能体驱动的体验将如何呈现。非常感谢。谢谢。
亚历克斯: 感谢邀请我们。
主持人Sonya: 谢谢。
