Harness Engineering 为什么是 Agent 时代的“控制论”？

01.

同一个模式，出现了三次

我读完 OpenAI 那篇关于 harness engineering 的文章后，心里一直有种说不清楚的感觉。直到某一刻，我突然想通了：这个模式我已经见过了，而且见过不只一次，是三次。

第一次是在 18 世纪 80 年代。詹姆斯·瓦特（James Watt）发明了离心调速器（Centrifugal governor）。在这之前，工人得一直守在蒸汽机旁边，用手不停地调节阀门。有了调速器之后，一套带飞球的机械装置会自动感知转速、自动调节阀门。工人没有因此消失，只是工作内容变了：从亲手拧阀门，变成设计调速器本身。

第二次是在 Kubernetes 出现之后。使用 Kubernetes 的时候，你只需要声明目标状态，比如运行三个副本、用这个镜像、分配这些资源。控制器（controller）会持续监测系统的实际状态，一旦实际状态和目标状态出现偏差，控制器就会自动介入修正：重启崩溃的 Pod，调整副本数量，回滚出问题的部署。工程师的工作也随之改变：从手动重启服务，变成编写系统需要对齐的目标 spec。

第三次就是现在。OpenAI 在文章中描述了这样一批工程师：他们不再亲手写代码，而是负责设计运行环境、构建反馈回路、把架构约束转化成可执行的规则，然后让 agent 去完成实际的编码工作。他们用五个月生成了约一百万行代码，没有一行是人手写的。OpenAI 把这种工作方式叫做“harness engineering”。

每一次变化的背后其实都是同一个模式。诺伯特·维纳（Norbert Wiener）在 1948 年给这个模式命名为控制论（cybernetics）。这个词来自希腊语 κυβερνήτης，意思是舵手，Kubernetes 这个名字也来自同一个词根。本质含义都是一样的：你不再需要亲手拧阀门，而是开始掌舵。

这个模式每次出现，背后都有同一个原因：有人造出了足够强大的传感器和执行器，能够在那个层面上把反馈回路闭合起来。

02.

为什么代码库是最后被攻克的领域？

代码库并不是没有反馈回路（feedback loop），只是这些回路都存在于底层。

• 编译器（Compilers）在语法层面闭合回路；

• 测试套件在行为层面闭合回路；

• Linter 在代码风格层面闭合回路。

这些机制虽是真实的控制论回路，但仅能处理可机械检验的问题，比如，代码能编译吗？测试能通过吗？格式符合规范吗？

再往上一层，就没有任何自动化机制了，比如，这个改动符合系统的整体架构吗？这个技术方案是对的吗？这个抽象层随着代码库不断增长，将来会不会出问题？这些问题既没有传感器来感知，也没有执行器来修正。只有人能在这个层面上工作，而且两端都需要人来完成：一端是判断质量好坏，另一端是动手写出修复方案。

而 LLM 同时改变了上述这两端。LLM能像人一样判断代码质量和进行改动：重构一个模块；重新设计接口不一致的地方；围绕真正重要的约束条件重写整套测试。这是第一次，反馈回路可能在真正关键的决策层面闭合。

但是闭合回路只是必要条件，还不是充分条件。瓦特的调速器需要仔细调校才能正常工作，Kubernetes 的控制器需要一份正确的 spec 才能对齐目标，而在代码库里工作的 LLM，则需要一样更难提供的东西。

03.

如何校准传感器和执行器？

事实上，让 agent 能够执行测试、CI 能产出可解析的结果、报错信息能指向具体修复方向这样的基础反馈循环运行起来，仅仅是最低门槛。

Carlini 曾经做过一个演示：他让 16 个 agent 并行协作，一起构建一个 C 编译器。他用的 prompt 极其简单，但测试基础设施的设计却非常精心。他事后说：“我大部分的精力都花在设计 Claude 周围的环境上，也就是测试、运行环境和反馈机制。”

左右滑动以查看全部内容

也就是说，真正困难的问题在于，如何基于你对自己系统的认知，来校准这套传感器和执行器。大多数人就卡在这一步，然后把问题归结于 agent 本身：“它一直在做错误的事情，它根本不理解我们的代码库。”这种诊断几乎总是错的。

Agent 失败，不是因为它的能力不够，而是因为它需要的那些知识，比如对你的系统来说什么叫做“好”、你的架构鼓励哪些模式、又刻意回避哪些模式，这些知识全都锁在你自己的脑子里，你从来没有把它们写出来。Agent 不会自主学习进化。如果你不把这些知识写下来，agent 第一百次犯的错会和第一次一模一样。

因此，真正需要做的工作，是把你的判断标准变成机器可以读懂的形式：写一份描述真实分层结构和依赖方向的架构文档，配置一套内置了修复指引的自定义 Linter，整理一套把团队审美和品味编码进去的黄金原则。OpenAI 也发现了这一点：他们曾经每周五花 20% 的时间专门清理“AI slop”，后来他们把自己的标准直接编进了 harness 本身，问题才得到根本解决。

04.

唯一的出路

文档、自动化测试、编码成规则的架构决策、快速的反馈回路，这些本来就是正确的工程实践。过去三十年，几乎每一本软件工程的书都在推荐这些。但大多数人选择跳过，因为跳过的代价来得很慢、散得很开：代码质量缓慢下滑，但新人上手越来越痛苦，技术债在不知不觉中积累。

Agentic engineering 让这个代价变得极端。

• 如果你跳过了文档，agent 就会无视你所有的规范，而且不是在某一个 PR 上出问题，而是在每一个 PR 上都出问题，并以机器的速度，全天候不间断地重复同样的错误。

• 如果你跳过了测试，反馈回路就根本无法闭合。

• 如果你跳过了架构约束，代码漂移的速度会远远快过你手动修复的速度。

• 更糟糕的是，如果 agent 不知道什么叫做整洁的代码，你就没有办法用 agent 来收拾这个烂摊子。也就是说，没有经过校准的 agent，制造出了问题，也解决不了问题。

该做的事情从来没有变过。只是不做这些事情的代价，已经变得无法承受。

正因如此，我们必须关注生成之外的验证环节。生成答案和验证答案之间存在明显的不对称性，也就是 P vs NP 问题的核心直觉：通常验证一个答案比生成一个正确答案要容易得多。Cobbe 等研究者已经在 LLM 上通过实验验证了这一点。这个不对称性给出了明确的方向：你不必在编写代码上比机器更快，只要你能知道怎么高效地评估它的产出。也就是说，你需要能够定义什么是“正确”，识别输出结果偏离目标的地方，并判断整体方向是否正确。

左右滑动以查看全部内容

那些当年设计了瓦特调速器的工人，后来没有回去拧阀门。不是因为他们不会拧，而是因为回去拧阀门这件事，已经没有任何意义了。

 排版：夏悦涵

延伸阅读

OpenClaw 引爆 AI 安全焦虑，Armadin 的 Agent 攻防闭环会成为新范式吗？