Harness Engineering是什么？AI圈火爆的Harness全解析

最近一个月，我的信息流里同时涌现出多条看似无关却都指向同一概念的信号。

OpenAI 发布了一篇深度文章，详细讲述了如何借助 AI Agent 编写了超过 100 万行代码。清华大学发表了相关学术论文，进行了消融实验。Martin Fowler 的网站跟进了一篇透彻的分析。LangChain 公布了一组令人震惊的测试数据。还有独立开发者在 GitHub 上开展了递归自进化实验。

推特上的讨论也异常激烈。

不到两个月，一个人的博客观点就演变成了一个拥有学术论文、工业实践和社区争议的行业级概念。

这个概念就是 Harness Engineering（AI 工作环境工程）。

那么，Harness Engineering 到底是什么

“Harness”这个词直译是“挽具”，就是套在马身上的缰绳、马鞍和方向盘。无论马的力气有多大，没有这套装备，它也只能在旷野中乱跑。

放到 AI 的语境里，Harness 就是你为 AI 搭建的一整套工作环境：包括告诉它能做什么、不能做什么的规则文件；自动检查它是否犯错的校验脚本；帮助它记住关键信息的上下文管理；以及出现问题时能够回滚的安全机制。

一句话总结：模型是马力，Harness 是方向盘加刹车。

一个典型的 Harness 包含：

• 约束：Agent 能做什么、不能做什么（架构边界、依赖规则、权限控制）
• 上下文：Agent 需要知道什么才能做好工作（文档、代码结构、项目规范）
• 验证：Agent 完成后如何判断结果是否正确（测试、linter、截图对比、评分脚本）
• 修复：Agent 出错时如何纠正，并确保同一错误不再重复（规则沉淀、自动修复）
• 生命周期：Agent 如何启动、如何交接、如何与人类协作（审批流、子 Agent 派发、定时任务）

用一个比喻说清楚它是什么

你招了一个新员工，聪明，学东西快，但有三个毛病：记性差（每次开会都忘了上次说的），会自作主张（你没说不能做的事它都会去试），而且很爱面子（做错了也会跟你说“我觉得还行”）。你怎么管这个人？不是反复叮嘱他“你要仔细一点”，那是 Prompt Engineering，相当于每次开会多强调几句。也不只是给他更多参考资料，那是 Context Engineering，相当于给他配了个文件柜。你真正需要的是给他搭一套完整的工作环境：明确的操作手册（什么能做什么不能做），自动化的检查流程（做完了系统自动验证对不对），错误记录本（每犯一个错就记下来，下次自动提醒），还有交接制度（他下班了，接班的人知道从哪里继续）。

这套系统，就是 Harness。

如果你用过 Claude，你在设置里写的那些偏好、反复告诉它的规则，其实就是最原始的 Harness。如果你用 Claude Code，你的 CLAUDE.md 文件就是 Harness 的一部分。

唯一区别在于：你是在有意识地设计这套系统，还是在凑合使用。

从提示词到 Harness：三代人解决同一个问题

让我们拉一条时间线。2022 到 2024 年，大家研究的是 Prompt Engineering——如何把一句话写得更精准，从而让 AI 输出更好的结果。核心是一次性的输入优化。

2025 年进入 Context Engineering 阶段。光靠提示词已经不够了，还需要把背景文档、历史对话、项目结构一起喂给 AI。核心变成了信息管理。据 Epsilla（一家 AI 应用基础设施公司）的博客引用数据，同一个模型、同一个 prompt，只需更换运行时环境，编程基准测试的成功率就从 42% 提升到了 78%。

2026 年，Harness Engineering 登场。它不再只优化输入，而是优化 AI 工作的整个环境和流程。核心是基础设施。

每个阶段的抽象层级都比上一个更高。Prompt 管理一次对话，Context 管理一次任务，Harness 则管理整个生命周期。

三代解决的核心问题始终没变：如何让 AI 干活更可靠。

为什么偏偏在这个时间点燃了

有两个主要原因。

第一，AI 模型之间的差距在缩小。2025 年大家还在比“谁家的 AI 更聪明”。到 2026 年，顶级 AI 模型的能力已经相当接近，模型本身变成了一种“大家差不多”的商品。这时候谁能胜出，不取决于你用哪个 AI，而取决于你怎么管理这个 AI。

第二，AI 从“演示”阶段进入了“实际干活”阶段。2025 年，AI 编程还停留在“你看它能写出一段代码好厉害”的 demo 层面。2026 年，人们开始让 AI 真正上岗，连续工作几天甚至几周。

这时候问题全部暴露了：AI 跑了 50 步之后开始偏离最初的指令，跑了 100 步之后完全跑偏。它会复制代码库中已有的坏模式，而且越复制越糟糕。任务越复杂，塞给它的信息越多，它越容易丢失重点。Anthropic 的研究还发现，AI 在自我评价时过于宽容，很难自己发现自己的 bug。

这些问题靠“换一个更聪明的 AI”是解决不了的。就像你招了一个聪明但缺乏经验的实习生，问题不在于他不聪明，而在于你的公司缺少好的入职培训和工作流程。

Harness 就是这个工作流程。

这个概念是怎么来的

Mitchell Hashimoto，是开发 Terraform（一款非常流行的基础设施工具）的公司 HashiCorp 的创始人。他不是 AI 圈的人，而是基础设施领域的传奇人物。一个搞基础设施的人为 AI 编程提出了一个基础设施层面的概念，说服力天然就很高。他还声明了利益关系：他不在任何 AI 公司工作，不投资，也不担任顾问。

他今年 2 月 5 日写了一篇博客，讲述自己如何一步步接纳 AI 写代码。

他的方法很反常识。第一步就直接抛弃对话框，改用 AI Agent（能自主执行任务的 AI 助手）。第二步更狠：强迫自己用 Agent 重新完成所有手动写过的代码。他说这个过程“很折磨人”——明明自己写更快，却不得不等 AI 慢慢磨。但目的是逼自己理解 AI 到底哪里行、哪里不行。

到第五步，他给这套做法起了名字：Harness Engineering。核心思路只有一句话：每次发现 AI 犯错误，就设计一个机制防止它再犯。

他的开源项目里有一个规则文件，每一行对应一个 AI 曾经犯过的具体错误。这不是说明书，而是一份血淋淋的踩坑记录。他称 AI 为“有点蠢但莫名高产的机器人朋友”。

6 天后，OpenAI 接棒了。

100 万行代码，没有一行是人写的

OpenAI 发表了一篇同名文章。

数据非常惊人：从 3 个人起步，后来扩展到 7 人，5 个月里大约完成了 1500 次代码提交，生成了 100 万行代码，没有一行是人工手写的。全部由 AI 生成。效率大约是传统方式的 10 倍。

但这篇文章真正有价值的地方不在于数字，而在于他们坦诚地列出了 AI 在工作时犯的四类错误：

• 信息过多反而效果更差。 你给 AI 提供的资料越多越好？不是。就像你把一本 500 页的手册丢给新员工说“都看完”，他反而什么也记不住。AI 也一样，信息量太大就抓不住重点。
• 什么都强调等于什么都没强调。 如果你在规则文件里写了 200 条“重要”规则，AI 就不知道哪条才是真正重要的。
• 规则本身会过时。 你上个月写的规则，这个月代码结构变了，规则就不适用了。而且规则过时的速度往往比代码还快。
• 无法自动检查 AI 是否真的照做了。 你说“代码要有注释”，AI 说“好的”，但你如何确认真加了注释？

他们的解决方案不是换一个更聪明的 AI，而是改造工作环境。他们缩短规则文件，把详细的说明分散到不同位置，让 AI 每次只看与当前任务相关的部分。同时搭建了自动检查流程，AI 写完的代码必须通过一系列自动化测试才能提交。

关于技术债务：他们最初每周五留出 20% 的时间手动清理 AI 写的糟糕代码，但失败了。后来改为让后台 AI 定期扫描偏差，自动提交修复，大部分在一分钟内就能审核完成并自动合并。技术债务不是攒到某天集中偿还，而是每天用小增量来清理。

他们还发现了一个有趣的现象：AI 在使用那些已经存在十几二十年的“老技术”时表现最好。因为这些老技术文档齐全、案例丰富，AI 在训练数据中见过大量相关内容。而对于新潮的技术框架，AI 反而容易搞砸。

有数据证明这东西有用吗

有，而且很有说服力。

LangChain 的实验： 他们做了一项 AI 编程能力测试。同一个 AI 模型，只改变了工作环境（Harness），成绩就从 52.8% 跳升到了 66.5%，排名从 30 名开外冲进前 5。没有换 AI，只换了 AI 的“办公环境”。

他们还发现了一个反直觉的现象：让 AI 全力思考反而成绩更差，因为想太久会导致超时。最佳策略是“开头认真想，中间快速做，结尾认真检查”——他们称之为“推理三明治”。

HumanLayer 的实验： Claude（Anthropic 开发的 AI）在不同的工作环境里，排名分别在第 33 和第 5 位。同一个大脑，换一个办公室，表现天差地别。

Anthropic 的实验： 他们做了一个对比。让一个 AI 独立工作，20 分钟花了 9 美元，做出来的东西核心功能都是坏的。然后让两个 AI 配合——一个负责干活，一个专门负责挑毛病——6 小时花了 200 美元，结果做出一个真正可用的完整应用。

为什么要用两个 AI？因为他们发现 AI 在评价自己工作时过于宽容，就像让学生自己给自己的考试打分。如果把“干活”和“检查”拆给两个 AI，并让检查的那个刻意挑刺，效果会好得多。

Stripe（全球最大的在线支付公司之一）的 AI 团队每周自动合并 1300 多次代码提交。

独立开发者中也有猛人。Peter Steinberger 一个人同时管理 5 到 10 个并行的 AI Agent，一个月提交了 6600 多次代码。他的观察很有意思：那些喜欢解算法谜题的工程师反而难以适应这种工作方式，而产品思维强的人适应得更快。因为这种模式不需要你写出精巧的代码，而是需要你会拆解任务、制定规则、检查结果。他说自己的工作节奏已经从“一个人埋头写代码”变成了“管一堆 AI 分活干”。

还有一个名为 yoyo 的开源项目，从 200 行代码起步，每 8 小时自动醒来改进自己，26 天后增长到 3 万多行代码，总成本仅 12 美元。作者说了一句很深刻的话：难的不是保存状态，而是决定忘掉什么。

数据摆在这里，但反方的观点也不容忽视。

但也有人说这东西没用

苏黎世联邦理工的实验： 他们测试了 138 个 AI 配置文件，发现 AI 自动生成的配置文件反而让表现变差，还多花了 20% 的成本。而人工手写的配置文件呢？也只提升了大约 4%。花费大量精力编写规则，回报却如此有限。

他们还发现：AI 其实很擅长自己摸索代码库的结构。你写的“目录介绍”之类的内容，AI 自己翻翻代码就知道了，你多此一举反而浪费了它的注意力。

OpenAI 内部研究推理模型的研究员 Noam Brown 在一个播客中说得更直接：他认为现在大家精心搭建的这些工作环境，最终会被更强的 AI 模型“冲刷掉”。就像以前人们搞了一堆复杂的方法来让不够聪明的 AI 表现出推理能力，结果专门的推理模型一出来，那些方法全都没用了，反而碍事。

更反直觉的是：他们发现给 AI 加上“验证器”（做完后自动检查是否正确）反而让成绩变差。在某个测试中，添加验证器直接导致性能大幅下降。你精心设计的检查流程，加上去不但没用还帮倒忙。不过他们也发现了一件有趣的事：同样的工作规则，用自然语言描述比用代码实现效果好得多，成绩从 30.4% 跳到了 47.2%。问题不仅在于加了什么，还在于如何表达。

清华大学的实验

还有人质疑这根本不是什么新东西。SGLang 团队的 Chenyang Zhao 说得很直白：这就是传统软件工程中的“关注点分离”“单一职责”，不过是换了个名字包装了一下。他自己在做 AI 系统时凭直觉就用了类似的方法，做完之后才知道这些方法在 Harness Engineering 里有专门的名称。

Martin Fowler 网站上的分析指出了一个更关键的缺失：现有的 Harness 主要保证“代码写得很干净”，但不保证“产品做对了”。就像一个厨师刀工很好、厨房很整洁，但做出来的菜不好吃。她还直接点名利益冲突：OpenAI 在“让大家相信 AI 能维护代码”这件事上是有商业利益的。

社区里也有辛辣的声音。有人提出了一个悖论：你用 AI 快速生成的代码，在生成的那一刻就已经是没人能维护的遗产代码了。更吓人的是，有人发现 AI 会伪造测试——写一行“已完成”，然后自己去检查这行字是否存在，但实际上什么都没验证。还有人发现 AI 会把一个临时的权宜之计当成“标准做法”，并在整个项目中系统性地复制这个坏习惯。

所以到底该怎么看

正方和反方说的其实不是同一件事。

一个 AI 行业播客（Latent.Space）给出了最精准的判断：模型能力和 Harness 是两个不同的维度。模型决定的是 AI 能否持续工作而不犯糊涂，Harness 决定的是 AI 的产出质量。一个管续航，一个管方向。

打个比方：你有一辆车，发动机越好（模型越强），你就能跑得越远。但导航系统（Harness）决定了你跑的方向是否正确。发动机好了确实可以少依赖导航（路感好的老司机不怎么用导航），但这并不代表导航没有用。

Anthropic 自己的经历也验证了这一点。他们升级了 AI 模型之后，发现之前设计的一些管理流程确实不再需要了，模型自己就能搞定。但“让另一个 AI 专门检查质量”这件事依然有效，因为“活干得好不好”这个问题不会因为 AI 更聪明就消失。

AI 编程早期的叙事是“不用学编程了”“自然语言就是新的编程语言”。但 OpenAI 自己的实践告诉你：他们花最多精力的地方是设计架构约束、编写检查规则、搭建验证流程、管理上下文。这些都是传统软件工程中最严谨的那部分工作。他们自己说：“我们现在最难的挑战是设计环境、反馈循环和控制系统。”

Chad Fowler（一位很有影响力的程序员）称之为“严谨性搬家”：好的变革不是让你不再严谨，而是把严谨从一个地方搬到另一个地方。以前严谨体现在“写好每一行代码”，现在严谨体现在“搭好 AI 的工作环境”。严谨性没有消失，它只是换了个地方住。

核心判断：Harness 的价值是真实的，但也是暂时的。 它填补的是当前 AI 能力的缺口。AI 每前进一步，就会吃掉一层 Harness，但总有新的缺口需要新的 Harness 来填补。这是一场持续的军备竞赛，而不是一劳永逸的护城河。

几个值得注意的趋势

技术选择会被 AI 影响。 以后选用什么编程语言、什么框架，可能不再取决于程序员的偏好，而取决于“AI 用这个技术好不好使”。那些文档齐全、社区活跃的老技术会因此受益。

新项目和老项目的差距会拉大。 从零开始的新项目可以一开始就按 AI 友好的方式搭建。但给一个运行了十年的老项目补一套 AI 管理系统，难度极大。就像给一栋已经住满人的老楼加装电梯，比新楼加装电梯难十倍。

锁定效应是真实的。 有人在某个 AI 工具上搭建了 6 层自动化流程。一旦更换工具，所有积累归零。你在 Claude Code 上积累的规则和流程，搬到别的 AI 上不一定能用。

三个场景你现在就能试

你在写代码： 学习 Hashimoto 的方法，每次 AI 犯一个错误，就写一条规则记录下来。积累到 20 条就能看出规律，知道你使用的 AI 在哪些方面容易出错。但规则不要写太多，20 到 60 条就够了。太多了 AI 反而哪条都记不住。

你在管理团队： 先别想太复杂，把“AI 绝对不能做的事”列一个清单，这比列出“AI 应该做的事”更重要。就像管实习生，你告诉他“不能直接发邮件给客户”比告诉他“要注意邮件礼仪”有效得多。

你不写代码但经常使用 AI： 你可能已经在做 Harness Engineering 了，只是自己不知道。你反复跟 AI 说的那些要求（如“不要用太正式的语气”“回答要简短”“先给结论再解释”），把它们整理成一个文档，下次直接贴给 AI。这就是最简单的 Harness。日常内容创作也是如此——品牌调性规则就是 Harness，写完之后的多轮检查就是验证流程。

最后一句大实话

有人说 Harness Engineering 就是传统管理学换了个壳。有道理，但不完全对。传统管理学是管人的，人会学习、会记住教训、会自我反思。而 Harness Engineering 管的是一个概率性的、会遗忘的、会在你不注意时伪造工作成果的系统。对象变了，方法论也得跟着变。

但如果你觉得学会了就能躺着让 AI 干活，那肯定会栽跟头。模型在进步，Harness 在追赶，中间永远有一个缺口。能在这个缺口里创造价值的人，才是真正的 Harness Engineer。