AI 技术圈热衷于创造新术语。去年 Vibe Coding 的热度刚过，今年一个新概念又成为焦点——Harness Engineering。
OpenAI 发布了长篇论述，Anthropic 迅速跟进分享，清华发表了相关论文，Martin Fowler 的网站也刊载了深度分析。仿佛一夜之间，整个技术社区都在讨论它。社交媒体上充斥着 “Harness is the new Prompt”、“不懂 Harness 你就落伍了” 的声音。
但这真的只是一个炒作的概念吗？我花了两天时间，深入研究了来自 OpenAI、Anthropic、LangChain 和 Martin Fowler 四方的原始材料。今天，就用最直白的语言，把这件事彻底讲清楚。
一个令人震撼的案例
OpenAI 内部进行了一项实验：
3 名工程师，耗时 5 个月，交付了一个完整的软件产品。代码量超过 100 万行，提交了 1500 个 Pull Request。
人类工程师 没有手写过一行代码。
之后团队扩展到 7 人，每人每天平均处理 3.5 个 PR。注意，不是“编写” 3.5 个 PR，而是“处理”——审查、引导、纠正偏差。
这不是一个实验室演示，而是一个有真实内部用户、经历过线上故障和修复的真实产品。
那么，这些不写代码的工程师，整天在做什么？答案就是四个字：设计 Harness。
Harness 究竟是什么？
先别急着认为这又是一个华而不实的新词。“Harness” 这个词的本义是 马具——包括缰绳、马鞍、马镫、笼头等一整套装备。
想象一下：你面前有一匹千里马。它力气大、跑得快、精力旺盛。但如果你不给它套上马具，它就是一匹四处乱窜的野马。它可能冲向悬崖，可能跑进别人的田地，也可能跑着跑着自己就迷路了。
现在的 AI 智能体 就是这样一匹马。
能力确实强大。但不套上缰绳？它会自信满满地写出一堆“看起来正确但实际全错”的代码，会无视你的架构规范，会在你不注意时悄悄引入技术债务。
Anthropic 的一位工程师说过一句非常精准的话：
AI 就像一个极其听话但缺乏背景知识的实习生。它倾向于填补你指令中的空白，进行“自信的即兴发挥”。如果你不审查它的假设，就会积累“信任债务”。
“信任债务” —— AI 做了一堆你并未要求的决定，这些决定目前看似没问题，但在未来某个时刻会爆发，届时你将需要花费巨大代价去逆向工程那些你从未意识到的假设。
Harness Engineering 所做的工作，就是为这匹马搭建一套完整的工作环境——让它既能跑得快，又始终运行在你设定的轨道上。
三年三阶段：从“教说话”到“搭工位”
要理解 Harness，最好将其置于一个时间线中审视。过去三年，我们与 AI 协作的方式经历了三次范式转移：
🔹 2023-2024 年：Prompt Engineering —— 琢磨“如何与 AI 对话”
这个阶段大家最为熟悉。精心设计一段提示词，加上少量示例，祈祷 AI 输出一个好结果。问题是：任务一旦复杂就难以控制。你说了一大堆，AI 可能选择性忽略，只听到它想听的部分。
🔹 2025 年：Context Engineering —— 琢磨“给 AI 看什么信息”
Shopify 的 CEO 将这个推上了风口。开始管理系统提示、对话历史、记忆、RAG 检索结果。从“说什么”升级到“准备什么”。但本质上，交互模式没变——依然是“你给信息，AI 给输出”。
🔹 2026 年：Harness Engineering —— 琢磨“为 AI 构建什么样的工作环境”
这次是质变。不仅管理信息输入，还管理整个执行环境：它能使用什么工具、出错时由谁告知、必须遵守哪些规则、由谁来检查它的工作成果。
打个比方：
- Prompt Engineering 像是教马“左转”“右转”的口令。
- Context Engineering 像是给马一张地图让它自己看路。
- Harness Engineering 像是给马装上缰绳、马鞍和护栏——它可以自己奔跑，但跑不出你划定的安全范围。
说白了，这是一个从教它说话，到为它备课，再到 为它搭建工位、设立规矩、配备考核体系 的演进过程。
Harness 的构成：五大核心组件
说了这么多概念，Harness 具体长什么样？综合 OpenAI、Anthropic、LangChain 和 Martin Fowler 四方的实践经验，可以归纳为 五大核心组件，它们像五个齿轮一样围绕着 AI Agent 运转：
一、结构化知识系统 —— 给 AI 一张“地图”
AI Agent 要在一个拥有百万行代码的仓库中工作，它必须了解整体架构、各模块职责、API 约定。如何提供这些信息？
最天真的做法是：编写一个巨大的 AGENTS.md 文件，把所有信息塞进去。
OpenAI 曾踩过这个坑。 结果 AI 反而“看花了眼”——当一切都标记为“重要”时，一切就都不重要了。而且大文档腐化得最快，代码更新了而文档没跟上，过时的信息比没有信息更危险。
后来他们改成了 “地图模式”：
repo/
├── AGENTS.md ← 只保留约100行，像目录一样
├── docs/
│ ├── architecture/ ← 整体架构文档
│ ├── domains/ ← 各业务领域的详细文档
│ └── runbooks/ ← 操作手册
AI 从这份“地图”出发，按需深入特定区域。这被称为 渐进式披露——先给地图，走到哪里看到哪里，而不是一开始就扔给它一本百科全书。
更绝的是：OpenAI 还专门运行了一个 “文档清洁 Agent”——一个在后台工作的 AI，其唯一任务就是扫描文档与代码之间的不一致之处，并自动提交 PR 来修复过时的文档。
二、机械化架构约束 —— 将你的“品味”编码化
这是最反直觉但最有效的部分。
很多人抱怨 “AI 老是做错”，但真正的问题是：什么叫“对”，你从未明确告诉过它。 你团队的架构规范、编码风格、哪些模式该用哪些该避免——这些东西锁在你的头脑里，AI 不会通过“耳濡目染”来学习。
OpenAI 的解决方案是：将所有架构规则转变为自定义的 Linter 规则，进行机械化强制执行。
Types → Config → Repo → Service → Runtime → UI
每个业务领域按照这个层级组织，下层不能反向依赖上层。这条规则不是写在文档里靠人记忆的，而是被编写成 Linter 规则——任何违反的代码都无法通过 CI，无论它是人写的还是 AI 写的。
关键细节：Linter 的报错信息中 直接附带修复指导。不只是说“你违反了规则 X”，而是解释为什么这条规则存在、正确的做法是什么。AI 看到报错就知道如何修改，无需人工介入。
Martin Fowler 的网站上有一句精妙的总结：
为了获得更高的 AI 自主性，运行时必须受到更严格的约束。增加信任需要的不是更多自由，而是更多限制。
翻译成大白话：你越想赋予 AI 自由工作的能力，就越要把规矩定得死死的。 就像高速公路上的护栏——正是因为有了护栏，你才敢把车速提到 120 公里/小时。
三、可观测性注入 —— 让 AI 能“看见”自己的工作
AI 写完代码，如何知道它是否正确？仅靠测试是不够的，测试只覆盖你预先想到的场景。
OpenAI 的做法更为激进：让 AI 直接接入应用的运行时环境。
- 通过
git worktree 启动独立的应用实例。
- 接入 Chrome DevTools，AI 能像人一样在浏览器中操作应用、截图、录制 Bug 复现视频。
- 直接使用 LogQL 查询日志、PromQL 查询监控指标。
这意味着你可以给 AI 下达这样的指令：“确保服务启动时间在 800 毫秒内完成”——它会自己去查看指标、寻找瓶颈、修改代码。
传统软件工程中，可观测性是给人看的（仪表盘、告警）。在 Harness Engineering 中，可观测性是给 AI 看的。
四、自修复闭环 —— 代码库的“垃圾回收机制”
任何大型代码库都有一个天敌：熵增。代码越多，模式越分裂，技术债务积累得越快。
当 AI 大量生成代码时，这个问题会被放大十倍。AI 会 复现代码库中已有的坏模式——如果某处有一段写得糟糕的代码，Agent 会模仿这种写法，导致坏模式像病毒一样扩散。
OpenAI 最初每周要花费 20% 的时间来清理“AI 垃圾代码”，后来发现这无法规模化。
解决方案是：将清理工作也变成自动化 Agent 的任务。 后台定期运行“清洁 Agent”，扫描代码库中偏离标准的地方，自动提交重构 PR，经 CI 验证通过后自动合并。
这就是代码库的“垃圾回收机制”——不等技术债务堆积到崩溃时才偿还，而是进行小额、高频、持续的偿还。
五、Agent 互审机制 —— AI 审查 AI 的代码
在传统流程中，每个 PR 都需要人工审查。但当一天出现数百个 PR 时，人工审查就成了严重的瓶颈。
OpenAI 引入了 AI Reviewer——Agent A 编写代码，Agent B 审查代码，发现问题后修改并重新提交，直到通过为止。
人类只介入架构层面的重大决策。 日常的代码风格、逻辑正确性、测试覆盖率等，全部交由 Agent 互相审查。
不仅是概念包装：其本质是控制论
聊到这里，你可能仍在思考：这不就是把一堆最佳实践打了个包，起了个新名字吗？
我起初也这么认为。但深入研究后我发现，其背后有一个深刻的思想根基：控制论。
18 世纪，瓦特发明了离心式调速器。在此之前，需要一名工人站在蒸汽机旁手动拧阀门来控制转速。有了调速器，一个机械装置能自动感知转速并调节阀门。工人并未消失，但其工作发生了变化——从亲手拧阀门变为 设计调速器。
Kubernetes 也是同样的模式。你声明期望状态——3 个副本、这个镜像、这些资源限制。控制器持续观察实际状态，出现偏差就自动协调。工程师的工作从重启服务变为编写声明式配置。
现在，AI Agent 再次上演了这一模式。工程师不再编写代码，而是设计环境、构建反馈回路、将架构约束编写成规则。由 AI 来编写代码，由反馈回路来纠正偏差。
三次革新，同一种模式。 1948 年诺伯特·维纳就为它命名：控制论——你不再亲手拧阀门，而是开始掌舵。
因此，Harness Engineering 真正的深度在于：它并非一项全新的发明，而是控制论在 AI 编程时代的又一次具体实践。
实践效果如何？LangChain 的硬核验证
如果上述内容听起来偏理论，那么 LangChain 提供了一个 定量实验 作为验证：
使用同一个模型（gpt-5.2-codex），完全不更换模型，仅优化 Harness：
| 配置 |
Terminal Bench 2.0 得分 |
排名 |
| 基础 Harness |
52.8% |
30 名开外 |
| 全程最高强度推理 |
53.9% |
- |
| 优化后的 Harness |
66.5% |
前 5 名 |
模型完全没变。从 30 名开外一跃进入前 5，纯粹依靠 Harness 优化。性能提升了 13.7%。
他们做了几项关键改动：
- 强制“先验证再提交”：Agent 写完代码不能直接说“我完成了”，必须先运行测试。未通过验证则不允许退出任务。
- 死循环检测：Agent 反复修改同一个文件超过 N 次后，自动提醒“你是否应该换个思路了？”
- 推理“三明治”策略：在任务规划和结果验证阶段使用最强的推理能力，中间的执行阶段则降低强度——并非推理越多越好，而是要将算力用在刀刃上。
LangChain 有一个非常到位的定义：
Harness Engineering 是对模型智能的“塑形”——模型的能力参差不齐，Harness 的工作就是将这些能力塑造成适合具体任务的形状。
程序员角色的未来演变
最后，聊几句真正重要的事。
有一句话总结得非常到位：
生成代码的能力不再稀缺，判断代码好坏的能力才是核心竞争力。
这就像计算机科学中的 P 与 NP 问题——验证一个答案的正确性，通常比生成一个正确答案要容易。未来的工程师不需要在“编写代码”这件事上超越 AI，而是要在定义 “什么是对的” 这件事上超越它。
不得不承认，Harness Engineering 所要求的那些东西——良好的文档、自动化测试、编码化的架构决策、快速的反馈回路——过去三十年的软件工程书籍一直在推荐。大多数人跳过了这些实践，因为忽视它们的代价是缓慢显现的：代码质量逐渐下滑、新人上手变得困难、技术债务悄然累积。
但现在如果不做这些，AI 将以机器的速度、7x24小时不间断地生产出垃圾代码。
最佳实践本身并未改变。但忽视它们所付出的代价，已经变得无法承受。
那些设计了瓦特调速器的工匠，再也没有回去亲手拧阀门。不是因为他们做不到了，而是因为那样做已经失去了意义。
对这类前沿工程实践感兴趣的开发者，可以到 云栈社区 的开发者广场板块，与其他同行交流探讨最新的技术趋势与落地经验。
发表于 5 天前
|
查看: 24|
回复: 0
