👆 上下滑动阅读 · 左右滑动翻页 · 键盘方向键同理
⚡
极限Harness工程
📖 注释版
百万行代码 · 日处理十亿Token · 零人工编写或审查
——OpenAI Ryan Lopopolo 深度访谈
OpenAI Frontier 团队 · 前沿产品探索
📖 含 61 个技术术语与原理解析
🔵 蓝色虚线 = 技术工具/框架（点击查看详细解释）
🟢 绿色虚线 = 产品/平台名
🟠 橙色虚线 = 概念/方法论/原理
🟣 紫色虚线 = AI模型相关
点击或触摸带虚线下划线的术语查看注释 👇
人物与背景
WHO & WHY
本页要点
Ryan Lopopolo 来自 OpenAI Frontier 团队，负责前沿产品探索。他拥有 Snowflake、Brex、Stripe、Citadel 等企业级产品的深厚背景，是 AI 最大主义者的践行者。
主持人
你写了一篇重磅文章，关于 Harness 工程。这很可能会成为这一新兴学科的定义性文章。先做个背景介绍——你在哪个团队？
Ryan Lopopolo
我从事前沿产品探索和新产品开发，在 OpenAI Frontier 的领域。这是我们的企业平台，用于大规模安全地部署代理，具有良好的GRC治理。我和我的团队的角色是找出将我们的模型部署到打包终端产品中的新方法，作为解决方案出售给企业。
主持人
你的背景很有意思——Snowflake、Brex、Stripe、Citadel，然后看你的 Twitter，完全是 AI 全力以赴的心态。完美组合。
Ryan
作为一个 AI 最大主义者，如果你要坚持这个人设，OpenAI 是最好的地方。而且我们内部没有速率限制，可以全力投入。
极限约束：零人工代码
THE EXPERIMENT
本页要点
Ryan 设定了一个激进约束：不自己写任何一行代码。五个月内，3人团队用 AI 代理生成了超过百万行代码、1500 个 PR。前 1.5 个月比手写慢 10 倍，但最终效率提升 10 倍。
Ryan
我设定了一个相当大胆的约束——不自己写任何代码。如果我们试图让代理部署到企业中，他们应该能够做我所做的一切。在与这些编码模型合作了六到八个月后，我确实感到模型已经与我的能力同构。所以，唯一能做我工作的方式就是让代理来做我的工作。
Ryan
我们从最早的 Codex CLI 版本开始，使用 Codex Mini 模型。每当模型无法完成任务时，你就弹出任务，深入挖掘，构建更小的构建块，然后重新组合成更广泛的目标。前一个半月比我自己做要慢十倍。但正因为我们支付了这个成本，我们最终得到了比任何一个工程师都更富有成效的东西——因为我们为代理构建了工具和装配站。
"
代码是可处置的。前期投入的痛苦成本，最终换来的是远超个人极限的生产力释放。"
— Ryan Lopopolo
模型迭代之路
MODEL EVOLUTION
本页要点
从 Codex Mini 到 GPT-5.4，每个模型版本都带来不同的工作风格和能力跃升。团队需要不断适配代码库以应对模型的变化，包括构建系统从 Makefile 一路演进到 NX。上下文窗口的扩大是关键变量。
Codex Mini能力有限，无法组装复杂功能。迫使团队构建更小的构建块，形成装配站思维。
GPT-5 → 5.2没有后台 shell，依赖阻塞脚本执行长期工作。每工程师日均 3.5 个 PR。
GPT-5.3 + 后台 Shell模型变得不耐心，不再愿意等待长时间构建。构建系统必须在 1 分钟内完成——棘轮原则诞生。每工程师日均 5-10 个 PR。
GPT-5.4首个合并顶级编码与通用推理的模型。百万 token 上下文窗口。可直接写博客文章，不再需要在 Chat 和 Codex 之间来回切换。
Spark (5.3)不同架构的快速小模型。适合快速原型、文档更新、ESLint 修复等低复杂度任务。
构建系统演进
BUILD SYSTEM
本页要点
构建时间是代理效率的关键约束，直接影响内循环速度。团队将构建系统从 Makefile → Bazel → Turbo → NX 逐步演进，最终实现 1 分钟内完成构建的棘轮纪律。代码库采用Monorepo架构。
构建系统演进路径
Ryan
构建时间必须有纪律。如果你不控制它，它会不断增长。一分钟只是一个漂亮的整数，当超过时，我们就把它当作信号——停下来，分解构建图，把时间压回来。因为 token 如此便宜，我们可以与模型大规模并行地持续进行"园艺工作"，确保维持这些不变量。
Electron 架构与 AI 原生产品
MODEL-VIEW-CLAW
本页要点团队构建的是 Electron+React 原生应用，后端托管在云端。Ryan 发明了一个 AI 原生的 MVC 变体：Model-View-Claw——其中"Claw"就是 Harness。更深层的洞见：如果你能把产品和用户旅程折叠成代码，编码代理就能解决它。
Ryan
我有一个有趣的双关语。你知道 MVC 是 Model-View-Controller，任何全栈 Web 开发者都知道。而我的 AI 原生版本是 Model-View-Claw——Claw 就是 harness。
Ryan
我确实认为有一个有趣的空间值得探索——将 Codex harness 作为构建 AI 产品的一部分。模型在编码能力上已经有了巨大飞跃，如果你能弄清如何将你试图构建的产品、试图解决的用户旅程折叠成代码，那么用 Codex harness 来解决这个问题就非常自然了。它已经完成了所有接线工作，你只需要用 prompt 与模型沟通就行。
主持人
所以对于听众来说，Ryan 的意思是：编码代理将吞噬知识工作。你通常会想"哦，你需要为此构建一个单独的代理"——不，从编码代理开始，然后向上延伸。
Ryan
没错。务必用代码定义你的任务。给模型脚本——那些你本来就会为自己构建的脚本。
人类角色的演变
HUMAN IN THE LOOP
本页要点团队已超越人类审查代码的阶段——大多数审查是合并后进行的。人类唯一稀缺的资源是同步注意力，应该用系统思维来思考"代理在哪里犯错"。模型是平凡可并行化的。
Ryan
我们甚至已经超越了人类审查代码的阶段。大多数人类审查现在都是合并后进行的。模型是平凡可并行化的——只要我愿意花费足够的 GPU 和 token，就能获得与代码库协作的能力。唯一从根本上稀缺的是我的团队同步的人类关注力。
Ryan
你必须后退一步，采用系统思维的心态，不断问：代理在哪里犯错？我在哪里花费时间？我如何不再花那些时间，并对自动化建立信心？通常情况是，我们最初需要密切关注代码，因为代理没有合适的构建块来生成模块化、可分解、可靠且可观测的软件。
"我不应该深入每个
PR 的细节。这就像我在 500 人组织中担任小组技术主管一样——你用代码编写方式的代表性样本，来推断团队在哪里遇到困难。"
— Ryan Lopopolo
团队影响与架构品味
TEAM IMPACT
本页要点Ryan 的工作方式如同管理 500 人组织的技术主管——不再深入每个 PR 的细节，而是通过代表性样本推断团队在哪里遇到困难。关键在于强制执行架构与品味，而非微观管理代码。模型越来越善于提出抽象概念来解除自身障碍。
主持人
你们小团队完全按照模型想要的方式编写软件——为了更好的代理可读性而牺牲人类可读性。这对更广泛的团队有什么影响？比如加入一个新团队带着这种方法论——团队应该全力转型吗？
Ryan
我的心态很明确——我已经从流程中移除了自己。我真的不能对代码有太多深入的意见。这就像我在一个 500 人组织中担任小组技术主管一样——我不适合去关注每一个 PR 的细节。我有一些代码编写方式的代表性样本，然后用它来推断团队在哪里遇到困难、在哪里可以获得帮助、在哪里已经快速推进。
Ryan
我确实有一个 command base class——用于可重复的业务逻辑块，自带追踪、指标和可观测性。需要关注的不是业务逻辑如何构造，而是它使用了这个基础原语——因为我知道这默认就能提供杠杆效应。这就是回到强制执行架构与品味的系统思维。
Ryan
而且随着模型越来越好，它们已经越来越善于自主提出抽象概念来解除自身障碍。这让我能够在堆栈中越来越高地移动，更深入地审视未来——什么最终阻碍了团队交付。
可观测性体系
OBSERVABILITY STACK
本页要点团队用半个下午搭建了完整的本地可观测性堆栈。核心思想是反转控制——不是为代理搭建环境，而是让代理成为入口点，自主决定何时启动堆栈。用 Grafana 做监控仪表盘。
可观测性堆栈 · 代理即入口
Ryan
这是推理模型与过去模型的根本区别。过去的模型无法思考，需要把它们放在盒子里，有预定义的状态转换。而现在，模型和 harness 成为整个盒子，我们给它一堆选项和足够的上下文来做聪明的选择。这就是反转控制的核心。
技能系统与自动化
SKILLS & AUTOMATION
本页要点团队从第一原理构建了"技能"体系：约 100 行的总体目录 + 小技能文件。包括技术债务追踪器、质量分数、制度知识文档等。模型渴望文本——关键是找到将文本注入系统的方法。
Ryan
技术债务追踪器和质量分数相当有趣——这基本上是一个 markdown 表格，是 Codex 的钩子。它可以审查应用中定义的所有业务逻辑，评估是否与所有记录的护栏匹配，并为自己提出后续工作。
Ryan
模型从根本上渴望文本。当我们因缺少超时遇到问题时，我可以在 Slack 上让 Codex 说"我将通过添加超时来修复。请更新我们的可靠性文档，要求所有网络调用都有超时。"我不仅做了一个时间点修复，还永久编码了这个制度知识。
- spec.md — 项目规范，引导代理的核心行为
- agent.md — 代理目录，约100行总体说明
- core_beliefs.md — 团队成员、产品、客户、12个月愿景
- 技术债务追踪器 — Markdown 表格 + cron 代理自动巡检
- 质量分数 — 代理决定何时使用，自主触发质量审查
Harness 文章的反响
COMMUNITY REACTIONS
本页要点Ryan 的 Harness 工程文章引发了意想不到的反响：人们直接把文章链接丢给 Codex 说"让我的仓库变成这样"——而且效果出奇地好。核心洞见：所有编码到文档、测试和审查代理中的内容，本质上都是非功能性需求的 Prompt 注入。
Ryan
我在文章中可能没有讲得足够清楚的一点是：我们编码到文档、测试和审查代理中的所有东西，本质上都是把构建高规模、高质量、可靠软件的非功能性需求放进一个能prompt 注入代理的空间。我们要么把它写成文档，要么在错误信息中添加链接告诉代理如何正确操作。
Ryan
整个元游戏就是从团队中所有工程师的脑袋里提取出他们认为什么是好的，他们默认会怎么做，或者他们会如何指导一个新入职的成员让代码合并。这就是为什么我们关注代理犯的所有"错误"——这些是与某个尚未写下的非功能性需求不一致的代码。
主持人
还有一件很有趣的事——人们直接把你文章的链接丢给 Codex，说"让我的仓库变成这样"。你已经达到了完全递归。
Ryan
而且效果出奇地好。它就是直接开始执行了。这其实是一种很好的学习方式——你给它所有代码、所有上下文、再加上文章，它就能很好地引导你了解该改变什么、该如何调整。
代码审查自动化
AUTO CODE REVIEW
本页要点代码审查代理可以自主合并。团队定义了 P0-P2 优先级体系。关键洞见：编码代理需要有灵活性推迟或反对审查反馈，否则会陷入无法收敛的死循环——这就是PR流程中的"代理欺凌"问题。
代理驱动的 PR 流程
Ryan
最初，编码代理愿意被 PR 审查者"欺凌"，导致无法收敛。所以我们需要给两边更多选项：审查代理被指示倾向合并，不表面大于 P2 的问题；编码代理也有灵活性推迟或反对反馈——就像人类工程师说"这个先归档到待办事项"一样。
完全委派：Dollar Land
FULL DELEGATION
本页要点Dollar Land 技能实现了完全委派——从推送 PR 到等待审查、修复不稳定因素、合并上游、进入合并队列，直到代码在 main 分支中。Git Worktrees 大量使用，模型擅长解决合并冲突。代码可处置性是关键心态。
Ryan
我们调用一个 Dollar Land 技能：推送 PR → 等待人工和代理审查 → 等待 CI 变绿 → 有不稳定因素则修复 → PR 出现冲突则合并上游 → 放入合并队列 → 处理不稳定因素直到进入 main。这是一个对人类有重大负担的流程，但代理完全有能力做到。
Ryan
是的，我们非常大量地使用 Git Worktrees。但模型在解决合并冲突方面真的很擅长。到了终端中状态不同步的地步，我几乎不在乎是否有合并冲突——代码是可处置的。
Ryan
所有代理做的工作包括：产品代码和测试、CI 配置和发布工具、内部开发工具、文档、评估工具、审查注释、管理仓库的脚本、Grafana 生产仪表盘定义文件——基本上什么都有。但因为我们构建原生应用（Electron+React），不做持续部署，所以人工仍在循环中进行发布分支切割和烟雾测试。
Greenfield 免责与全景
SCOPE & CAVEATS
本页要点重要前提：所有这些成果都发生在全新代码库中，不应假设可直接推广到遗留系统。团队不做持续部署——发布分支的切割和烟雾测试仍由人工完成。代理的工作范围涵盖了从产品代码到 Grafana 仪表盘定义的一切。
主持人
我想确认一下——这并不是在构建基础设施级别的东西，对吗？不是那种需要"多个九"的可靠性。
Ryan
没错。而且必须充分认识到——所有这些活动都发生在一个全新的代码库中。不应该有任何断言说这可以普遍适用于所有场景。
Ryan
当然，这是真实的。你提到我们从零开始建仓库——第一个月左右的入职过程相当艰难，基本上是倒着工作的。然后你必须与系统配合。现在我们已经达到了一个平衡点。
主持人
有没有任何一个人类团队成员曾经拉过"停止一切"的紧急刹车？
Ryan
因为我们构建的是原生应用（Electron），不做持续部署，所以发布分支的切割和烟雾测试仍然有人工在循环中。这提供了一道安全网。
Symphony 编排系统
ORCHESTRATION
本页要点当每工程师日均 5-10 个 PR 时，上下文切换令人精疲力竭。Symphony 诞生的目的就是将人类从终端前解放出来。使用 Elixir/BEAM 构建，因为其进程监督和 gen servers 天然适合流程编排。包含重做状态机制。
Symphony 架构
Ryan
在 Symphony 中有一个重做状态：一旦 PR 被提议并升级给人类审查，应该是廉价的审查——要么可合并，要么不是。如果不是，你把它移到重做，Elixir 服务会完全清空整个工作树和 PR，从头开始。这又是一个机会来问"代理做了什么不好的事？"——修复反馈，然后继续。
幽灵库与依赖内化
GHOST LIBRARIES
本页要点Twitter 上称之为"幽灵库"——通过规范而非代码来分发软件。低到中等复杂度的依赖可以在一个下午内部化。内化抽象允许去除Postel 定律带来的冗余，只专注于实际需要的功能。
Ryan
与世界分享软件变得便宜得多——你定义一个规范，说明如何构建所需内容。流程非常巧妙：让 Codex 以我们的代码库为参考写规范，启动 TMUX，让一个 Codex 实现规范，另一个审查实现与上游的差异并更新规范。然后一遍遍循环，直到得到高保真度的规范。
主持人
Brett Taylor（OpenAI 董事长）也在回应你的文章，他说软件依赖项将会消失。
Ryan
100% 同意。当前我们能内部化的依赖复杂度是低到中等。一个数千行的依赖项可以在一个下午内轻松内部化。通过内部化抽象，你可以去除Postel 定律带来的通用部分，只专注于你需要的东西。而且当我们部署 Codex Security 时，它能深度审查内部化的依赖项，摩擦远低于推送补丁上游再拉下来的传统流程。
Symphony 深度：工具与协作
SYMPHONY DEEP DIVE
本页要点团队对 MCP 持悲观态度——它强制注入 token、干扰自动压缩、代理容易忘记工具用法。替代方案：有人"vibed"出一个本地守护进程，通过 shim CLI 暴露 Playwright。代码库架构如同 500 个 NPM 包的万人级工程组织。每日站会 45 分钟。
Ryan
有一次我们把 Playwright 通过 MCP 直接连到 Electron 应用。我对 MCP 相当悲观——harness 会强制将所有那些 token 注入上下文，我完全没有发言权。它们干扰自动压缩，代理会忘记如何使用工具。而且 Playwright 里我实际需要的可能只有三个调用，但我要为一大堆东西付出代价。
Ryan
有人"vibed"出了一个本地守护进程——启动 Playwright 并暴露一个很小的 shim CLI 来驱动它。我完全不知道这件事发生了，因为对我来说，我只是运行 Codex 然后它突然能驱动界面了。就是突然变好了。
Ryan
所以在人类层面，我们不得不花大量时间做同步知识共享。我们的每日站会长达45 分钟，因为我们几乎必须扇形展开当前状态的理解。这对单人多代理来说还好，但多人多代理是一个爆炸式的复杂度。
Ryan
这从根本上就是为什么我们的应用有如此严格的、万人级工程组织级别的架构——代码库像 500 个 NPM 包。对一个七人团队来说这看起来过度架构，但如果每个人实际上对应 10 到 50 个代理，那么在分解、分片和正确的接口边界上做到极致就合理多了。
六层抽象架构
SIX LAYERS
本页要点Symphony 定义了六个层次：策略、配置、协调、执行、集成、可观测性。加上第零层——元反思："我们工作得好吗？可以改进吗？"代理可以自省会话日志、修改自己的 workflow、切割自己的票证。
六层架构 + 元反思层
Ryan
策略层不需要写一堆代码——这就是你的制度知识。你只需给它 gh CLI 和一些文本，比如"CI 必须通过"。这使得系统维护容易得多。代理也可以修改自己的 workflow、切割自己的票证、通过会话日志自省来改进自己的使用方式。
CLI 与 Token 效率
CLI DESIGN
本页要点模型喜欢文本、CLI 和 Bash。CLI 对代理非常节省 token。关键实践：给 prettier 传 --silent，包装测试输出只显示失败部分，将非文本内容转为 ASCII 艺术。代理在潜在空间中感知世界。
Ryan
模型喜欢使用工具，喜欢 Bash，喜欢读文本。给它一个 CLI，让它自由发挥。CLI 非常节省 token，而且可以很容易地使其更节省。你会想给 prettier 传 --silent，因为代理不在乎每个文件是否已格式化——它只想知道是否通过。同样，测试套件的大量输出也需要包装成只输出失败部分。
Ryan
我们也一直在将非文本的东西转换成文本形式。代理看东西的方式与人类不同——它们在潜在空间中感知。如果想让代理看到布局，把图像光栅化为 ASCII 艺术并输入代理几乎更容易。我们也用 FFmpeg 自动录制代理操作的演示视频。
"Andrej Karpathy 说过英文是最热门的编程语言。这种说法已经成真了。"
— Ryan Lopopolo
Meme 文化与代理幽默
AGENT HUMOR
本页要点团队甚至有制作 deep-fried memes 和 Slack reacji 文化的技能文件。幽默是一个极高的智能测试——需要把大量上下文压缩到极少的词中。这也是为什么 GPT-5.4 对团队是巨大提升——它能代替工程师发表搞笑内容。
Ryan
有一件可能会让你更惊讶的事——我们有专门的技能文件来生成 deep-fried memes 和 Slack reacji 文化。因为有了 Slack ChatGPT 应用，我能让代理代表我发表搞笑内容。
Ryan
相当不错。我认为幽默是一个非常高难度的智能测试——你需要把大量上下文压缩到非常少的词中。这就是为什么 5.4 对我们来说是如此大的提升。
主持人
所以 5.4 能发表搞笑帖子。这就是本集的关键结论。
Ryan
顺便说一下，等你们今天结束后，让 Codex 回顾你的编码代理会话然后吐槽你。
Frontier 企业平台
ENTERPRISE VISION
本页要点OpenAI Frontier 的目标是成为每个企业 AI 转型的平台——部署高度可观测、安全、可控、可识别的代理。Agents SDK 是核心，提供默认工作的驾驭系统。安全规范针对特定企业定制。
Ryan
Frontier 是我们想要进行每个企业 AI 转型的平台。我们希望在工作场所部署高度可观测、安全、可控、可识别的代理变得容易。我们希望它与你的公司本地 IM 堆栈一起工作，能够插入你拥有的安全工具和工作空间工具。
Ryan
Agents SDK 是核心部分——它使初创公司创始人和企业开发者都能拥有一个默认工作的驾驭系统，包括 shell 工具、文件附件、容器等。安全规范是针对特定企业的。我们有责任让企业能够对代理进行检测，防止数据外泄，了解内部代号之类的东西。
Ryan
两个层面：最终员工——他们出现的任何界面、可访问的连接器；以及 IT、GRC 合规团队、AI 创新办公室、安全团队——负责以符合监管要求的方式成功部署到员工工作场所的利益相关者。
Harness 与模型训练的关系
IN-DISTRIBUTION
本页要点驾驭工程与模型训练之间存在根本张力。关键原则：所有护栏都应以代码原生方式构建——运行测试就是写可靠软件的一部分。如果围绕 Codex 构建独立的 Rust 脚手架来限制输出，那种额外驾驭容易被废弃。用强化学习的类比：要构建on-policy 的 harness。
Ryan
它们绝对还没有做到从新产品想法到原型的一次性完成。这是我花大量时间指导的地方。同样，最严重的重构是我打断最多的地方。但这只会越来越好。在一个月的过程中，我们从低复杂度任务扩展到低复杂度和大任务两个方向。所以，不要与模型能力增长对赌。
Ryan
如果我们构建的所有护栏都是代码原生的——运行测试就是写可靠软件的一部分——那么对模型进步没有任何摩擦。但如果围绕 Codex 构建独立的 Rust 脚手架来限制输出，那种额外驾驭就很容易被废弃。在分布内构建策略，从那里修改它。
主持人
这就像强化学习中的on-policy 与 off-policy 的区别。你的意思是应该构建一个 on-policy 的 harness——已经在分布内的，然后从那里修改。但如果 off-policy 构建，那就不太有用了。
编码已解决，下一站知识工作
WHAT'S NEXT
本页要点Codex 团队一个月内连续发布 5.3、Spark、5.4——"疯狂发货"是核心工程价值观。Codex 已超过两百万周活跃用户，周环比增长 25%。Ryan 的宣言：编码？已解决。下一步是知识工作。OpenAI 正在 Bellevue、纽约扩展工程团队。
Ryan
我一直非常兴奋地受益于 Codex 团队的所有成果。他们绝对是在疯狂地发货——这是我们的核心工程价值观之一"ship relentlessly"，而那个团队将其体现到了极致。5.3 刚好是一个月前，昨天就是 5.4。每个月都有新的模型发布。
Ryan
Codex 的增长也与此相关——他们宣布了两百万用户。但几乎不用再关心 Codex 本身了。这就是这个游戏。编码？酷，已解决。接下来是知识工作。让代理自然地与人类合作，意味着协作工具是一个有趣的探索空间。
Ryan
我们刚刚在 Bellevue 开设了新办公室，在华盛顿州构建未来。Frontier 的企业客户服务还有大量工作要做，我们当然在招聘。如果你还没试过 Codex 应用，请下载试试。两百万周活跃用户，周环比增长 25%。快来加入我们。
"你可以做东西。这就是这一集的台词。你可以直接去做事情。这是一个非常光荣的未来，我们就生活在其中。"
— Ryan Lopopolo
— 全文完 —