务实工程师
务实工程师订阅

深入 OpenAI 的 Agentic 软件工厂

1

拥有无限代币预算的情况很少见，但在OpenAI，所有工程师、研究人员、金融同事和市场人员都是这么做的。最近，我参观了世界领先的前沿实验室之一，了解OpenAI目前的运作方式——并展望软件工程作为一门职业可能的发展方向。

自去年OpenAI总部以来，变化很大。不到一年，Codex就从一个“可有可有”的工具，变成了公司几乎所有业务的支柱。

为了了解更多信息，我与那里的七位工程领导者和工程师进行了交流：Venkat Venkataramani（工程副总裁，应用基础设施）、Sulman Choudhry（ChatGPT工程主管）、Andrew Abrosino（桌面负责人）、Joe Gershenson（核心代理团队负责人）、Akshay Nathan（工程负责人，生产力）、Ahmed Ibrahim（Codex工程师）和Steve Coffey（响应API工程师）。

感谢所有参与的朋友！

今天，我们将涵盖：

  1. Codex 接管了 OpenAI。几个月内，几乎所有非工程师都转用Codex和ChatGPT Work，且没有上级的授权。
  2. IDE和拉取请求的死亡。自从一月份Codex使用激增以来，IDE使用率一直下降。公共声明和代码审查需要重新考虑。
  3. OpenAI的代理软件工厂。OpenAI 构建了一个“软件工厂”，配备了多个自动化的代理反馈循环：例如，Perf Factory 监控生产并启动 Codex 代理以自动修复性能问题。
  4. 工程工具和实践的变化。手工内部工具正逐渐被Codex取代，Codex在调试中越来越受青睐，而非专用工具。利用效率在软件工厂中至关重要。
  5. 为十亿用户设计：OpenAI如何扩展其基础设施。他们先买，后进内部。还有地理基础设施分布、容量规划策略和挑战。
  6. 让OpenAI的API更可靠、更高性能.CPU正成为瓶颈，故意让部署速度变慢，并解决负载问题。
  7. 软件工程工作正在发生变化。工程专业化正在消失，判断力和能动性变得更重要，而只需一两个工程师，之前“不可能”的重写和迁移就能成功。

开始之前，先更新一下时间安排：我这周在纽约，参加LDX3大会，并拜访市内几家初创企业和科技公司，所以周四不会有《The Pulse》的一期。

正常服务将于下周恢复！

本文底部可能会被某些电子邮件客户端截断。

1. Codex 接管 OpenAI

我参观公司总部时，最深刻的收获是Codex——最近还有Codex——以及ChatGPT的工作——已经接管了一切大约从一月开始。桌面负责人Andrew Ambrosino告诉我：

“过去几个月的主要主题是，现在一切都是一个编码代理。无论可见的代码是否是你的输出，代理都写出了你的作品。这样想：你的整个生活都通过软件展开。你的电脑里有这些强大的工具（代理），循环、推理和编写代码的能力，就是能做所有事情的能力。”

下面的代币使用图表展示了这波突如其来的采用激增：

在四个月内，非工程类组织如财务、招聘和法务部门的Codex使用率从~0%降到了90%。现在，几乎所有OpenAI员工每周都在使用Codex和ChatGPT。

那么，发生了什么？

OpenAI 于 2 月发布了 Mac 版 Codex 应用，3 月发布 Windows 版，7 月发布了 ChatGPT Work（由 Codex 驱动）。随后，非工程师将所有工作流程迁移到 Codex，再到 Work。

注意：OpenAI 内部版本的 Codex 比外部版本更先进，因为它几乎接入了所有 OpenAI 系统–和接线方式类似。

有趣的是，OpenAI在非工程团队中采用率接近40%，而Codex应用对非工程用户却很友好（使用困难）。2月至4月间，Codex应用仍显示代码，但即便如此，非技术同事也在屏幕上显示不过用它是因为它能做复杂工作，比如研究和制作演示文稿、文档、电子表格，或者产生丰富输出的任务。

如今，这些人已经是它非常重度的使用者。

能够在更复杂的事情上工作更长时间推动了采用。OpenAI 在 Codex 中添加了 /goal 设置，你可以为代理设置目标，并且它会一直运行直到完成。

从四月到五月，使用率从60%激增到90%。Andrew 认为，硬件对长期任务处理能力的提升是造成这种情况的原因之一：

“变化最大的一点是人们开始更长时间地使用线程，而这种更长的使用时间是一次突破。令人惊讶的是，人们在线程上花费的时间之长甚至几天！他们常常设定目标，然后让模型启动。Codex擅长长期任务似乎导致人们并行做的事情减少。这是因为长期运行的特工经常会分拆其他特工去做其他事务，减少了你作为人类必须管理的表面积。”

Codex团队认为，“认知过剩”是快速采用的另一个原因。正如生产力团队工程负责人Akshay Nathan告诉我的：

“很长一段时间里，我们存在'能力过剩'：模型是有能力的，但产品并没有完全发挥这一点。现在，我们看到认知度的差距。有些人发现可以用Codex监控Slack、更新Airtable或创建入职材料。但还有很多人用它做某项任务，然后通过口碑从队友那里发现更多用途。但在表面之下，你仍然可以做更多事情。”

创建并分发针对特定角色和团队的插件。另一个加速采用的因素是，每个团队开始以插件形式分发有用的特定角色工作流程。Andrew 解释了为什么不仅仅是提供一个通用的编码代理很重要：

“如果你打造了一个能做任何事情的产品，团队需要一种方法让它成为自己的。你不能给每个人一个空盒子。技能和插件让团队能够将代理调整到他们的工作中。有时，我们也需要一个新的应用功能，比如代理可以同时使用的浏览器。但同样的构建模块已经涵盖了许多不同的角色。”

主题专家嵌入ChatGPT工作工程团队中。在某些领域，模型已经比开发者“更聪明”，因此开发者无法将“品味”融入这些领域。因此，领域专家被纳入工程团队。

这是ChatGPT工作被许多非工程领域广泛使用的结果：嵌入工程领域的专家会为开发者提供诸如优秀幻灯片、电子表格或业务报告的建议。

当然，领域专家加入工程团队是构建高质量产品已有数十年历史的最佳实践。似乎每隔几年就会在不同环境中被重新发现！

OpenAI完全依赖Codex和Work。这种情况如此之大，以至于即使发生轻微故障，同事的内部消息也会在自动警报发布时，甚至提前通知Codex和Work团队。

基本上，工作通过Codex和Work进行，基本上没什么否则。从外部看，这种对单一共享束的依赖尤其引人注目;两年前，没有AI代理，只有先进的AI自动补全！

2. IDE的失效与拉取请求

去年年底，Codex团队在是否发布Codex桌面应用上曾陷入分歧。Andrew回忆起当时的犹豫：

“2025年12月，我们并不完全确定是否会发布Codex应用。我们用的是Codex CLI作为终端，市面上有大型、功能丰富的IDE。那么，是否有空间放置一个介于终端和IDE之间的开发工具？在我脑海中，有一个未来，它不会行得通，会像iPad那样'格格不入'。很多人买了iPad却从未使用过：他们要么用更小、更便携的智能手机（这可以相当于这个比喻中的CLI）或者他们功能丰富的笔记本电脑（相当于IDE的版本）。另外，别忘了去年十一月，Antigravity作为VS Code分支发布。这加剧了我们或许应该为Codex应用分支VS Code的感觉。但我们还是拒绝了诱惑，顺从直觉，认为随着AI代理的进步，IDE的重要性会降低。”

事实上，自一月以来，IDE使用率下降，OpenAI的赌注看起来不错。然而，Codex应用正逐渐成为一个小更像是集成开发环境（IDE）：例如，在应用内编辑文件的功能于六月发布。

CI/CD系统负载大幅增加。Codex带来生产力提升的一个标志是通过OpenAI开发基础设施系统流转的额外代码量。更多代码的创建和推送带来了新的扩展挑战，团队目前正全力解决这些挑战。

应用基础设施工程副总裁Venkat Venkataramani表示：

“每位工程师的拉取请求（PR）数量正像曲棍球棒一样快速增长（以非常高且加速的速度）.构建-测试-部署流程的每个环节都经历了显著增加的负载。我们谈论的是某些系统的负载大约增加了10倍。在大多数公司，这种增长可能需要两三年实现。而在OpenAI，我们大约六个月内就能看到。这种加速水平暴露了各处瓶颈：版本控制必须处理更多的代码编写和推送，CI/CD系统必须随之扩展，生产发布流程还要吸收更高的变化速度。每个月，我们都会面对一系列新的基础设施扩展挑战。就在我们认为已经为下一阶段增长创造了足够的容量时，模型又解锁了另一波能力浪潮，这在系统其他地方制造了新的瓶颈。”

在此背景下，PR和代码审查正在被重新思考。他们在软件工程中有“核心原语”，但这种开发加速正是重新构想它们的机会。再次引用Venkat的话：

“在这波开发加速中，我们应该问自己的问题是，如何重新构想许多我们视为理所当然的事情。例如，我们如何重新构想CI（持续集成）和CD（持续部署）流程？可观察性在这个世界上意味着什么，人们应该如何与拉取请求互动？如果你问我，我们今天做代码审查的方式越来越不合理，pull request也是如此。我们现在看到代理代码审查通过一系列不同的视角审视代码变更。过去，云基础设施工程师和安全工程师审查每一个代码变更都是不切实际的。有了代理，这变得可能。我们也可以重新思考代码在代理部署方式上。我们正在构建一个能够“手把手”一直到生产环境的代理——无论是代码变更还是功能标志后的变更。它会观察相关的监控图表，同时也能构建自己的仪表盘来监控重要信号。通过这种代理监控，我们更多的代码变更将进入生产环境。”

一个日益棘手的瓶颈是部署原生移动应用。当拉取请求数量是它的十倍时，后端或网页部署变得困难，需要更多基础设施来实现。然后，在你重构CI/CD系统并确保有足够容量运行它们后，你将会部署更多的PR到生产环境。

这源于向原生iOS和Android应用发布更新时，因为每次应用更新都需要经过苹果和谷歌的人工审核流程，这些流程需要数小时甚至数天才能完成。

在与ChatGPT工程主管Sulman Choudhry交谈时，他解释了应用审核瓶颈如何影响迭代速度。Sulman曾在Facebook工作，他记得这家社交媒体公司如何加快移动端发布的速度：

“早在2010年代，Facebook在更快地发布原生移动代码方面取得了相当重要的突破。App Store的发布从每月更新变成了双周更新，再变成每周更新一次。与此同时，实验和功能标志让团队可以在代码准备发布前发布代码，然后在准备好时远程开启功能。这种模式带来了更大的速度mobile.InCodex时代，我认为我们正面临这个问题的下一个版本。代码生成速度正在大幅提升，但将代码送到用户手中却没有。尤其是Codex，使用高度以移动为先，这一差距对我们和用户来说已经变得痛苦。我预计这里的压力会迅速增加。如果软件能在几分钟内编写完成，那么等待数天甚至数周才能加载到手机上，看起来越来越荒谬。我们应该追求一个原生移动端代码发布速度与网页上传同等快的世界。实现这一目标可能需要对发布内容、发布时间以及远程激活内容进行一些创造性重新思考。但如今，我们还远远未达成目标。”

讽刺的是，原生iOS或Android应用的发布如今面临的挑战与2008年App Store上线时完全相同。18年过去了，变化不大！苹果仍未正式允许应用绕过App Store审核流程，发布有意义的体验变更。

3. OpenAI 的代理软件工厂

“软件工厂”的概念类似于机器人和人类共同生产汽车的实体工厂。在软件领域，是人工智能代理和人类共同生产软件。一些制造现场是全自动化的“黑暗工厂”，因为没有人类，不需要照明。

同样的全自动化流程能否在软件工程中出现？在今天的OpenAI，有一个“软件工厂”在运行，且全部围绕Codex构建。

以下是“传统”软件开发流程过去的样子，与OpenAI如今的代理基础设施流程相比，正如工程副总裁、应用基础设施副总裁Venkat Venkataramani所描述的：

管道：

1. 人类建造者定义期望的结果。软件工程师或产品经理会明确问题和期望的结果。判断、优先级和品味在这个阶段变得更为重要。有趣的是，Venkat告诉我，OpenAI的工程师越来越像产品经理，而不是传统的系统工程师。

2. 法典收集背景。OpenAI 已将所有文档转移到源代码内部，使代理更容易理解更多代码内容。Codex 还可访问：

  • Git 仓库和 GitHub
  • Slack 与 Notion
  • 内部数据源：Databricks、Datadog、内部日志等
  • 内部Codex技能——其中一些由OpenAI的Codex实现本身维护！

Codex 与 OpenAI 紧密相连，以至于新工程师会被引导去向 Codex 咨询任何他们在入职时会有问题，因为这涉及出乎意料的丰富背景。

3. Codex 实现代码变更。这一步很简单：Codex开始工作，进行一系列代码修改直到达到目标，然后验证软件是否正常工作。

4. 构建并测试，然后进行CI。代理构建代码，运行测试，在测试失效时修复代码，然后创建一个拉取请求。这个拉取请求会触发持续集成（CI）服务器运行和执行更全面的 linter 和测试套件。

代理会对 PR 进行“绿色”照看，修复任何 CI 失败并自动更新 PR。

新：一个“穿孔背带”：代理还使用perf工具将有问题的PR发送到Synthetics A/B框架，以评估性能影响。如上所述，过去六个月CI系统的负载大幅增加。

5. 智能代码审查。OpenAI不再使用一个通用的AI代码审查者，而是剥离出多个代理，每个代理都有“领域专家”配置。Venkat告诉我，他们认为这相当于每个相关基础设施团队的人工领域专家审查每一个变更。

Gergely的说明：我对声称被告知为云基础设施专家的代理会与通用代理不同的评价持怀疑态度。然而，所有Codex代理都能完全访问OpenAI的代码和文档，因此这位“云基础设施专家”代理很可能收集了大量关于云基础设施设置和最佳实践的背景信息，因此应能提供高度针对性的反馈。

关键在于这些“领域专家”代理的设置方式、他们可访问的上下文，以及他们如何专注于自己的领域，以充分利用有限的上下文窗口。

代码变更按风险分类。高风险变更可以通过更严格的流程发送;例如，可能会启动更多的AI代码审查，或要求AI代理完成后由人工审核。低风险变更则走更简单的路径;代码库中的某些区域可以选择使用代理自动批准低风险PR，消除人工接受作为瓶颈，提高速度。

风险评估的一个好处是，OpenAI可以在需要额外合规输入时实现自动化：无论是通过其他代理进行自动化，还是人工审核。由于生成的PR数量庞大，人工审核所有代码在没有辅助的情况下是不可能的。

就像CI一样，编码代理会看管评论，并更新PR来修正出现的问题。

6. 主动部署。在人类批准进入生产环境的变更后，会被分配自己的代理，指令可总结为：

“在安全全面投入生产之前，先拖延这项变更。”

代理手握代码变更和功能标志背后的变更。例如，在功能标志后发生变更时，代理会：

  • 阅读代码库，弄清楚功能标志的位置
  • 了解变革的效果
  • 判断哪些信号表示成功，哪些信号示失败
  • 构建了自己的监控仪表盘–这是一个相当令人印象深刻的改进，对我来说也是全新的体验
  • 关注相关的生产信号及其仪表盘

OpenAI的长期目标是打造类似“每次更换自动站点可靠性工程师”（站点可靠性工程师）的代理，能够几乎自主部署。

7. 观察生产。跟踪生产系统的工具：

  • 代理在前一步骤中生成的仪表盘
  • OpenAI 内部可观测性栈，包括一系列自定义工具，生成日志、指标、追踪和广泛事件数据

自我上次访问Codex之前以来，OpenAI的一个重大变化是，当时工程师创建仪表盘来监控服务，而现在，代理人员则以每次变更部署的细度方式完成。

8. 生产监控反馈到开发中。OpenAI的“Perf Factory”利用代理筛选警报和仪表盘，消除重复信号，识别真实延迟回归，找出根源并提出修复建议。

这有助于发现因持续代码变更带来的性能问题，将工作流程从部署扩展到持续改进。

9. 响应停电。Sevbot 是 OpenAI 内部的事件响应代理;不出意外，它同样建立在 Codex 之上。当检测到事件时，机器人会“唤醒”。它的作用如下：

  • 收集事件背景
  • 确定可能的缓解措施（但从未执行过任何缓解措施）
  • 回答开发者的问题（这是Slack频道的一部分）
  • 工程师可以告诉它应用特定的缓解措施

OpenAI的目标是让Sevbot能够自主采取行动来缓解部分停机。我们的梦想是，在停机期间，不会有人在工作时间外被叫醒，因为Sevbot能够自主处理“例行”停机，人员在返回工作岗位时会审核其操作。

但目前，待命值班在公司并未成为过去。

4. 工程工具和实践的变化

毫不意外，Codex 正在改变内部工具构建的便利性，并影响了标准工程实践，比如调试。以下是我与 OpenAI 人员交流中了解到的情况。

参与讨论