OpenAI的Ryan Leopo谈"Harness Engineering"：当代码免费时，如何构建软件

来源

背景：Ryan 在演讲开篇给出整个框架的支点，不是”AI 能帮你写代码”，而是从稀缺资源角度重新定义了软件工程的约束条件。

实现（Implementation）不再是软件工程工作的稀缺资源。代码是免费的。

代码生产免费，重构免费，不再是需要纠结的事情。我们过去把代码视为负担，是因为它会同步消耗团队里人类工程师的注意力。但模型无比耐心，无限并行。所以生产、维护、重构和删除代码，不再是分配工程资源时的约束条件。

这个世界的稀缺资源只剩三样：人类时间、人类与模型的注意力，以及模型的上下文窗口。

这三条稀缺资源的命名是整篇演讲的骨架。代码不再稀缺，稀缺的是注意力和上下文，这是下面所有工程决策的出发点。兴趣匹配度高。

背景：被追问”什么是好的 harness”时，Ryan 把复杂概念压到一句话，同时给出了”just-in-time 上下文注入”的具体操作例子。

好的 harness，本质上是在正确的时间把正确的文本给到模型，让它能看到自己做了什么、以及什么叫做得好。模型天生被训练成执行指令的。harness 要做的，只是在正确的时刻把指令呈现给模型。

不要一开始就把所有指令全部塞进去，那会把 agent 淹没。但这些”什么叫做好”的要求，需要在整个 PR 周期里持续被关注到。所以好的 harness，是要想清楚怎么延迟或即时地把这些指令注入进来。

举的例子：React 组件拆分的规范不需要在任务开始就加载，等到 lint 时再注入——「好，你已经把功能写出来了，现在要收尾，你得把这些组件拆开，让它们尽可能小、尽可能无状态。」这就是 just-in-time 上下文注入的实际形态。兴趣匹配度高。

背景：Ryan 把工程里所有常见机制都重新标记为 prompt 的不同形态，罗列出一条完整的注入链。

提示词。规则文件——提示词。技能（Skills）——提示词。lint 报错信息——提示词。每次推送都触发、在 PR 上留下评论并要求 agent 在提交前处理的 review agent——提示词。你会发现代码里有大量可以插入提示词的地方。

我们代码库里有安全审查和可靠性审查 agent，在每次推送和 CI 时持续运行。它们看着文档和这次提交的 patch，问一些简单的问题：这段网络代码有没有超时和重试？引入的这个接口是不是从设计上就不可能被误用？

我写了一条专门针对我们代码库的 lint 规则，检查每次调用 fetch 时有没有包一层重试和超时。从此这个问题被我一次性彻底解决了。

从 agents.md 到自定义 ESLint 到 review agent，整条链都是 prompt 注入的不同形态。这个框架让”上下文工程是工程基础设施”变得很具体。兴趣匹配度高。

背景：问答环节被问到车里怎么和 agent 工作，Ryan 顺带说出了他衡量 harness 质量的真正标准：不是产出质量，而是人类干预的频率。

大多数时候，技能里已经告诉 agent——你在执行一个任务，跑到测试全绿为止。我不需要伸手过去戳它一下”继续”。

每次我不得不对 agent 输入”继续”，都是 harness 的失败——它没有给模型足够的上下文，让它知道怎么跑到完成。

理想状态是 50 个 agent 同时跑，24/7，我完全不用介入。做到这件事的方式是：把工作定义好，找到自动调度的方法，把自己从”需要点按钮”这件事里移除出去。

把”需要人类介入的频率”定义为 harness 质量的反向指标，把工程目标从”代码质量”转移到”最小化人类注意力消耗”。兴趣匹配度高。

背景：被问到代码库规模扩大后怎么保持 agent 效率，Ryan 从 750 个 PNPM 包的决策引出了”代码即 prompt”这个核心洞察。

文件系统里的代码也是文本，也就是说它实际上是你给 coding agent 的 prompt。代码越一致，agent 不管看到代码库的哪个角落，都能积累可迁移的上下文。

应该只有一种做有边界的并发 helper 的方式，一种 ORM，一种编程语言，一种写 CI 脚本的方式，一种加 lint 规则的方式。这样模型需要产出的 token 就更容易预测，无论它看哪里都能稳定生成。

代码即 prompt。大规模重构是免费的。让代码尽可能一致，是你们所有人现在就能做到的事。

“代码即 prompt”解释了为什么统一性对 agent 如此重要：减少模型激活的注意力，让上下文可预测、可迁移。兴趣匹配度高。