Gergely Orosz 探访 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 工程师）。 感谢各位的参与！
今天，我们涵盖：
开始之前，先更新一下日程：我这周在纽约，参加 LDX3 大会，并拜访这座城市的一些初创公司和科技公司，所以周四不会有 The Pulse。下周恢复正常更新！
本文底部在某些邮件客户端中可能会被截断。 在线阅读完整文章，不受干扰。
在线阅读完整文章
1. Codex 在 OpenAI 全面接管
我参观该公司总部后最印象深刻的收获是，Codex——以及最近的 Codex 和 ChatGPT Work——已经接管了那里的 一切 ，大约从一月开始。桌面端负责人 Andrew Ambrosino 告诉我：
“过去几个月的主题是，现在一切都是编码智能体。无论可见的代码是否是你的产出，智能体都会编写你的工件。
可以这样想：你的整个生活都通过软件进行。你的电脑里有这些强大的工具（智能体），而循环、推理和编写代码的能力就是做一切事情的能力。”
下面的 token 使用量图表显示了这种突然的采用激增：
在四个月的时间里，财务、招聘和法律等非工程组织对 Codex 的使用率从约 0% 上升到 90%。如今，几乎所有 OpenAI 员工每周都会使用 Codex 和 ChatGPT Work。那么，发生了什么？
OpenAI 于二月发布了 Mac 版 Codex 应用，三月发布了 Windows 版，并于七月发布了 ChatGPT Work（由 Codex harness 驱动）。此后，那里的非工程师将所有工作流都迁移到了 Codex，然后又迁移到了 Work。 注意：OpenAI 内部版本的 Codex 比外部版本先进得多，因为它几乎接入了所有 OpenAI 系统 —— 类似于 Ramp 的 Inspect AI 智能体 的接入方式。
有趣的是，在 Codex 应用对非工程用户并不友好（难以使用）的时候，OpenAI 在非工程团队中却获得了接近 40% 的采用率。在二月到四月之间，Codex 应用仍然会在屏幕上显示代码，但即便如此，工程部门以外的非技术同事 仍然 使用它，因为它能完成复杂工作，比如研究并创建演示文稿、文档、电子表格，或产生丰富输出的任务。如今，这些人都是它的重度用户。
能够在更复杂的事情上工作更长时间推动了采用。 OpenAI 为 Codex 添加了 /goal 设置，你可以为智能体设定一个目标，它会持续工作直到完成。在四月到五月之间，使用率从 60% 激增到 90%。Andrew 认为，harness 对长时间运行任务处理能力的改进是原因之一：
“最大的变化是人们开始使用更长时间的线程，这种更长时间的使用是一个突破。看到人们在一个线程上花费的时间之长——甚至几天！——令人惊讶。他们通常会设定一个目标，然后让模型持续运转。
Codex 擅长长时间运行的任务，似乎会导致人们并行处理的事情变少。这是因为长时间运行的智能体常常会衍生出其他智能体去做其他事情，从而减少了作为人类的你需要管理的范围。”
Codex 团队认为，“认知悬置”是快速采用的另一个原因。 正如生产力团队工程负责人 Akshay Nathan 告诉我的：
“很长一段时间里，我们存在一种‘能力悬置’：模型有能力，但产品没有完全发挥出来。现在，我们看到的是认知差距。有些人已经发现可以用 Codex 监控 Slack、更新 Airtable 或制作入职材料。但很多人仍然只把它用于一项任务，然后通过同事的口口相传发现更多用途。
但在表面之下，你还可以用 Codex 做更多事情。”
特定角色和特定团队的插件被创建并分发。 加速采用的另一件事是，每个团队开始将有用的特定角色工作流作为插件分发。Andrew 解释了为什么不能只提供一个通用的编码代理：
“如果你构建一个什么都能做的产品，团队需要一种方式让它成为自己的。你不能只给每个人一个空盒子。技能和插件让团队能够将代理适配到他们的工作中。有时，我们还需要新的应用能力，比如代理可以配合这些技能使用的浏览器。但同样的构建模块已经覆盖了许多不同的角色。”
领域专家被嵌入 ChatGPT Work 工程团队。 在某些领域，模型已经比开发者更‘聪明’，因此开发者无法在这些领域将‘品味’注入到框架中。所以，领域专家被引入工程团队。这是 ChatGPT Work 被如此多非工程领域使用的一个结果：嵌入工程团队的专家就什么是好的幻灯片、电子表格或商业报告向开发者提供建议。
当然，领域专家加入工程团队是打造高质量产品数十年来的最佳实践。似乎每隔几年，这一点就会在不同情境下被重新发现！
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）。
另外，别忘了 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（持续部署）流程？在这个世界里，可观测性意味着什么，人们又该如何与拉取请求交互？
如果你问我，我们今天做代码审查的方式越来越不合理，拉取请求也是如此。
我们现在看到智能体式代码审查，会通过一系列不同视角来审视代码变更。过去，让云基础设施工程师和安全工程师审查每一处代码变更并不现实。有了智能体，这变得可能。
我们也可以重新思考如何用智能体部署代码。 我们正在构建一个智能体，它会“手把手”护送一项变更一路到生产环境——无论是代码变更还是功能开关背后的变更。它会观察相关的监控图表，但也能构建自己的仪表盘来监控重要信号。我们越来越多的代码变更正带着这种智能体监控进入生产环境。”
部署原生移动应用正成为一个日益痛苦的瓶颈。 当拉取请求数量增加十倍时，在后端或 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 如今的智能体基础设施流水线对比：
流水线：
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 的人交谈后收集到的信息。
阅读更多