转载说明：本文基于 George（@odysseus0z）在 X 上发布的长文《Harness Engineering Is Cybernetics》精译整理。正文以 X Article 页面为准：https://x.com/odysseus0z/article/2030416758138634583。原始请求链接：https://x.com/i/status/2030416758138634583。StaticFlow 入库日期使用 2026-03-17；来源请求页的 Jina 镜像时间为 2026-03-17 15:56 UTC。Harness 工程就是控制论 阅读 OpenAI 那篇关于 Harness Engineering 的文章时，我一直有一种说不出的熟悉感。后来我终于想明白了：这个模式我以前见过，而且不是一次，是三次。 第一次出现在 18 世纪 80 年代的 詹姆斯·瓦特离心调速器。在它之前，工人要站在蒸汽机旁边手动调阀门。它出现之后，带配重的飞球机构会感知转速，再自动调节阀门。工人没有消失，但工作内容变了：从亲手拧阀门，变成设计调速器。 第二次是 Kubernetes。你声明一个期望状态：三个副本、这个镜像、这些资源限制。控制器会持续观察现实状态；一旦两者偏离，它就会做协调：重启崩掉的 Pod、扩缩副本、回滚失败部署。工程师的工作也从手动重启服务，转向编写系统要去持续对齐的那份规范。 第三次就是现在。OpenAI 描述了一类已经不再亲手写代码的工程师：他们设计环境、搭建反馈回路、把架构约束编码进去，然后由 agent 来写代码。五个月写出一百万行代码，没有一行是手工写的。他们把这件事叫作 “harness engineering”。 每一次，这个模式都完全一样。Norbert Wiener 在 1948 年给它起了名字：cybernetics，词根来自希腊语 κυβερνήτης，也就是 steersman，掌舵人。Kubernetes 这个名字也来自同一个词根。你不再去拧阀门，你是在掌舵。 为什么代码库会是例外？ 每当这种模式出现，本质上都是因为有人造出了足够强的传感器和执行器，能够在那个层级上把反馈回路闭合起来。 代码库当然早就有反馈回路，但它们一直只存在于更低层。编译器闭合的是语法回路，测试集闭合的是行为回路，lint 闭合的是风格回路。它们都是真正的控制论装置，但只能作用在那些可以机械检查的属性上。能不能编译？能不能通过测试？有没有违反规则？ 再往上的那些问题呢？这次修改是否符合系统架构？这个方向是不是对的？这个抽象会不会随着代码库继续长大而埋下问题？在这些层级上，过去既没有传感器，也没有执行器。只有人类能在这里同时承担两件事：判断质量，以及亲手修正它。 LLM 一次性改变了这两件事。它既能在过去只属于人类的层级上“感知”，也能在同一个层级上“行动”：重构模块、重设不一致的接口、围绕真正重要的契约重写测试。第一次，反馈回路终于可以在那些真正关键的决策层闭合。校准传感器与执行器 但回路能闭合，只是必要条件，不是充分条件。瓦特的调速器要调参，Kubernetes 控制器需要正确的 spec，而让 LLM 在你的代码库里工作，则需要一种更难提供的东西。 先把最基础的反馈回路搭起来，只是入场门槛而已：agent 能自己运行的测试、输出可解析的 CI、能够直接指向修复方向的错误信息，这些都只是最低配置。 Carlini 也说明了同样的道理：当他让 16 个并行代理去构建一个 C 编译器时，提示本身其实很简单，真正被精心设计的是测试基础设施。“我大部分精力都花在为 Claude 设计环境上——测试、环境、反馈。” 更难的问题，是如何用你这个系统独有的知识去校准传感器和执行器。大多数人真正卡住的地方就在这里，也是他们把锅甩给 agent 的地方。 “它老是在做错的事。它根本不理解我们的代码库。” 这种诊断几乎总是错的。agent 失败，不是因为它能力不够，而是因为它所需要的知识，也就是在你的系统里“什么算好”、什么模式会被架构鼓励、什么模式会被架构排斥，这些东西一直锁在你的脑子里，而你并没有把它们外化出来。agent 不会靠耳濡目染学会这些事。如果你不把它写下来，那么第一百次运行时，它犯的错误和第一次并不会有什么本质区别。 真正的工作，是把你的工程判断变成机器可读的东西。能够描述真实分层和依赖方向的架构文档，内置修复建议的定制 lint，编码了团队品味的黄金原则。OpenAI 也撞上了同一堵墙：他们每周五有 20% 的时间都在清理 “AI slop”，直到把自己的标准编码进 harness 本身。 这套实践，文档、自动化测试、被编码的架构决策、快速反馈回路，其实一直都是对的。过去三十年的工程书几乎都在讲这些。多数人之…