OpenAI Frontier 工程师谈 Codex:Repo 如何变成 Agent 的大脑

视频：Aakash Gupta 采访 OpenAI Frontier 团队的 Ryan LaPopolo，主题是 AI coding agents、Codex、harness engineering，以及 AI-native 产品/工程组织怎么工作。

一句话总结

Ryan 的核心观点是：未来软件团队的瓶颈不再是“谁来写代码”，而是“团队能否把判断、上下文、质量标准和验证流程编码进 agent 的工作环境里”。代码生成变便宜之后，真正值钱的是 harness：让 agent 知道什么是好、能自己验证、能被安全并行调度。

代码生成便宜之后，代码本身不再是瓶颈，验证和判断才是瓶颈。
Repo 不是代码仓库，而是 agent 的工作大脑。
不要盯着 agent 写代码，要让系统替你盯。
人类反馈最多给两三次，第三次就应该沉淀进 harness。
AI 时代的工程师不是写更多代码，而是构建能生产高质量代码的系统。
先让单个 agent 可靠，再追求长任务，最后才做并行。
最有价值的周末工程：让 agent 能看见 app、点击 app、证明它真的修好了。

核心观点

1. 代码从资产变成负债

过去工程组织默认“代码最贵”：人类工程师同步敲键盘、验证、部署，所以代码被严密保护。现在 agent 可以大规模并行生成代码，代码本身不再是稀缺资源。

新的瓶颈变成：

如何判断代码是否真正满足用户需求
如何避免 agent 写出 slop
如何让非工程角色也能安全进入代码库
如何把团队隐性判断变成 agent 可读取、可执行的规则

2. 工程、产品、设计的边界会被重画

传统 EPD 分工是：工程拥有代码，设计拥有视觉，PM 拥有问题定义。Ryan 认为 agent 会让三者都能直接影响最终可执行 artifact。

这不是说角色消失，而是角色的核心价值回到各自的判断力：

PM 提供问题、用户、业务目标和验收标准
Designer 提供 taste、信息架构、交互质量和视觉系统判断
Engineer 提供架构、质量门禁、验证、可维护性和系统边界

大家不再通过低信号 handoff 传话，而是在同一个代码 artifact 上协作。

3. Harness engineering 是真正的护城河

Ryan 反复讲的 harness，不是简单 prompt，而是一整套让 agent 能做完整工作的环境。

它包括：

AGENTS.md / agents.md：告诉 agent 去哪里找上下文，而不是把所有信息硬塞进上下文窗口
文档树：设计文档、执行计划、历史决策、关键用户路径、产品功能说明
llms.txt / 依赖文档：把 Stripe、OpenAI、UV、内部设计系统等文档以纯文本形式放进 repo
persona review docs：frontend architect、reliability engineer、appsec engineer 等审查角色
tests / lints / CI：把团队 taste 和质量要求变成会失败的检查
observability / browser / computer use：让 agent 能看日志、看 UI、点按钮、验证副作用

一句话：repo 不是代码仓库，而是 agent 的工作大脑。

4. 不要同步盯着 agent，要让系统替你盯

最大的误区是把 AI coding tool 当成人类同步驾驶的工具：人坐在旁边，看它写、不断纠正。

Ryan 的方向相反：像管理队友一样管理 agent，而不是像操作 autocomplete 一样操作 agent。目标是让 agent 能跑更长时间、更少被人打断、更能自己完成闭环。

所以关键不是“写更好的 prompt”，而是：

让 agent 能自己发现上下文
让 agent 能运行测试和本地环境
让 agent 能看到 app 行为
让 agent 能收到 reviewer agents 的反馈
把每次人类反馈沉淀回 harness，避免下次重复提醒

5. 第一阶段会很慢，但会形成复利

他们一开始从空 repo 构建内部 agent 产品，约 100 万行代码，其中 25 万行左右是 Markdown prompt/docs。约束是：人类不直接写代码，全部由 Codex 生成。

早期很慢，甚至第一个月比人手写慢很多，因为他们不断递归补底层能力：Slack 访问、credential management、keychain、安全编码、测试、验证、文档。

但每补一个能力，都是给未来所有任务增加杠杆。Ryan 的说法是：人类反馈最多给两三次，就要把它变成 repo/harness 的一部分，让 agent 下次自己避免。

6. PM 可以从 PRD 到 shipped PR，但前提是工程先铺好安全边界

一个例子是 PM 写 Markdown PRD，团队评审后，Codex 在一周内做出演示，下一周交付给用户。成功原因不是 PM 突然会写代码，而是工程团队提前做了模块化架构：

业务逻辑边界清晰
依赖通过 interface 注入
每个业务模块都有 high-fidelity fake 用于测试
UI、业务逻辑、底层 infrastructure 的可触达范围受控

如果没有这些边界，非工程角色直接进代码库很容易产生 spaghetti。

7. Designer 更适合先做 painted door

他们也有失败案例：设计师尝试做类似 scheduled automation / cron 的功能，结果为了做 UI 需要补后端调度系统，最后变成前端里塞 scheduler 的 spaghetti，被 revert。

后来团队总结出更好的模式：designer 可以做完整 UI 和交互实验，但后端可以先是 no-op / stub，也就是 painted door。这样可以先验证用户是否理解、是否需要这个功能，再决定工程是否投入真正后端能力。

8. Token 使用不是成本问题，而是产能问题

Ryan 有个很激进的观点：如果没有每天用到十亿 token，某种程度上是在浪费机会。他的逻辑是，token 是把模型智能榨出来的燃料，更多 token 意味着更多并行尝试、更长 horizon、更深验证。

他举例说，曾经一个 PR 用了约 3.5 亿 token，一个 60 小时 Codex CLI session 做了他职业生涯里最难的 refactor 之一。人类只追加了两次 prompt，agent 持续完成工作。

这里真正重要的不是烧 token，而是能不能把 token 变成高质量 PR，而不是一堆要丢弃的尝试。

9. GPT-5.2 之后，团队开始追求并行化

Ryan 认为 GPT-5.2 是一个明显能力跃迁点。模型升级后，在没有额外投入的情况下，每个工程师每天能多产出 1-2 个 PR。

随后他们开始做 Symphony 这样的 orchestrator，把 Linear ticket 推进状态、交给 Codex 产出 PR。因为前面已经有足够强的验证与质量体系，才敢进一步把每周每工程师 PR 数提升约 10 倍。

核心顺序是：

先让单个 agent 可靠
再让 agent 跑长任务
最后才做并行调度

10. 新工程师更像 staff engineer

Ryan 说新的工程工作不是亲手写所有代码，而是“让团队能产出代码”。每个工程师都像有 5 个、50 个甚至 5000 个虚拟键盘手，关键是能不能组织、验证、调度这些资源。

这要求工程师从“最会写代码的人”转成：

架构边界设计者
agent 工作流设计者
质量门禁设计者
repo 可读性维护者
token factory / agent factory 的系统工程师

他说这像在代码库里玩 Factorio：目标是构建一条能持续生产高质量变更的 token 工厂。

11. 六个月路线图：可读、可验证、多人可用

Ryan 给普通团队的 Monday morning roadmap 很清晰：

让 repo 对 agent 可读把团队隐性判断写下来，放进 docs tree；agents.md 只做地图，告诉 agent 去哪里找。
让验证变便宜让 agent 能跑测试、看日志、看数据库副作用、点 UI、做端到端验证。PR 必须有 proof of work，而不是“我觉得做好了”。
让使用者不只限于工程师产品、设计、用户运营、DevOps 都应该能把自己的 domain expertise 反哺进 repo/harness。

12. 周末最该补的技能：闭环验证

如果 tech lead 这个周末只做一件事，Ryan 建议是：让 Codex 能看见你的 app，并能驱动业务逻辑。

也就是让 agent 能：

启动 app
点击按钮
观察 UI
触发业务行为
检查副作用
证明改动满足 brief

这比继续堆 prompt 更重要。

13. 他偏向“一个强 agent 做完整任务”，不是多 agent 乱分工

在被问到 OpenAI stack 和 Anthropic stack 的取舍时，Ryan 的观点是：OpenAI 的模型更优化在 full agentic behavior，能完整接下一个任务，不需要人持续 poke。

他还提出一个反直觉观点：multi-agent 系统理想上要优化到“一个 agent”。因为一个 agent 持有完整上下文，可以跨设计、后端、前端做整体取舍；多个 agent 之间的 handoff 会带来损耗。

这不是说不要 reviewer agents 或 orchestrator，而是主执行 agent 越能做完整工作，质量越高。

对我们的启发

这期最值得拿来做产品/内容的不是“Codex 很强”，而是“AI-native engineering 需要一套新基础设施”。

可做的小工具方向：

Repo Legibility Auditor：检查 repo 是否对 coding agent 友好
AGENTS.md / CLAUDE.md / Codex plugin 体检器：上下文地图是否太肥、太散、不可维护
Agent QA Pack：自动要求 agent 提供 proof of work、截图、日志、测试、关键用户路径验证
Docs Tree Generator：把 Slack/PR/设计文档沉淀成 agent 可读的 repo docs
Painted Door Builder：给 PM/Designer 快速生成 no-op 后端 + 完整 UI 实验
Token Factory Dashboard：衡量 token 是否转化成高质量 PR，而不只是烧了多少钱