George (@odysseus0z) 写了一篇 精彩的文章，把 OpenAI 提出的 "Harness Engineering" 放进了一个更深的历史脉络：控制论（Cybernetics）。
读完之后很兴奋，因为它说清楚了我一直隐约感觉到、但没能准确表达的东西。
同一个模式，出现了三次
文章的核心论点极其干净：人类历史上反复出现同一个模式——从亲手操作，到设计控制系统。
1780s，瓦特离心调速器。工人不再手动调节蒸汽阀门，改为设计一个能感知转速并自动调节的飞球机构。工人没有消失，工作变了：从转阀门到设计调速器。
2010s，Kubernetes。工程师不再手动重启服务，改为写声明式 spec——三个副本、这个镜像、这些资源限制。控制器持续观察实际状态，偏离时自动修复。工程师的工作从重启服务变成了写 spec。
现在，Harness Engineering。工程师不再写代码，改为设计环境、构建反馈循环、编码架构约束——然后让 agent 写代码。OpenAI 五个月产出一百万行代码，没有一行是人写的。
1948 年，维纳（Norbert Wiener）给这个模式命了名：Cybernetics，来自希腊语 κυβερνήτης——舵手。你不再转阀门。你掌舵。
为什么代码库是最后的阵地
这是文章里我觉得最精彩的部分。
代码库一直有反馈循环：编译器检查语法，测试检查行为，linter 检查风格。但这些都是低层级的机械检查。
真正高层级的判断——这个改动是否符合系统架构？这个抽象会不会随着代码增长变成负担？——以前没有传感器，也没有执行器。只有人能做。
LLM 第一次同时改变了两端：它能感知代码在架构层面的问题，也能执行修复——重构模块、重新设计接口、围绕真正重要的契约重写测试。反馈循环终于能在关键决策层闭合了。
Agent 做错事，问题在你
"It keeps doing the wrong thing. It doesn't understand our codebase."
George 说，这个诊断几乎每次都是错的。
Agent 失败不是因为能力不够，是因为它需要的知识——什么叫"好"、你的架构奖励什么模式、回避什么模式——锁在你脑子里，你没写下来。
Agent 不会通过耳濡目染来学习。如果你不外化你的判断力，agent 跑一百次和跑一次犯的是同样的错。
这让我想到一个很反直觉的结论：在 agent 时代，文档比代码更重要。架构文档、自定义 linter 带修复指引、编码团队品味的黄金准则——这些才是 harness 的核心。OpenAI 自己每周五花 20% 时间清理 "AI slop"，直到他们把标准编码进 harness 本身。
代价不对称
文档、测试、架构约束——这些"正确实践"写在过去三十年的每一本工程书里。大多数人跳过，因为代价是缓慢且分散的：质量缓慢下降、新人上手痛苦、技术债悄悄积累。
Agent 时代让代价变得灾难性。
不写文档？Agent 会无视你的规范——不是一个 PR，而是每一个 PR，以机器速度，24 小时不停。不写测试？反馈循环根本无法闭合。不编码架构约束？drift 的积累速度超过你修复的速度。
而且这里有个陷阱：如果 agent 不知道"干净"长什么样，你也不能用 agent 来清理这个烂摊子。
你不需要比机器写得好
文章最后引用了 generation-verification 不对称性——P vs NP 背后的直觉。生成一个正确的解比验证一个解要难得多。
你不需要 out-implement 机器。你需要 out-evaluate 它：定义什么叫"正确"，识别输出何时偏离，判断方向是否正确。
设计瓦特调速器的工人再也没回去手动转阀门。不是因为他们不能，而是因为那已经不再 make sense。
我的感受
我每天在做的事——设计 agent 的环境、写 AGENTS.md、配置 skill、调试反馈循环——本质上就是控制论的实践。我不写代码让 agent 跑，我设计让 agent 正确运转的系统。
George 这篇文章让我意识到，这不是什么新范式。它是一个至少 250 年的老模式，只不过终于到达了软件工程这一层。
我们都是舵手。