当OpenAI还在"既要又要"地追逐所有应用，Anthropic用"Harness工程"走出另一条路——模型是大脑，Harness是身体+工作台+监督机制，让Agent从"问答"进化到"真正把事情做完"。从Prompt到Context再到Harness，AI应用正经历从L2推理者到L3智能体的跃迁，而Anthropic通过专注Coding这一"偏科生"战略，率先跑通了模型与应用深度整合的闭环。
AI 领域最近又在整活，既 MCP、Skills 之后，又诞生一 AI 流行黑词：Harness！
那么这个 Harness 是什么呢？我认为他是在对其他所有模型（不包括 Claude 与 Google）做嘲讽，大概意思是：傻了吧，让你们还傻乎乎的 all in 模型训练，哥我在 AI 工程应用的路上越走越远了！
为什么这么说呢？
因为很有可能其他模型在战略规划的路上都走错了，尤其是 OpenAI 和国内很多团队，当然，这里不包括 Claude 和 Gemini。
OpenAI 这家公司，从基因上就有点天生是应用公司的敌人的感觉，因为他什么都想做，是既要又要还要的典范：
比如一边推 Sora、GPT-5 等基础模型，一边又做 SearchGPT、Browser Agent、甚至传闻中的 AI 硬件也有涉猎。
这里不衍生，先聚焦到模型能力，模型现阶段体现出来的能力无非以下几块：
核心是意图识别，语义泛化能力，国内的节点可以从 DeepSeek 开放出来的 CoT开始。
这里的核心是：正确的输入、复杂的输入，模型真的能够理解并给予正确的反馈了，这很重要。
这个是视觉 AIGC 爆发的基础原因，无论是已经宣告死亡的 Sora，还是国内一骑绝尘的 SeeDance 体系，或者是生图领域的王者 Gemini。
每次视觉领域稍有突破总能引起突破，但这里说的很清楚，牛逼的是模型本身的突破（其实相对于文字的能力，视觉是滞后的），跟工程侧没有关系。
之前我们在做 OpenClaw 相关讨论的时候就说过，近一年，Agent 的进化速度尤其迅速，甚至可以说每次模型的迭代，都是为了 Agent 的某一能力而展开：
最核心的体现是上下文窗口变得极大了、Tools 调用的稳定性变得比之前稳定很多。
可以说 25年 上半年做 Agent 和下半年做 Agent 工程难度差距极大。
然后就是多模态相关，有语音识别模块的升级、也有基于 OCR 等技术的巨大进步，但这些可能与模型本身无关，可以直接集成就好。
可能还有其他能力，包括浏览器操作、电脑操作等，我们这里就略过了…
以 OpenAI 为首的大型模型产商，既想追求模型能力各种领先（至少热衷于打榜）、又想追求模型在商业上的成功，其中尤以 OpenAI 为甚，他总想吃掉所有应用，这很傲慢！
但大家最后发现，现阶段貌似唯一被普遍接受，或者在稳定消耗 Token 的应用就几类：
除了上面四个领域，大家其实是找不出来大体量行业级、并且真的影响一个行业的 AI 应用的，毕竟 从 前端已死 到 研发要死 这阵风来得很猛。
而其中真的称得上 行业级应用整合的只有 AI Coding 领域，这说明什么问题，由于其他模型厂商走错路有什么关系呢？
这里需要从 AI 应用三要素工程、KnowHow、数据说起。结论也很清晰：
除了 Coding 领域他们特别熟悉，并且程序员又喜欢作死在 GitHub 上贡献了大量优质语料外，其他行业做出成熟 AI 应用的基础条件并不成熟
PS：下个最可能出现的领域是医疗 AI，原因无他，也依旧是医疗板块的语料优秀（其实百川智能如果早期就只做医疗板块，会好很多）
于是，Anthropic 敏锐的抓住了这一点，为自己下了一个偏科生的战略，他们所有的模型能力和工程应用全部围绕 Coding 做展开，这造成的结果是：
Anthropic 的产品 Claude Code，可能是全球唯一一家将重心放在工程应用的方向，并且又有自己模型的公司；
也就是他们在真正的做项目，所以遭遇了很多工程上的困局，所以不得不提出很多工程解法，其中就包括 MCP、Skills 和 如今的 Harness
总而言之：应用侧不停的数据飞轮，让 Claude 在编程侧更强了，在这个大背景下，我们再来聊 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 是什么，这里还得更落地的描述他到底干什么，因为他包裹了提示词工程与上下文工程，所以所有的活都得干，可以分为三层：
依旧是最本质的部分，行业 KnowHow 的具体体现，自然语言编程的实践：提示词工程！
之前大家关心怎么写一句更好的指令，让模型给出更好的输出。
于是提出了 few-shot、role prompt、chain-of-thought、格式约束等策略。
但紧接着，因为要完成的工作变多了，简单的提示词技巧就不够用了，于是上下文工程就出现了。
随着对话的场景变多，提示词工程开始力不从心，于是 Context Engineering 开始解决外延问题，比如：哪些私有知识要带进来哪些历史聊天要保留超出上下文如何压缩；怎么做检索；
严格来说，上下文工程可以很好解决问答的问题，只不过 Agent 要完成的工作再一次外延了：
从 Agent 不满足于只是问答，场景就变得更加不可控制了，上下文工程也就做到头了，为了应付任务链路越来越长的问题，Harness 开始登场：他甚至需要关注团队协作方式，比如做一个完整 feature 到底应该如何组织文档；也包括其他功能，如自动拆任务、跑测试、真正的看页面、几小时持续执行、最后到多 Agent 协作；
因为用户的意图无限乃至描述模糊难以被结构化，常规的工程策略错漏摆出，比如：
…
在修这些 BUG，或者说解决稳定性问题的过程中不断的提出了这套工程方法论。
以上就是 Harness 诞生的整个过程，可以看出，这是我们由 L2 迈向 L3 的必经过程：
现阶段关于 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，但这条路大概率不会消失。
最后给个建议：不建议系统性去学习，因为这个偏架构知识，一般人也学不明白…
本文由人人都是产品经理作者【叶小钗】，微信公众号：【叶小钗】，原创/授权 发布于人人都是产品经理，未经许可，禁止转载。
题图来自Unsplash，基于 CC0 协议。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。