Harness Engineering：Agent 时代的“控制论”回归
OpenAI 提出的 Harness Engineering 标志着软件工程从“编写代码”转向“设计环境”，即工程师通过构建反馈回路让 Agent 自主完成编码。这一模式复刻了瓦特离心调速器和 Kubernetes 控制器的历史演进，本质是诺伯特·维纳定义的“控制论”在 AI 时代的体现。其核心挑战不在于模型能力，而在于将人类对系统的隐性认知（如架构规范、质量判断）显性化为机器可执行的规则与测试机制。
事件概述
2024 年 2 月，OpenAI 发布文章《Harness engineering: leveraging Codex in an agent-first world》，提出一种新的工程范式：Harness Engineering。在该模式下，工程师不再直接编写代码，而是负责设计运行环境、制定规则并构建反馈回路，由 Agent 在其中完成实际的编码工作。据 OpenAI 描述，采用该方式的团队在五个月内生成了约一百万行代码，且无一人为手写。
这一概念引发了技术圈的广泛讨论，被视为继 Prompt Engineering（提示工程）和 Context Engineering（上下文工程）之后的第三次叙事演变。其核心转变在于：工程师的关注点从“如何与模型对话”转向“如何构建一个能够持续运行的系统”。
核心信息：控制论的三次演进
这种模式的本质并非新事物，而是**控制论（Cybernetics）**在不同技术阶段的重复应用。1948 年，Norbert Wiener 将这种“从亲手操作转变为设计自动运转机制”的模式命名为控制论。历史上该模式出现过三次：
- 蒸汽机时代（1788 年）：James Watt 改进离心调速器（Centrifugal governor）。工人不再需要手动调节阀门，转而设计能自动感知转速并调节阀门的机械装置。
- 云原生时代（Kubernetes）：工程师只需声明目标状态（如副本数、镜像版本），**控制器（Controller）**会自动监测实际状态与目标的偏差，并执行修正（如重启 Pod、回滚部署）。工作重心从手动运维转向编写对齐目标的 Spec。
- Agent 时代（当前）：工程师设计环境约束与反馈机制，让 Agent 处理编码细节。正如 Kubernetes 词根源自希腊语“舵手”，这一模式的核心逻辑始终是“掌舵”而非“划桨”。
关键挑战：校准传感器与执行器
尽管代码库底层存在编译器、测试套件和 Linter 等反馈回路，但它们仅能处理语法、行为或风格等机械检验问题。在架构决策层面（如方案是否合理、抽象层是否随时间恶化），过去缺乏自动化机制，必须依赖人工判断与修复。
LLM 的出现首次使得在架构决策层面闭合反馈回路成为可能，但这要求极高的校准精度：
- 隐性知识显性化：Agent 无法自主学习团队的审美、架构偏好或“什么是好代码”的标准。如果这些知识未写入文档或规则中，Agent 会反复犯同样的错误。
- 基础设施设计：真正的难点在于设计测试环境、CI 流程及报错解析机制。例如，Nicholas Carlini 曾演示让 16 个 Agent 并行构建 C 编译器，其成功关键在于精心设计的测试与反馈环境，而非简单的 Prompt。
- 验证优于生成：基于 P vs NP 问题的直觉，验证答案的正确性通常比生成正确答案更容易。因此，工程重点应转向定义“正确标准”、识别输出偏差以及高效评估产出，而非单纯追求生成速度。
结论：工程实践的代价重构
文档、自动化测试、架构约束和快速反馈回路，本就是软件工程三十年来推崇的最佳实践。然而，过去跳过这些步骤的代价是缓慢且分散的（如技术债积累、新人上手难）。
在 Agentic Engineering 时代，跳过这些步骤的代价变得极端且即时：
- 若无文档，Agent 会以机器速度全天候重复违反规范的行为。
- 若无测试，反馈回路无法闭合。
- 若无架构约束，代码漂移速度将远超人工修复速度。
唯一的出路是将人类的判断标准转化为机器可读取的形式（如架构文档、自定义 Linter 修复指引、黄金原则配置）。未经校准的 Agent 不仅无法解决问题，反而会加速制造混乱。因此，Harness Engineering 并非取代程序员，而是迫使团队回归最基础但常被忽视的工程纪律。