Harness Engineering：工程师角色的第三次跃迁
作者：George Zhang（OpenClaw 维护者）
本文系 George Zhang 对 Harness engineering 的深度解读，原文发布于其 X 平台。
今年 2 月，OpenAI 发布文章《Harness engineering: leveraging Codex in an agent-first world》，提出一种新范式：工程师不再直接编写代码，而是设计运行环境、构建反馈回路、将架构约束转化为可执行规则，交由 AI agent 完成编码任务。
该理念迅速引发技术圈热议。有人视其为软件工程的终结，也有人认为只是新一轮炒作。事实上，AI 编程的演进路径清晰可见：从 prompt engineering，到 context engineering，再到 harness engineering——工程师的关注重心，已从“如何与模型对话”，转向“如何构建可持续自主运行的系统”。
这一转变并不新鲜。从瓦特的离心调速器，到 Kubernetes 的控制器，工程师的角色始终在重复同一逻辑：从手动操作系统，升级为设计让系统自我调节的机制。1948 年，诺伯特·维纳（Norbert Wiener）将这种以反馈闭环为核心的理论命名为控制论（cybernetics）。
因此，真正关键的问题并非“AI 是否取代程序员”，而在于：当反馈回路首次延伸至“架构决策”层面时，工程师应如何确保整套机制稳健运转？
01 同一个模式，出现了三次
读完 OpenAI 关于 harness engineering 的文章后，我意识到：这个模式我已见过三次。
第一次：18 世纪蒸汽机时代
詹姆斯·瓦特改进离心调速器（Centrifugal governor），使机械系统能自动感知转速、调节阀门。工人不再守在机器旁手动操作，转而专注于调速器的设计与校准。
离心调速器是一种利用离心力自动调节发动机转速的机械装置，1788 年瓦特将其成功应用于蒸汽机速度控制。
第二次：云原生时代
Kubernetes 引入声明式 API：工程师只需定义目标状态（如副本数、镜像、资源配额），控制器便持续比对实际状态并自动纠偏——重启失败 Pod、扩缩容、回滚异常部署。工程师的工作重心，由此从运维干预转向 spec 设计。
Kubernetes 是开源容器编排平台，用于自动化部署、扩展和管理容器化应用，由 Cloud Native Computing Foundation（CNCF）维护，是现代云原生基础设施的核心组件。
第三次：AI Agent 时代
OpenAI 描述了一类新型工程师：他们不写代码，只设计 agent 运行所需的环境、约束与反馈机制。团队曾用五个月生成约一百万行代码，全程无人手编写，该模式被命名为 harness engineering。
三次变革共享同一内核：诺伯特·维纳提出的控制论（cybernetics）——源自希腊语 κυβερνήτης（舵手），Kubernetes 之名亦出于此。本质即：从“拧阀门”转向“掌舵”。
Norbert Wiener（1894–1964）是美国数学家，控制论奠基人，在《Cybernetics: Or Control and Communication in the Animal and the Machine》中构建了信息、控制与反馈的理论框架。
这一模式反复出现的根本原因在于：每当某一层级出现足够可靠的传感器与执行器，该层级的反馈回路便得以闭合。
02 为什么代码库是最后被攻克的领域？
代码库并非没有反馈回路，只是现有回路均停留在底层：
- 编译器在语法层面闭环；
- 测试套件在行为层面闭环；
- Linter在风格层面闭环。
这些机制仅能处理可形式化验证的问题：能否编译？是否通过测试？格式是否合规？
但再向上一层——架构合理性、技术方案优劣、抽象设计的长期可维护性——既无传感器感知，亦无执行器修正。这类高阶判断与修复，至今仍完全依赖人工，且需两端协同：一端评估质量，一端输出修改。
大语言模型（LLM）同时改变了这两端：它能理解上下文、识别架构缺陷、重构模块、重写接口、重设测试，并围绕核心约束进行系统性优化。这是首次，反馈回路有望在最关键的“架构决策层”实现闭环。
但闭环只是必要条件，而非充分条件。瓦特的调速器需精细调校，Kubernetes 的控制器依赖精准 spec，同理，作用于代码库的 LLM 更需要一套可落地的“harness”——而这恰恰最难构建。
03 如何校准传感器和执行器？
让 agent 执行测试、CI 输出结构化结果、报错指向具体修复路径——这只是最低门槛。
Nicholas Carlini 曾演示：用 16 个 agent 协作构建 C 编译器。他所用 prompt 极其简单，但测试与运行环境的设计却极为精密。他事后坦言：“我大部分精力花在设计 Claude 周围的 harness 上——包括测试、运行时和反馈机制。”
Nicholas Carlini 是专注 AI 安全与对抗性攻击研究的计算机科学家。
左右滑动以查看全部内容
真正的挑战在于：如何基于你对系统的深层认知，校准这套传感器与执行器。
多数人在此卡住，却归咎于 agent 本身：“它总做错事”“它不懂我们的代码库”。这几乎总是误判。
agent 失败，从来不是因为能力不足，而是因为它的决策依据——什么算“好代码”、哪些架构模式被鼓励或规避——全部封存在工程师脑中，从未显式写出。agent 不会自主进化；若你不将标准编码化，它第一百次犯的错，与第一次毫无区别。
因此，核心工作是将隐性判断标准显性化、机器可读化：
- 撰写真实反映分层结构与依赖方向的架构文档；
- 配置内置修复指引的自定义 Linter；
- 将团队技术审美与最佳实践提炼为可执行的黄金原则。
OpenAI 同样发现此关键点：早期团队每周需花费 20% 时间清理“AI slop”（低质产出），后来将质量标准直接编入 harness，问题才得到根治。
04 唯一的出路
文档、自动化测试、架构约束显性化、快速反馈回路——这些本就是三十年来软件工程公认的正道。人们常选择跳过，因代价显现缓慢：代码质量渐衰、新人上手困难、技术债悄然累积。
Agentic engineering 将这一代价急剧放大：
- 若跳过文档，agent 将无视所有规范，在每一个 PR 中以机器速度重复相同错误；
- 若跳过测试，反馈回路无法建立；
- 若跳过架构约束，代码漂移（Code Drift）速度将远超人工修复能力；
- 更危险的是：若 agent 不知何为整洁代码，你也无法用它来收拾烂摊子。
代码漂移指项目代码随时间偏离原始设计目标或规范的现象，表现为架构不一致、功能冗余等，最终抬升维护成本、削弱可读性与可靠性。
该做的事从未改变，只是不做之事的代价已不可承受。
因此，我们必须聚焦“生成之外”的验证环节。生成答案与验证答案存在根本不对称性——即 P vs NP 问题的直觉体现：验证通常远比生成容易。Cobbe 等人已在 LLM 实验中证实：训练“验证器”判断答案正确性，比直接生成正确答案更高效、更稳定。
P vs NP 是计算机科学核心未解难题：所有可快速验证的问题（NP 类），是否也可被快速求解（P 类）？
Karl Cobbe 等人于 2021 年 10 月在 arXiv 发表《Training Verifiers to Solve Math Word Problems》，证明在 LLM 上验证数学应用题答案的准确率显著优于直接生成。
左右滑动以查看全部内容
当年设计调速器的工人，没有回到蒸汽机前拧阀门——不是不会，而是此举已毫无意义。
排版：夏悦涵