代码越写越快，PR 审查越不能靠人堆

如果团队里的 Agent 已经能一口气写完功能、提 PR、把测试跑绿，下一步最容易犯的错是什么。

把它当成一个更快的初级开发者，然后往原来的代码审查队列里继续塞。

这条路会很快卡住。代码变多不是唯一的麻烦，真正难的是，谁来判断这次改动该不该合、该放到多少流量、上线后要盯哪几根指标。以前一个资深工程师一天能看几十处改动，已经够累了。现在一组 Agent 可以把待审变更堆成一整面墙。人没变多，风险也没有自动变小。

Pragmatic Engineer 的 Gergely Orosz 刚发了一篇 公开探访，聊 OpenAI 内部怎样把 Codex 用成一座智能体软件工厂。他采访了七位工程负责人和工程师。报道里最刺眼的数字不是哪个模型分数，而是部分研发基础设施的负载在约六个月里涨了十倍。

好家伙，代码生成刚把油门踩下去，版本控制、CI、部署、监控这些老系统就先开始冒烟。

这篇文章最值得看的一点，不是 OpenAI 又用了多少智能体。那套内部系统接了代码仓库、文档、协作工具、数据平台和监控系统，外部团队暂时很难复刻。真正有参考价值的是他们承认了一件事，软件开发的主线正在从写出代码，变成让每一次变更可靠地走完交付过程。

报道中的数据图显示，财务、招聘和法务等团队在约四个月里从接近零使用，升到约九成使用。

代码只是起点。PR 也只是中途站。

产能上来后，瓶颈会搬家

很多团队已经见过第一阶段的爽感。给 Claude Code、Codex 或 Cursor 一个边界清楚的任务，半小时后多出一批能跑的改动。然后大家顺手得出结论，既然生成速度上来了，开发效率自然也会上来。

不一定。

生成只是把需求翻成文件。后面还有四件更贵的事，理解现有系统，验证改动没伤到别处，判断风险，观察它进入生产环境之后会不会慢慢把服务拖歪。

OpenAI 的受访者描述得很直白，PR 数量快速增加后，负载会沿着版本控制、构建、测试和发布一路传导。过去几年，团队很擅长优化写代码这一小段。现在变更产出加速，原来被人力自然限速的队列突然失去节奏，CI 排队、审查疲劳、灰度信号没人看，都成了新的瓶颈。

上周那篇 Anthropic 的 CI 复盘 也给过同样的提醒，Agent 写的代码变多，测试数量和 CI 任务会比团队人数快得多。两家公司说的不是同一套产品，麻烦却长得很像。

不是模型把研发流程取代了。

是模型把流程里原来藏着的薄弱处，全推到灯光底下。

公开报道里的流程图。重点不在某个 Agent，而在变更需要一路经过上下文、验证、审查、部署和生产反馈。

这也解释了为什么只买一套 AI 编程订阅，很难直接买到交付效率。你给 Agent 更长的上下文、更大的权限和更多并发，它确实可能更会干活。可一旦没有足够的验证和观察，快只是把故障更快送到用户面前。厉害了，事故复盘也会被迫变成高频栏目。

PR 不会消失，它要换一份工作

报道里有个判断很硬，传统的 PR 和代码审查，已经越来越不适合承接高速变更。这个判断不该被听成 PR 要被废掉。

PR 过去承担了好几件不同的工作。它既是代码差异，也是同事沟通的入口，还是质量门禁和责任记录。人写代码的年代，把这些事塞进一个页面问题不大。Agent 一次可以拉出多个分支、反复改动、自己处理评论，继续让所有人盯着同一份 diff，慢慢就会变成找针。

OpenAI 公开探访里提到的做法更像把审查拆开。不是找一个万能审查机器人说一句看一下这个 PR，而是按领域派出不同视角的审查智能体。基础设施、安全、性能等方向，各自只盯自己最关心的失败模式。它们能发挥作用的前提不是提示词写得花，而是能读到对应的代码、文档和规则。

这里有个很容易被忽略的区别。

通用 Agent 给的多半是通用建议。真正有用的审查，要知道你们的服务依赖什么、哪里有延迟预算、什么改动必须过合规检查、哪些模块一动就得叫上负责人。没有这些上下文，所谓专业审查只是在扮演专业人士，输出看着很满，实际很虚。

OpenAI 对内部 Codex 安全运行的说明 里也强调了清晰边界、低风险操作和高风险操作的透明化。把这件事落到团队，不必从多智能体大阵仗开始。先把变更分成能自动走和必须停下来的两类，就已经比一股脑全交给 Agent 靠谱得多。

变更处境	该交给谁	该拿什么证明
文案、测试补全、低风险内部工具	Agent 完成并自动校验	格式检查、单测、静态检查
局部业务逻辑	Agent 实现，人做抽样审查	关键测试、变更说明、回滚方案
权限、支付、用户数据、核心链路	人做最终授权	风险评估、双人审查、灰度计划
发布后出现异常信号	Agent 收集证据，人决定处置	指标、日志、追踪、回滚开关

这张表没有魔法。它只是把原来一句让 Agent 写完就提 PR，拆成了授权和证据两个问题。一个改动越难回滚、影响范围越大、越接近用户数据，就越不应该沿用同一条自动路径。

把上线看成一段旅程，不是一颗绿勾

公开探访里最有意思的细节，反而在 PR 之后。每次获得批准的变更，可以交给一个智能体持续跟着上线。它要理解这次改了什么，挑出应该观察的信号，生成自己的仪表盘，并在变更进入生产环境后继续看着。

很多团队的上线动作还是一句合并了，CI 绿了，发吧。绿色勾当然重要，可它只能证明某些预设检查过了。它不能证明线上请求没有变慢，某个功能开关没有误伤用户，也不能证明新的调用方式没把成本曲线顶起来。

所以我很认同 OpenAI 讲 Harness Engineering 的文章 里那条线索。智能体可靠不可靠，不只看模型会不会写函数，更看环境里有没有明确目标、可访问的上下文、验证规则和反馈回路。模型能力像发动机，Harness 更像道路、护栏和仪表盘。只加发动机，不修路，车会先跑得很刺激。

报道里的 Perf Factory 也沿着这个思路工作，它从告警与仪表盘里归并信号、识别性能回归、寻找原因并提出修复。另一个事故响应智能体 Sevbot 会收集上下文和建议缓解措施，但在报道所述阶段并不自行执行处置。

这个边界很克制，也很对。

能自动收集证据，能自动给出候选方案，不等于该让它直接把生产环境拨来拨去。尤其在故障场景里，系统状态往往已经不完整，错误动作的代价也最大。把人放在最终处置点，不是 Agent 不够聪明，而是责任、信息和回滚能力还没有长到能放手的程度。

普通团队，先补这四个空位

看完 OpenAI 的软件工厂，最容易上头的动作，是去给每个环节都配一个 Agent。愚钝如我，觉得更该问一个朴素的问题，我们现在最缺的是生成代码，还是接住变更的能力。

如果团队还在起步，可以先把四个空位补上。

第一是任务边界。每个可交给 Agent 的任务，都要能说清输入、完成标准、不能碰的区域和允许使用的工具。任务写不清，人来做也会反复返工，别把模糊需求甩给模型后再怪它。

第二是验证证据。不要只要求它改好，而要提前定义哪些测试、检查和实际信号能证明改好了。测试绿了不代表业务正确，Agent 提交的说明也不等于验收。

第三是风险分层。把低风险、可回滚的改动留给自动路径。涉及权限、资金、数据删除、关键依赖和大范围配置的改动，规定必须由谁批准，出问题怎么停。规则越早写下来，审查越不靠临场记忆。

第四是生产观察。一次变更至少要能回答三个问题，影响了谁，哪个指标会先变坏，变坏后怎么回退。这样即使暂时没有自动生成仪表盘的能力，也已经在用软件工厂的方式给变更配上出口。

不用一次做到 OpenAI 的规模。把这四件事做好，Agent 就不再只是一个会写代码的同事，而开始变成能被系统可靠接住的生产力。

代码越来越便宜，判断、验证和承担后果反而越来越贵。

软件工程没有被压缩成一句提示词，它只是把真正需要人负责的那一段，重新留到了台前。

你们团队现在让 Agent 参与到哪一步了，写代码、跑测试、审查 PR，还是已经跟到上线之后？