本文来自微信公众号： 叶小钗 ，作者：叶小钗
引言：本文火车上写的，阅读约10分钟，非常简单，稍微有点乱...
AI领域最近又在整活，既MCP、Skills之后，又诞生一AI流行黑词：Harness！
那么这个Harness是什么呢？我认为他是在对其他所有模型（不包括Claude与Google）做嘲讽，大概意思是：傻了吧，让你们还傻乎乎的all in模型训练，哥我在AI工程应用的路上越走越远了！
为什么这么说呢？
因为很有可能其他模型在战略规划的路上都走错了，尤其是OpenAI和国内很多团队，当然，这里不包括Claude和Gemini。
OpenAI的路走错了
OpenAI这家公司，从基因上就有点天生是应用公司的敌人的感觉，因为他什么都想做，是既要又要还要的典范：
比如一边推Sora、GPT-5等基础模型，一边又做SearchGPT、Browser Agent、甚至传闻中的AI硬件也有涉猎。
这里不衍生，先聚焦到模型能力，模型现阶段体现出来的能力无非以下几块：
一、语义理解能力
核心是意图识别，语义泛化能力，国内的节点可以从DeepSeek开放出来的CoT开始。
这里的核心是：正确的输入、复杂的输入，模型真的能够理解并给予正确的反馈了，这很重要。
二、视觉相关能力
这个是视觉AIGC爆发的基础原因，无论是已经宣告死亡的Sora，还是国内一骑绝尘的SeeDance体系，或者是生图领域的王者Gemini。
每次视觉领域稍有突破总能引起突破，但这里说的很清楚，牛逼的是模型本身的突破（其实相对于文字的能力，视觉是滞后的），跟工程侧没有关系。
三、Agent相关优化
之前我们在做OpenClaw相关讨论的时候就说过，近一年，Agent的进化速度尤其迅速，甚至可以说每次模型的迭代，都是为了Agent的某一能力而展开：
最核心的体现是上下文窗口变得极大了、Tools调用的稳定性变得比之前稳定很多。
可以说25年上半年做Agent和下半年做Agent工程难度差距极大。
四、多模态相关
然后就是多模态相关，有语音识别模块的升级、也有基于OCR等技术的巨大进步，但这些可能与模型本身无关，可以直接集成就好。
可能还有其他能力，包括浏览器操作、电脑操作等，我们这里就略过了...
问题在哪
以OpenAI为首的大型模型产商，既想追求模型能力各种领先（至少热衷于打榜）、又想追求模型在商业上的成功，其中尤以OpenAI为甚，他总想吃掉所有应用，这很傲慢！
但大家最后发现，现阶段貌似唯一被普遍接受，或者在稳定消耗Token的应用就几类：
模型聊天窗口，典型代表：ChatGPT、DeepSeek、豆包；
AI客服；
各种视觉类AIGC；
然后就是AI Coding了，这里代表很多，初期是Cursor、现在是Claude Code；
除了上面四个领域，大家其实是找不出来大体量行业级、并且真的影响一个行业的AI应用的，毕竟从前端已死到研发要死这阵风来得很猛。
而其中真的称得上行业级应用整合的只有AI Coding领域，这说明什么问题，由于其他模型厂商走错路有什么关系呢？
这里需要从AI应用三要素工程、KnowHow、数据说起。结论也很清晰：
除了Coding领域他们特别熟悉，并且程序员又喜欢作死在GitHub上贡献了大量优质语料外，其他行业做出成熟AI应用的基础条件并不成熟
PS：下个最可能出现的领域是医疗AI，原因无他，也依旧是医疗板块的语料优秀（其实百川智能如果早期就只做医疗板块，会好很多）
于是，Anthropic敏锐的抓住了这一点，为自己下了一个偏科生的战略，他们所有的模型能力和工程应用全部围绕Coding做展开，这造成的结果是：
Anthropic的产品Claude Code，可能是全球唯一一家将重心放在工程应用的方向，并且又有自己模型的公司；
也就是他们在真正的做项目，所以遭遇了很多工程上的困局，所以不得不提出很多工程解法，其中就包括MCP、Skills和如今的Harness
总而言之：应用侧不停的数据飞轮，让Claude在编程侧更强了，在这个大背景下，我们再来聊Harness就更有价值了。
Harness是什么
因为后续我们有Harness工程偏实现角度的介绍，所以今天的介绍会偏科普一点，关于Harness最简单的理解是：
模型=大脑；
Harness=身体+工作台+操作规程+监督机制；
而新的公式也就出来了：Agent=LLM+Harness，也不好说正不正确，因为里面真正应该独立的只有LLM，其他无论是Agent还是Harness都是工程化实现本身。
然后，Agent这东西也很特殊，似乎什么都能装，Harness也是围绕Agent实践的一种范式尝试罢了。
所以，现阶段Harness还非常不足以与LLM与Agent坐一桌，毕竟也不知道他半年后还在不在；
现在被迫为Harness“抬轿子”的是Prompt Engineering与Context Engineering。要特别说一点，提示词工程一定是AI应用核心中的核心，只不过似乎最近他与Context Engineering，被一起包裹进了Harness了：
我这边最早熟悉这个词，是关注Anthropic讲agent评估时，他把“评估框架”定义为一套跑任务、提供工具、记录步骤、评分和汇总结果的基础设施；
随后，他又将这套工程化策略（不知道怎么表述更合理）上升到Agentic Coding表现的关键变量。随后OpenAI也开始跟进，把Harness Engineering作为Codex在agent-first世界中的方法论，强调工程师的工作重点已经转向环境设计、反馈回路和控制系统，而不只是写代码。
至此Harness这东西一下子就活了，虽然多数人都不知道他是干嘛的...
怎么说呢？我认为Harness是一套工程化产物，是我们在实现Agent过程中要解决的一个个问题最终形成的工程化策略
比如OpenClaw的那一套架构叫做Agent RunTime，Harness有点那个意思，但又貌似没有那么大的控制力（可能最终会外延），所以非要工程化的描述可以是：
Harness，不是单个组件，而是把模型能力变成持续、稳定、可验证产品能力的那套系统。
Harness的演进历史
前面说了Harness是什么，这里还得更落地的描述他到底干什么，因为他包裹了提示词工程与上下文工程，所以所有的活都得干，可以分为三层：
第一层：Prompt Engineering
依旧是最本质的部分，行业KnowHow的具体体现，自然语言编程的实践：提示词工程！
之前大家关心怎么写一句更好的指令，让模型给出更好的输出。
于是提出了few-shot、role prompt、chain-of-thought、格式约束等策略。
但紧接着，因为要完成的工作变多了，简单的提示词技巧就不够用了，于是上下文工程就出现了。
第二层：Context Engineering
随着对话的场景变多，提示词工程开始力不从心，于是Context Engineering开始解决外延问题，比如：
哪些私有知识要带进来
哪些历史聊天要保留
超出上下文如何压缩；
怎么做检索；
严格来说，上下文工程可以很好解决问答的问题，只不过Agent要完成的工作再一次外延了：
第三层：Harness Engineering
从Agent不满足于只是问答，场景就变得更加不可控制了，上下文工程也就做到头了，为了应付任务链路越来越长的问题，Harness开始登场：
他甚至需要关注团队协作方式，比如做一个完整feature到底应该如何组织文档；
也包括其他功能，如自动拆任务、跑测试、真正的看页面、几小时持续执行、最后到多Agent协作；
因为用户的意图无限乃至描述模糊难以被结构化，常规的工程策略错漏摆出，比如：
一个任务如何持续推进而不半路失忆；
模型如何知道自己到底做对了没有；
...
在修这些BUG，或者说解决稳定性问题的过程中不断的提出了这套工程方法论。
以上就是Harness诞生的整个过程，可以看出，这是我们由L2迈向L3的必经过程：
工程拆解Harness
现阶段关于Harness的讨论很多，但其真实的实践却很少，其中LangChain、OpenClaw都可以称作Harness。
这很容易理解，LangChain本身就是Agent框架，他理所当然应该解决那些工程实践问题并形成方法论；而OpenClaw是短时间爆火的Agent代表，其框架也是开源的，也可以作为解读材料，我们这里选择OpenClaw。
但也要注意，如果往最原子处收，也并不是OpenClaw的所有组件都应该马上纳入框架，比如团队入口协议层就可以再考虑，我认为Harness应该围绕Agent做展开：
只要Agent真开始运行，系统还需要补哪些东西，才能让模型把事持续、稳定、可验证地做完
第一块，角色与规则
一个模型接到任务后，第一件事不是调工具，也不是查知识，而是先做意图识别，先知道自己现在到底是谁，具体来说：
它是负责规划，还是负责执行，还是负责验收。
它能做到什么程度，边界在哪里，碰到不确定情况该怎么办。
这些东西如果不先定下来，后面所有动作都没有控制性。
所以Harness最先控制的的不是功能，而是身份。也就是先把模型规划成一个能工作的角色，从这里的目标就不是随便聊两句。
你可以把这一层理解成公司的机制流程，流程本身不干活，但它决定了后面所有人怎么干活。
第二块，记忆系统
任务一旦变长，就一定会产生很多中间结果。比如已经拆出来的任务、讨论过的方案、当前做到哪一步。
这些东西如果全靠上下文窗口，先不说会不会撑爆，长了模型肯定会失焦。
Harness需要把这些中间结果从模型上下文里拿出来，让它们变成可以反复读、反复接、反复续的工件。
这也是为什么现在很多Agent系统都非常看重记忆模块。他们形式可以不同，但本质都一样：让任务过程留下痕迹，而不是一切都悬在上下文里。
第三块，上下文加载机制
很多人现在已经接受上下文工程这个说法了，但到了Harness这里一样也是核心，因为一旦任务复杂起来，模型前面能看的东西会越来越多：
规则、角色、历史、记忆、工具返回结果、中间工件、当前任务、最新输入...
这里的问题就很具体了，不在于信息不够，而在于信息太多。到底什么该进来，什么只给摘要，什么按需去查，什么干脆别放，这些都要有人管。
说实话，这块非常难，尤其是行业级应用，以医疗AI为例，这次到底该加载什么，准不准确，多了还是少了，这些都很重要
所以Harness很重要的一层，就是专门负责给模型加载知识。不是所有东西都上模型，而是每一轮只给它当前最需要的那部分。
这里又有几个核心：单次东西够不够，多了还是少了，多了产生了什么问题，少了又怎么样，有没有数据飞轮系统，这些都很重要，可以说这个模块是最重要的
这一层如果做不好，系统就会出现两种典型症状：
一种是看得太少，像失忆；
一种是看得太多，开始变蠢；
第四块，稳定执行
在知识没问题后，模型就能想明白，然后就是手脚问题了。
所以Harness一定会关注如何让语言真正变成具体动作，并且也关注每次动作完成得怎么样。
有时候是调工具，有时候是跑代码，有时候是搜资料，有时候是读写文件，有时候是去看页面、查日志、打接口。形式很多，但本质上都是同一件事：
把模型的判断，变成真实世界里的执行。
这一层特别容易被讲成工具清单，但其实工具本身不是重点，意图识别准确性、任务拆解准确性才是。
也就是重点是系统有没有办法把这些能力稳定地接起来，让模型真的能动手，而不是只会给建议。
没有这一层，模型更像顾问，有了这一层，它才开始像员工。事实上现阶段很多模型优化，也是围绕着这块做展开，也就是前面我们说的围绕Agent做展开。
第五块，有效循环
普通聊天的逻辑很简单，就是你说一句，它答一句。
但Agent不是这样。就像我们前面文章说的，Agent的本质并不是只能，而是一套Token换架构、时间+成本换取泛化Workflow的能力，所以Agent真正的工作方式，一定是一个循环：
先理解任务
再决定下一步
然后执行
执行完再读结果
再判断下一步
一直循环到收口为止
这件事说起来很简单，但一旦真的跑长任务，你就会发现问题很多。
它可能跑着跑着就提前收尾了。
也可能做了一半就绕回原地。
还可能不断重复同一个动作，消耗很多成本，却没有实质推进；
这段时间，最常见的问题是模型能解决的用不了太多循环，模型不能解决的，循环在多次都没用...
所以Harness里面一定会有一层，是专门负责推进节奏的。它不一定非得长成很复杂的编排器，但一定得有办法保证任务在往前走，而不是在原地打转。
第六块，反馈+校验
所有与自进化有关的模块一定都是核心，所以这个部分我觉得特别关键。
因为模型最大的问题之一，不是不会做，而是经常觉得自己已经做完了。
表面上看，代码写出来了，页面也渲染了，回复也发出去了，好像事情已经闭环了。但只要一验，就会发现很多地方根本没通。
所以Harness需要让系统能把结果反向喂回来。告诉模型这次到底做对了没有，差在哪，需不需要继续改。
这一层在有些系统里表现成测试，在有些系统里表现成浏览器验收，在有些系统里表现成日志和指标回流。形式不一样，但目标是一致的：
不要让模型稀里糊涂自己给自己打高分
如果没有这层，Agent很容易变成一种会自信交付半成品的系统。
只不过这一层说起来简单，实际非常难，比如很多模型公司都有个专门团队在做BenchMark，如果你打听过他们的工作，就知道这一切有多么的难了，并且这个工作并不是独立的，他跟很多模块都相关。
第七块，中断修复
最后还有一层，平时最不性感，但真正跑起来以后特别重要。
那就是做过的事情怎么留下来，任务断了以后怎么接回来。
因为真实任务不是永远一气呵成的。会中断，会超时，会压缩，会切session，会失败后重试，也会隔一天再继续。
如果系统没有恢复能力，之前做得再好，断一次就前功尽弃。如果系统没有记忆沉淀能力，踩过的坑还是会反复踩。
所以Harness最后一定会长出这一层：把值得留下的东西沉下来，把中断过的东西接起来。
这样一来，系统才不只是当下聪明，而是能持续工作。
要注意，所有这些模块都是我根据OpenClaw推测的，他是围绕能让一个Agent真正工作做展开的。
结语
标题这里有点偏（标题党有点骚），大家一笑而过就好，总结一句：
Harness是一套工程架构，他的目标是让模型能以一个稳定角色工作、让任务过程有痕迹、让上下文不失控、让能力真正能执行、让任务持续推进、让结果可被校验、让中断之后还能恢复
他不是什么神秘新概念，而是Agent真开始干活后，被工程现实逼出来的一套方法。
当任务变长、环节变多、结果需要验证时，大家迟早都会发现：只靠模型本身并不够，真正决定系统能不能落地的，是整套工程能力。
它以后未必还叫Harness，但这条路大概率不会消失。
最后给个建议：不建议系统性去学习，因为这个偏架构知识，一般人也学不明白...