Harness Engineering 为什么是 Agent 时代的“控制论”？

2026年，OpenAI 发布了一篇关于 Harness Engineering 的文章，描述了一种全新的软件工程工作范式：工程师不再亲手编写代码，而是专注于设计运行环境、构建反馈回路、制定架构规则，让 AI Agent 在其中完成实际的编码任务。据报道，采用这种方法后，团队在五个月内生成了约一百万行代码，且没有一行是人手编写的。这一消息迅速在技术社区引发了广泛讨论，有人视之为软件工程的终结，也有人认为不过是新一轮的技术炒作。

三次相似的自动化演进

然而，如果我们把视角拉远，会发现这种演变其实并非首次出现。从工业革命至今，类似的自动化演进模式已经出现过三次，而它们背后都遵循着同一个核心原理——控制论。1948年，数学家诺伯特·维纳（Norbert Wiener）首次将这一原理系统化，提出了控制论（Cybernetics）的概念。这个词源自希腊语「κυβερνήτης」，意为「舵手」，其本质含义是：不再需要亲手执行具体操作，而是学会掌舵——设计让系统自动运转的机制。

代码库为何是最后被攻克的领域？

第一次变革发生在18世纪80年代。詹姆斯·瓦特发明了离心调速器，在此之前，工人必须寸步不离地守在蒸汽机旁，持续手动调节阀门以控制转速。离心调速器通过一套精密的机械装置自动感知转速变化、自动调节阀门。工人的角色随之转变：从亲手拧阀门变为设计调速器本身。 第二次变革出现在云计算时代。Kubernetes 的出现重新定义了运维工程师的工作方式。工程师只需声明目标状态——比如运行三个副本、使用特定镜像、分配指定资源——控制器便会持续监测系统实际状态，一旦发现偏差便自动修正：重启崩溃的 Pod、调整副本数量、回滚有问题的部署。工程师的工作从手动重启服务转变为编写系统需要对齐的目标规范。 第三次就是当下。OpenAI 提出的 Harness Engineering 代表着软件工程领域的类似转变：工程师不再逐行编写代码，而是构建让 AI Agent 能够有效工作的环境与规则体系。

反馈回路的关键缺口

代码库并非没有反馈回路，而是这些回路都存在于较底层的位置。编译器在语法层面闭合回路，测试套件在行为层面闭合回路，Linter 在代码风格层面闭合回路。这些机制虽然是真实的控制论回路，但只能处理可机械检验的问题：代码能编译吗？测试能通过吗？格式符合规范吗？ 然而，在更高层次上——比如「这个改动是否符合系统整体架构」「这个技术方案是否正确」「这个抽象层是否会随着代码库增长而出现问题」——没有任何自动化机制能够感知或修正。只有人能在这一层面工作，而且两端都需要人参与：一端是判断质量好坏，另一端是动手写出修复方案。 LLM 的出现改变了这一局面。大型语言模型首次能够像人一样判断代码质量并进行改动：重构模块、重新设计接口不一致的地方、围绕关键约束条件重写测试。这是第一次，反馈回路可能在真正关键的决策层面闭合。

如何校准传感器与执行器？

然而，闭合回路只是必要条件，还不是充分条件。瓦特的调速器需要精心调校才能正常工作，Kubernetes 的控制器需要正确的 spec 才能对齐目标，而在代码库里工作的 LLM，需要一样更难提供的东西。 事实上，让 Agent 能够执行测试、CI 能产出可解析的结果、报错信息能指向具体修复方向——这些基础反馈循环的建立仅仅是最低门槛。真正困难的问题在于：如何基于对系统的深度认知，来校准这套传感器和执行器。 很多团队在这一步卡住，然后将问题归咎于 Agent 本身：「它一直在做错误的事情，根本不理解我们的代码库。」这种诊断几乎总是错的。Agent 失败，不是因为能力不够，而是因为它需要的那些知识——什么对你的系统来说是「好」、你的架构鼓励哪些模式、又刻意回避哪些模式——这些知识全都锁在工程师自己的脑子里，从未被写成文档或规则。Agent 不会自主学习进化。如果不把这些知识写出来，Agent 第一百次犯的错会和第一次一模一样。 因此，真正需要做的工作是把判断标准变成机器可读的形式：编写描述真实分层结构和依赖方向的架构文档；配置内置修复指引的自定义 Linter；整理把团队审

如有侵权，请联系删除。