当OpenAI还在"既要又要"地追逐所有应用，Anthropic用"Harness工程"走出另一条路——模型是大脑，Harness是身体 工作台 监督机制，让Agent从"问答"进化到"真正把事情做完"。从Prompt到Context再到Harness，AI应用正经历从L2推理者到L3智能体的跃迁，而Anthropic通过专注Coding这一"偏科生"战略，率先跑通了模型与应用深度整合的闭环。

最核心的体现是上下文窗口变得极大了、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 就更有价值了。

我这边最早熟悉这个词，是关注 Anthropic 讲 agent 评估时，他把“评估框架”定义为一套跑任务、提供工具、记录步骤、评分和汇总结果的基础设施；

随后，他又将这套工程化策略（不知道怎么表述更合理）上升到 Agentic Coding 表现的关键变量。随后 OpenAI 也开始跟进，把 Harness Engineering 作为 Codex 在 agent-first 世界中的方法论，强调工程师的工作重点已经转向环境设计、反馈回路和控制系统，而不只是写代码。

至此 Harness 这东西一下子就活了，虽然多数人都不知道他是干嘛的…

怎么说呢？我认为 Harness 是一套工程化产物，是我们在实现 Agent 过程中要解决的一个个问题最终形成的工程化策略

比如 OpenClaw 的那一套架构叫做 Agent RunTime，Harness 有点那个意思，但又貌似没有那么大的控制力（可能最终会外延），所以非要工程化的描述可以是：

Harness，不是单个组件，而是把模型能力变成持续、稳定、可验证产品能力的那套系统。

现阶段关于 Harness 的讨论很多，但其真实的实践却很少，其中 LangChain、OpenClaw 都可以称作 Harness。

这很容易理解，LangChain 本身就是 Agent 框架，他理所当然应该解决那些工程实践问题并形成方法论；而 OpenClaw 是短时间爆火的 Agent 代表，其框架也是开源的，也可以作为解读材料，我们这里选择 OpenClaw。

但也要注意，如果往最原子处收，也并不是 OpenClaw 的所有组件都应该马上纳入框架，比如团队入口协议层就可以再考虑，我认为 Harness 应该围绕 Agent 做展开：

只要 Agent 真开始运行，系统还需要补哪些东西，才能让模型把事持续、稳定、可验证地做完

任务一旦变长，就一定会产生很多中间结果。比如已经拆出来的任务、讨论过的方案、当前做到哪一步。

这些东西如果全靠上下文窗口，先不说会不会撑爆，长了模型肯定会失焦。

Harness 需要把这些中间结果从模型上下文里拿出来，让它们变成可以反复读、反复接、反复续的工件。

这也是为什么现在很多 Agent 系统都非常看重记忆模块。他们形式可以不同，但本质都一样：让任务过程留下痕迹，而不是一切都悬在上下文里。

很多人现在已经接受上下文工程这个说法了，但到了 Harness 这里一样也是核心，因为一旦任务复杂起来，模型前面能看的东西会越来越多：

规则、角色、历史、记忆、工具返回结果、中间工件、当前任务、最新输入…

这里的问题就很具体了，不在于信息不够，而在于信息太多。到底什么该进来，什么只给摘要，什么按需去查，什么干脆别放，这些都要有人管。

说实话，这块非常难，尤其是行业级应用，以医疗 AI 为例，这次到底该加载什么，准不准确，多了还是少了，这些都很重要

所以 Harness 很重要的一层，就是专门负责给模型加载知识。不是所有东西都上模型，而是每一轮只给它当前最需要的那部分。

这里又有几个核心：单次东西够不够，多了还是少了，多了产生了什么问题，少了又怎么样，有没有数据飞轮系统，这些都很重要，可以说这个模块是最重要的

这一层如果做不好，系统就会出现两种典型症状：一种是看得太少，像失忆；一种是看得太多，开始变蠢；

在知识没问题后，模型就能想明白，然后就是手脚问题了。

所以 Harness 一定会关注如何让语言真正变成具体动作，并且也关注每次动作完成得怎么样。

有时候是调工具，有时候是跑代码，有时候是搜资料，有时候是读写文件，有时候是去看页面、查日志、打接口。形式很多，但本质上都是同一件事：

把模型的判断，变成真实世界里的执行。

这一层特别容易被讲成工具清单，但其实工具本身不是重点，意图识别准确性、任务拆解准确性才是。

也就是重点是系统有没有办法把这些能力稳定地接起来，让模型真的能动手，而不是只会给建议。

没有这一层，模型更像顾问，有了这一层，它才开始像员工。事实上现阶段很多模型优化，也是围绕着这块做展开，也就是前面我们说的围绕 Agent 做展开。

最后还有一层，平时最不性感，但真正跑起来以后特别重要。

那就是做过的事情怎么留下来，任务断了以后怎么接回来。

因为真实任务不是永远一气呵成的。 会中断，会超时，会压缩，会切 session，会失败后重试，也会隔一天再继续。

如果系统没有恢复能力，之前做得再好，断一次就前功尽弃。 如果系统没有记忆沉淀能力，踩过的坑还是会反复踩。

所以 Harness 最后一定会长出这一层： 把值得留下的东西沉下来，把中断过的东西接起来。

这样一来，系统才不只是当下聪明，而是能持续工作。

要注意，所有这些模块都是我根据 OpenClaw 推测的，他是围绕能让一个 Agent 真正工作做展开的。

标题这里有点偏（标题党有点骚），大家一笑而过就好，总结一句：

Harness 是一套工程架构，他的目标是让模型能以一个稳定角色工作、让任务过程有痕迹、让上下文不失控、让能力真正能执行、让任务持续推进、让结果可被校验、让中断之后还能恢复

他不是什么神秘新概念，而是 Agent 真开始干活后，被工程现实逼出来的一套方法。

当任务变长、环节变多、结果需要验证时，大家迟早都会发现：只靠模型本身并不够，真正决定系统能不能落地的，是整套工程能力。

它以后未必还叫 Harness，但这条路大概率不会消失。

最后给个建议：不建议系统性去学习，因为这个偏架构知识，一般人也学不明白…

本文由人人都是产品经理作者【叶小钗】，微信公众号：【叶小钗】，原创/授权 发布于人人都是产品经理，未经许可，禁止转载。

题图来自Unsplash，基于 CC0 协议。