走进 OpenAI 的智能体软件工厂：Codex 如何接管一家前沿实验室

本文基于 Gergely Orosz（The Pragmatic Engineer）2026 年 9 月 15 日的深度报道整理。作者实地走访 OpenAI 总部，访谈了七位工程负责人与工程师：Venkat Venkataramani（应用基础设施工程副总裁）、Sulman Choudhry（ChatGPT 工程负责人）、Andrew Ambrosino（桌面端负责人）、Joe Gergershenson（核心 Agent 团队负责人）、Akshay Nathan（生产力团队工程负责人）、Ahmed Ibrahim（Codex 工程师）与 Steve Coffey（Responses API 工程师）。

在 OpenAI，工程师、研究员、财务同事和市场同事都用着不受限制的 token 预算工作。这种事在别处很罕见。去年作者曾到访 OpenAI 总部，一年后再去，变化是根本性的：Codex 已从「有它更好」的工具，变成公司里几乎所有事情的骨架。

一、Codex 接管 OpenAI

从今年 1 月左右开始，Codex——以及近期的 Codex 和 ChatGPT Work——接管了那里的一切。桌面端负责人 Andrew Ambrosino 说：

「过去几个月最大的主题是：一切现在都是编码智能体。无论可见的代码是不是你的产出，智能体都在写你的产物。可以这么理解——你的整个生活都经由软件。你电脑里有这些强大的工具（智能体），而循环、推理和写代码的能力，就是做一切事情的能力。」

图 1：2025 年 8 月以来 OpenAI 各部门的 Codex 使用情况。图片来源：OpenAI

数据显示：在四个月内，财务、招聘、法务等非工程部门对 Codex 的使用率从约 0% 升到 90%。现在几乎所有 OpenAI 员工每周都在使用 Codex 和 ChatGPT Work。发生了什么？

• 产品节奏。Codex Mac 版 2 月发布、Windows 版 3 月发布，ChatGPT Work（由 Codex harness 驱动）7 月推出。非工程岗随即将全部工作流迁到 Codex，再迁到 Work。
• 在「难用」时就已经起量。值得玩味的是，OpenAI 在非工程团队做到接近 40% 采用率的那个时间点，Codex 应用对非工程用户其实并不友好——2 月到 4 月间，应用还会在屏幕上直接显示代码。但非技术同事依然在用，因为它能完成研究、做演示文稿、文档、电子表格这类产出丰富的复杂工作。如今这批人已是重度用户。
• 能做得更久、更复杂，是采用的直接推手。OpenAI 给 Codex 增加了 /goal 设定：你给智能体设一个目标，它会一直干到完成为止。4 月到 5 月，使用率从 60% 冲到 90%。Andrew 认为 harness 对长时任务处理能力的改善是原因之一：

「变化最大的一点是，人们开始把一个 thread 用得非常久，这种长时间使用是一个突破。你会惊讶于人们花在一个 thread 上的时间长度——甚至好几天！他们常常设一个目标，然后让模型去转。」

「Codex 擅长长时任务，反而让人们并行做的事变少了。因为一个长时运行的智能体常常派生出其他智能体去做别的事，这就减少了你作为人类需要管理的表面积。」

• 「认知鸿沟」取代「能力鸿沟」。生产力团队工程负责人 Akshay Nathan 的说法是：过去很长时间是「能力过剩」——模型有能力，产品没把它带出来；现在则是一个「认知缺口」：有人发现可以用 Codex 盯 Slack、更新 Airtable、做入职材料，但更多人只用它做一件事，然后从同事那里口口相传发现新用法。「水面之下，Codex 能做的还有太多。」
• 角色专属插件被自发分发。每个团队开始把好用的、角色专属的工作流做成插件分发出去。Andrew 解释为什么不能只给一个通用编码智能体：「如果你做一个什么都能干的产品，团队需要一种办法把它变成自己的。你不能只给大家一个空盒子。Skills 和插件让团队把智能体适配到自己的工作。有时我们也需要新的应用能力，比如智能体可以和这些技能一起使用的浏览器。但同样的积木已经覆盖了非常多的不同角色。」
• 领域专家被嵌入 ChatGPT Work 工程团队。在某些领域里模型已经比开发者「更懂」，开发者无法把自己的「品味」注入 harness。于是领域专家被引入工程团队，告诉开发者一份好的幻灯片、电子表格或业务报告长什么样。（这其实是做高质量产品几十年的老经验，只是每隔几年就在新语境里被重新发现一遍。）
• OpenAI 已完全依赖 Codex 和 Work。依赖到什么程度？即使是轻微故障，同事在内部的通报会和自动化告警同时——甚至更早——到达 Codex 与 Work 团队。从外部看，这种对单一共享 harness 的依赖尤其扎眼：两年前还没有 AI 智能体，只有高级 AI 自动补全。

二、IDE 与 Pull Request 的「死亡」

去年年底，Codex 团队曾为是否发布桌面应用而犹豫。Andrew 回忆：

「2025 年 12 月，我们并不确定会不会发布 Codex 应用。我们有 Codex CLI 作为终端，外面又有大而全的 IDE。那么，一个介于终端和 IDE 之间的开发工具，还有空间吗？我脑子里有个未来画面：它行不通，会像 iPad 那样是个『不合适』的产物。很多人买了 iPad 就再也不用了：他们要么用更小更便携的智能手机（这个类比里相当于 CLI），要么用功能丰富的笔记本（相当于 IDE）。另外别忘了 11 月 Antigravity 作为 VS Code 分叉出来了，这更让人觉得也许我们也该为 Codex 应用分叉 VS Code。但我们还是抵挡住了诱惑，凭直觉下注：随着 AI 智能体变强，IDE 会越来越不重要。」

结果看，1 月以来 IDE 使用量确实在下降，这个赌注押对了。不过 Codex 应用本身也在变得有那么一点像 IDE——比如 6 月上线了在应用内编辑文件的能力。

CI/CD 承受了暴涨的负载

Codex 带来生产力提升的一个直接证据，是流经 OpenAI 开发基础设施的代码量。更多代码被创建和推送，带来了新的规模化挑战。应用基础设施工程副总裁 Venkat Venkataramani 说：

「人均 Pull Request 数像曲棍球棒一样增长（速率非常高且在加速）。构建—测试—部署流水线的每一环都承受着剧增的负载。我们说的是某些系统上大约 10 倍的负载增长。在大多数公司，这种增长可能要两三年才会发生；在 OpenAI，我们大约六个月内就看到了。」

「这种加速暴露了各处的瓶颈：版本控制要处理远超以往的代码写入和推送，CI/CD 系统要跟着扩容，生产发布流程要吸收高得多的变更速率。每个月我们醒来都要面对一组新的基础设施扩展难题要解决。就在我们以为为下一阶段增长准备了足够容量时，模型又解锁了新一轮能力，在系统别处制造出一组新的瓶颈。」

PR 与代码评审需要被重新想象

「在这种开发加速之中，我们应该问自己：如何重新想象那些我们习以为常的东西。比如，我们如何重新想象 CI 与 CD 流程？可观测性在这个世界里意味着什么，人们应该如何与 Pull Request 交互？依我看，我们今天做代码评审的方式越来越说不通了，Pull Request 也是如此。我们正在看到智能体代码评审，它从一系列不同的视角审视代码变更。过去，让一位云基础设施工程师和一位安全工程师评审每一个代码变更是不切实际的；有了智能体，这成为可能。我们也可以重新想象用智能体部署代码的方式。我们正在构建一个『一路护送』变更到生产的智能体——无论是代码变更还是藏在 feature flag 后面的变更。它观察相关的监控图表，还能自建仪表盘来监控重要信号。我们越来越多的代码变更是在这种智能体监控下进入生产的。」

一个越来越痛的瓶颈：原生移动端发布

PR 数量涨十倍，后端和 Web 的部署需要更多基础设施来承接；而当你重做完 CI/CD、保证容量之后，你要向生产环境发布的是多出十倍的 PR。真正的卡点出现在 iOS / Android 原生应用的更新上——每一次应用更新都要经过 Apple 和 Google 的人工审核，耗时数小时到数天。

ChatGPT 工程负责人 Sulman Choudhry（此前在 Facebook 工作过）这样对比：

「2010 年代，Facebook 在如何更快发布原生移动代码上有过一次重要突破。App Store 发布从每月一次，到两周一一次，再到每周一次。同时，实验和 feature flag 让团队可以在功能就绪前就发布代码，然后远程打开。那个模型给移动端带来了大量速度。在 Codex 时代，我认为我们正在撞上这个问题的下一个版本：代码生成在急剧变快，但让这些代码进入原生移动端用户手中并没有变快。对 Codex 来说，它的使用是重度移动优先的，这个差距对我们和用户都已经变得痛苦。我预计这里的压力会快速上升。如果软件可以在几分钟内写好，那为了让它上到手机上等几天甚至几周，就越来越显得荒谬。我们应该追求一个『在原生移动端发布代码像在 Web 上一样快』的世界。要做到这一点，可能需要对我们发布什么、什么时候发布、什么可以远程激活做一些有创意的重新思考。今天，我们离那儿还差得远。」

一个讽刺之处是：今天发布原生 iOS 或 Android 应用的挑战，和 2008 年 App Store 上线时一模一样。18 年过去，变化不大——Apple 至今仍不允许应用绕过 App Store 审核去推送有意义的体验变更。

三、OpenAI 的智能体软件工厂

「软件工厂」的类比来自实体工厂：工厂里机器人和人类一起造汽车，软件工厂里则是 AI 智能体和人类一起造软件。有些制造现场是全自动的「黑灯工厂」，因为没有人，连照明都不需要。那么软件工程里会不会也出现同样的全自动流程？在今天的 OpenAI，就有一条围绕 Codex 运转的「软件工厂」。

图 2：传统的软件开发流水线 vs OpenAI 今日的智能体基础设施流水线。图片来源：The Pragmatic Engineer / OpenAI

流水线九步

1. 人类「建造者」定义期望结果。由软件工程师或产品经理说明问题和期望产出。判断力、优先级取舍和品味在这个阶段变得越来越重要。Venkat 提到一个有意思的现象：OpenAI 的工程师正在变得更像产品经理，而不是传统的系统工程师。
2. Codex 收集上下文。OpenAI 已把所有文档搬进源码内部，让智能体更容易理解代码。Codex 还能访问：Git 仓库与 GitHub、Slack 与 Notion、内部数据源（Databricks、Datadog、内部日志等）、内部 Codex 技能——其中一部分技能由 OpenAI 自家的 Codex 实现自己维护。Codex 被「接通」得如此彻底，以至于新工程师入职时会被指引：有任何问题都去问 Codex，因为它掌握的上下文多得惊人。
3. Codex 实施代码改动。这一步相对平淡：Codex 开工，做一连串代码改动直到达成目标，然后验证软件确实按预期工作。
4. 构建、测试，然后进 CI。智能体构建代码、跑测试、在测试挂掉时修代码，然后创建 Pull Request。这个 PR 触发 CI 服务器跑一轮更彻底的 lint 与测试。智能体会「照看」这个 PR 直到它变绿，修掉任何 CI 失败并自动更新 PR。这里还有个新东西：perf harness——智能体会用性能 harness 把有问题的 PR 送到 Synthetics A/B 框架去评估性能影响。前面提到，过去六个月 CI 系统的负载大幅上升。
5. 智能体代码评审。OpenAI 不用一个通用的 AI 评审者，而是派生出多个智能体，每个都配置成某个「领域专家」。Venkat 说，他们认为这等同于让每一个相关基础设施团队的人类领域专家来评审每一次变更。变更按风险分级：高风险变更走更严格的流程（比如调用更多 AI 评审，或在 AI 智能体完成后强制要求人类评审）；低风险变更走更容易的路径，代码库的某些区域可以选择性地启用一个「自动批准低风险 PR」的智能体，把人类审批从瓶颈上去掉，提升速度。风险评估还有一个巧妙之处：OpenAI 可以自动化判断何时需要额外的合规输入——走另一个智能体，或者走人工评审。以产出的 PR 数量，不借助智能体，人类根本不可能评审所有代码。
6. 智能体部署。人类批准变更进入生产后，这个变更会被分配专属的智能体，指令可以概括为一句话：「护送这个变更，直到它安全、完整地铺开到生产环境。」智能体既护送代码变更，也护送 feature flag 背后的变更。以 feature flag 为例，智能体会：读代码库找出 flag 在哪；理解这个变更做了什么；判断哪些信号代表成功、哪些代表失败；自建一个监控仪表盘来使用（这一点相当惊人，也是我没见过的新做法）；盯住相关的生产信号和它自己的仪表盘。OpenAI 的长远目标是做出某种「per-change autonomous SRE」——每个变更配一个能几乎自主部署的站点可靠性工程智能体。
7. 观察生产。跟踪生产系统的工具包括：前几步中由智能体生成的仪表盘，以及 OpenAI 的内部可观测性栈（一堆生成日志、指标、trace 与宽事件数据的自研工具）。相比 Codex 之前的时代，一个重大变化是：过去是工程师创建仪表盘来监控服务，现在是智能体在「每次部署变更」的粒度上做这件事。
8. 生产监控回流到开发。「Perf Factory」用智能体筛一遍告警和仪表盘、去重信号、识别真正的延迟回归、定位根因并提出修复。它捕捉由持续代码变更引入的性能问题，把工作流从部署延伸到持续改进。
9. 响应故障。Sevbot 是 OpenAI 内部的故障响应智能体，不出意外也构建在 Codex 之上。故障被检测到时，这个机器人「醒过来」，它会：收集故障上下文；判断可能的缓解措施（但绝不执行）；回答开发者的问题（它在 Slack 频道里）；由工程师指示它去应用某个具体的缓解措施。OpenAI 的目标是让 Sevbot 能在缓解部分故障时自主行动——梦想是：常规故障由 Sevbot 自主处理，人类在回来上班后复核它的动作，不再有人在下班时间被叫醒。但就目前而言，oncall 值班在这家公司还没有成为历史。

哪些是内部的，哪些是你能买到的

一个关键提醒，也是这篇文章真正的论点：OpenAI 内部版本的 Codex 比外部版本先进得多，因为它接入了几乎每一个 OpenAI 系统——类似 Ramp 的 Inspect AI 智能体被接线的方式。把上面这条流水线和市售 Codex 混为一谈，是关于这张图最常见的误读。

阶段	做什么	内部分有 vs Codex 已提供
1 建造者定义结果	工程师或 PM 定义期望产出	人类步骤，不是软件
2 Codex 写/改代码	从源码、文档、GitHub、Slack、Notion、内部技能和数据系统取上下文	Codex 写代码已提供；内部上下文图（Slack、Notion、内部数据）仅内部
3 CI 构建+测试	为智能体规模负载重建的流水线，外加 Perf Harness	已提供（你自己的 CI）；OpenAI 的扩容工作是内部的
4 智能体代码评审	数据、基础设施、云、安全领域专家智能体并行评审 + 风险分级	仅内部
5 低风险判定	低风险变更放行；高风险追加人类评审	仅内部
6 智能体部署	护送变更进生产，含 feature flag 铺开，自建仪表盘	仅内部
7 生产监控	在内部可观测性栈上看图表、信号与告警	仅内部
8 故障 → Sevbot	调查故障、提出缓解措施、回答问题	仅内部
9 Perf Factory	过滤重复告警、找延迟回归、提修复	仅内部
10 回流	智能体持续修复直到 CI 与各层评审通过，修复建议回到建造者	描述的是内部闭环

换句话说：外部团队今天能直接照搬的大约只有第 1–3 步（外加第 2 步的一小部分上下文接入），第 4–9 步描述的是一个方向，不是一个能买到的功能。这并非贬低 OpenAI——这种规模的内部工具需要数年才能长成。

四、来自 OpenAI 官方数据的交叉印证

OpenAI 经济研究团队 2026 年 6 月发布的 《How agents are transforming work》为上述观察提供了量化支撑：

• 任务时长变长。到 2026 年 5 月，80.6% 的抽样个体用户至少发起过一个估计超过 30 分钟人力工作的 Codex 请求，70.2% 超过 1 小时，25.6% 超过 8 小时。
• Codex 成为每个部门的主力工具。工程部门最先转移，法务、财务、招聘在 2026 年 4 月前后跨过「以 Codex 为主」的门槛。普通 OpenAI 员工现在超过 85% 的 output token 由 Codex 产生；由于 Codex 用户本身用得更多，它占总 token 的比例更高——Codex 占 OpenAI 内部每周 output token 的 99.8%。
• 非开发者增长更快。自 2025 年 8 月以来，个体用户中的非开发者增长 137 倍，组织用户 189 倍，OpenAI 内部 12 倍。
• 角色边界被打破。业务职能（财务、市场、运营）用 Codex 完成的工作中，超过四分之一是工程或编码类任务。
• 重度并行。到 2026 年 6 月，第 99 百分位的日活用户一天内会跑出 60 小时以上的 Codex 智能体轮次，分布在多个并行智能体上。

五、几点冷静的读法

• harness 效率是软件工厂的关键变量。Codex 采用率从 60% 跳到 90%，直接原因是 harness 对长时任务的处理改善——不是模型变大。工厂的吞吐取决于 harness 能在无人看管下跑多久、派生出多少有效子任务，而不是单点生成速度。
• 「人类需要管理的表面积」是新指标。Andrew 的观察很精准：长时智能体派生子智能体，反而减少了人类要管的东西。评估一套智能体系统时，值得量化的是人类注意力占用，而不只是产出速率。
• 评审是新的瓶颈，而风险分级是解法的一半。当 PR 涨十倍，人类评审不可能覆盖全部。OpenAI 的做法是双轨：低风险区域允许智能体自动批准，高风险强制人类复核——并且用自动化判断何时需要合规输入。
• 发布链路的最后一公里仍未打通。App Store / Google Play 的人工审核是智能体绕不过的物理约束。代码分钟级生成，上手机却要等数天，这个落差正成为新的痛点。
• 什么仍然属于人类。建造者仍然定义结果；人类仍然批准高风险变更、授权故障缓解措施；Sevbot 做过的事仍有人事后复核，oncall 轮值仍然存在。文章收尾的那句话比任何数字更能概括这场转变：「判断力、优先级取舍和品味正变得越来越重要。」

注：原文为付费订阅内容，以上整理覆盖其公开可见部分（第 1–3 节）与 OpenAI 官方经济研究数据；第 4–7 节（工程工具与实践变化、十亿用户基础设施扩展、API 可靠性与性能、软件工程职业变化）在付费墙之后，此处不作转述。推荐订阅原文获取完整内容。