OpenAI最新Harness工程分享 | 代码免费后，码农将变身“AI驾驭师”

代码已经免费，软件开发的实现环节不再是稀缺资源。未来工程师的核心工作，不是亲手编写每一行代码，而是构建和维护一个能让 AI Agent 高效工作的「驾驭」（Harness）。

过去，我们谈论敏捷、DevOps、云原生，这些都是为了优化人类工程师的生产力。但现在，开发工作被彻底颠覆了。最近，OpenAI 的工程师 Ryan Lopopolo 分享了他们内部 Harness Engineering 的做法，这不仅是对他过去九个月工作方式的总结，更是对未来软件工程形态的一次预言。

Ryan 和他的团队做了一个极端的实验：禁止团队成员接触编辑器，所有工作必须通过 AI Agent 来完成。他们变身「Token Billionaire」，每天消耗超过十亿级别的 Token。这听起来很疯狂，但这种疯狂的背后，是对一个核心信念的践行：模型已经有能力成为一个完整的软件工程师，人类的角色必须随之改变。

新的现实：免费的代码与稀缺的注意力

Ryan 的第一个论点是「代码是免费的」（Code is free）。这个「免费」不是指开源，而是指生产成本趋近于零。当一个团队拥有 GPU 和 Token 预算时，就相当于拥有了 5 个、50 个甚至 5000 个 7x24 小时工作的工程师。实现本身，不再是瓶颈。

过去，代码是资产，但也意味着维护负担。代码越多，人类工程师的同步注意力就被消耗得越多。但对于 AI Agent 而言，它们是「无限耐心且无限并行」的。重构、迁移、删除陈旧代码，这些在人类团队中需要巨大决心和资源投入的“技术债清理”工作，对于 Agent 来说，只是又一个可以并行处理的任务。Ryan 提到，那些拖了六个月都无法完成的大型代码迁移项目，现在可以派 15 个 Agent 去同时执行，直到完成为止。

如果代码生产不再是问题，那什么才是稀缺的？Ryan 指出了三样东西：人类的时间、人类和模型的注意力、以及模型的上下文窗口。

当生产力无限时，价值就从生产本身转移到了对生产方向的「指引」和对生产过程的「约束」上。人类工程师的角色，正从键盘上的执行者，转变为系统的思考者、设计者和委派者。你不再是一个砌墙的工匠，而是那个规划整个城市蓝图，并为施工队（AI Agents）设定标准、提供工具、清理障碍的总工程师。Ryan 将这种新角色称为「员工工程师」（Staff Engineer），每个人都拥有一个庞大的、由 AI 组成的虚拟团队。

这种转变带来的直接好处是惊人的。过去，产品需求列表上，P0 任务永远排在前面，而那些 P1、P2 的「有用但非紧急」的功能，可能永远等不到资源。但在代码免费的世界里，你可以把所有 P1、P2 任务同时启动，甚至每个任务都用四种不同的方式并行尝试，最后选择一个最好的方案合并。Ryan 举例，他可以轻易地为内部工具从第一天起就提供完善的国际化和本地化支持，因为这不再需要与其他更高优先级的任务抢夺人力资源。

Harness Engineering：如何为 AI 构建一个高效的「驾驭」

既然工程师的职责是「驾驭」Agent，那么具体要怎么做？这就是「Harness Engineering」的核心。它的目标不是去构建一个多么复杂的自动化平台，而是创造一个能让 Agent 清晰理解任务、高效执行、并产出「可接受」代码的环境。这个环境，就是「驾驭」。

驾驭由什么构成？它不是一个单一的软件，而是一整套系统、流程和结构的集合。几乎所有的技术细节，都可以被归结为在为 Agent 提供「清晰的指令」和「有效的反馈」。

第一，让「潜规则」显性化。一个好的软件工程师在写代码时，会做几百个微小的决策，这些决策关乎代码的可维护性、可靠性、可读性等非功能性需求。这些往往是团队内部约定俗成的「潜规则」。Agent 在训练中见过无数代码，它知道所有可能的实现方式，但它不知道在你的项目里，哪一种是「好」的。

因此，工程师的首要任务就是把这些潜规则写下来，变成 Agent 能看得懂的文档。比如，一个团队里有前端架构专家、有后端性能专家、有产品思维强的工程师，每个人把自己对「好代码」的理解（那些非功能性需求）文档化。这样一来，任何一个 Agent 在执行任务时，都能同时获得整个团队所有专家的“知识加持”。例如，一个工程师写下一份详尽的「如何编写高质量 QA 计划」的文档，那么之后所有 Agent 提交的功能，都会附带一份符合标准的 QA 计划。

第二，「万物皆是 Prompt」。Harness Engineering 的一个精髓在于，把工作流中的每一个环节，都视为一次向 Agent 注入上下文（Prompting）的机会。Ryan 总结了这些概念演变：

最开始，我们有 Prompt。

然后我们把 Prompt 结构化，称之为 Rules 或 Skills。

接着，我们发现 Lint 规则的报错信息，也可以是一个 Prompt。一个失败的测试，它的输出信息也可以是一个 Prompt。比如，当 Agent 写出了类型不安全的代码，Linter 不应该仅仅报错，而应该输出一段文字提示它：「不，这里不应该有未知类型。我们信奉在系统边界进行解析而非验证的原则，你完全可以从 Zod schema 推导出这里的确切类型。」 这段文字就是一条精准的 Prompt。

再进一步，可以有「Reviewer Agent」（审查员 Agent）。这些 Agent 在 CI/CD 流程中自动运行，像人类审查者一样，根据文档化的规范，在 PR 下留下评论。这些评论，同样是给执行任务的 Agent 的 Prompt。

最终，连代码库的结构本身，也是一个 Prompt。一个组织良好、模块清晰、依赖关系明确的代码库，本身就在引导 Agent 以一种更结构化的方式去思考和行动。

这是一种对「提示工程」的极致应用，它将原本需要人类专家在 Code Review 时反复指出的问题，固化成了系统内的自动化反馈机制。

第三，为 Agent 适配环境，而非相反。一个反直觉但非常重要的观点是：我们需要在一定程度上改造我们的代码库，使其对 Agent 更「友好」。这听起来像是本末倒置，但考虑到 Agent 的「物理限制」（如上下文窗口），这是一种务实的工程选择。

Ryan 举例说，他们会写一些测试来限制单个文件的行数不超过 350 行。为什么？因为这样可以更高效地利用模型的有限上下文。这是一种「上下文效率工程」。同样，他们会把代码库拆分成大量（750个）微小的 pnpm 包，每个包有清晰的业务领域或技术分层。这样做的好处是，当 Agent 修改某个功能时，大部分变更可以被限制在一个明确的目录子树内，从而减少了它需要加载和理解的上下文范围。

这种做法，本质上是将文件系统和代码结构，也变成了向 Agent 传递信息的一种媒介。通过「让所有东西尽可能保持一致」（make things the same），比如统一的异步处理方式、统一的 ORM、统一的 CI 脚本，可以显著降低 Agent 在不同代码区域工作的「认知负担」，使其更容易预测并生成符合规范的代码。

结语：从「写代码」到「定义现实」

Ryan Lopopolo 的分享之所以重要，因为它揭示了 AI 时代软件工程师真正的价值所在。这不再是关于你掌握了多少种编程语言或框架，而是关于你定义和塑造「工作现实」的能力。

这首先是一个认识论（Epistemology）问题。Ryan 提到一个词，meta-epistemological question，即关于「什么是好」的元认识论问题。这触及了问题的核心。Harness Engineering 的本质，就是将团队对于什么是好的代码、什么是好的流程、什么是好的产品这些模糊的、主观的共识，不断地、系统地转化为机器可以理解和执行的、明确的规则和约束。这是一个将「品味」和「经验」形式化的过程。

那些能够在代码审查中提出深刻见解的高级工程师，他们的价值并没有消失，反而被放大了。现在，他们的任务不再是重复地在每个 PR 中指出同一个问题，而是将他们的洞察力「编译」成一个可以自动运行的 Reviewer Agent 或一条 Linter 规则，从而让整个Agent 团队的水平得到永久性的提升。

其次，这是一个关于「杠杆」的思考。过去，工程师创造杠杆的方式是编写可复用的库和框架。现在，杠杆的支点发生了变化。最高的杠杆在于：

定义流程：设计一个从需求到上线的、由 Agent 驱动的、高度自动化的工作流。

固化知识：将最佳实践、架构原则、非功能性需求转化为文档、规则和自动审查机制。

构建反馈循环：建立一个能够持续观察 Agent 行为、发现问题、并快速将解决方案融入驾驭的闭环。Ryan 团队的「垃圾收集日」（Garbage Collection Day）就是这种反馈循环的绝佳实践。

最终，Ryan 可以在车里用笔记本电脑跑 Agent 这象征着一个终极目标：让工作流完全自动化，人类只需在起点定义好任务，在终点验收结果，中间的过程由 Agent 们在一个设计良好的「驾驭」中自行推进。甚至说的极端一点，人类需要手动点击「Continue」的每一次操作，都被视为是「驾驭」设计上的失败。

最后，这对工程师提出了新的能力要求。未来，一个优秀的工程师需要具备的能力将是：

系统思维：不再局限于单个文件的实现，而是能够从整个系统的角度思考如何组织代码、定义接口、划分模块，从而让 Agent 更容易理解和操作。

抽象和形式化能力：将模糊的需求和隐性的知识，提炼成精确的文档、规则和测试。这可以看作一种立法者的工作。

强大的委派和信任能力：学会放弃对每一行代码的控制欲，信任自己建立的系统和流程能够保证 Agent 的产出质量。将精力从「微观管理」代码，转移到「宏观调控」系统上。

Ryan Lopopolo 描绘的并非一个工程师被取代的黯淡未来。恰恰相反，这是一个将工程师从繁琐的实现细节中解放出来，让他们能更专注于软件工程中最具创造力和最高价值部分——系统设计、质量保障和流程优化——的光明前景。

代码的生产成本正在趋于零，但创造价值的成本从未改变。它需要深刻的思考、清晰的定义和高效的协作。只不过，未来的协作对象，除了人类同事，还将包括成千上万个不知疲倦的 AI Agent。而我们，作为工程师，正在成为这个新时代的「AI 驾驭师」。

我们的工作，是为那些能力强大但行为不受控的「野马AI」构建一个水草丰美、规则清晰的牧场，然后看着它们自由驰骋，去建设我们想要的世界。

参考来源：Harness Engineering: How to Build Software When Humans Steer, Agents Execute — Ryan Lopopolo, OpenAI