驾驭式工程就是控制论（译）

Harness Engineering Is Cybernetics

• 作者：George
• 发布时间：2026 年 3 月 8 日 06:54
• 原文链接：https://x.com/odysseus0z/status/2030416758138634583

读 OpenAI 那篇关于 harness engineering 的文章时，我一直有一种难以名状的熟悉感。

后来我突然意识到：这种模式我以前见过，而且不是一次，是三次。

第一次，是 18 世纪 80 年代 James Watt 的离心调速器。

在它出现之前，一个工人站在蒸汽机旁，靠手工调节阀门。它出现之后，一个带有配重飞球的机械装置会感知转速，并自动调节阀门。

工人并没有消失，变化的是工作的性质：从拧动阀门，变成设计调速器。

第二次，是 Kubernetes。你声明一个目标状态：三个副本、这个镜像、这些资源限制。

控制器持续观察实际状态；一旦两者出现偏离，控制器便执行协调：重启崩溃的 Pod、扩缩副本、回滚错误部署。

工程师的工作，也就从重启服务，转向编写那份供系统持续协调的规格。

第三次，就是现在。OpenAI 描述了一类已经不再直接写代码的工程师。

相反，他们设计环境、构建反馈回路、把架构约束编码进系统，然后由智能体去写代码。

五个月，一百万行代码，没有一行是手写的。他们把这称为“harness engineering”。

三次看到的，都是同一种模式。Norbert Wiener 在 1948 年已经给它命名：控制论（cybernetics）。

这个词来自希腊语 κυβερνήτης，意为“舵手”。Kubernetes 这个名字也来自同一个词根。你不再拧阀门，而是开始掌舵。

每当这种模式出现，本质上都是因为：有人构建出了足够强的传感器与执行器，使反馈回路能够在那个层次上闭合。

为什么代码库一直是最后的顽固例外

代码库当然也有反馈回路，但过去这些回路只存在于较低层次。

编译器闭合的是语法层面的回路。测试套件闭合的是行为层面的回路。Linter 闭合的是风格层面的回路。

它们都是真正的控制论机制，但只能作用于那些能够被机械检验的属性：它能编译吗？它能通过测试吗？它符合规则吗？

而再往上的那些问题，比如 “这次改动是否符合系统架构？” “这是不是正确的方法？” “这个抽象会不会随着代码库增长而制造麻烦？”。

在过去既没有传感器，也没有执行器。在那个层次上，只有人类能工作，而且要同时承担两端的角色：既负责判断质量，也负责亲手修复。

LLM 一次性改变了这两端。

它们既能在过去由人类独占的层次上“感知”，也能在同一层次上“行动”：重构一个模块、重新设计一个不一致的接口、围绕真正重要的契约重写整个测试套件。

第一次，最关键决策发生的地方，也终于能够形成闭环。

但闭合回路只是必要条件，不是充分条件。

Watt 的调速器需要校准；Kubernetes 的控制器需要正确的规格；而让一个 LLM 在你的代码库中有效工作，则需要一种更难提供的东西。

校准传感器与执行器

让最基础的反馈回路运转起来——让智能体可以运行测试、让 CI 输出可解析、让错误信息直接指向修复方向——也不过是最基本的入场条件。

Carlini 已经展示过这一点：他让 16 个并行智能体去构建一个 C 编译器，用到的提示词简单得近乎夸张，但测试基础设施却经过了精心设计。

正如他所说：

“我的大部分精力，都花在为 Claude 设计外围环境上——测试、环境、反馈。”

更难的问题，是如何用只属于你的系统的知识去校准这个传感器与执行器。多数人真正卡住的地方就在这里，而他们往往会把责任归咎于智能体本身。

“它总是在做错事。它根本不理解我们的代码库。”

这种诊断几乎总是错的。

智能体失败，并不是因为它没有能力；它失败，是因为它所需要的知识——在你的系统里，什么才叫“好”；

你的架构会奖励哪些模式，又会避免哪些模式——全都锁在你的脑子里，而你还没有把它外化出来。

智能体不会靠耳濡目染学会这些东西。如果你不把它们写下来，那么第一百次运行时，它犯的错误和第一次不会有本质区别。

真正的工作，是把你的判断转化为机器可读的形式：描述真实分层结构与依赖方向的架构文档；内嵌修复说明的自定义 linter；编码了团队品味的“黄金原则”。

OpenAI 遇到的正是这个问题：他们一度每逢周五都要花去当天约 20% 的时间清理“AI 残渣”，直到他们把自己的标准编码进 harness 本身。

唯一的出路

这一切所要求的实践——文档、自动化测试、被编码的架构决策、快速反馈回路——其实一直都是正确的。

过去三十年里，几乎每一本工程书都在推荐这些做法。大多数人之所以跳过它们，是因为跳过的代价过去来得缓慢而分散：质量缓慢下滑、入职过程痛苦不堪、技术债悄无声息地不断复利。

而智能体工程把这种代价推到了极端。

如果你跳过文档，智能体忽视你的约定就不再只发生在一个 PR 上，而是会在每一个 PR 上，以机器速度、昼夜不停地重复发生。

跳过测试，反馈回路根本无法闭合。跳过架构约束，系统漂移积累的速度会快到你来不及修。

更糟的是，这里还有一个陷阱：如果智能体根本不知道“干净”是什么样子，你甚至无法再依赖它们替你收拾残局。没有校准，那些制造了问题的机器，也同样无力解决问题。

这些实践本身并没有改变；改变的是，忽视它们的代价已经变得难以承受。

“生成”与“验证”之间的不对称——也就是 P vs NP 背后的那种直觉，并且已经被 Cobbe 等人在 LLM 上经验性地验证过——也指明了接下来的方向。

生成一个正确解，比验证一个解是否正确更难。你并不需要在实现层面胜过机器；你需要在评估层面胜过它：明确规定“正确”意味着什么，识别输出偏离了哪里，判断它前进的方向是否正确。

那些设计出 Watt 调速器的人，并没有再回去拧阀门。不是因为他们做不到，而是因为那已经不再有意义。