> ## Content Index > Fetch the complete content index at: https://www.hubwiz.com/blog/llms.txt > Use this file to discover other available public pages before exploring further. # Harness工程就是控制论 - URL: https://www.hubwiz.com/blog/harness-engineering-is-cybernetics/ - Published: 2026-03-10T15:02:07.000Z - Updated: 2026-03-11T01:24:46.000Z - Description: 阅读 OpenAI 关于Harness工程的文章时，我始终有一种难以言喻的感觉。后来我恍然大悟：我以前见过这种模式。而且不止一次——而是三次。 - Author: admin - Tags: AGENT, #Import 2026-10-14 14:41 阅读 OpenAI 关于[Harness工程](https://openai.com/index/harness-engineering/?ref=hubwiz.com)的文章时，我始终有一种难以言喻的感觉。后来我恍然大悟：我以前见过这种模式。而且不止一次——而是三次。 第一次是 18 世纪 80 年代[詹姆斯·瓦特发明的离心式调速器](https://en.wikipedia.org/wiki/Centrifugal%5Fgovernor?ref=hubwiz.com)。在此之前，工人需要站在蒸汽机旁手动调节阀门。之后，一个配重飞球机构能够感知转速并自动调节阀门。工人并没有消失。工作内容发生了变化：从手动调节阀门变成了设计调速器。 ![](https://www.hubwiz.com/blog/content/images/2026/03/image-72.png) 第二次是 [Kubernetes](https://kubernetes.io/docs/concepts/architecture/controller/?ref=hubwiz.com)。你声明期望状态——三个副本、这个镜像、这些资源限制。控制器持续监控实际状态。当两者出现偏差时，控制器会进行协调：重启崩溃的 Pod、扩展副本、回滚错误的部署。工程师的工作也从重启服务转变为编写系统用来协调的规范。 第三次就是现在。OpenAI 描述了那些不再编写代码的工程师。相反，他们设计环境、构建反馈回路并编写架构约束——然后由代理编写代码。[五个月内写出一百万行代码](https://openai.com/index/harness-engineering/?ref=hubwiz.com)，没有一行是手工编写的。他们称之为“驾驭工程”。 ![](https://www.hubwiz.com/blog/content/images/2026/03/image-73.png) 每次都是同样的模式。[诺伯特·维纳](https://en.wikipedia.org/wiki/Cybernetics:%5FOr%5FControl%5Fand%5FCommunication%5Fin%5Fthe%5FAnimal%5Fand%5Fthe%5FMachine?ref=hubwiz.com)在1948年将其命名为控制论（cybernetics），源自希腊语κυβερνήτης——舵手。你停止转动阀门，你开始掌舵。 每次这种模式出现，都是因为有人构建了足够强大的传感器和执行器，从而在该层闭合了回路。 ## 为什么代码库是例外？ 代码库也有反馈回路，但仅限于底层。编译器对语法进行闭环控制。测试套件对行为进行闭环控制。代码检查工具对风格进行闭环控制。这些都是真正的控制论控制——但它们只能作用于那些可以通过机械方式检查的属性。它能编译吗？它能通过测试吗？它符合规则吗？ 除此之外的一切——这个改动是否符合系统架构？这是正确的方法吗？随着代码库的增长，这种抽象方式会不会带来问题？——过去，系统既没有传感器也没有执行器。只有人类才能在那个层面上进行操作，包括判断质量和编写修复程序。 LLM同时改变了这两方面。它们能够感知过去由人类掌控的层面，并在同一层面上采取行动：重构模块、重新设计不一致的接口、围绕真正重要的契约重写测试套件。反馈回路首次能够在做出重要决策的地方闭合。 但闭合回路是必要的，而非充分的。Watt 的调速器需要进行调整。Kubernetes 控制器需要正确的规范。而运行在你的代码库上的 LLM 则需要提供更复杂的功能。 ## 校准传感器和执行器 让基本的反馈回路正常工作——代理可以运行的测试、提供可解析输出的持续集成、指向修复的错误信息——是基本要求。Carlini 用 16 个并行代理构建 C 编译器时[证明了这一点](https://www.anthropic.com/engineering/building-c-compiler?ref=hubwiz.com)：[提示信息非常简单](https://github.com/anthropics/claudes-c-compiler/commit/a28ff299?ref=hubwiz.com)，但测试基础设施设计得非常精良。 “我的大部分精力都投入到了围绕 Claude 设计环境上——测试、环境、反馈。” 更难的问题在于如何利用特定于你系统的知识来校准传感器和执行器。大多数人都会卡在这里，并把责任归咎于智能体。 “它总是做错事。它不理解我们的代码库。”这种诊断几乎总是错误的。智能体失败并非因为能力不足，而是因为它需要的知识——对你的系统而言“好”意味着什么，你的架构奖励哪些模式，又避免哪些模式——都锁在你的脑子里，而你没有将其外化。智能体不会通过耳濡目染来学习。如果你不把这些知识写下来，智能体在第一百次运行中犯的错误和第一次一样。 关键在于让你的判断能够被机器理解。例如，描述实际分层和依赖关系的架构文档；内置修复指令的自定义代码检查工具；以及体现团队风格的黄金法则。 OpenAI 发现，他们每周五都要花 20% 的时间来清理“AI 垃圾”，直到他们将标准编码到框架本身。 ## 唯一的出路 这些实践——文档、自动化测试、规范化的架构决策、快速反馈循环——一直都是正确的。过去三十年出版的每一本工程书籍都推荐这些做法。大多数人之所以忽略它们，是因为忽略的代价缓慢而分散：质量逐渐下降、繁琐的上手流程、以及悄然累积的技术债务。 智能体工程使这些代价变得极其巨大。忽略文档，智能体就会无视你的规范——不是在某个 PR 上，而是在每一个 PR 上，以机器的速度，全天候地无视规范。忽略测试，反馈循环根本无法闭合。忽略架构约束，偏差累积的速度会超过你的修复速度。而陷阱就在这里：如果智能体不知道“干净”是什么样子，你就无法用它们来清理垃圾。没有校准，制造问题的机器……连lem也解决不了这个问题。 实践方法并没有改变。但忽视这些方法的代价却变得难以承受。 生成与验证之间的不对称性——[P问题 vs. NP问题](https://en.wikipedia.org/wiki/P%5Fversus%5FNP%5Fproblem?ref=hubwiz.com)背后的直觉，Cobbe等人通过对LLM的实证研究[证明了这一点](https://arxiv.org/abs/2110.14168?ref=hubwiz.com)——预示着未来的发展方向。生成一个正确的解比验证一个解要难得多。你不需要在实现上超越机器，而是需要超越它的评估能力：明确“正确”是什么样子，识别输出何时出错，判断方向是否正确。 设计瓦特调速器的工人们没有再回去转动阀门。不是因为他们做不到，而是因为这样做已经没有意义了。 --- 原文链接：[Harness Engineering Is Cybernetics](https://x.com/odysseus0z/status/2030416758138634583?ref=hubwiz.com) 汇智网翻译整理，转载请标明出处