一个已经过期的问题#

我们这边还在反复争论：Agent 写出来的代码，到底能不能进生产环境？

在 OpenAI 内部，这个问题已经没有人问了。

2026 年 9 月 15 日，The Pragmatic Engineer 的 Gergely Orosz 发布了他在 OpenAI 总部的实地访谈，对象是七位工程负责人：应用基础设施 VP Venkat Venkataramani、ChatGPT 工程负责人 Sulman Choudhry、桌面端负责人 Andrew Ambrosino、核心 Agent 团队负责人 Joe Gershenson、生产力工程负责人 Akshay Nathan，以及 Codex 团队的 Ahmed Ibrahim 和 Responses API 团队的 Steve Coffey。

他看到的不是一个用上了 AI 工具的公司，而是一家围绕自家编码 Agent 重新组织的公司。下面是我读完之后觉得最值得记下来的部分，以及一些我认为普通团队容易误读的地方。

四个月，从工具变成地基#

最刺眼的是这组数字：财务、招聘、法务这类非工程部门，Codex 渗透率在四个月窗口里从接近 0% 走到 90%。今天几乎每个 OpenAI 员工每周都会用 Codex 或 ChatGPT Work。

产品时间线解释了节奏：Codex 的 Mac 应用 2 月上线，Windows 版 3 月跟上，7 月 ChatGPT Work 发布，跑在 Codex 的执行框架之上。

真正让我停下来想了一会儿的是 2 月到 4 月那段。那时候桌面应用还会把原始代码直接铺在屏幕上，对非技术用户称不上友好，但非工程人员的使用率仍然爬到了接近 40%。原因很朴素：它真的把活干完了。调研、演示稿、表格，任何有明确交付物的任务都算。代码只是 Agent 干活的方式，不是用户必须盯着看的东西。

转折点是一个斜杠命令#

4 月到 5 月，使用率从 60% 跳到 90%。Ambrosino 把功劳记在 /goal 上：给 Agent 一个目标，它会一直磨到完成为止。

配套的变化是对长任务的支撑变好了。人们开始在一个线程里待上好几天。这里有个反直觉的推论：任务越长，人反而越不需要并行开工。一个长跑的 Agent 会自己派生别的 Agent 去处理支线，人需要协调的面积反而缩小了。

Akshay Nathan 给当前阶段起了个名字，叫 awareness overhang，我译作「认知落差」。过去几年行业里存在的是能力落差：模型能做的事比产品暴露出来的多。现在反过来了，产品能做很多，而大多数用户不知道自己手上这套东西能干什么。有人已经让 Codex 盯着 Slack、更新 Airtable、写新人入职材料，另一些人还把它当成一次性任务执行器，靠口口相传发现自己能怎么用。

还有两件事在加速渗透。一是团队开始把角色化的工作流打包成 plugin 在内部流通，Ambrosino 的原话是「你不能只丢给大家一个空盒子」。二是 OpenAI 把领域专家直接嵌进工程团队，因为在某些领域模型已经比搭执行框架的工程师更懂行，得有人把品味注入进去：一张好的演示稿、一个好的表格、一份好的业务报告到底长什么样。

依赖程度可以这样衡量：Codex 或 Work 出现一点小故障，同事的内部消息会和自动告警同时到达，有时还更早。

这里必须加一句前提。 OpenAI 内部的 Codex 比我们能用到的强得多，因为它接进了几乎全部内部系统。下面这套流水线，有些工序是可以搬走的，有些工序的前提你根本没有。

IDE 和 PR 正在安静地退场#

2025 年 12 月，Codex 团队认真争论过要不要做桌面应用。Ambrosino 承认他当时担心这东西会变成 iPad 式的产品：买了，然后放着不动。那个 11 月 Antigravity 作为 VS Code 的 fork 发布时，团队一度也想跟着 fork 一个，最后放弃，赌的是另一件事：Agent 变强之后，IDE 本身就没那么重要了。

这个赌注看起来押对了。内部 IDE 使用率从 1 月起持续下降。而 Codex 应用反而在往「准 IDE」的方向长，6 月上线了应用内文件编辑。

下一个被重塑的是 PR 和代码审查。Venkataramani 说人均 PR 数的曲线变成了冰球杆，某些系统半年内吸收的负载增长大约是 10 倍，而同样的增长在多数公司要花两三年。他的原话是：「每个月醒来，都有一批新的基础设施扩容难题在等我们。」

这个速度下，旧仪式撑不住了。

代码审查被重构成多个 Agent，每个都是领域专家：相当于每一次变更都有一位云基础设施专家和一位安全专家逐个过目。这在人类时代从来不可行，因为请不起。

部署也在变。OpenAI 在做一个能「护送」变更一路走到生产的 Agent，它会看监控图，甚至自己搭仪表盘。变更按风险分级：低风险的 PR 允许 Agent 自动批准，把人从瓶颈里挪开；高风险的走更严流程，可能强制人工审查。

九道工序#

文章里最清楚的一段，是 Orosz 复现出来的那条流水线。他把它叫作「Agent 软件工厂」，人和 Agent 一起生产软件，形态像机器加人一起造车的物理工厂。

  • 第一道，人定义结果。 工程师或 PM 说清问题是什么、「成功长什么样」。判断力、优先级、品味在这一步最值钱。Venkataramani 说他手下的工程师越来越像产品经理，不再像系统工程师。
  • 第二道，Codex 收集上下文。 OpenAI 把所有文档搬进了源码仓库本身。Codex 能读 Git 和 GitHub、Slack、Notion、Databricks、Datadog、内部日志，以及内部 skills。新人的上手方式被简化成一句：有问题问 Codex。
  • 第三道，Codex 实现。 它迭代到目标达成，并且验证软件行为是正确的，不只验证编译通过。
  • 第四道，构建、测试、CI。 Agent 跑构建和测试，修失败，开 PR，然后守在 PR 旁边直到 CI 变绿。性能 harness 会把可疑的 PR 送进 Synthetics A/B 框架。
  • 第五道，Agent 代码审查。 不是单个通用审查者。Orosz 承认他一开始很怀疑，因为「扮演一位云基础设施专家」听起来像 cosplay。但每个 Agent 都能读到完整的代码库和文档，这些专家角色确实能积累起针对性的上下文，这和让一个通用模型泛泛而谈是两件事。
  • 第六道，风险分级加 Agent 部署。 人工批准生产发布之后，这个变更会拿到一个专属 Agent，指令只有一句：护送这个变更，直到它完全且安全地铺开。Agent 自己读代码找出 feature flag，自己判断哪些信号代表成功或失败，自己搭监控仪表盘，然后盯着。
  • 第七道，观察生产。 仪表盘现在按变更由 Agent 生成。一年前 Orosz 到访时，这还是工程师的手工活。
  • 第八道，Perf Factory。 Agent 过一遍告警，去掉重复信号，识别出真正的延迟回归，定位根因，提出修复方案。闭环从部署延伸到了持续改进。
  • 第九道，Sevbot。 事故响应 Agent，同样建在 Codex 上。事故来了它醒过来，收集上下文，提出缓解方案，但从不自己执行，并在 Slack 里回答工程师的问题。目标是常规故障的自治处理：没有人凌晨三点被叫醒，人类早上复核 Agent 做过的事。目前 on-call 班还在。

最刺眼的瓶颈不在 AI，在应用商店#

代码产出涨十倍之后，卡住整条流水线的地方相当复古：发原生移动应用。

iOS 和 Android 的每次更新都要过苹果和谷歌的人工审核，耗时几个小时到几天。Choudhry 在 Facebook 经历过 2010 年代的解法，发布节奏从月更压到双周更再到周更，靠 feature flag 先上暗的、再远程打开。

他的判断是，Codex 时代把这个老问题以更尖锐的形式复活了。写代码快了一个数量级，把代码送到手机上完全没有加速。「如果软件几分钟就能写出来，等几天甚至几周才能到用户手机上，这件事开始显得越来越荒谬。」他认为目标应该是移动端发布和 Web 一样快，同时坦承「今天，我们离得很远」。

Orosz 补了一刀：2026 年发布一个原生应用，流程和 2008 年 App Store 刚上线时基本一样。十八年，没什么进步。

拼起来看：什么在贬值，什么在升值#

把这九道工序拼起来，画面其实很清楚。

写代码正在变成整条流水线里最便宜的一步。昂贵的是定义问题、判断风险、做最终决定。这套工厂不是「无人化」，它更像物理工厂：机器干活，人定目标、处理异常、维护机器。区别在于这个工厂的产品是软件，被自动化掉的技艺，恰好是工程师自己的技艺。

但如果你打算照搬，有三个前提必须先自查，缺任何一个这套流水线都不成立。

上下文是不是真的通。 OpenAI 把文档搬进源码、把 Slack 和 Datadog 接进 Agent。如果你的 Codex 连不上你的 Jira 和监控系统，第二道工序就是残缺的，后面七道全都会打折。这一条的投入产出比通常比换模型高得多。

你的 CI 和测试可信吗。 Agent 能自己开 PR 并守到 CI 变绿，前提是那个绿灯是真的。测试是摆设的团队用上这套流程，只会更快地生产假绿，而且是自动化地、规模化地生产。

风险分级得自己长出来。 低风险自动批准、高风险强制人工，这是整套设计里最关键也最没有标准答案的一环。OpenAI 有专门的系统吸收 10 倍 PR 负载，你的团队需要的是一个和自己业务对齐的分级标准，不是一个抄来的阈值。

最后一层是心态。「工程 specialization 正在溶解成判断力和行动力」这句话，反过来读也很清楚：只会执行、不会判断的位置最危险；而能定义「成功长什么样」的人，比过去任何时候都值钱。

至于「认知落差」，我认为这才是大多数团队的真实处境。不是工具不够强，是你不知道自己手上这套东西能干什么。所以在急着上第六道到第九道工序之前，先把第一道和第二道做到位。把成功标准写清楚，把上下文喂足，这两件事的回报比继续堆工具大得多。

结语留一个不太舒服的问题：如果前沿公司已经这么干活了，你的团队还有多少时间去适应？

不必照抄那九道工序。但值得开始问自己一句：在你的团队里，整条流程中哪一步最贵？如果答案仍然是「写代码」，那差距已经不在工具层面了。

参考来源#

  • Gergely Orosz, Inside OpenAI’s agentic software factory, The Pragmatic Engineer, 2026 年 9 月 15 日
  • 文中引用的访谈对象：Venkat Venkataramani、Sulman Choudhry、Andrew Ambrosino、Joe Gershenson、Akshay Nathan、Ahmed Ibrahim、Steve Coffey