编者摘要：《OpenAI 内部的智能体软件工厂》深度文章指出，Codex 正在重塑 OpenAI 内部研发流程，构建起一套智能体驱动的软件生产体系。OpenAI 内部工程师、研究员乃至财务、市场人员，都拥有近乎无上限的 token 使用额度，全面依托 AI 开展工作。
文章探访 OpenAI 前沿实验室，剖析这套智能体软件工厂的运作模式，以及面向十亿级用户规模的工程难题。传统开发流程（IDE 编码、人工提交 PR、人工代码评审）被大幅改变：大量代码编写、单元测试、缺陷自查由 Codex 智能体完成，人类工程师重心从写代码转向需求定义、校验逻辑、风险把控。
智能体软件工厂拥有标准化流水线：需求拆解、代码生成、自动化测试、安全扫描、迭代修复、打包部署、监控反馈等环节，AI 智能体自动串联。随之产生新工程挑战：大规模智能体并发调用的成本控制、代码质量一致性、模型幻觉带来的隐性 bug、版本管理和合规安全。
研发人员角色发生转变，不再以手写代码为核心能力。同时十亿用户场景带来高并发、可用性、延迟难题。文章也探讨软件工程职业的未来走向：未来软件工程师的核心价值，是清晰定义目标、校验 AI 产出、处理复杂边界问题，而非逐行编码。
10 个关键问题 Q&A
Q1：OpenAI 内部所有人都可以使用不限量 Token 吗？A：是的，工程师、研究员、财务、市场等内部同事，都享有近乎无上限 token 预算用于日常工作。
Q2：Codex 在 OpenAI 内部起到了什么样的作用？A：Codex 深度接管代码生产工作，承担编码、单元测试、漏洞自查，是智能体软件工厂的核心引擎。
Q3：传统 IDE 和 PR 流程发生了什么变化？A：人工写代码、人工提交 PR 评审的模式大幅减少，大量编码和基础代码审查交给 AI 智能体。
Q4：智能体软件工厂的核心流水线包含哪些环节？A：需求拆解、代码生成、自动化测试、安全扫描、迭代修复、打包部署、线上监控反馈。
Q5：工程师的工作内容发生了什么转变？A：从手写代码为主，转为定义需求、审核 AI 产出、识别边界风险、校验逻辑正确性。
Q6：这套体系最大的代码风险来自哪里？A：大模型幻觉，会生成看起来正确但暗藏逻辑缺陷的隐性 bug，人工很难一眼发现。
Q7：面向十亿用户规模，核心工程难点是什么？A：系统高并发、服务可用性、响应延迟，同时要控制海量智能体调用带来的算力成本。
Q8：智能体生成代码如何保障安全？A：流水线内置自动化安全扫描环节，自动检测漏洞，但复杂场景仍需要人工复核。
Q9：软件工程这个职业未来会如何变化？A：逐行编码能力不再是核心竞争力，读懂系统、精准定义目标、校验 AI 结果的能力更重要。
Q10：这套智能体软件工厂是完全自动无人化开发吗？A：不是。AI 负责基础代码生产，人类仍然把控需求方向、边界案例、重大风险与最终决策。
附录
《Inside OpenAI’s agentic software factory》译文 + 要点梳理（第 1–4 部分）
原文来源：The Pragmatic Engineer（Gergely Orosz），2026-09-15，付费专栏
标题：深入 OpenAI 的智能体软件工厂副标题：深度解析 Codex 如何 “接管” OpenAI、这家前沿实验室如何搭建智能体软件工厂，以及面向十亿用户规模的工程挑战，来自 OpenAI 内部一手信息
开篇
能拥有近乎无上限 token 预算的团队十分罕见，但在 OpenAI，所有工程师、研究员、财务、市场同事都在这样的环境下工作。最近我走访了这家全球顶尖前沿实验室，了解 OpenAI 当下的运作模式，也一窥软件工程这个职业未来可能走向何方。
相比去年到访 OpenAI 总部时，一切早已物是人非。短短一年，Codex 从一个 “锦上添花” 的工具，变成了公司几乎所有业务的底层支柱。
为完成这次调研，我采访了 7 位 OpenAI 工程负责人与工程师：应用基础设施工程副总裁 Venkat Venkataramani、ChatGPT 工程负责人 Sulman Choudhry、桌面端负责人 Andrew Ambrosino、核心智能体团队负责人 Joe Gershenson、生产力工程负责人 Akshay Nathan、Codex 工程师 Ahmed Ibrahim、Responses API 工程师 Steve Coffey。感谢所有人接受采访！
本文将覆盖这些主题：
刊前通知：本周我在纽约参加 LDX3 大会，同时拜访当地多家初创企业与科技公司，周四《The Pulse》暂停更新，下周恢复正常更新。部分邮件客户端可能截断文章，完整原文：https://newsletter.pragmaticengineer.com/p/openai-software-factory
一、Codex 接管 OpenAI
这次走访最震撼的结论：大约从今年 1 月起，Codex（以及后续的 Codex+ChatGPT Work）接管了公司几乎全部工作。桌面端负责人 Andrew Ambrosino 这样描述：
“过去几个月最大的主题：一切都变成编码智能体。无论最终产出是否是可视化代码，各类工件都由智能体生成。可以这么理解：你的全部工作都依托软件完成。你的电脑里有强大的智能体工具，而循环推理、编写代码的能力，几乎可以完成所有事。”
Codex token 用量图表清晰展示了爆发式增长。OpenAI 内部，2025 年 8 月起按部门统计的 Codex 使用数据显示：短短 4 个月，财务、招聘、法务等非工程团队，Codex 使用率从接近 0% 飙升至 90%。如今几乎所有 OpenAI 员工每周都会使用 Codex 和 ChatGPT Work。
背后的时间线：
之后非技术员工陆续把工作流迁移到 Codex，再迁移到 ChatGPT Work。
注意：OpenAI 内部版本 Codex 远强于对外公开版本，它深度接入 OpenAI 几乎所有内部系统，类似 Ramp 内部 Inspect 工具的深度集成模式。
最有意思的一点：Codex 客户端早期对非技术用户并不友好，界面还会直接展示代码，但依然在非工程团队实现了接近 40% 渗透率。2–4 月，就算界面直接露出代码，财务、法务这类非技术员工依然坚持使用，因为它能完成复杂任务：调研、生成 PPT、文档、表格，产出丰富的业务成果。如今这群人已经是重度用户。
长任务能力是爆发增长的核心推手OpenAI 给 Codex 增加了
/goal目标指令：你可以给智能体设定目标，它持续运行直到任务完成。4–5 月使用率从 60% 涨到 90%。Andrew 认为，执行层对长任务的处理能力提升是关键：“最大的变化是，大家开始用更长的对话线程。这种长任务能力是重大突破。人们在单一线程里投入的时长超乎想象，甚至跨好几天。通常只需要设定目标，交给模型持续执行。Codex 擅长长时间任务，反而让大家减少并行处理多件事。因为长任务智能体会自动派生其他子智能体处理子任务，大幅减少人类需要管理的工作量。”
Codex 团队把另一增长原因称为能力认知滞后（awareness overhang）。生产力工程负责人 Akshay Nathan 解释：
“很长一段时间，我们处在‘能力储备过剩’：模型能力已经到位，但产品没能完全释放。现在进入认知缺口阶段。一部分人发现能用 Codex 监控 Slack、更新 Airtable、制作入职材料；很多人只用来做单一任务，再通过同事口口相传挖掘更多用法。Codex 底层还藏着大量尚未被挖掘的能力。”
面向岗位 / 团队的插件生态加速普及各团队把岗位专属工作流打包成插件分发。Andrew 解释为什么不能只提供一个通用编码智能体：
“如果产品号称无所不能，团队就需要自定义适配的方式。不能直接丢一个空白工具给所有人。技能与插件可以让智能体适配团队业务。有时我们还需要配套新能力，比如让智能体调用浏览器。但这套基础组件已经可以覆盖大量不同岗位。”
领域专家嵌入 ChatGPT Work 工程团队部分场景下，模型的专业能力已经超过开发人员，开发者无法凭经验定义业务 “好的标准”。因此，领域专家被嵌入工程团队。ChatGPT Work 大量面向非工程场景，带来这个结果：业务专家和开发团队一起，定义一份优质幻灯片、表格、业务报告应该长什么样。当然，领域专家嵌入工程团队本身是几十年的成熟工程实践，只是在 AI 智能体时代被重新验证。
OpenAI 已经高度依赖 Codex 与 Work依赖程度极高：哪怕轻微故障发生，内部同事的告警消息，会和系统自动告警同时、甚至更早发给 Codex 与 Work 团队。简单说：工作基本都通过 Codex 和 Work 完成，其他方式几乎不再使用。从外部视角看，这种对单一共享执行层的强依赖极具冲击力；两年前，这里还只有 AI 代码补全，不存在 AI 智能体。
二、IDE 与 Pull Request 时代走向终结
去年底，Codex 团队甚至犹豫要不要发布 Codex 桌面客户端。Andrew 回忆当时的顾虑：
“2025 年 12 月，我们不确定要不要推出 Codex 桌面端。我们已有 Codex CLI 终端，市面上也有成熟、功能完备的 IDE。那一款介于终端和 IDE 之间的开发工具，还有生存空间吗？我当时预想过失败的可能性，就像 iPad 一样：很多人买了 iPad 却很少用，要么用便携手机（类比 CLI），要么用功能完备笔记本电脑（类比 IDE）。另外 11 月 Antigravity（VS Code 分支）发布，当时我们甚至考虑，Codex 客户端也直接 fork VS Code。但我们放弃了这个想法，凭直觉判断：随着 AI 智能体变强，IDE 的重要性会下降。”
事实印证了这个判断：自今年 1 月起，IDE 使用率持续下降。不过 Codex 客户端也在慢慢增加 IDE 类能力：6 月上线了内置文件编辑功能。
CI/CD 系统负载暴涨Codex 带来生产力提升的直观体现：大量新增代码涌入开发基础设施。代码提交量暴增带来全新扩容挑战，团队正在全力应对。应用基础设施工程副总裁 Venkat Venkataramani：
“每位工程师提交 PR 的数量呈曲棍球棒式高速增长。构建 - 测试 - 发布流水线的所有环节负载急剧上升。部分系统负载大约提升 10 倍。多数公司要 2–3 年才会遇到的增长，OpenAI 只用大约 6 个月。这种爆发式增长到处暴露瓶颈：版本控制系统要承载更多代码提交，CI/CD 随之扩容，发布流程要承接更高变更频率。每个月我们都会遇到全新基础设施扩容难题。刚为下一阶段增长准备好容量，模型解锁新能力，又在系统其他位置制造出新瓶颈。”
在此背景下，大家开始重新思考 PR 与代码评审。它们曾是软件工程的基础原语，但开发速度的爆发，给了我们重新构想的机会。Venkat 继续说：
“在开发速度爆炸的当下，我们该重新审视很多习以为常的东西：如何重新设计 CI/CD？可观测性该是什么形态？人类该如何和 PR 交互？在我看来，当前代码评审和 PR 的模式，合理性越来越低。我们现在已经在使用智能体代码评审：从多个不同专业视角审视代码变更。过去，让云基础设施工程师、安全工程师逐行审核每一处代码改动并不现实；有了智能体，这件事成为可能。我们也在用智能体重新设计发布流程：正在构建智能体，全程护送变更上线，无论是代码变更还是功能开关背后的改动。智能体观测监控指标，甚至可以自建仪表盘追踪关键信号。越来越多代码变更，在这类智能体监控下进入生产环境。”
原生移动端 App 发布成为愈发痛苦的瓶颈PR 总量翻 10 倍后，后端、Web 端发布需要扩容基础设施。但 iOS/Android 原生 App 更新有独特卡点：每一次更新都要经过苹果、谷歌人工审核，耗时数小时到数天。
ChatGPT 工程负责人 Sulman Choudhry（前 Facebook）解释移动端审核瓶颈如何拖累迭代速度：
“2010 年代 Facebook 在原生移动端发布上有重大突破：App Store 版本从月更，改成双周、周更。同时，实验平台 + 功能开关，让团队可以提前上线代码，再远程开启功能。这套模式极大提升移动端迭代速度。Codex 时代，我们遇到这个问题的升级版。代码生成速度大幅提升，但原生移动端把代码交付到用户手里的速度跟不上。尤其 Codex 本身是移动优先场景，这个落差已经让我们和用户都感到痛苦。我预计压力会快速加剧。几分钟就能写完代码，却要等数天甚至数周才能推送到手机，这件事会显得越来越不合理。我们的目标：原生移动端发布速度和 Web 端一样快。要实现这点，需要创造性重新思考发布内容、发布时机，以及哪些能力可以远程激活。目前我们距离这个目标很远。”
颇具讽刺意味：iOS/Android 原生 App 发布的痛点，和 2008 年 App Store 刚上线时几乎一样。18 年过去，底层机制变化不大。苹果官方依然不允许 App 绕过 App Store 审核，推送重大功能变更。
三、OpenAI 的智能体软件工厂
“软件工厂” 的类比类似实体汽车工厂：机器人 + 人类共同生产汽车。放到软件领域：AI 智能体和人类一起产出软件。部分制造工厂是全自动化 “黑灯工厂”，无需人工照明、不需要人在场。软件工程领域会不会也出现完全自动化的开发流程？OpenAI 现在已经运行着一套以 Codex 为核心的软件工厂。
Venkat 对比了传统软件开发流水线，和 OpenAI 当下智能体基础设施流水线：
智能体软件工厂完整流水线
Codex 深度接入内部系统，新员工入职培训时，被引导直接问 Codex 解决问题，因为它掌握海量上下文。
作者注：我一开始怀疑，仅仅提示 “你是云基础设施专家” 的智能体，和通用智能体产出会不会差别不大。但所有 Codex 智能体都拥有 OpenAI 完整代码与文档访问权限，这个 “云基础设施专家智能体” 会积累大量内部基础设施配置、最佳实践上下文，从而给出高度定向反馈。关键点在于：领域智能体的配置、可访问上下文、聚焦单一领域，高效利用上下文窗口。
代码变更按风险分级高风险变更走更严格流程：调用更多 AI 评审，AI 评审完成后强制人工复核。低风险变更走快速通道；代码库中部分模块可以开启自动审批，由智能体直接放行低风险 PR，消除人工卡点，提升迭代速度。风险评估还可以自动判断是否需要合规介入：由另一智能体处理，或触发人工审核。PR 数量爆炸的情况下，完全靠人工评审代码已经不可行。和 CI 环节一样，编码智能体会持续跟进评审意见，更新 PR 修复问题。
“全程护送本次变更，安全完整上线。”
智能体同时处理代码变更、功能开关背后的改动。例如针对功能开关变更，智能体：
OpenAI 长期目标：实现单变更自治 SRE 智能体，几乎完全自主完成发布。
Codex 时代之前，由工程师手动创建服务监控面板；现在，每次发布变更，都由智能体生成细粒度仪表盘。
OpenAI 目标：未来 Sevbot 可以自主处理部分故障。愿景是常规故障无需夜间叫醒工程师，Sevbot 自主处置，等员工上班后复核动作。但目前，值班 oncall 制度依然保留。
四、工程工具与开发范式的变革
不出意料，Codex 大幅降低内部工具开发门槛，同时改变调试等传统工程实践。下面是采访中收集到的信息。
-
收集事故上下文 -
生成可行缓解方案（不会自动执行） -
在 Slack 频道回答工程师问题工程师可以指令它执行特定缓解操作。 -
上一步智能体生成的仪表盘 -
OpenAI 内部可观测体系，包含日志、指标、链路追踪、事件数据等大量自研工具 -
读取代码库，定位功能开关 -
理解本次改动的业务逻辑 -
定义成功 / 失败的观测指标 - 自建专属监控仪表盘
（这是我之前没见过的新能力） -
持续观测相关线上指标与仪表盘 -
Git 仓库、GitHub -
Slack、Notion -
内部数据源：Databricks、Datadog、内部日志等 -
内部 Codex 技能（部分技能本身由 Codex 维护） -
2 月：Mac 版 Codex 客户端发布 -
3 月：Windows 版 Codex 客户端发布 -
7 月：基于 Codex 执行层（harness）构建的 ChatGPT Work 上线 线上监控反馈回开发环节OpenAI 的Perf Factory（性能工厂），由智能体筛选告警与仪表盘、去重信号、定位真实性能退化、分析根因并给出修复方案。捕捉代码变更引入的性能问题，把开发流程延伸到上线后的持续优化。
故障响应Sevbot 是 OpenAI 内部故障响应智能体，同样基于 Codex 构建。检测到事故时自动启动：
- 线上观测
观测来源： - 智能体发布
人工批准上线后，分配专属智能体，指令概括为： Codex 实现代码变更Codex 持续进行代码修改，直到达成目标，并验证软件行为符合预期。
构建、测试，进入 CI智能体构建代码、运行测试，测试失败就修复代码，然后创建 PR。PR 触发 CI 服务器执行完整的静态检查与测试套件。智能体会持续跟进这个 PR，修复 CI 报错、自动更新 PR，直到 CI 全部通过。新增：性能执行层（perf harness）：智能体把存在风险的 PR 送入 Synthetics A/B 框架，评估性能影响。过去半年 CI 系统负载暴涨。
智能体代码评审不再使用单一通用 AI 评审，而是启动多个具备领域专家配置的独立智能体。Venkat 说，这相当于每个相关基础设施团队，都派人类专家评审每一处变更。
人类定义目标结果工程师或产品经理定义问题与预期成果。这个阶段，判断力、优先级取舍、产品审美越来越重要。Venkat 提到：OpenAI 工程师正在变得更像产品经理，而不是传统系统工程师。
Codex 收集上下文OpenAI 把所有文档都放进代码仓库，方便智能体理解代码。Codex 可访问：
-
Codex 接管 OpenAI：短短数月，几乎所有非工程岗位员工，在没有自上而下强制要求的前提下，转向使用 Codex 与 ChatGPT Work -
IDE 与 Pull Request 时代走向终结：自 1 月 Codex 大规模普及后，IDE 使用率持续下滑；PR 与代码评审机制需要重新设计 -
OpenAI 的智能体软件工厂：搭建了多套自动化智能体反馈闭环，例如性能工厂（Perf Factory）监控线上环境，自动调用 Codex 智能体修复性能问题 -
工程工具与开发范式的变革：自研内部工具正逐步被 Codex 替代；相比专用调试工具，大家越来越倾向用 Codex 做调试；软件工厂里，执行链路（harness）效率至关重要 -
面向十亿用户的工程扩容：先采购资源、后续自研内化；地域化基础设施部署、容量规划策略与难点 -
提升 OpenAI API 可靠性与性能：CPU 正在成为瓶颈；主动放慢发布节奏，解决负载挑战 -
软件工程岗位本身的变化：工程细分专业边界消融；判断力与自主决策能力变得更重要；过去需要大量人力的重构与迁移，现在仅需 1–2 名工程师就能完成。