Harness Engineering深度解析：AI领域热门工程平台

过去一个月，信息流中频繁出现各种跨领域信号，全部指向同一个主题。

OpenAI 发布了一篇长文，详细介绍如何借助 Agent 完成了 100 万行代码的编写。清华大学发表了相关消融实验论文。Martin Fowler 的网站随后推出了深度分析。LangChain 公布了令人震惊的测试数据。独立开发者在 GitHub 上展开了递归自进化实验。

推特上的争论愈演愈烈。

短短两个月内，一个博客中的个人观点演变成了涵盖学术论文、工业实践和社区争议的行业级概念。

这个概念名为 Harness Engineering。

Harness Engineering 究竟在讲什么

Harness 直译为“挽具”，即套在马身上的缰绳、马鞍和方向盘。无论马力多大，没有这套装置，马匹只能在原野上漫无目的地奔跑。

将这一概念映射到 AI 领域，Harness 就是为 AI 搭建的完整工作环境：定义规则的文件（明确什么能做、什么不能做）、自动校验脚本（检查是否出错）、上下文管理机制（帮助记住关键信息），以及问题出现时可回滚的安全措施。

一句话概括：模型是动力来源，Harness 是方向盘加刹车系统。

一个 Harness 通常包含以下组件：

• 约束：Agent 的执行边界（架构范围、依赖规则、权限控制）
• 上下文：Agent 完成任务所需的信息（文档、代码结构、项目规范）
• 验证：任务完成后如何确认结果正确（测试、linter、截图对比、评分脚本）
• 修复：出错时如何纠正，并防止同一错误再次出现（规则沉淀、自动修复）
• 生命周期：Agent 的启动、交接及人机协作流程（审批流、子 Agent 分发、定时任务）

用一个类比讲明白

假设你招了一位新员工，聪明、学习能力强，但存在三个问题：记性差（每次开会都忘记上次的内容）、自作主张（未经允许会尝试各种操作）、自尊心强（做错了也只会说“我觉得还行”）。你该如何管理他？不是反复叮嘱“要仔细”——那是 Prompt Engineering，相当于每次开会多强调几句。也不是只提供更多参考资料——那是 Context Engineering，相当于配个文件柜。你真正需要的是为他搭建一整套工作环境：明确的操作手册（什么能做、什么不能做）、自动化的检查流程（任务完成后系统自动验证）、错误记录簿（每次犯错自动记录并下次提醒），以及交接制度（下班后，接班的人知道从哪里继续）。

这套体系就是 Harness。

如果你用过 Claude，在设置中写下的偏好、反复告知它的规则，其实就是最简陋的 Harness。若你使用 Claude Code，项目中的 CLAUDE.md 文件便是 Harness 的一部分。

核心差别在于：你是在有意识地设计这个系统，还是仅仅在凑合着用。

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

回顾时间线。2022 至 2024 年间，行业聚焦于 Prompt Engineering，核心是优化一次性输入，让 AI 输出更准确。

2025 年进入 Context Engineering 阶段，单纯优化提示词已不够，需要同时提供背景文档、历史对话和项目结构。核心转变成信息管理。据 Epsilla 博客引用数据，同一模型、同一提示词，仅改变运行时环境，编程基准测试成功率从 42% 提升至 78%。

2026 年，Harness Engineering 正式登场。不再只优化输入，而是全面优化 AI 工作的整体环境。核心是基础设施。

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

三代要解决的核心问题始终如一：如何让 AI 工作更可靠。

为何偏偏在这个时间引爆

两个关键原因。

第一，AI 模型间的能力差距正在收窄。 2025 年，大家还在比拼“谁的 AI 更聪明”。到 2026 年，顶级模型的能力已高度接近，模型本身变成了一种“大家差不多”的商品。胜负不再取决于选哪个 AI，而在于如何管理 AI。

第二，AI 从“演示”阶段迈入“实际工作”阶段。 2025 年，AI 编程还停留在“看，它能写出一段代码好厉害”的展示层面。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。

来源：互联网