走进 OpenAI 的智能体软件工厂：Codex 如何接管内部研发

与无限的 token 预算打交道的机会并不多，但在 OpenAI，所有工程师、研究员、财务同事和营销人员都是这么做的。最近，我参观了全球领先的前沿实验室之一，想了解 OpenAI 如今是如何运作的——也借此一窥软件工程作为一个职业可能走向何方。

自从我去年到访OpenAI 总部以来，发生了很多变化。一年之内，Codex 已从“可有可无”的工具变成了公司几乎一切工作的支柱。

为了了解更多，我与那里的七位工程负责人和工程师进行了交流：Venkat Venkataramani（应用基础设施工程副总裁）、Sulman Choudhry（ChatGPT 工程负责人）、Andrew Ambrosino（桌面端负责人）、Joe Gershenson（核心 Agent 团队负责人）、Akshay Nathan（生产力工程负责人）、Ahmed Ibrahim（Codex 工程师）和 Steve Coffey（Responses API 工程师）。感谢所有人的参与！

今天，我们涵盖：

Codex 接管 OpenAI。在短短几个月内，OpenAI 几乎所有非工程师都迁移到了 Codex 和 ChatGPT Work，而且上面并没有下达强制要求。
IDE 与拉取请求的消亡。自 1 月 Codex 使用量开始激增以来，IDE 的使用量一直在下降。PR 和代码审查需要重新思考。
OpenAI 的智能体软件工厂。OpenAI 构建了一个“软件工厂”，包含多个自动化、智能体驱动的反馈循环：例如，Perf Factory 会监控生产环境并启动 Codex 智能体来自动修复性能问题。
工程工具与实践正在如何变化。手工构建的内部工具正逐渐被 Codex 取代，在调试方面 Codex 越来越比专用工具更受青睐。在软件工厂中，harness 效率至关重要。
为十亿用户做工程：OpenAI 如何扩展其基础设施。他们先购买，之后再自研。此外还有地理上的基础设施分布、容量规划策略与挑战。
让 OpenAI 的 API 更可靠、更高性能。CPU 正成为瓶颈，故意进行更慢的部署，以及解决负载挑战。
软件工程这份工作正在如何变化。工程专业化正在消失，判断力和主动性更重要了，而以前“不可能”的重写和迁移，现在只需要一两名工程师就能成功完成。

在我们开始之前，先更新一下日程安排：我这周在纽约，参加 LDX3 大会并拜访该市的一些初创公司和科技公司，所以周四不会有 The Pulse 的内容。下周恢复正常更新！

在某些邮件客户端中，本文的底部可能会被截断。在线阅读完整文章，不受干扰。

在线阅读完整文章

1. Codex 接管 OpenAI

我参观该公司总部后印象最深的一点是，Codex——以及最近的 Codex 和 ChatGPT Work——已经接管了那里的一切，大约从一月开始。桌面端负责人 Andrew Ambrosino 告诉我：

“过去几个月的主题是，现在一切都是编码智能体。无论可见的代码是否是你的输出，智能体都会编写你的产物。
这样想吧：你的整个生活都通过软件进行。你的电脑里有这些强大的工具（智能体），而能够循环、推理和编写代码的能力就是做一切事情的能力。”

下面的 token 使用量图表显示了这种突然的采用激增：

OpenAI 自 2025 年 8 月以来按部门统计的 Codex 使用情况。来源：OpenAI

在四个月的时间里，财务、招聘和法律等非工程部门对 Codex 的使用率从约 0% 上升到 90%。如今，几乎所有 OpenAI 员工每周都会使用 Codex 和 ChatGPT Work。那么，发生了什么？

OpenAI 于 2 月发布了 Mac 版 Codex 应用，3 月发布了 Windows 版，并于 7 月发布了 ChatGPT Work（由 Codex harness 驱动）。此后，那里的非工程师将所有工作流都迁移到了 Codex，然后又迁移到了 Work。 注意：OpenAI 内部的 Codex 版本比外部版本先进得多，因为它几乎接入了 OpenAI 的每一个系统——类似于 Ramp 的 Inspect AI 智能体的接入方式。

这件事引人入胜的地方在于，在 Codex 应用对非工程用户并不友好（难以使用）的时候，OpenAI 却在非工程团队中获得了接近 40% 的采用率。在 2 月到 4 月期间，Codex 应用仍然会在屏幕上显示代码，但即便如此，工程部门以外的非技术同事仍然使用它，因为它能完成复杂的工作，比如研究和创建演示文稿、文档、电子表格，或产生丰富输出的任务。如今，这些人都是它的重度用户。

能够在更复杂的事情上工作更长时间推动了采用。OpenAI 为 Codex 添加了 /goal 设置，你可以为智能体设定一个目标，它会持续工作直到完成。在 4 月到 5 月期间，使用率从 60% 飙升到 90%。Andrew 认为，harness 对长时间运行任务处理能力的改进是原因之一：

“最大的变化是，人们开始将线程使用更长的时间，而这种更长时间的使用是一项突破。看到人们在一个线程上花费的时间之长令人惊讶——甚至长达数天！他们通常会设定一个目标，然后让模型全力运转。
Codex 擅长长时间运行的任务，似乎会导致人们并行处理的事情变少。这是因为长时间运行的智能体常常会衍生出其他智能体去做其他事情，从而减少了作为人类的你需要管理的范围。”

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

“很长一段时间里，我们存在一种‘能力过剩’：模型本身能力很强，但产品没能充分把这种能力发挥出来。而现在，我们看到的是认知差距。有些人已经发现可以用 Codex 来监控 Slack、更新 Airtable 或制作入职培训材料。但很多人仍然只把它用于一项任务，然后通过同事的口口相传才发现更多用法。
但在表面之下，Codex 还能做太多太多的事情。”

针对特定角色和团队的插件被创建并分发。 另一个加速采用的因素是，每个团队都开始把有用的角色专属工作流作为插件分发出去。Andrew 解释了为什么不能只提供一个通用的编码 agent：

“如果你构建一个什么都能做的产品，团队需要一种方式让它变成自己的。你不能只给每个人一个空盒子。Skills 和插件让团队能够把 agent 适配到他们的工作中。有时，我们还需要新的应用能力，比如一个 agent 可以配合这些技能使用的浏览器。但同样的构建模块已经覆盖了很多不同的角色。”

领域专家被嵌入到 ChatGPT Work 工程团队中。 在某些领域，模型已经比开发者更“聪明”，因此开发者无法在这些领域把“品味”注入到 harness 中。所以，领域专家被引入到工程团队。这是 ChatGPT Work 被如此多非工程领域使用的一个结果：嵌入工程团队的专家就什么是好的幻灯片、电子表格或商业报告向开发者提供建议。

当然，领域专家加入工程团队是打造高质量产品几十年来的最佳实践。看起来这每隔几年就会在不同的情境下被重新发现一次！

OpenAI 完全依赖 Codex 和 Work。 这一点体现得如此彻底，以至于即使发生轻微故障，同事发来的内部消息也会与自动警报同时——甚至更早——提醒 Codex 和 Work 团队。

基本上，工作都是通过 Codex 和 Work 完成的，几乎没有其他方式。 从外部来看，这种对单一共享 harness 的依赖尤其引人注目；两年前还没有 AI agent，只有高级的 AI 自动补全！

2. IDE 与 pull request 的消亡

去年年底，Codex 团队就是否发布 Codex 桌面应用产生了分歧。Andrew 回忆起当时的犹豫：

“2025 年 12 月，我们并不完全确定是否会发布 Codex 应用。我们有 Codex CLI 作为终端工具，市面上也有大型、功能丰富的 IDE。那么，一个介于终端和 IDE 之间的开发工具还会有空间吗？在我脑海中，存在这样一种未来：它最终行不通，变成像 iPad 那样的‘异类’。
很多人买了 iPad 之后就再也不用：他们要么用更小、更便携的智能手机（在这个比喻里相当于 CLI），要么用功能丰富的笔记本电脑（相当于 IDE）。
另外，别忘了 11 月时，Antigravity 作为 VS Code 分叉版本问世。这更让人感觉，或许我们也应该为 Codex 应用分叉 VS Code。但我们还是抵制住了这种诱惑，遵从直觉：随着 AI 智能体变得更强，IDE 的重要性会下降。”

确实，自 1 月以来，IDE 的使用量已经下降，OpenAI 的押注看起来是正确的。不过，Codex 应用正变得稍微更像一个 IDE：例如，在应用内编辑文件的能力已于 6 月上线。

CI/CD 系统正承受巨大的负载增长。Codex 带来生产力提升的一个迹象，是流经 OpenAI 开发基础设施系统的额外代码量。更多代码被创建和推送，带来了新的扩展挑战，团队目前正全力解决。应用基础设施工程副总裁 Venkat Venkataramani 表示：

“每位工程师的拉取请求（PR）数量正呈曲棍球棒式增长（以非常高且不断加速的速率）。构建-测试-部署流水线的每个环节都承受着急剧增加的负载。
我们说的是某些系统的负载大约增加了 10 倍。在大多数公司，这种增长可能需要两到三年。而在 OpenAI，我们大约六个月就看到了。
这种加速程度暴露了各处的瓶颈：版本控制必须处理多得多的代码写入和推送，CI/CD 系统必须随之扩展，生产发布流程必须吸收高得多的变更速率。
每个月，我们醒来都会面临一组新的基础设施扩展挑战需要解决。就在我们以为已经为下一阶段增长创造了足够容量时，模型又解锁了新一波能力，从而在系统的其他地方制造出一组新的瓶颈。”

在此背景下，PR 和代码审查正在被重新思考。它们是软件工程中的“核心原语”，但这种开发加速水平正是重新构想它们的契机。同样来自 Venkat：

“在这场开发加速之中，我们真正该问自己的是，如何重新构想许多我们习以为常的东西。例如，我们如何重新构想 CI（持续集成）和 CD（持续部署）流程？在这个世界里，可观测性意味着什么，人们又应该如何与拉取请求交互？
如果你问我，我们今天做代码审查的方式越来越说不通，拉取请求也是如此。
我们现在看到智能体式代码审查，会通过一系列不同的视角来审视代码变更。过去，让云基础设施工程师和安全工程师审查每一处代码变更是不切实际的。有了智能体，这就成为可能。
我们也可以重新思考如何用智能体部署代码。我们正在构建一个智能体，它“手把手”地将一项变更一路护送到生产环境——无论是代码变更还是功能开关背后的变更。它会观察相关的监控图表，也能构建自己的仪表盘来监控重要信号。我们越来越多的代码变更正伴随着这种智能体监控进入生产环境。”

部署原生移动应用正成为一个日益痛苦的瓶颈。当拉取请求（pull request）数量增加十倍时，在后端或 Web 上部署就会变得困难，而且需要更多基础设施来支撑。然后，在你改造完 CI/CD 系统并确保有足够容量运行它们之后，你将把同样多出许多的 PR 部署到生产环境。

这出现在向原生 iOS 和 Android 应用推送更新时，因为每一次应用更新都需要经过 Apple 和 Google 的人工审核流程，而这些流程需要数小时甚至数天才能完成。

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

“早在 2010 年代，Facebook 在如何更快地发布原生移动代码方面取得了一项相当重要的突破。App Store 发布从每月一次变为每两周一次，再到每周一次。与此同时，实验和功能开关让团队可以在代码准备好发布之前就将其发布，然后在功能就绪时远程开启。
这种模式为移动端带来了大幅提升的速度。
在 Codex 时代，我认为我们正在遇到这个问题的新版本。代码生成正变得极快，但要让这些代码通过原生移动端到达用户手中却并非如此。尤其是对 Codex 来说，其使用明显以移动端优先，这一差距对我们和用户来说已经变得令人痛苦。
我预计这里的压力会迅速增加。如果软件可以在几分钟内编写完成，那么等待数天或数周才能把它放到手机上，就开始显得越来越荒谬。
我们应该以这样一个世界为目标：在原生移动端发布代码和在 Web 上发布一样快。要实现这一点，可能需要对发布什么、何时发布以及什么可以远程激活进行一些创造性的重新思考。今天，我们离这一目标还差得很远。”

颇具讽刺意味的是，如今发布原生 iOS 或 Android 应用所面临的挑战，与 2008 年 App Store 推出时完全相同。18 年过去了，并没有太大变化！Apple 仍然没有正式允许应用绕过 App Store 审核流程来发布有意义的体验变更。

3. OpenAI 的智能体软件工厂

“软件工厂”的概念类似于实体工厂，在那里机器人和人类共同生产汽车。在软件语境中，则是 AI 智能体和人类共同生产软件。一些制造场所是完全自动化的“黑灯工厂”，因为没有人，所以不需要照明。软件工程中是否也会出现同样的全自动化流程？在今天的 OpenAI，就有一个“软件工厂”在运行，而且它完全围绕 Codex 构建。

以下是应用基础设施工程副总裁 Venkat Venkataramani 所描述的“传统”软件开发流水线与 OpenAI 今天的智能体基础设施流水线的对比：

OpenAI 的“智能体软件工厂”

该流水线：

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

2. Codex 收集上下文。OpenAI 已将其所有文档移入源代码内部，这让智能体更容易理解更多代码。Codex 还可以访问：

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

Codex 与 OpenAI 的集成如此之深，以至于新工程师在入职期间被要求向 Codex 提出任何问题，因为它拥有多得惊人的上下文。

3. Codex 实施代码变更。这部分相当简单：Codex 开始工作并进行一系列代码变更，直到达成目标，然后验证软件是否按预期运行。

4. 构建与测试，然后是 CI。 智能体构建代码、运行测试，在代码导致测试失败时修复代码，然后创建拉取请求。该拉取请求会触发持续集成（CI）服务器运行，并执行更全面的 linter 和测试套件。智能体会照看该 PR，直到它“变绿”，修复任何 CI 失败并自动更新 PR。

新增：一个“性能测试框架”：智能体还会使用性能测试框架将有问题的 PR 发送到 Synthetics A/B 框架，以评估性能影响。如上所述，过去六个月里 CI 系统上的负载大幅增加。

5. 智能体代码审查。OpenAI 没有使用一个通用的 AI 代码审查员，而是启动多个智能体，每个都配置为“领域专家”。Venkat 告诉我，他们认为这相当于让每个相关基础设施团队的人类领域专家审查每一项变更。

Gergely 的备注：我原本怀疑，一个被指定为云基础设施专家的智能体，是否会比通用智能体给出不同的审查结果。然而，所有 Codex 智能体都可以完全访问 OpenAI 的代码和文档，因此这个“云基础设施专家”智能体很可能已经收集了大量关于云基础设施设置和最佳实践的上下文，这意味着它应该能提供高度有针对性的反馈。重要的是这些“领域专家”智能体如何设置、它们能访问哪些上下文，以及它们如何只专注于自己的领域，以最大限度地利用其有限的上下文窗口。

代码变更按风险分类。高风险变更可以走更严格的流程；例如，它们可能触发更多 AI 代码审查，或强制要求人类在 AI 智能体完成后进行审查。低风险变更则走更简单的路径；代码库的某些区域可以选择启用一个智能体，自动批准低风险 PR，从而消除人类审批这一瓶颈并提高速度。

风险评估的一个妙处在于，OpenAI 可以自动化判断何时需要额外的合规输入：要么由另一个 agent 自动完成，要么交由人工审核。考虑到产生的 PR 数量之多，人类若没有协助，根本不可能审查所有代码。

就像 CI 一样，编码 agent 会盯着评论并更新 PR，以修复暴露出来的问题。

6. Agentic 部署。在人类批准某项变更进入生产环境后，该变更会被分配一个自己的 agent，其指令可以概括为：

“盯住这项变更，直到它安全且完整地推送到生产环境。”

Agent 既要盯住代码变更，也要盯住功能开关背后的变更。例如，对于某个功能开关背后的变更，agent 会：

阅读代码库，找出该功能开关所在的位置
理解这项变更做了什么
判断哪些信号代表成功、哪些代表失败
构建自己的监控仪表盘供自己使用——这是一个相当令人印象深刻的改进，对我来说也是新鲜事
观察相关的生产信号及其仪表盘

OpenAI 的长期目标是拥有类似“按变更配备的自主 SRE”（站点可靠性工程师）的东西，其形式是一个能够几乎自主完成部署的 agent。

7. 观察生产环境。用于跟踪生产系统的工具：

由 agent 在之前步骤中生成的仪表盘
OpenAI 内部的可观测性技术栈，包括一系列生成日志、指标、追踪和宽事件数据的自定义工具

与我上次访问、Codex 之前相比，OpenAI 的一个重大变化是：那时工程师会创建仪表盘来监控服务，而现在 agent 会以单次变更部署为粒度来完成这件事。

8. 生产监控反馈回开发环节。 OpenAI 的“Perf Factory”使用 agent 来筛选告警和仪表盘、对信号去重、识别真正的延迟回退、进行根因分析并提出修复方案。这有助于捕捉持续代码变更引入的性能问题，将工作流从部署延伸到持续改进。

9. 响应故障。Sevbot 是 OpenAI 内部的故障响应 agent；不出所料，它也是基于 Codex 构建的。当检测到故障时，这个 bot 会“醒来”。以下是它的工作内容：

收集与故障相关的上下文
确定可能的缓解措施（但从不执行任何措施）
回答开发者的提问（它是 Slack 频道的一员）
工程师可以指示它应用某个特定的缓解措施

OpenAI 的目标是达到这样一种状态：Sevbot 在缓解某些故障时能够自主采取行动。理想情况是，故障期间不再有人需要在工作时间之外被叫醒，因为 Sevbot 可以自主处理“例行”故障，而人类在回到工作岗位时审查它的操作。但截至目前，在公司里 oncall 值班还不是过去式。

4. 工程工具与实践正在如何改变

不出所料，Codex 正在改变构建内部工具的难易程度，并对调试等标准工程实践产生影响。以下是我与 OpenAI 相关人员交流后收集到的内容。