No.7

阅读 OpenAI 的harness engineering文章时，我一直有一种说不上的感觉。然后突然明白了：我以前见过这种模式。不是一次——是三次。

核心观点

第一次是詹姆斯·瓦特的离心调速器（1780年代）。在那之前，工人站在蒸汽机旁手动调节阀门。之后，weighted flyball 机制感知转速并自动调节阀门。工人并没有消失。工作变了：从转动阀门到设计调速器。

第二次是 Kubernetes。你声明期望状态——三个副本，这个镜像，这些资源限制。控制器持续观察实际状态。当它们偏离时，控制器进行调和：重启崩溃的 pod，扩展副本，回滚错误的部署。工程师的工作从重启服务转变为编写系统调和的规范。

第三次就是现在。OpenAI 描述工程师不再编写代码。相反，他们设计环境、构建反馈循环并编纂架构约束——然后代理编写代码。五个月一百万行代码，零手写。他们称之为"harness engineering"。

每次都是同样的模式。诺伯特·维纳在1948年将其命名为控制论，来自希腊语 κυβερνήτης——舵手。你停止转动阀门。你开始掌舵。

每次这种模式出现，都是因为有人构建了足够强大的传感器和执行器来在该层闭合循环。

代码库确实有反馈循环，但只在较低层次：

但"以上的一切——这个变更是否符合系统架构？这是正确的方法吗？这个抽象在代码库增长时是否会引起问题？——没有传感器也没有执行器。只有人类能在那个层次上运作。"

LLM 同时改变了感知和行动能力：

更难的问题是校准传感器和执行器，使其具有特定于你系统的知识。

"它一直在做错事。它不理解我们的代码库。"诊断几乎总是错误的。代理失败不是因为它缺乏能力，而是因为它需要的东西——什么对你的系统"好"，你的架构奖励什么模式——锁在你脑子里，而你还没有将其外部化。

解决方案：让判断机器可读

文档、自动化测试、编纂的架构决策、快速反馈循环——这些一直是正确的实践，但现在：

生成-验证不对称性指向了关键：你需要在评估上超越机器，而不是在实现上。

就像设计瓦特调速器的工人没有回去转动阀门一样，因为我们不再需要手动"转动阀门"，而是需要学会"掌舵"。

原文作者：George @odysseus0z 翻译时间：2026年3月10日