Harness Engineering：别再逼 AI 背锅了，先给它装个方向盘

这两个月，AI 圈里冒出一个新词：Harness Engineering。

名字听着像给赛马配装备，意思也差不多。马力再大，没有缰绳、马鞍和刹车，最后多半不是冲线，而是冲沟里。放到今天的 AI 身上，模型是马力，Harness 是方向盘、导航、刹车、后视镜，外加一位脾气不太好的质检主管。

说白了，Harness Engineering 讨论的不是“怎么把 AI 夸聪明”，而是“怎么把它管明白”。

这个词之所以突然火起来，一条很清晰的时间线摆在那儿：2 月 5 日，Mitchell Hashimoto 在自己的文章里把这种做法明确称为 “harness engineering”；2 月 11 日，OpenAI 发文把这个概念带进主流讨论；2 月 17 日，Thoughtworks 的 Birgitta Böckeler 又补上了更冷静的分析。一个词从个人经验，迅速升级成工程圈公共话题，也就用了十来天。

它到底是什么？

很多人一听这词，第一反应是：不就是提示词升级版吗？

还真不是。

提示词工程，像是你对实习生说：“认真点，别写错。”
上下文工程，像是你把公司文档、项目说明、历史记录一股脑塞给他。
Harness Engineering 则是：你不再靠嘴叮嘱，而是给他配完整的工作制度。

什么制度？

有边界。哪些能做，哪些不能碰。
有上下文。该看什么资料，不该翻什么垃圾堆。
有验证。写完以后必须过测试、过检查、过规则。
有修复。错一次，就补一个机制，别让同样的坑连摔三回。
有交接。一个会话干不完，下一个会话接着干，不至于昨天是架构师，今天失忆症。

所以它本质上不是“教 AI 怎么回答”，而是“设计 AI 怎么干活”。

为什么偏偏现在火了？

因为大家终于发现，AI 真正的短板，不全在脑子，很多时候在工位。

前几年，行业热衷于比模型谁更聪明。现在模型能力越来越接近，光拼脑容量，边际收益没那么夸张了。于是工程现场开始出现一个扎心事实：同一个模型，换一套工作环境，表现能差出两条街。

LangChain 就做过很直白的实验：他们没有换模型，只改了 harness，Terminal Bench 2.0 上的成绩就从 52.8 提升到 66.5，排名从 Top 30 外冲到 Top 5。

这说明什么？

说明很多时候，问题不是 AI 不会干，而是你让它在一个灯坏了、门没锁、文档乱飞、验收全靠自觉的办公室里干活。谁进去都得发疯。

OpenAI 那篇文章，真正震撼的不是 100 万行代码

OpenAI 那篇文章最吸睛的标题，是“5 个月、0 行手写代码、做出一个 100 万行代码的产品”。更刺激的是，他们估算这套方式大约只用了手写代码十分之一的时间。

但比数字更有价值的，是它透露出一个更现实的变化：

工程师的主要工作，正在从“亲手写代码”，转向“设计环境、表达意图、搭反馈回路”。 OpenAI 自己在文中就直说了，人类负责 steering，agent 负责 execute。

翻译成人话就是：

以前工程师像厨师，自己切菜自己下锅。
现在工程师越来越像后厨总管：定菜单、订标准、盯出菜、骂跑偏的人——哦不，跑偏的 agent。

这不是“程序员没用了”，而是“程序员开始从手工型，转向系统型”。

Mitchell Hashimoto 这套说法，为什么让人信服？

因为他讲得特别土，也特别真。

他的核心思路一点都不玄：每次 agent 犯一个错，就花点时间设计一个机制，让它以后别再犯。 这机制可以是更好的 AGENTS.md，也可以是脚本、截图工具、过滤测试、自动检查。

这套逻辑最妙的地方在于，它不是把 AI 当天才，而是把 AI 当一个：

手速惊人、执行力爆表、但偶尔会把厨房抹布当产品方案提交的实习生。

你管理这种人，靠鸡汤没用，靠制度才有用。

但先别急着封神，它也不是万能药

如果故事讲到这里就结束，那就太像成功学短视频了。

问题是，反方的证据也不弱。

ETH Zurich 的论文研究了 repository-level context files，也就是很多人爱写的 AGENTS.md 这类仓库说明文件。结论相当扎心：这些文件往往会降低任务成功率，同时把推理成本抬高 20% 以上。论文作者的建议很克制——人写的规则最好只保留“模型自己推不出来的必要信息”，别把 README、家规、人生感悟全塞进去。

换句话说，Harness 不是越厚越强，很多时候是越厚越糊。

你给 AI 喂 200 条“非常重要”的规则，效果大概相当于在公司门口贴满 200 张“注意安全”。最后谁也不知道到底该注意哪条。

Thoughtworks 的 Birgitta Böckeler 也提了一个很关键的提醒：OpenAI 展示的这些做法，确实有助于提升代码质量和可维护性，但它并不能自动证明产品做对了、行为符合真实需求。换句话说，厨房是更整洁了，刀工也漂亮了，但端上来的菜，未必就下饭。

这句提醒非常重要。因为很多团队现在最容易犯的错，就是把“代码看起来挺规矩”误以为“业务肯定没问题”。

这中间差着十个需求评审和二十个线上事故。

真正有意思的地方，是它把“严谨”搬家了

过去大家对 AI 编程有一种误会：以为自然语言来了，软件工程就能从此走向“差不多就行”。

现实刚好相反。

现在最值钱的，不再只是把一行代码写得多优雅，而是把整个系统约束得够清楚：边界怎么划，文档怎么组织，验证怎么设计，回滚怎么做，错误怎么沉淀。

这也是为什么 Anthropic 最近的实践会继续往多 agent 结构上走：规划的、生成的、评估的，职责拆开，各干各的，靠结构来提升质量，而不是指望一个 agent 既当运动员又当裁判。

所以 Harness Engineering 最像什么？

它最像传统软件工程、测试工程、DevOps、架构治理、知识管理，几家人坐下来开了个会，最后决定一起养 AI。

听着新，其实骨子里很老派。
不是新玄学。
是老工程学，换了件新冲锋衣。

我自己的判断：它是真的，但也只是阶段性真理

Harness Engineering 的价值，我认为是实打实的。

因为只要 agent 会跑偏、会遗忘、会自信满满地胡说八道，Harness 就有存在意义。它解决的不是“模型够不够强”，而是“模型在复杂任务里，怎么别越干越歪”。

但它也不是什么永恒圣杯。

模型变强以后，一部分今天很有用的 harness，明天可能就会显得笨重。新的能力上来，会吃掉旧的脚手架；新的复杂度出现，又会逼出新的脚手架。最近一篇来自清华团队的论文甚至就在尝试把 harness 外化成可迁移、可执行的自然语言工件，本身也说明这个领域还在快速变形。

所以更准确的说法不是：

“以后都靠 Harness 了。”

而是：

在接下来很长一段时间里，谁更会给 AI 搭工作环境，谁就更能把同样的模型用出不一样的产出。

最后一句大实话

如果你把 AI 当天降神兵，Harness Engineering 听起来像多此一举。

但如果你真的拿 AI 下过几次生产现场，你就会明白：它不缺热情，不缺速度，甚至也不太缺想象力。

它最缺的，是规矩。

而软件工程干到最后，往往也就剩这两个字最值钱：规矩。

以前规矩写给人看。
现在，规矩得先写给 agent 看。

这大概就是 Harness Engineering 最朴素的本质：
不是让 AI 更像人，而是别让它像脱缰的马。