AI 如何自主编码、测试、优化？从独立思考、到访问终端、最后改写未来！
代码世界的下一个浪潮将由谁掀起？当 AI 不再仅仅是辅助工具，而是化身为能够独立思考、访问终端、甚至拥有“专属电脑”的智能体软件工程师，软件开发的未来图景正被彻底改写。从去年最早的 Devin 号称“首个 AI 程序员”，GitHub Copilot 逐渐成为全球程序员的主流工具，今年 Cursor 的爆火，再到前几日 OpenAI 发布 Coding Agent 产品 Codex，这些幻想正在逐渐变为现实。
今日分享一篇知名 AI 工程师播客 Latent Space 的最新深度访谈，主持人邀请到了 Codex 团队的核心成员 Josh Ma 与 Alexander Embiricos。
他们分享了 Codex 项目的缘起——从赋予模型访问终端权限带来的“AGI 曙光乍现”时刻，到构建“智能体软件工程师”的宏伟蓝图。这场对话不仅揭示了 Codex 背后的技术思考与产品哲学，更探讨了人与 AI 结对编程的全新范式，以及开发者如何在这个智能时代乘风破浪。
-
AI 正从辅助工具进化为能独立思考、访问终端、拥有“专属电脑”的智能体软件工程师，彻底改写软件开发未来。
-
赋予 AI 模型访问终端的权限，是 OpenAI 团队初见“AGI 曙光乍现”的关键时刻，催生了为智能体配备专属计算机的构想。
-
OpenAI 核心成员预测，未来两年内有望打造出能独立完成软件工程工作的“智能体软件工程师”。
-
Codex 不仅是编码模型，更是擅长独立完成软件工程工作、能长时间自主工作的智能体，追求“一次性搞定”复杂任务。
-
在 AI 时代，模型本身就是产品核心。未来模型将承担更多决策，人类开发者则更聚焦于 AI 尚不擅长的架构设计与创新性工作。
以下为本次访谈的精彩内容：
主持人：今天的节目嘉宾是来自 ChatGPT Codex 团队的 Josh Ma 与 Alexander Embiricos，我们和 Alexander 算是新相识，他一直在主导 Codex 的许多测试和演示工作。
Alexander：大家好，我是 Alexander，来自 OpenAI 的 ChatGPT Codex 产品团队。
主持人：我们就默认读者都看过 Codex 的发布直播了。你们当天还发了一篇博客，里面有不少测试演示视频，非常有意思。我注意到演示视频里，工程师们都是单打独斗，形单影只，然后就对着他们的 AI 伙伴自言自语，一起写代码。我不知道这是不是你们想营造的氛围，但给我的感觉就是这样。
Alexander：说得在理。那些视频，我们追求的是极致的真实感，就是工程师本人讲述 AI 如何助其一臂之力。这个反馈我收下了。
主持人：不过，这倒是实话。有时候，值夜班很孤独，移动端开发也挺寂寞的，毕竟这类岗位人不多。所以，完全理解。话说回来，你们各位具体都做了些什么呢？或许我们可以从这里开始。你们是怎么被拉进这个项目的？后续又有哪些进展？
“人与 AI 结对编程，赋予模型访问终端的巨大价值”
Alexander：或许我先说吧，因为我们俩如何开始合作的，还有个挺有意思的故事。在加入 OpenAI 之前，我做了一款叫 Malti 的 macOS 原生软件，专注于人与人之间的协作，算是一种结对编程工具。后来 ChatGPT 之类的东西火了，我们就开始琢磨，如果不再是人与人结对编程，而是人与 AI 结对编程，会怎么样呢？
所以，中间的曲折我就不细说了，总之就是这么一段历程，然后我们都加入了 OpenAI。我之前主要做桌面软件。后来我们推出了推理模型。我相信你们在理解推理模型价值方面肯定遥遥领先，但对我而言，它一开始只是个更强大的聊天工具，可一旦你能给它工具，它就能真正化身为一个“智能体”（agent）。所谓智能体，就是一个配备了工具、拥有环境和安全边界，并且可能针对特定任务进行过训练的推理模型。
总之，我们对此产生了浓厚的兴趣，并开始思考如何将推理模型引入桌面端。与此同时，OpenAI 内部也在进行大量实验，尝试赋予这些推理模型访问终端的权限。需要澄清的是，我并没有参与最初的那些实验，但那些实验确实是我第一次真正感受到“AGI 曙光乍现”的时刻。那次经历发生在我与一位名叫 David K 的设计师交谈时，他当时在做一个叫 Scientist 的项目。他向我展示了一个它能自我更新的演示。放到现在，修改个背景颜色可能已经惊艳不到我们任何人了。
主持人：是指修改它自己的代码吗？
Alexander：是的。而且，他们当时还设置了热重载。我那时简直惊呆了。时至今日，那依然是个超酷的演示。我们当时尝试了很多类似的东西，我后来加入了其中一个正在捣鼓这个方向的小组。我们意识到，弄清楚如何赋予推理模型访问终端的能力，价值巨大。然后，我们就必须解决如何将其打造成有用的产品，以及如何确保其安全性的问题，对吧？你总不能让它在你的本地文件系统里为所欲为，但人们最初确实是这么尝试使用的。
这些经验很多最终演变成了最近发布的 Codex CLI。其中，我最引以为傲的思考是实现了诸如全自动模式之类的功能，并且在这种模式下，我们实际上增强了沙箱隔离，以确保用户安全。
我们当时就在做这类事情，然后开始意识到，我们希望模型能有更长的“思考”时间，希望模型更大，希望模型能在无需任何审批的情况下安全地做更多事情。于是我们想，或许我们应该给模型一台它自己的电脑，给这个智能体一台专属电脑。与此同时，我们也在尝试将 CLI 放入我们的持续集成（CI）流程中，让它自动修复测试。我们还搞了个异想天开的破解方法，让它能自动修复我们问题跟踪器 Linear 上的工单。就这样，我们最终创建了这个名为 Codex 的项目，它的核心理念就是赋予智能体访问计算机的能力。哎呀，我意识到我可能没回答你问的我个人具体做了什么，但无论如何，故事我是讲完了，希望没关系。
主持人：你已经巧妙地把个人经历融入到宏大叙事中了，我相信 Josh 还有后续要补充。
“两年内打造出智能体软件工程师！”
Josh：我的故事有些不同。我来 OpenAI 两个月了，这是我人生中最有趣也最兵荒马乱的两个月。不过，或许我该从几年前我创立的一家叫 Airplane 的公司说起。我们当时在构建一个内部工具平台，初衷是让开发者能够非常轻松地构建内部工具，并且真正深入开发者需求。这听起来可能与现在做的没什么关联，但很多方面，类似的主题又浮现了：本地开发的最佳形态是什么？如何将工具部署到云端？如何在云端运行代码？如何将存储、计算和用户界面这些基础模块组合起来，让开发者能极速构建软件？
我常开玩笑说我们只是早了两年。项目快结束时，我们开始尝试 GPT-3.5，想把它做得更酷。我们当时已经能很快地搭建一个 React 视图了。我想如果我们继续做下去，或许它就会演变成今天你看到的那些 AI 构建工具。但那家公司最终被 Airtable 收购了，我在那里负责过一些 AI 工程团队。
就我个人而言，今年年初，我目睹了我们在智能体式软件开发方面取得的进展。对我来说，那有点像我自己的“登月时刻”，我预感到这件大事即将发生。无论我是否参与其中，未来两年内，我认为我们将打造出一个智能体软件工程师。于是，我找到了我在 OpenAI 的朋友，问他：“嘿，你们是不是在做类似的东西？”他瞪大了眼睛看着我，说：“我什么都不能告诉你，但或许你可以和团队聊聊。”
所以，非常幸运的是，当时 Alex 和 Foster 正好在启动相关项目。我记得在面试时，我们就针对产品形态展开了激辩，对吧？它应该是命令行工具（CLI）吗？这种形态的问题在于，等待它完成任务时无法时常打断，而且你可能想同时运行四次、十次。或许就在那时我说，也许两者兼备才好。我们现在也正朝着这个方向努力。总而言之，我当时非常激动，现在依然如此，致力于推动这个项目前进。我认为 Codex 还处于非常初级的阶段。很高兴能与世界分享它，但还有很多工作要做。
Alexander：我们第一次见面那场对话非常有趣。他一进来——我以前从未遇到过这种情况——就说：“世界正在发生这样的变革，因此我想打造这样的产品。我知道你不能确认你们是否在做这个，但这是我唯一想做的事情。”然后我问了几个开放式问题，我们立刻就切入了一些关于工具形态的核心争论点。我心想，太棒了，我们必须一起共事。
主持人：我想，开发者工具圈的人，彼此之间总能一眼认出同道中人。
说句题外话，苹果早期的 iPhone 团队也是这样，因为团队成员之间都不知道对方是否在同一个项目组，他们不被允许互相透露。所以他们只能靠“三角定位法”来判断。
产品形态大讨论：CLI 还是云端？
主持人：谈到产品形态，你们提到了已经发布的 CLI，我想市面上还有其他一些云端代码工具，比如 Aider 等等。大家是否应该把 ChatGPT 中的 Codex 看作是一个托管版的 Codex CLI？两者之间有显著的区别吗？我们来聊聊这个。
Alexander：你来吧。
Josh：我觉得，简单来说，它就是允许你在 OpenAI 的云端运行 Codex 智能体。但我认为，产品形态远不止是计算机在哪里运行那么简单。它关乎如何与用户界面结合，如何随时间扩展，如何管理缓存和权限，以及如何实现协作。所以，不知道你是否同意，但我认为产品形态才是核心。
Alexander：老实说，这是一段非常有趣的旅程。前几天，也可能是昨晚吧，Josh 因为要做直播所以睡了，我不用。总之，我们几个人回顾了当初规划要发布什么功能的文档，结果发现我们的项目范围不知不觉扩大了不少。但实际上，所有这些范围的增加都是顺理成章的，因为我们越来越深入地认同这样一个理念：这不仅仅是一个擅长编码的模型，更是一个擅长独立完成软件工程工作的智能体。我们越是深入这个理念，事情就越发显得与众不同。
所以，我们可以先把 Josh 负责的整个计算平台这个话题暂放一边。单说模型本身，我们不只希望它擅长写代码，也不只希望它能解决 SWeBench 上的任务。SWeBench，给不了解的朋友解释一下，是一个评估基准，它有特定的方式来对输出结果进行功能性评分。但如果你去看很多通过 SWeBench 测试的智能体输出，它们其实并不是你会合并到代码库的 PR（Pull Request），因为代码风格可能迥异。它能用，但风格不对。
因此，我们花了大量时间确保我们的模型非常擅长遵循指令，非常擅长推断代码风格，这样你就无需明确告知它。但即便如此，假设你拿到了一个代码风格良好、也很好地遵循了你指令的 PR，如果模型给出的关于它如何构建的描述冗长无比，这个 PR 可能依然很难合并。而且你很可能需要把它拉到本地电脑上测试更改，验证其有效性。如果你只运行一个更改，这或许还能接受，但在我们设想的未来世界里，大部分代码实际上可能都由我们委托的智能体并行完成任务，那么，作为人类开发者，能否轻松集成这些更改就变得至关重要。
举个例子，我们开始训练的另一项内容是 PR 描述。我们要真正把“写出好的、简洁的、能突出重点的 PR 描述”这件事做到极致。所以，我们的模型实际上会写出漂亮简短的 PR 描述，PR 标题也会符合你代码仓库的格式。如果你愿意，我们还提供了 agents.md 文件，让你可以更细致地引导它。然后在 PR 描述中，它还会引用它在过程中找到的相关代码，或者其 PR 中的相关代码，这样你鼠标悬停就能看到。
或许我最喜欢的功能是我们处理测试的方式。模型会尝试测试它的更改，然后会用一种非常友好的方式，就像打勾一样，告诉你这些测试是否通过。同样，如果测试通过，它会引用日志中确定的参考信息，让你能看到并确信：“好的，我知道这个测试通过了。”如果测试失败，它会说：“嘿，这个没成功。我觉得你可能需要安装 pnpm 之类的”，然后你可以查看日志，找出问题所在。这些就是我们一直在努力的方向，基本上就是在云端构建这个软件工程师智能体——哎呀，我好像忘了最初的问题是什么了，但这些就是我们一直在深入钻研的东西。
Josh：我也觉得感觉非常不一样。你可以只看功能，但我认为，对我而言，那种感觉是，你得有“信仰之跃”。头几次用的时候，你会想：“我真不确定这玩意儿行不行。”然后它就跑了三十分钟。但当它带着结果回来时，你会惊叹：“哇，这个智能体居然出去了，写了一堆代码，还写了脚本来辅助代码修改它自己的改动，测试了这些，并且真正完整地思考了它想要做的变更。”一开始我完全不相信它能成功。但用过几次之后，你会觉得：“哇，它居然真的搞定了！”那种长时间独立工作的能力，很难用语言概括，你必须亲自试试。但最终，它给人的感觉截然不同，非常特别。
主持人：我用过了。几分钟前我刚给它提了个 PR。我很幸运，是首批 25% 拿到内测资格的用户之一。非常好用。不过它走了个捷径，因为它搞不定怎么在 Rails 环境下运行 RSpec，所以它就只检查了 Ruby 文件的语法，然后说：“我看挺好。”但我估计它还没用上 agents.md。等我把那个配置好，应该就没问题了。
从 agents.md 到“有意识的命名”
主持人：如果你能列举一些最佳实践，那就太好了。我从直播中注意到，他们提到专业用户会安装代码检查工具（linters）和格式化工具（formatters），这样智能体在开发环中就能利用这些验证器。事实证明，这些也是开发者的最佳实践，但现在智能体可以自动使用它们了。提交钩子（commit hooks）对人类来说一直是个棘手的问题，因为我待过的团队里，有的坚持所有东西都必须有提交钩子，也有的团队觉得这玩意儿碍事，干脆全删了。但实际上，对于智能体来说，提交钩子非常好用。
Josh：你把我接下来要说的话都说了。我想说的三点是：第一，agents.md。我们投入了大量精力确保智能体能理解这种指令层级结构。你可以把它们放在子目录里，它能明白哪些指令有更高的优先级。而且，我们现在也开始用 GPT-3 和 GPT-4 来为我们编写 agents.md 文件了。
主持人：我喜欢这些技巧。你们实际上把这里的提示描述开源了。
Josh：是的。
主持人：有什么值得强调的吗？
Josh：我觉得可以从简单入手，别一开始就搞得太复杂。一个简单的 agents.md 文件就能带来很大帮助，远胜于没有。然后就是在使用过程中慢慢学习。我们真正希望的是，未来能根据你创建的 PR 和你给出的反馈，自动为你生成这个文件，但我们还是决定早点发布，而不是追求完美。
主持人：你提到你们也用 GPT-3、GPT-4 来编写 agents.md。
Josh：我会把整个目录都给它，然后说：“嘿，生成一个 agents.md。”实际上，这些天我都是用 Code One 来做这件事，哦抱歉，是 Codex One，因为它能遍历你的目录树并生成这些文件。所以，我建议逐步、渐进地投入到 agents.md 的建设中。然后，就像你说的，配置好最基础的代码检查和格式化工具。这其实能带来相当大的收益，因为这和你用 VS Code 打开一个新项目时，能获得一些开箱即用的检查功能类似。智能体一开始，如果比作人类的话，就像是缺少了这种优势。所以，这样做就是为了把这种优势还给智能体。你还有别的补充吗？
Alexander：关于这点我有个类比，然后我还想谈谈根据我们使用其他编码智能体，甚至是任何编码智能体的经验，如何为此做好准备。我喜欢的那个类比是：如果你从一个基础的推理模型开始，你得到的基本上是一个非常早慧、聪明绝顶、知识渊博，但又有点古灵精怪、天赋异禀的大学毕业生。我们都知道，如果你雇佣这样的人，让他们独立完成软件工程工作，他们会有很多实践方面的东西不懂。
所以，我们用 Codex One 做的很多事情，基本上就是赋予它最初几年的工作经验。这实际上就是训练的意义所在，让它能更懂行。你想想看，写一份好的 PR 描述就是一个典型的例子，甚至可能包括知道什么不该写进去。
然后，你就得到了这个：一个知识渊博得有些诡异、天赋异禀但又有点怪咖、同时拥有几年工作经验的大学毕业生。接着，每次你启动一个任务，都像是它在你公司的第一天。所以，agents.md 基本上就是一种让你压缩它必须进行的“入职探索”时间的方法，让它能了解更多。正如 Josh所说，我们当然希望——目前它还是研究预览版，所以你得自己更新——但我们有很多关于如何实现自动化的想法。这只是个有趣的类比。
Josh：或许我最后要说的一点是，让你的代码库易于被发现。这相当于为新员工维护良好的工程实践，让他们能更快地理解你的代码库。我的很多提示都是以“我正在这个子目录下工作，我想完成这个，能帮我做一下吗？”这样的方式开始的。所以，给出这种指导和范围限定很有帮助。
Alexander：我通常会给出三点建议。首先，语言选择。前几天我和一个朋友聊天，他算是 AI 领域的后来者，他说：“我想尝试做一个智能体产品，我应该用 JavaScript 吗？”我回答说：“你还在用 JavaScript？难怪了。至少用 TypeScript 吧，给它点类型信息。”所以，我觉得这是最基本的一点。我相信现在听我们播客的各位应该不需要我再强调这个了。
另一点是，让你的代码模块化。代码越模块化、越容易测试，效果就越好。你甚至不需要自己写测试，智能体可以写，但你得把架构设计得模块化。我最近看到这里有个人做的一个演示，他基本上——他不是那种凭感觉写代码的，而是专业的软件工程师——但他在用 Codex 这样的工具构建一个新系统。他从零开始构建这个系统，有一张图表显示了他的代码提交速度。然后他的系统有了一定的用户量，于是就到了“现在我们要把它移植到 ChatGPT 那个庞大的单体代码库里”的阶段，那个代码库经历了疯狂的超高速增长，所以可能在架构规划上不是那么尽善尽美。结果，同样一个工程师，用着同样的工具，甚至 AI 工具还在不断进步，他的代码提交速率却直线下降。
所以，我认为另一点就是，架构，好的架构比以往任何时候都更加重要。而且有趣的是，目前这还是人类真正擅长的事情。所以，这对软件工程师做好本职工作来说，挺好也挺重要的。
主持人：千万别看我的代码库。
Alexander：那我的代码库就更不能看了。但最后一点是个有趣的故事：我们项目的内部代号是 Wham，WHAM。我们选它的时候，我和我们的研究负责人一起，他说：“嘿，选代号之前，记得先在代码库里搜一下（grep）。”于是，我们搜索了代码库，“Wham”这个字符串只出现在少数几个更长的字符串里，从来没有单独作为字符串出现过。这意味着，我们写提示的时候可以非常高效，可以直接说“在 Wham 里”。然后，无论是我们 Web 代码库、服务器代码库、共享类型还是其他任何地方的 Wham 代码，智能体都能高效找到。反过来，如果我们当初把产品命名为 ChatGPT Code——不是说没考虑过啊——那智能体就很难搞清楚我们想让它去哪里找了，我们可能就得提供更多相对文件夹路径。所以，当你开始前瞻性地思考：我将来会有一个智能体，它会用终端来搜索，那么你就可以开始有意识地命名了。
主持人：你们会开始为了方便智能体理解而牺牲一些人类可读性来命名吗？在你看来，这其中的权衡是什么？
Josh：这很有意思，因为我刚加入 OpenAI 时，确实带着一些先入为主的看法，但我现在认为，这两个系统（人类可读性与智能体可读性）实际上是高度趋同的。也许是因为只要你看到人类和 AI 都在编写它。或许在某个只有 AI 维护代码库的世界里，假设会改变。但一旦你不得不打破那“第四堵墙”，让人类介入进行代码审查、部署代码，你就需要代码处处都带有人类的印记。所以，人类如何向 AI传达要在哪里修改，如何传达需要修复的 bug，或者如何传达业务需求，所有这些都不会立刻消失。因此，我认为整个系统实际上仍然非常“人性化”。我知道或许可以说一些更酷的答案，比如它像个外星生物，完全不同，但我认为这些东西始于大型语言模型，其根基深植于人类的交流方式。
Alexander：顺便说一句，如果你们想转换话题，尽管打断我们，因为我意识到我们俩自顾自聊开了。
agents.md vs. readme.md
主持人：不，我觉得这也和 agents.md 有关。为什么叫 agents.md 而不是 readme.md？我想在你们看来，智能体和人类消费信息的方式存在某些根本性的差异。所以我很好奇，你们认为这种差异是在类命名层面，还是仅仅在指令层面，或者说，界限在哪里？
Josh：你说吧。
Alexander：这个命名，我们考虑过几个选项。你可以用 readme.md，也可以用 contributors.md。你还可以用 Codex agent.md，然后可能再来个 Codex CLI.md，作为两个带品牌标识的独立文件。
主持人：还有像 cursor.rules，Witserf rules，每家都有自己的规则文件。
Alexander：然后你还可以选择 agents.md。这里有几个权衡点。我想一个是开放性，另一个大概是特异性。所以我们考虑的是，嗯，可能有些东西你想告诉智能体，但不需要告诉贡献者。同样，有些东西你想告诉贡献者，以便真正帮助他们在你的代码库中进行设置等等，这些则不需要告诉智能体，智能体自己就能搞定。所以我们想，这两者可能会有所不同，而且智能体反正也会读取你的 readme，那么 agents.md 可能就用来存放那些你需要告诉智能体、但它无法从 readme 中自动获取的信息。于是我们就做了这个决定。
然后我们又考虑，智能体有不同的形态。我们正在构建和发布的这个东西，最特别之处在于它提供了一种开箱即用的方式来使用云端智能体，这种智能体可以并行处理许多任务，可以进行长时间思考，并且可以安全地使用大量工具。于是我们想，那么，你想给这种智能体下达的指令集，与你在本地计算机上更具协作性地使用的智能体所需的指令集，两者之间到底有多大区别呢？老实说，我们对此进行了相当多的讨论。最终我们得出结论，这些指令集之间的差异其实并没有大到需要为这个文件设定命名空间的程度。如果确实有什么需要区分命名空间，你大概可以直接在文件里用自然语言说明。
最后我们考虑的是，我们认为你需要给我们的智能体下达的指令，与你可能给运行在不同模型上或由不同公司构建的智能体下达的指令，两者之间的差异有多大？我们只是觉得，如果你必须创建所有这些不同的智能体文件什么的，那体验会很糟糕。这也是为什么我们把 Codex CLI 开源的部分原因；很多问题，比如如何安全部署这些东西所涉及的安全问题，都需要解决，而且不应该让每个人都重复造轮子。所以，这就是我们选择一个不带品牌名称的原因。
Josh：我有一个具体的例子来说明为什么 readme 和 agent.md 是不同的。对于智能体，我认为你其实不必告诉它代码风格。它会查看你的代码库，然后写出与之风格一致的代码。而人类开发者则不会花时间去通读代码库并遵循所有约定。这只是一个例子；归根结底，这两种“开发者”处理问题的方式是有区别的。
模型即产品？
主持人：我觉得这些建议非常棒。你们刚才说的内容，简直就是我们这期播客的标题了。我们就叫它“使用 ChatGPT Codex 的最佳实践”，我想大家肯定都想知道最佳实践是什么。
我注意到一个很有意思的现象。在构建智能体方面，似乎总有两种思路。一种是试图更强地控制，让它更具确定性。另一种则是尝试直接给提示，然后信任模型。我觉得你们的方法非常倾向于“提示并信任模型”。我看到在 agents.md 的系统提示里，你们只是提示它按照你们期望的方式行事，然后就指望模型能那样做。当然，你们能控制模型，所以如果它表现不好，你们可以训练它。但有一点让我疑惑的是，你们如何把所有东西都放进上下文里？如果我的 agents.md 文件超级长怎么办？在你们的直播演示中，你们是在 OpenAI 的那个巨大的单一代码库（monorepo）上进行的。那么，你们是如何管理缓存、上下文窗口这些东西的呢？
Josh：如果我现在告诉你，所有东西都还能塞进上下文窗口，你信吗？
主持人：OpenAI 的代码库可不行吧。
Josh：不，是智能体需要的所有东西。
主持人：哦，明白了。所以你们会精简 agents.md，然后把它放在最前面？就像另一个系统提示一样。
Josh：不，它是一个文件，智能体知道如何去搜索（grep）、查找并读入上下文，因为可能会有多个这样的文件。你其实可以在工作日志里看到，它会非常积极地寻找 agents.md。它是被训练成这样做的。
我要说的是，加入 OpenAI 之后，我发现当你在思考模型的未来走向以及几年后 AI 产品会是什么样子时，你会用一种不同的方式来设计产品，这真的很有意思。在加入 OpenAI 之前，尤其是当你没有研究团队和大量 GPU 资源的时候，你会构建这些确定性的程序，围绕它的运作方式搭建很多脚手架。但你并没有真正让模型发挥其全部潜能。
我刚加入时有个有趣的现象，我经常受到质疑：“嘿，我们为什么不直接把这个硬编码进去？听着，你老是用错这个工具，我们就在提示里说‘别那么做’不就行了。”然后研究员们会说：“不不不，我们不那么做。我们要用正确的方式来做。我们要教会模型为什么这样做才是对的。”我觉得这与一个更宏观的思考有关，那就是：你应该在哪里设置确定性的“护栏”，又在哪里真正让模型去“思考”。
关于规划阶段也是类似的讨论。我们是否应该设置一个明确的规划阶段，比如让它“先大声思考，写下你要做什么，然后再去做”？当然可以，但如果任务很简单呢？你真的希望它一直思考吗？如果它在执行过程中需要重新规划呢？你是否要为此设置各种 if-else 条件和启发式规则？还是说，你应该训练一个非常优秀的模型，让它知道如何在这些思考模式之间切换？所以，这很难。我确实也曾主张在下一次训练完成之前，设置一些小小的“护栏”。但我认为，我们真正为之构建的是一个未来——在这个未来里，模型能够做出所有这些决策。真正重要的是，你为它提供了正确的工具：管理上下文、管理记忆、探索代码库的方法。这些仍然非常重要。
Alexander：是的，说得太好了。我觉得在这里做产品非常有趣，也很不一样。模型并非产品的全部，但模型就是产品本身。你多少需要带着一种谦逊的态度去思考：这里有三方，有用户，有开发者，或许还有模型。哪些事情是用户一开始就需要决定的？然后，哪些事情是我们开发者能比模型做出更好决定的？再然后，哪些事情是模型本身能做出最佳决定的？每一个决策都必须归于这三者之一。
并非所有事情都由模型决定。例如，我们目前在用户界面上有两个按钮：“提问”和“编码”。这两个功能或许可以内联到模型做出的决策中。但目前来看，一开始就给用户选择权是非常合理的，因为我们会根据用户按下的按钮，首先为模型启动一个不同的容器。所以，如果你要求编码，我们会把所有依赖项都放进去——我这里简化了说法。但如果你不要求编码，只是提问，我们会在模型获得任何选择权之前，进行一个快得多的容器设置。所以，这或许是一个用户决策。
在某些方面，用户和开发者的决策会在环境层面交汇。但最终，我看到的很多智能体都令人印象深刻，但其令人印象深刻的部分原因在于，是一群开发者围绕着一系列简短的模型调用，构建了一个非常定制化的状态机。这样一来，模型能够解决的问题复杂度的上限，实际上就受限于开发者大脑能容纳的程度。而我们希望，随着时间的推移，这些模型能够独立解决越来越复杂的单个任务，应对越来越复杂的问题。最终，你甚至可以想象一个由智能体组成的团队协同工作，或许还有一个智能体来管理这些智能体。那样的话，复杂度就会爆炸式增长。
所以，我们真心希望将尽可能多的复杂性，尽可能多的状态机，都推给模型去处理。于是，你就得到了这两种构建模式。一方面，你在构建产品用户界面和规则。另一方面，你仍然需要做工作来让模型学习某些东西，但你需要做的是弄清楚，这个模型在训练过程中需要看到哪些正确的东西才能学会。所以，要实现这种改变，仍然需要大量的人力投入，但这是一种截然不同的思考方式：我们要让模型看到这个。
“编码” vs “提问”
主持人：但是你们如何构建产品来获取这些信号呢？如果想想“编码”和“提问”这两个按钮，这几乎是让用户在某种程度上标记提示——因为他们说“提问”，这就是一个提问提示；说“编码”，这就是一个编码提示。在你们构建这个产品的过程中，还有其他什么有趣的产品设计，是基于“我们认为模型可以学习这个，但我们没有数据，所以我们这样设计 Codex 来帮助我们收集数据”这种思路的吗？
Josh：文件上下文和范围限定，我们目前还没有很好的内置功能，但这是我们显然需要添加的功能之一。这也是这类情况的另一个例子。你可能会，我们通常会惊喜地发现，“哦，它居然找到了我正在想的那个确切文件”，但这需要一些时间。所以很多时候，你会通过直接说“嘿，我正在这个目录里找，你能帮我找点东西吗？”来缩短一连串的思考过程。所以我认为，在拥有更好的架构化索引和搜索能力之前，这种情况可能会持续一段时间。
主持人：好的，酷。关于 Codex 本身，我们还有几个事实性问题需要收尾，然后我们想深入探讨一下计算平台方面的事情，我想 Josh 你更想多谈谈这个。我注意到细节里提到，任务时长在 1 到 30 分钟之间。这是一个硬性限制吗？你们有没有遇到过任务时长更久的情况？对任务时长有什么评论吗？
Josh：我在来之前刚查过代码库。其他人也有类似的问题。我们目前的硬性上限是一小时。不过，别太当真，这个随时可能调整。我见过最长的是两小时，那是在开发模式下，模型完全失控了。所以，我认为 30 分钟对于我们试图解决的这类任务来说，是一个合理的范围。这些都是硬骨头任务，需要大量的迭代和测试，模型需要这段时间来思考。
Alexander：我们的平均时长远低于 30 分钟，但如果你给它一个艰巨的任务，确实会耗到 30 分钟。
主持人：我觉得这里有几个可以类比的。一是 Operator 团队跑过一个基准测试，他们不得不把上限设在两小时。另一个是 Metr 那篇论文，不知道流传开没有，他们估计目前平均的自主运行时间大概是一小时，而且可能每七个月翻一番。所以一小时听起来差不多，但那也是中位数，所以肯定会有一些任务超过这个时间。
Alexander：完全正确。
主持人：SWeBench 验证过的例子里，有 23 个无法运行，这和时长限制有关吗？还是其他原因？
Alexander：老实说，我不太确定，但我感觉 SWeBench 的一些案例本身，说它们无效可能有点过，但我觉得它们在运行时确实存在一些问题，所以就是跑不起来。
主持人：好的。那么最大并发数呢？有并发限制吗？如果我同时运行 5 个、10 个、100 个 Codex 实例呢？
Alexander：5 个、10 个完全没问题。实际上我们感觉确实为了防止滥用而设置了一个上限。具体是多少，我不清楚。
Josh：我印象中目前是每小时 60 个。
主持人：每分钟一个。
Josh：但是，听着，这正是关键所在。长远来看，我们其实不希望你费心去想你是在委派任务给 AI 还是在与 AI 协作。想象一下一个 AGI 超级助手，你只管提问，只管和它说话，它就能把事情搞定。需要快速回答时它就快，需要长时间思考时它就慢慢来。而且你也不必只和它对话，它也融入在你的各种工具里。这是长远的目标。但短期内，它是一个你用来委派任务的工具。
我们观察到的最佳使用方式——回到我们这期播客可能的主题“最佳实践”上来——是你必须抱有“富足心态”，并且要把它看作是帮你探索事物，而不是消耗你的时间。所以，通常当一个智能体要在你的电脑上工作时，你会非常仔细地斟酌提示，因为它会占用你的电脑一段时间，你可能无法做别的事情。但我们看到那些最爱用 Codex 的人，他们并不会这样；他们思考提示的时间最多也就 30 秒。就是那种：“哦，我有个想法，走起！”“哦，我想做这个，搞定！”“哦，我刚看到这个 bug 或者这个客户反馈”，然后你就把任务发出去了。所以，你并行运行的任务越多，我们其实越开心，我们也认为用户看到这种情况会越满意。这就是这个产品的调性。
主持人：我也分享下我的亲身经历。我曾是这个项目的受信测试员之一，你们俩都很清楚。后来我发现我用错了方法。我把它当 Cursor 用了，开着聊天窗口，看着它写代码。然后我才意识到，我不该这么做。我恍然大悟：“哦，你们都是直接把任务扔出去，然后就忙自己的事去了。”这确实是个思维方式的转变。
Alexander：快速补充一点，我会尽量简短。一个很有趣的用法是在手机上使用它，因为不知为何，在手机上操作会改变人们的思考方式。所以我们把网站做成了响应式的，最终也会把它整合到 App 里。试试看，真的非常有趣和令人满意。
主持人：所以这和其中一个视频里展示的移动端工程师在手机上用它编程不一样，它目前还不能在 ChatGPT 的 App 里用。
Alexander：暂时还不行。
主持人：我从移动端收到的通知有个问题。当它开始任务时，会显示“开始研究”，和深度研究的通知一样。它是把深度研究作为一个工具来用了，还是你们只是复用了同一个通知？
Alexander：我们只是用了同一个通知。
智能体能访问什么？安全边界在哪？
主持人：你们提到了计算平台，也提到了你们和强化学习（RL）共享了一些基础设施。能不能给听众们大致介绍一下 Codex 能访问什么，不能访问什么？看起来用户似乎不能自己运行命令，只能指示模型去做。还有其他需要注意的事项吗？
Josh：这是一个持续演进的讨论，我们仍在探索哪些部分可以开放给用户和智能体访问，哪些部分目前需要保留。所以我们还在学习，并且非常希望能和人类用户及智能体共享尽可能多的访问权限，当然，前提是符合安全和安保的约束。
目前你能做的是，作为人类用户，设置环境，设置运行脚本。这些脚本通常是用来安装依赖的，我预计这大概会占到 95% 的使用场景。目的就是把所有正确的二进制文件准备好，供你的智能体使用。我们其实也提供了一些环境编辑的体验，人类用户可以进入一个交互式解释器（REPL），尝试一些东西。所以，请不要滥用它，但你确实有办法在那里与环境互动。
Alexander：我们本来没打算做一个能交互式更新环境的 REPL，但我们试了。Josh 说：“天啊，我们太需要这个了”，所以这就是一个范围蔓延的例子。感谢你把它做出来了。
Josh：我们确实设置了速率限制，并且会非常仔细地监控。但那里确实有一些交互式的功能来帮助你上手。一旦智能体开始运行，我们目前实际做的是——并且希望在这方面有所改进——我们会切断互联网访问。因为我们仍然不完全清楚，让一个智能体在其自身环境中自由活动会带来什么后果。目前为止，所有的安全测试都非常严格地表明，它不容易受到某些针对提示注入的窃取企图的影响，但这个领域仍然存在很多风险，所以我们还不确定。这就是为什么我们一开始采取了更保守的策略，当智能体运行时，它没有完整的网络访问权限。
但我很希望能改变这一点：允许它有限度地访问，比如特定的域名或特定的代码仓库。总而言之，随着我们构建出支持这些功能的正确系统，这一点也在不断发展。不确定这是否完全回答了你最初的问题。
不过，我最后还想提一点，就是交互性方面的问题。当智能体在运行时，有时你会想：“哦，我想纠正它一下，让它去别的地方”，或者“让我来填补这部分，然后你再接手”。这些问题我们也还没有完全解决。我们真正想从一开始就追求的是那种完全独立、一次性就能交付巨大价值的模式。但我们肯定在思考如何更好地将人类和智能体结合起来。
主持人：说句公道话，我觉得“一次性搞定”这个角度很好，其他人在拿你们和 Devin、Factory 以及其他竞品比较。他们更侧重于多次人工反馈。我手头有个网站正在开发，我给它提了个需求，然后和其他工具都对比了一下，这就是我对 Codex 的测试。它确实一次性搞定了。
这真的非常棒，尤其是当你同时运行 60 个任务的时候。所以我认为这很有道理。但这确实是一个非常宏大的目标，因为人类反馈是我们乐于依赖的“拐杖”。这也迫使我们写更多测试，这挺烦人的，因为我不喜欢写测试，但现在我不得不写了。幸运的是，我现在可以让 Codex 帮我写测试了。我还特别喜欢直播里演示的，你可以直接让它看你的代码库，然后建议你做些什么，因为我连想该做什么的精力都没有了。
Alexander：授权他人进行授权，我觉得这话说得很好。需要明确的是，我们并不是说某种形态就一定比其他形态更好。我非常喜欢用 Codex CLI，而且我们真正想要的，就像我在 OpenAI 面试时我们聊到的那样，是两种模式兼备。但我认为，Codex 在这里扮演的角色，是真正推动那个“一次性搞定”的自主软件工程师的边界。
是的，我有点把这次研究预览版看作是我们的一个思想实验。它就像是在探索：一个编码智能体，在它最纯粹、最能体现 AGI 潜力或规模效应的形态下，会是什么样子？然后或许，对我个人而言，在 OpenAI 工作令我兴奋的部分原因，不仅仅是为开发者解决问题，更是真正思考 AGI 如何造福全人类，以及非开发者对此会有怎样的感受。所以，对我来说，真正有趣的是将 Codex 视为一个实验，看看在其他职能部门工作会是什么感觉。我为之奋斗的目标是这样一个愿景：我们做那些模棱两可、富有创造性或难以自动化的工作，但除此之外，我们把大部分工作都委托给智能体。而这些智能体，它们不是那种遥不可及的未来产物，也不是昙花一现的短期工具，而是无处不在、随时伴你左右的。所以，我们决定从最纯粹的形式开始，我们原以为这会是发布范围最小的东西，但事实可能并非如此。不过，我们最终会将这些不同的东西整合起来。
迈向 AGI 超级助手
主持人：好的，我想我们还有时间问几个问题。我们再深入聊聊这个研究预览版。它为什么是“研究预览版”？还有哪些不足？你们认为达到什么标准才能算作正式发布？在直播中，Greg 提到了云端和 CLI 之间的无缝过渡。是这个原因，还是你们有其他的考虑？
Alexander：老实说，我们之所以如此坚信迭代部署，部分原因在于——我现在可以分享一些我的想法，但我们也真的很好奇最终会怎样。因为这是一种全新的产品形态。但我目前最关注的几点包括多模态输入，我们之前也讨论过。
主持人：我知道你喜欢那个。
Alexander：另一个例子是，再给它多一点接触外部世界的权限。很多人都要求各种形式的网络访问。我还认为，我们目前发布的用户界面，实际上是我们迭代过的一个版本。这里面有个有趣的故事，但总的来说，这是一个人们觉得有用的界面，但它肯定不是最终形态，我们非常希望它能更紧密地融入开发者日常使用的工具中。这些是我们正在思考的一些主题。但需要明确的是，我们会不断迭代并找出答案。
主持人：我担心的是它正式发布后的定价，但我现在会好好利用这个免费期。何乐而不为呢？
Alexander：关于定价，也请给我们反馈。
主持人：现在谈定价是不是太早了？
Alexander：是的，现在还太早。
主持人：好吧。参考 Claude Code 的情况，这确实是大家担心的一点。Claude 已经开始引入一些固定定价和可变定价了，我觉得这搞得一团糟。没有标准答案。每个人都只想要他们能得到的最便宜的代码处理能力。所以，祝你们好运。
Alexander：谢谢。
Josh：我的看法是，我们的目标是交付巨大的价值，而我们有责任去展示这一点，并真正让人们意识到：“哇，这东西在为我做非常有经济价值的工作。”我认为很多定价问题都可以从这一点出发。但我觉得，对话应该从这里开始：我们是否真的在交付那种价值？
主持人：太棒了。好吧。非常感谢你们。感谢你们的努力，也感谢你们抽出时间。这一天我们等了很久，但我想大家开始看到，OpenAI 整体上对智能体越来越认真了。这不仅仅是编码，但编码显然是一个自我加速的闭环，我想你们对此也充满热情。看到这些真的很鼓舞人心。
Alexander：非常高兴能把这个编码智能体带给大家，并最终将它融入通用的 AGI 超级助手中。感谢邀请我们。
原播客链接：https://open.spotify.com/episode/7soF0g9cHqxKaQWWJBtKRI
（文：AI科技大本营）