Harness 工程(上):AI 时代的新软件工程范式
一、什么是 Harness 工程？——AI 时代诞生的新工程学科
1.1 概念起源与定义
“Harness”（马具/缰绳）这个词来自马术——缰绳、马鞍、嚼口构成了驾驭一匹强健但不知方向的马所需的全套装备。这个比喻对 AI 代理时代极为贴切：
马具（Harness）= 工程基础设施——约束、护栏、反馈回路，将模型的力量引向正确方向
Harness 工程（Harness Engineering）是 2026 年初由 Mitchell Hashimoto（Terraform、Ghostty 创始人）命名、经 OpenAI 工程博客系统阐述的新兴软件工程学科。其核心定义是：
设计约束机制、反馈回路、文档结构、代码审查规则、可观测性流水线和生命周期管理系统，使 AI 编程代理能够在生产规模下可靠运行的工程实践。
用 Hashimoto 的原话说：”这是一种理念——每当你发现代理犯了一个错误，你就花时间设计一套解决方案，使代理永远不再犯同样的错误。”
1.2 OpenAI 的里程碑实验
2026 年 2 月，OpenAI 工程师 Ryan Lopopolo 发表了一篇极具震撼性的博客文章，记录了一个为期五个月的内部实验：
实验约束：团队强制要求自己使用”零手写代码”原则——所有应用逻辑、测试、CI 配置、文档、可观测性工具和内部开发工具，全部由 Codex 代理编写。
-
-
-
平均吞吐量：每位工程师每天 3.5 个 PR，随团队从 3 人增长到 7 人，吞吐量持续提升
-
-
产品已有内部每日用户和外部 Alpha 测试用户，真实交付、部署、出问题、被修复
-
这不是演示或概念验证——而是一个真实运行的生产系统。
1.3 范式转变：从”写代码”到”设计环境”
OpenAI 的实验揭示了 Harness 工程最核心的洞察：
“当软件工程团队的主要工作不再是编写代码，而是设计环境、明确意图、构建允许 Codex 代理可靠工作的反馈回路时，一切都变了。”—— OpenAI 工程博客
核心转变的本质：每当代理失败，修复方法几乎从不是”让它更努力尝试”，而是工程师介入并追问：”代理缺少什么能力，以及如何让这种能力既对代理可理解又可强制执行？“
1.4 Harness 工程的三大支柱
OpenAI 实验总结出的 Harness 框架包含三个核心类别：
支柱一：上下文工程（Context Engineering）
代理只能看到当时上下文窗口中的内容——任何存在于 Google Docs、Slack 聊天或人们脑袋里的知识，对代理来说等同于不存在。这要求团队把一切决策推入仓库：
将 AGENTS.md（或 CLAUDE.md）作为目录，而非百科全书。文件约 100 行，作为一张地图，指向更深层的信息源
结构化的 docs/ 目录作为知识系统，包含设计文档（含验证状态和核心信念）、架构文档（域和包分层的顶层地图）、质量文档（记录每个产品域和架构层的技术债缺口）
将 Slack 中对齐架构模式的讨论及时写回仓库——”如果它不能被代理发现，它就和三个月后入职的新员工所不知道的事情一样不存在”
支柱二：架构约束（Architectural Constraints）
：每个域的代码对其他域有刚性依赖约束，防止代理创造意外耦合
：要求代理在模块边界处解析数据形状，而非使用模糊的 any 类型
机械不变量（Mechanical Invariants）
：CI 中的 linter 和验证器在每次代码变更时强制执行架构边界、格式规则和数据校验
：这是 OpenAI 实验中最聪明的创新之一——自定义 linter 错误消息同时充当补救指令。当代理违反架构约束时，错误消息不只是标记违规，还告诉代理如何修复。工具在代理工作时教会它规范
支柱三：熵管理（Entropy Management）
：在代理吞吐量远超人类注意力的系统中，修正是廉价的，等待是昂贵的。PR 应该小而快，不应被不稳定的测试无限阻塞
：当代理出错或在任务上挣扎时，始终由 Codex 自身来写修复——这形成了将文档变成反馈回路而非静态制品的机制
二、为什么 Harness 工程重要：模型是商品，Harness 才是护城河
2.1 LangChain 的决定性证明
最令人信服的证据来自 LangChain 的实验：在不改变任何模型权重的前提下，仅通过改变 Harness，他们的编程代理在 Terminal Bench 2.0 上从 52.8% 跳升至 66.5%——从前 30 名跃入前 5 名。
相同模型，不同 Harness = 显著更好的结果
具体改动：增加了一个自我验证循环和循环检测机制。这就是 Harness 工程的威力——不是更好的模型，而是更好的环境。
2.2 自主性的层级进化
OpenAI 的实验记录了一个完整的自主开发闭环，当 Harness 足够完善时，代理能够：
-
-
-
录制展示失败的视频（通过 Chrome DevTools Protocol 集成）
-
-
-
-
-
-
-
-
单次 Codex 运行有时工作长达六个小时——通常在人类睡眠时进行。
三、Harness 工程的三大核心洞察
3.1 架构刚性产生可靠性
OpenAI 的发现反直觉：更多约束通常产生更高可靠性，而不是更少。代理在严格架构边界内（由 linter 和验证器强制执行）比在灵活、模糊的环境中表现更好。
这颠覆了许多工程师的直觉——我们通常认为灵活性有助于创新。但对于 AI 代理，明确的边界创造了可预测的行为空间，而模糊的规则导致不可控的漂移。
3.2 文档是代码，不是附属物
在 Harness 工程中，文档不再是可选的、事后补写的、快速过时的负担——它是代理运行的基础设施。Martin Fowler 的一位分析师评论道：
“OpenAI 团队讨论了架构刚性和约束规则。我能看到的主要关注点是保持数据结构稳定，以及定义和强制模块边界。”
AGENTS.md（或CLAUDE.md）不是 README——它们是可执行的行为规范，通过 CI 持续验证其一致性。
3.3 工程纪律转移到脚手架，而非代码
“构建软件仍然需要纪律，但纪律更多地体现在脚手架而非代码本身。”
-
代码质量 → 由 CI linter 和测试强制保障
-
架构一致性 → 由机械不变量（Mechanical Invariants）维护
-
-
人类工程师的价值不再在于能写多少行代码，而在于设计多好的环境，以及能够多精准地将工程判断编码为代理可理解的规范。
结语：新工程学科的黎明
Harness 工程不是一个新工具，而是一种新思维方式。正如 OpenAI 的实验所揭示的：
“我们最困难的挑战现在集中在设计环境、反馈回路和控制系统——帮助代理实现我们的目标：大规模构建和维护复杂、可靠的软件。”
当 Claude Code 这样的工具让代理能够持续工作数小时、自动打开 PR、运行测试并自我修复时，真正稀缺的资源不再是代码输出，而是人类的时间、注意力和工程判断力。
Harness 工程正是这种转变的系统回应：将工程纪律从”我怎么写这段代码”转移到”我如何设计一个让代理可靠地写好代码的环境”。
无论你用的是 Claude Code、Codex、Cursor 还是自定义工具链——你都在做 Harness 工程。唯一的问题是，你是在有意识地做，还是仍在随机应对？
夜雨聆风
