最近在海外 AI 圈子里，有一个词被频繁提起，叫 Harness Engineering。
可能有人会觉得，硅谷又在造新词了。
但我的观察是，这两年 AI 发展过程中，一个词突然火起来，背后往往是某种行业共识正在形成。所以理解这个词代表什么，还是挺重要的。
今天聊聊我的看法。
#01
到底什么是 Harness Engineering？
这让我想起智能手机早期的故事。还记得吧，2012 年移动互联网刚爆发那会儿，智能手机发布会都在比硬件。每一场发布会都是参数大战。
但后来呢？硬件越过某个临界点之后，用户对这些参数已经无感了。因为够用了。
这两年苹果的 A 系列芯片越来越强，跑分越来越高，但对大多数人来说，完全无感。真正影响换机决策的，是整体的产品体验。
AI 正在经历同样的转变。过去两年，行业的注意力都在模型上。各家都在拼 benchmark 分数。
但从去年四季度开始，Benchmark 明显已经没那么重要了。因为大家觉得，更重要的是模型在实际场景中的表现。
什么是 Harness？
可以这样理解。模型是引擎，Harness 是围绕引擎造的那辆车。引擎马力再大，车本身不行，照样跑不动。
Harness Engineering 做的事情，说白了就是给 AI 搭工作环境、设计流程、建立规则、构建验证机制。
以前我们熟悉的是 Copilot 式的辅助系统。人提一句，AI 动一下，人再追一句，AI 再补一步，主导权一直在人手里。
但 Harness 指向的方向不一样，它说的是 always-on、long-running 的自治系统。AI 不只是等着接收命令，它有记忆层，有触发器，有定时任务，有完整的工具环境，能够持续推进任务。
就像前两天 Karpathy 在访谈里说的那样：当下最重要的是，把自己移出整个工作的 loop，别让人成为 AI 的瓶颈。
之所以 Harness Engineering 变得重要，是因为大家发现，很多时候模型执行任务失败，原因往往不是模型不够聪明。模型其实知道该怎么做。
但在执行过程中，它会迷失方向，会反复尝试已经失败的方法，会忘记自己到底要干什么。问题出在外部系统太乱了，模型每次启动都像失忆一样重来。
这就是 Harness 要解决的问题。
#02
一个具体的实例
最近在体验一个 AI Coding 的创业产品叫 ONES，很有意思。
大家看看下面的截图，我给它说了自己的需求之后，它就开始自己工作了。到目前为止，运行了 40 多分钟，它会自己跑测试，自己修正，最后给我交付一个成品。
和 ONES 的同学聊了下，他们告诉我内部一直强调的一个概念叫：AI² Execution System，AI 的平方，意思是 AI 驱动 AI。
我觉得，这个思路其实和 Harness Engineering 异曲同工。
传统的人机协作是线性的，输入指令，等输出，不满意就改 prompt 再来。AI² 要做的是把整个过程变成一个闭环系统。用户锚定目标，系统动态拆解任务，多个 AI 协作执行，完成后自动验证。
假设我需要做一个网站，展示咖啡馆的菜单，还要有预约功能。
传统路径是找设计师出设计稿，找前端写页面，找后端搭服务，自己盯着协调，最后部署上线。
或者用 AI 工具辅助，自己写 Prompt，生成代码片段，调试报错，反复修改，最后还得懂点技术才能把东西串起来。
他们希望 ONES 这套系统完全就是一个专业的软件团队。用户只需要说清下自己的需求，比如做一个展示咖啡馆菜单和预约功能的网站。
然后系统自己完成需求分析、UI 设计、前端开发、后端部署、上线验收。整个过程除了部分需求的澄清外，其他都不需要我再介入。
这背后就是 Harness 在起作用。任务怎么拆解，多个 Agent 怎么协作，执行状态怎么追踪，结果怎么验证，这些全都封装在系统内部了。
我体验下来，感觉这套产品的核心逻辑，其实是把过去几十年软件开发领域积累的最佳实践给还原了。
需求怎么梳理，任务怎么分配，验收怎么做，这些东西在专业的软件公司里是有一套成熟打法的。
如果在大一点的公司待过，或者了解那些专业外包公司怎么工作，就会知道这套流程是行业里沉淀下来的经验。
具体怎么做的，我说说体验过程中看到的。
首先是需求沟通。AI 会一步一步问我想要什么。这个设计很关键，因为用户自己其实也说不清楚。
我只知道我想要一个能展示菜单、能预约的网站，但细节呢？配色要什么风格，按钮放哪里，预约流程怎么走，这些我根本没想过。
它通过不断地问，把我脑子里模糊的东西一点点具象化。
需求理清之后，Agent 们会开一个圆桌会议。参会的都是不同工种的 Agent，前端工程师、后端工程师、设计师，各个角色都有。
它们会一起讨论刚才收集到的用户需求，然后分配任务，谁负责什么，各自认领。
分配完之后，在看板里就能看到每个角色的工作进度，甚至能看到每一个 Agent 的具体产出。
更有意思的是验收环节。每轮验收完，系统会再开一次会。项目经理主持，验收结果，如果有 bug，通过 Git 的提交记录定位是谁的代码出了问题，然后那个 Agent 去修。
Agent 之间的通信，用的是 Google A2A 协议的拓展版本。
从需求沟通到分工协作到验收定责，这套流程全都固化在产品里了。
开会、分工、各自干活、验收、定责、修复。不是一个超级 Agent 包揽一切，而是多个专业角色各司其职，协同推进。
说实话，这是 ONES 让我眼前一亮的地方。产品还在内测，我没办法放链接，征得他们团队允许后，我把这些理念尽量写清楚。
把这些复杂性都封装好之后，用户体验会变成什么样？
这个问题 ONES 内部在践行 OpenAI 之前提过的思路：OneShot。一句话，一个完整结果。
我觉得这个理念应该抓住了一个很多人都有的痛点。我们用 AI 产品的时候，最消耗耐心的是什么？是反复调 prompt。
写一版，生成，不对，改，再生成，还是差点意思，再改。有时候改到第五六轮，已经忘了自己最开始想要什么了。
OneShot 想解决的就是这个问题。随着平台能力持续优化，逐步逼近一句话拿结果的体验。当然，目前来看，这个理念肯定还是有点激进，甚至疯狂。
但创业公司干的不就是疯狂的事嘛。
这里面有一个值得展开说的点。一句话能拿到结果，靠的不是某个模型特别强，而是背后有一套系统在运转。
用户说出目标，平台做意图识别，系统匹配合适的 AI 团队去执行，同时复用历史上类似任务的经验，最后生成结果。每完成一次任务，系统就多一份经验可以复用。
同样，这和我们刚聊的 Harness 又是一回事。AI 能不能稳定交付，关键在于系统设计，在于任务怎么拆、怎么验、怎么从过去的执行里学东西。
从生成内容到交付结果，听起来只差两个字，但这两件事的难度差了不止一个量级。
一个自然的问题：如果系统生成的东西跟我想的不太一样，怎么办？
ONES 有一个叫 Goal Editing 的交互方式。
在正式生成之前，系统会先给一个可视化的预览。用户看着预览，直接用自然语言说想改什么。
比如，预约按钮放大一点。首页加个联系地址。配色换成暖色调。
系统理解目标，执行修改，再预览，直到满意为止。
这个交互方式的好处是门槛很低。用户不需要懂设计，不需要会写代码，看到什么说什么就行。改的是目标，不是内容本身。系统负责把目标翻译成执行动作。
#03
写在最后
这张图里有验收报告，有浏览器渲染验证，还能看到多轮验收的过程。
为什么我觉得这个值得单独拿出来说？
因为这回应了我们开头聊的一个问题。很多 Agent 失败，不是因为不会写代码，而是因为不会验收代码。
模型写完一段代码，跑个 unit test 通过了，就觉得搞定了。但实际上很多问题根本不是代码局部能看出来的，得把整个流程跑一遍才知道行不行。
ONES 的做法是给模型接入了 Chrome DevTools、Playwright 这类工具。
模型可以自己打开页面，复现 bug，看 DOM 结构，截图对比，验证修复前后的差异。
这里面真正重要的不是多了几个工具，是反馈回路变短了，模型能直接看到结果。看到不对，就继续改，再验证，再改。这就是截图里那个多轮验收的意思。
回到 Harness Engineering 这个话题。其实验证机制就是 Harness 里非常核心的一环。
模型能力够强了，但如果没有办法检验自己的输出，它就只能盲人摸象。给它一双眼睛，让它能看到自己做的事情对不对，整个系统的可靠性就上来了。
这两天，和我们 AI Maker Summit 大会的一个投资人嘉宾聊天，也提到了 Harness Engineering 的话题。
他的判断是，去某个垂直行业里，真正吃透一整条工作流，然后围绕这条工作流做出一个完全自治的系统，这样的产品在 AI 时代会有比较大的机会。