ARTICLE · 1020368
【技术解读】OpenAI 的智能体软件工厂:来自内部的一线观察
【技术解读】OpenAI 的智能体软件工厂:来自内部的一线观察「在 OpenAI，工程师、研究员、财务同事和营销同事们都在无限 token 预算下工作。」这句话出自 The Pragmatic Engineer 的作者 Gergely Orosz 之口。他最近再度探访了这家前沿实验室，想搞清楚一个所有工程师都关心的问题：当 AI 深度介入开发流程之后，一家顶级科技公司到底是怎么写软件的 [1]。 这次探访的分量来自受访者名单。Orosz 与七位 OpenAI 的工程负责人和工程师深入对谈，覆盖了应用基础设施（Venkat Venkataramani，VP of Engineering, Applied Infra）、ChatGPT（Sulman Choudhry，Head of Engineering）、桌面端（Andrew Ambrosino，Lead）、Core Agent 团队（Joe Gershenson，Lead）、生产力工程（Akshay Nathan，Engineering Lead）、Codex（Ahmed Ibrahim）以及 Responses API（Steve Coffey）[1]。名单本身就是一个信号：这次聊的刚好是 OpenAI 软件生产链路的每一环。 与一年前相比，最大的变化可以用一句话概括：Codex 已经从「有了更好」的工具，变成了整个公司运转的骨架。Orosz 的观察是，这一切在 1 月前后开始加速，而且没有来自上层的强制命令 [1]。 这篇博客基于 Orosz 的原文逐段解读，所有事实、数据与引语均出自原文 [1]，关键图表也从原文中提取。全文围绕七个话题展开：Codex 如何接管 OpenAI、IDE 与 Pull Request 的式微、智能体软件工厂、工程工具链的演变、十亿用户规模的基建打法、API 的可靠性与性能，以及软件工程师这份职业本身的变化。 
2026 年 1 月前后，OpenAI 内部发生了一次安静的迁移：Codex 从工程师的工具箱扩散到财务、招聘、法务等几乎每个部门，而且没有任何来自管理层的强制命令 [1]。四个月里，非工程部门的使用率从接近 0% 冲到 90%。如今，几乎全员每周都在用 Codex 和 ChatGPT Work [1]。原文中那张按部门统计的用量曲线图，把这次陡峭的爬坡拍得清清楚楚 [1][2]。 桌面端负责人 Andrew Ambrosino 的总结相当直白，值得整段引用： 「过去几个月的大主题是：一切皆编码智能体。无论最终产出里有没有可见的代码，你的成果物都是智能体写出来的。这样想：你的整个生活都经由软件运转。你手上有这些强大的工具，而循环、推理、写代码的能力，就是做任何事的能力。」[1] 把时间线拉直看更有意思。OpenAI 在 2 月发布了 Mac 版 Codex 应用，3 月发布 Windows 版，7 月上线由 Codex harness 驱动的 ChatGPT Work [1]。2 到 4 月间，这款应用对非技术用户其实相当不友好，界面上还会直接展示代码，即便如此非工程团队的使用率也接近 40%。原因很简单：它能完成调研、写演示文稿、做文档和表格这类有丰富产出的复杂任务 [1]。用户用脚投票，投给了结果，投给了界面友好之外的东西。 真正的引爆点是长任务能力。OpenAI 给 Codex 加上了 /goal 设定：给智能体一个目标，它会一直干到达成为止。4 到 5 月间，使用率从 60% 蹿升到 90% [1]。Ambrosino 认为 harness 对长任务的处理改进是原因之一： 「真正在变的是，人们开始在一个会话里工作长得多的时间，这种长时间使用是突破口。看到人们在一个线程上花的时间以天计，很惊人。他们常常设一个目标，然后让模型一直转。Codex 擅长长任务之后，人们并行开的东西反而变少了：长任务智能体往往会自己分派出别的智能体去干活，你作为人类需要管理的面积就缩小了。」[1] 快速普及还有一个原因，Codex 团队称之为「awareness overhang（认知过剩）」。生产力工程负责人 Akshay Nathan 在访谈里是这样解释的： 「很长时间里我们处于『能力过剩』：模型很强，产品没完全发挥出来。现在我们看到的是认知差距。有些人已经发现可以用 Codex 盯 Slack、更新 Airtable、做入职材料，但还有很多同事只用它做一件事，然后靠口口相传发现新用法。水面之下，能做的事还有非常多。」[1] 两个细节值得注意。其一，插件在加速扩散：各个团队把适用于自身角色的流程做成插件分发。Ambrosino 的说法是，如果你造了一个什么都能做的产品，团队就需要办法把它变成自己的，你不能只发给每个人一个空盒子 [1]。其二，OpenAI 内部版 Codex 比外部版本先进得多，因为它接入了几乎每一个内部系统，接入深度类似于 Ramp 的 Inspect AI 智能体 [1]。 还有一个耐人寻味的组织变化：领域专家被编进了 ChatGPT Work 的工程团队。因为模型在某些领域已经比开发者更懂行，开发者没法在这些领域向工具灌输「品味」，于是懂行的人直接加入了工程团队，告诉开发者一份好的幻灯片、表格或商业报告长什么样。原文点明，这是 ChatGPT Work 被大量非工程领域使用带来的结果之一 [1]。Orosz 顺带调侃了一句：领域专家进工程团队是几十年的老最佳实践，每隔几年就会被重新发现一次 [1]。 今天的 OpenAI 已经完全依赖 Codex 和 Work。依赖到什么程度？出现哪怕轻微故障时，同事发来的内部消息往往和自动告警同时、甚至更早抵达 Codex 和 Work 团队 [1]。两年前，世界上还没有 AI 智能体，只有高级一点的自动补全。这个对比，是原文里最扎眼的一句注脚。 
2025 年 12 月，Codex 团队还在为要不要发布桌面应用而纠结。Ambrosino 当时脑中有一个失败的剧本： 「我们已有终端里的 Codex CLI，市面上也有大而全的 IDE，那么一个介于终端和 IDE 之间的开发工具还有生存空间吗？我脑中的剧本是它会像 iPad 那样不合身：很多人买了 iPad 然后吃灰，要么转头用更便携的手机，在这个比喻里相当于 CLI，要么用功能齐全的笔记本，相当于 IDE。再加上 11 月 Antigravity 作为 VS Code 的分叉发布了，更让人怀疑我们是不是也该分叉 VS Code。但我们抵制了这个诱惑，凭直觉押注：智能体越强，IDE 越不重要。」[1] 结果自 1 月起，OpenAI 内部的 IDE 使用量持续下降，这一把押对了 [1]。有意思的是，Codex 应用自己反而在向 IDE 靠拢，6 月上线了应用内编辑文件的能力 [1]。工具的边界在两条线上互相试探。 另一个更硬核的变化发生在流水线上。Venkat Venkataramani（VP of Engineering, Applied Infra）描述的负载曲线像一根曲棍球杆： 「人均 Pull Request 数量在以非常高的加速度增长。构建、测试、部署流水线的每一环都在承受大得多的负载。我们说的是部分系统上大约 10 倍的负载增长。在大多数公司，这种增长也许要两三年才发生；在 OpenAI，我们大约六个月就见到了。这种加速会在各处暴露瓶颈：版本控制系统要扛住更多代码的编写与推送，CI/CD 系统要随之扩容，生产发布流程也要消化高得多的变更速率。每个月我们醒来都会发现一组新的基础设施扩展难题。刚以为为下一阶段增长备足了容量，模型又解锁一波新能力，系统别处又冒出一批新瓶颈。」[1] 负载背后是工作方式的重新想象。Venkat 的判断是：今天的 code review 与 Pull Request 方式越来越说不通了 [1]。正在进行的试验包括三件事。智能体代码审查：多个智能体各自带着一个「领域专家」配置来审同一条变更，相当于让每个相关基础设施团队都派一位人类专家审每一条代码；过去让云基础设施工程师和安全工程师审遍每条变更并不现实，智能体让它成为可能 [1]。按风险分级放行：高风险变更走更严格的流程，比如触发更多轮 AI 审查，或要求人类在智能体之后再复核；低风险变更可以走更轻的通道，部分代码库区域已启用智能体自动批准，人类签核从瓶颈位置上退了下来 [1]。陪伴式部署：一个专属智能体的指令可以概括为「把这个变更一路护送到生产环境安全全量」，它盯监控图，还能自己搭建仪表盘观察关键信号，越来越多的代码变更在这种智能体监护下进入生产 [1]。 Orosz 对「领域专家智能体」的说法起初是怀疑的：给通用智能体安一个头衔，审查结果真的会不同吗？他后来想通了。所有 Codex 智能体都能访问 OpenAI 的全部代码与文档，这位「云基础设施专家」大概率已经吸收了大量相关上下文，能给得出高度针对性的反馈。关键在于这类智能体如何配置、能访问什么上下文、如何聚焦本领域以用好有限的上下文窗口 [1]。 整条链路上最疼的瓶颈，反而是原生移动应用。后端与 Web 的部署可以靠堆基础设施硬扛，iOS 和 Android 的每次更新却都要过苹果与谷歌的人工审核，一耗就是几小时到几天 [1]。ChatGPT 工程负责人 Sulman Choudhry 曾在 Facebook 亲历过上一个时代的解法： 「2010 年代，Facebook 在移动端发布速度上有个重要突破，App Store 发布从每月一次到双周再到每周，配合实验与特性开关，代码可以先上船、功能再远程开启。那套模型给移动端带来了高得多的速度。到了 Codex 时代，我认为我们撞上了这个问题的下一版本：代码生成快得惊人，把这些代码送进用户手机却快不起来。对使用高度移动优先的 Codex 来说，这个差距已经让我们和用户都感到痛了。如果软件几分钟就能写完，等几天甚至几周才能上手机，越来越显得荒谬。我们该追求的目标是原生移动端的发布速度与 Web 一样快。今天，我们还差得远。」[1] Orosz 的收尾点评带一点苦笑的意味：从 2008 年 App Store 上线算起，18 年过去了，苹果依然不允许应用正式绕过审核发布实质性的体验变更。代码生产的速度换了几代人，闸门还是当年那一道 [1]。 「软件工厂」这个词借自制造业：机器人和人一起造汽车的地方，换成智能体和人一起造软件。制造业里还有全自动的「黑暗工厂」，因为车间没有人，连灯都不用开。软件工程会不会也走到那一步？Orosz 的观察是，OpenAI 今天真的有一座「软件工厂」在运转，而且全部围绕 Codex 搭建 [1]。原文的叙述把传统开发流水线与 OpenAI 现行的智能体流水线做了对照，下面这张截图取自原文，画的是这条智能体流水线本身，从 builder 定义目标一路画到 Perf Factory 与 Sevbot [1][3]。 整条流水线可以拆成九道工序 [1]： 这张九工序清单读下来，最值得咀嚼的设计选择其实只有一个词：闭环。从目标定义到故障响应，每个环节的产出都成为下一个环节的输入，生产监控的数据又回流到开发。工厂之所以叫工厂，靠的就是这个。 
原文第 4 部分的标题与第一段之后，紧跟的就是付费订阅提示。公开可见的最后一段写的是：Codex 正在改变构建内部工具的难易程度，也在影响调试这类标准工程实践 [1]。为了不编造，本节只复述 Orosz 在原文目录中亲自写下的四条提要，并如实说明这些主题的完整内容属于付费部分。 即便只是四句提要，信息密度也足够高。CPU 成为瓶颈与刻意放慢部署这两条，尤其值得基础设施方向的从业者去读原文 [1]。 把 Orosz 这份探访读下来，热闹的细节很多，真正值得带走的判断有三条。 第一条，工具层面，接入深度决定能力上限。OpenAI 内部版 Codex 之所以比外部版本先进得多，原文给出的原因是它接入了几乎每一个内部系统：文档搬进源代码、权限铺到 Databricks 和 Datadog、连内部技能都由 Codex 自己维护 [1]。换算成一句可以搬回自己团队的话：智能体能摸到多少上下文，在很大程度上决定它能发挥多少价值。 第二条，流程层面，人从流水线的必经节点上退下来，退到高风险处。按风险分级放行、低风险自动批准、智能体守着 PR 到变绿、部署后有专属智能体护送，这些设计的共同点是把人类的注意力留给真正需要判断力的位置 [1]。 第三条，职业层面，工程师的角色在上移。Venkat 的观察是，OpenAI 的工程师正变得越来越像产品经理，而不太像传统的系统工程师；相应地，判断力、优先级排序与品味变得更值钱 [1]。九道工序里留给人类的岗位，恰好都是关于「做什么」与「值不值得」的岗位。 最后回到 Orosz 的两句收尾观察。其一，OpenAI 已经完全依赖一个共享 harness，工作经由 Codex 和 Work 发生，基本再无别的通道 [1]。其二，两年前这个世界上还没有 AI 智能体，只有高级一点的自动补全 [1]。一个值得每位读者自问的问题：如果连 OpenAI 都在重新思考 Pull Request 和代码审查，我们自己流程里那些「理所当然」，还能理所当然多久？ 参考资料 1.Gergely Orosz. Inside OpenAI's agentic software factory. The Pragmatic Engineer, 2026. 原文链接：newsletter.pragmaticengineer.com/p/openai-software-factory。正文引言与前三部分为公开内容，第 4 部分中段起为付费订阅内容，本文所有事实均出自公开可见部分及作者目录提要。 2.Codex usage since August 2025 at OpenAI by department. 数据图表，来源：OpenAI，刊载于文献 [1]，本文第一节引用。 3.OpenAI's "agentic software factory". 流水线示意图，刊载于文献 [1]，图注为 OpenAI's "agentic software factory"，本文第三节引用。 图片来源说明：第一节与第三节的图表取自文献 [1]（原始出处为 OpenAI）；引言处的自动化工厂照片来自 Unsplash，摄影师 Simon Kadula，仅作视觉隐喻使用。
OpenAI 的智能体软件工厂：来自内部的一线观察
一、Codex 如何接管 OpenAI：一场没有行政命令的迁移
二、IDE 的式微与 Pull Request 的重造
三、智能体软件工厂：九道工序的全自动流水线
人类定义目标。工程师或产品经理描述问题与期望结果。判断力、优先级排序和品味在这一步变得更值钱。Venkat 有个有趣的观察：OpenAI 的工程师正变得越来越像产品经理，而不太像传统的系统工程师 [1]。 Codex 收集上下文。OpenAI 把全部文档搬进了源代码，方便智能体理解代码。Codex 还接入了 Git 仓库与 GitHub、Slack 与 Notion、Databricks 与 Datadog 及内部日志等数据源，甚至包括部分由 OpenAI 内部的 Codex 实现自己维护的内部技能 [1]。接入深到什么程度？新工程师入职时被引导去问 Codex 任何问题，因为它掌握的上下文多得惊人 [1]。 Codex 实现代码变更。这一步在原文里的形容是「足够平凡」：改代码、验证、迭代，直到目标达成 [1]。 构建、测试与 CI。智能体构建代码、跑测试、修坏项，然后提交 Pull Request 触发 CI。它会守着 PR 直到变绿，CI 挂了就自动修。新增了一个性能 harness：有性能风险的 PR 会被送去 Synthetics A/B 框架评估性能影响 [1]。 智能体代码审查。上节提到的多位「领域专家」审查在这里落地。变更按风险分级：高风险走更严流程，必要时人类复核；低风险可由智能体自动批准。合规审查同样可以由智能体或人类按需触发。以现在的 PR 数量，没有智能体帮忙，人类根本审不过来 [1]。 智能体部署。人类批准上生产后，这个变更会分到一位专属智能体，指令大意是「把这个变更一路护送到生产环境安全全量」。它连特性开关后的变更都能处理：读代码找到开关位置、理解变更含义、判断成功与失败的信号、给自己搭一个监控仪表盘、然后盯着生产信号。OpenAI 的长期目标是造出「每个变更一位自主 SRE」[1]。 观测生产。仪表盘由智能体在部署时自己生成，配上内部可观测性栈的日志、指标、链路追踪与宽事件数据。Orosz 特意指出一个变化：上次探访时还是工程师手工搭服务监控面板，这次已经变成智能体按「每个变更」的粒度自动生成 [1]。 生产监控回流开发。Perf Factory 用智能体筛告警与仪表盘、去重信号、识别真实的延迟回归、定位根因并给出修复建议，把工作流从部署延伸到持续改进 [1]。 响应故障。内部事件响应智能体 Sevbot 同样构建在 Codex 之上。故障发生时它会「醒来」：收集上下文、列出可选缓解措施（但一个都不执行）、在 Slack 频道里回答工程师的提问，工程师可以指令它执行某个具体缓解动作。OpenAI 的目标是由 Sevbot 自主缓解部分故障，梦想是值班的人不再半夜被叫醒，回来上班时复核它的动作就行。就目前而言，值班这件事还没成为历史 [1]。
四、付费墙之后的四个话题：原文目录透露了什么
工程工具与实践的变化：手工搭建的内部工具正逐步被 Codex 取代；在调试这件事上，大家越来越多地直接用 Codex，胜过使用专用工具；而在软件工厂里，harness（驱动智能体的那套工具链）的效率至关重要 [1]。 面向十亿用户的工程：基础设施的策略是先采购、后自研；此外还有基建的地理分布、容量规划的战术与挑战 [1]。 让 API 更可靠、更高效：CPU 正在成为瓶颈；团队在刻意放慢部署节奏；以及负载难题的解法 [1]。 软件工程师职业的变化：工程内部的专精分工正在消失，判断力与主观能动性变得更重要；以前被认为「不可能」的重写与迁移，如今一两个工程师就能做成 [1]。