微信扫码
添加专属顾问
我要投稿
AI Agent的未来已来,Harness正成为决定成败的关键战略资产。核心内容: 1. 2026年大模型能力进入高原期后Harness的战略意义 2. DeepMind实验和Claude Code案例揭示Harness的关键作用 3. 从30年软件工程演进看Harness出现的必然性
Datawhale干货
分享:黄佳,新加坡科研机构AI研究员
在不改变原意的情况下,Datawhale 进行了如下微调和整理。
好的,大家好,我是黄佳。今天想跟大家深入聊聊 Agent Harness 这个话题。
我们现在在 2026 年这个时间节点,当模型的能力进入高原期——2024 年的时候,我会觉得我比较聪明,我会觉得 GPT 比较傻,跟它说话笨笨的,我都瞧不起它,但它知识很丰富。到了 2025 年的时候,我就会觉得我比较傻,模型的高度比较高。
我不需要模型再进步了,因为它已经达到了这个高度,已经超过我这种人类的智商水平一大块了。我就不需要模型再进一步进化,因为它再进化,我研究的又不是世界顶级的科研课题,我也感受不出来了。
我就希望这个模型能够真正帮我把事儿做好。也就是说,现在它智力在线、过关了、OK 了。以前 2025 年之前的模型智力还不在线,那还不行。现在是模型智力都 OK,无论是中国的还是外国的模型都可以。
我们现在比拼的是 Harness。
DeepMind 的 Agents 团队做的实验很有名:我用同一个模型,咱们先把模型固定住不动,只换 Harness、换模型的外围,性能就能够产生巨大的差异。因此说明这个 Harness,就是模型的外围工程,真的是很有必要的。
Claude Code 本身现在进步这么快,它的商业价值也如日中天,都是表明这个 Harness 是战略级别的资产。它做的东西就是 Harness。
现在我们肯定都在讲 Agent,Agent 很厉害,我们以为它什么都能做。实际上如果我们从另外一个视角切入的话,你会发现 Agent 是越来越强、越来越厉害,但会有一个问题凸显得越来越明显——你不一定能够真正掌控你所搭建的系统。
如果我们全部把所有的东西都让 Agent 来生成代码,那么一个完全不懂软件工程的人,岂不是跟我们能够设计出一样的系统吗?实际上这个前提是不成立的。因为当这个系统真正在产品级别上线的时候,你会发现什么东西都是飘在表面上,这个东西不是我们设计出来的,而是处于一个失控的状态。
这也就是为什么现在我们又都回到原点。当我们谈到 Harness 也是一样,我们现在讨论的是如何驾驭这个 Agent。如何真正驾驭 Agent,我感觉最后我们还是要回到一个非常基础的东西——我们每一个人对现在的 IT 系统的理解到底有多深。
这个东西是我们在 Agent 时代,每一个人能够往前走多远的一个分水岭。
我不想给大家讲解怎么用 OpenAI 去整点外快,这些东西是极为肤浅的。我们其实要打牢的是我们本质上对现代 IT 系统的理解。如果这一层没有打牢,我们做出的东西就是空中楼阁,就是失控的。
为什么我要从 30 年软件工程演进的角度来讲 Harness?因为 Harness 的出现不是偶然,而是历史的必然。
我们作为工程师来讲,一直都是在跟系统的复杂度做斗争。我们所做的所有努力,都是希望能够降低复杂系统的复杂度。技术架构演进二十几年不变的是什么?不变的就是如何驾驭复杂性。
如果给你两个字儿的话,就是抽象。有没有抽象能力?抽象能力加上结构化,把很乱的东西里边的本质抓出来,这个就是设计模式,也是抽象。微服务也是抽象,云计算也是抽象。
1994 年,GOF(Gang of Four,四人帮)写的《Design Patterns》是一个开山之作。那个时候软件工程师谈代码设计只能靠感觉走,那是一个很混乱的年代。
这四个人做了一件革命性的事情——他们借鉴了建筑史上的设计模式,在面向对象的基础上提出了 23 种设计模式:创建型、结构型、行为型。把软件设计里面的各个元素、可复用的组件拆解成为模式。
我们第一次有了设计词汇。设计词汇的重要意义在于程序员和程序员之间的沟通变得非常高效。
GOF 设计模式在驾驭什么?驾驭对象——一个类的生命周期、一个对象的职责、对象之间的协作。
差不多每过五六年或者十来年,软件设计的复杂性中心就一直在转移。原来很复杂的事情现在变得很简单,那什么东西变麻烦了?Enterprise(企业)变得很复杂,业务变得很复杂。
这个时候代表作就是马丁·福勒(Martin Fowler)写的《企业应用架构模式》。把企业系统分成表现层、服务层、领域层和数据层,每一层都有自己的设计模式。然后 Eric Evans 的《领域驱动设计》,让代码的结构反映业务的结构。
马丁·福勒在驾驭什么?驾驭架构——一个系统的分层、业务的边界、领域的模型,这是对企业业务的驾驭。
到了 2010 年之后,以互联网和移动互联网的爆炸式发展,所有的复杂性来自于系统的巨大流量。突然我们发现以前搭的所有架构,都被这个狂轰乱炸式的流量给毁掉了。
这个时候我们需要微服务在大量的多个系统之间去沟通。系统变得不再稳定,现在是成百上千个系统在运行,需要随时扩容、随时做所有系统的灾备。
这个时候的复杂性全部在数据的流动过程中——如何构建大规模的分布式系统。这个趋势整整延续了大概 15 到 20 年。
微服务时代在驾驭什么?驾驭分布式通信——几十个微服务之间怎么通信。消息系统、系统间消息的传递、入队、出队、怎么设优先级、失败了怎么办、怎么解决最终一致性问题。
Martin Kleppmann 写的《Designing Data-Intensive Applications》(DDIA)指出:软件的复杂性不在于业务逻辑,而在于数据系统。
怎么在大数据系统中进行消息传递、怎么把大数据拆分给多个机器、怎么做 MapReduce,这些东西变得更加复杂。数据系统成为了真正的复杂系统中心。
DDIA 在驾驭什么?驾驭数据分区复制、数据的共识,驾驭的是数据在时间和空间维度上的流动。
现在又过了七八年,有一个比数据还要更复杂的东西出现了——这个就是 Agent,自己会推理、会行动的系统。Agent 把本来就复杂的东西搞得更加复杂。
Agent 本身是一个概率机器,你输入一个东西期待它一个输出,但它并不一定按照你的要求走。所以怎么样去拆解它的输入输出、怎么样拆解这个结构,这都是我们新时代需要做的新事。
在 Agent 时代我们驾驭的就是一个智能体,这是我们第一次驾驭一个不确定性的系统。
而 Harness,就是我们驾驭 Agent 的缰绳。
我们 Agent 工程思维在过去两三年里经历了三次主要的跃迁,而 Harness Engineering 是最新的、也是最重要的阶段。
从 Prompt Engineering 开始,那个时候就很好玩。“你是一个很聪明的工程师”,还是“你是一个教小学生的教师”?我从来都没有跟大模型写过那样的东西,因为我觉得它知道它自己是谁。
但是当时有 CoT(Chain of Thought),“请你一步一步思考”,“Let‘s think step by step”,这是有用的。我们研究 Prompt Engineering,怎么让大模型去理解我们,然后给出我们所需要的回答。
到了 2024、2025 年,过去两年我们都在做 Context Engineering。这个很重要,现在也很重要。
你给大模型什么东西,就是你能够在大模型身上得到的东西。我给到它的东西要有深度,它给到我的东西才能够有深度。
我们做企业知识库、做 RAG 都是在做这个。做 RAG 也好、做 Agent 的 Context Engineering 也好,都是在调教模型的上下文。
到了 2026 年,只是做 Context Engineering,这个就比较窄了,目光高度就不够了。我们现在 Agent 能力这么强,我们需要不仅仅让它回答问题,还要让它自动采集、自动做审核、自动完成任务。
你需要设计循环的策略、工具、质量审核、分发治理,核心就是这两个字儿:可控。我们正在设计可控的系统。
所谓的 Harness 就是包裹模型运行的基础设施。很简单,就是:
Agent = Model + Harness
所有的外围工具全都是 Harness。
Harness 就是运行时和基础设施,大家可以把它简单理解为一个模型运行时、Agent 自助工具系统,然后上下文管理、权限控制、状态持久化,所有的东西都是 Harness 要解决的。
底层就是无状态的、纯推理的大模型。Harness 做的就是把大模型的大脑变成了 Agent 的身体。
现在首先大模型可以帮咱们编码,然后咱们有 Claude Code 泄露出来的种种源码、有 OpenAI 的一些开源项目,你就去照猫画虎,你很快就可以搭建出一套属于你自己的 Harness 系统。也不是什么难事儿,但是我们要知道它做些什么是很重要的。
Harness 有六大核心组件,也可以是七大,这个东西没有定论,也可以是五大,无所谓。拆分的目的就是让大家去学习比较容易理解:
接受一个输入,然后返回最终结果之前还有一个详细的循环过程,确保这个东西全部通过工具执行、反复运作,最后 OK 了,终于给用户的问题解决了,然后再返回最终结果。
这个复杂行为都从这个简单的循环中涌现出来,这个跟咱们最早的 ReAct 其实是一脉相承的。ReAct 不是说前端框架,这是一篇 Agent 的论文,Agent 的 ReAct 系统就是一个推理和行动的循环。
手脚,有工具调用能力。智能体能够通过调用各种工具和 API 来扩展大语言模型的行动范围,使其不仅限于语言生成和理解,还可以实际参与到现实生活中。
有记忆和上下文的管理。这个很重要,Claude Code 真的是 Context Engineering 做得特别强,因为这个提法概念就是他们最先提出来的。怎么做 Context 的压缩?Claude 在 Agent 工程这方面真的是领先别人好几条街。
你要 Allow、Deny、Ask。我们用 Claude Code 的时候会一直问我们要不要执行某个操作,人得给我控制这个权限,这很重要。缰绳的控制。
在你传代码到 GitHub 上面去的时候,有没有把 environment 文件也传上去?千万不要传,这些东西传了就出大事。
怎么控制这个运行时的机制。
这些东西跟着这个节奏,一个一个我们可以自己去研究别人的系统,可以自己去构建自己的 Harness 系统。
大家发现 Claude Code 出来之后,很多东西都可以落地了,我们真的可以解决很多问题。
Harness 解决了 Agent 五个落地卡点:
无限循环问题
上下文爆炸问题
权限失控问题
质量不可控问题
成本不透明问题
怎么解决的?因为人家给了一套很好的系统。
也就是说,现在如果你说“佳哥,我们公司做的这个 Agent 还不行,不够好,解决不了上下文爆炸的问题,或者说成本不透明”,那你就去参照 Claude Code 的源代码去调整修改,都能够解决。
做得不太好,还是我们业务理解没吃透,或者说 Harness 这个系统还没有足够到位,都可以解决。因为业界已经证明了,这就像出来了一个 Linux 系统,Linux 是开源的版本,全世界各个团队都在做各种各样的 Red Hat Linux、Ubuntu,都能够实现同样的操作系统级别的功能。
Harness 系统现在也技术上没有任何障碍。所以解决的还是我们设计模式理解的问题。
现在 Harness 的格局是百花齐放,但实际上有一条主线。
Claude Code 是最好的,我们公认这个是 Number One。说到 Harness,Claude Code 就是 Number One,绝对是碾压别人。
Claude Code 有几个设计哲学:
几个内置工具,原子操作搞定一切
少而精的工具设计,涌现出超强能力
上下文管理能力非常强
Claude 在 Agent 工程这方面真的是领先别人好几条街。Sub-agent 也是他提出来的,Skill 也是他提出来的,按 Topic 分类也是 Claude 提出来的,MCP 也是他提出来的。真的,Claude 很厉害。
Codex 是 OpenAI 开发的,而且它是开源的,GPT 很强,GPT 非常强。Codex 的代码能力非常强。
很多我的群友都说他们是用 Claude Code 编码,然后用 Codex 去做 review。他们都是这么用这个系统,一个做编码,一个做 review。而且 Claude 出了一个 Skill,这个 Skill 专门是给 Codex 去用来做编码 review 的。
Cursor、Windsurf:在 Claude Code 做出来之前比较流行的一些编码 IDE
Agent SDK:Claude Code 之上的可编程库,可以调用 Claude Code 里面的 Agent
OpenCode:Claude Code 的开源平替,做得也非常漂亮,很简洁好用。因为它免费,大家谁都可以用。非常容易配上 DeepSeek,DeepSeek 又比较便宜,简单的任务全都完成了。
OpenClaw 和 Hermes 这些第三方的,能够干更多事儿,能够帮你在 WhatsApp、飞书上做点运营,这些进一步的演进。
这个就很清晰了:
纵深型:Claude Code 这种,你用它做深度的工程开发
横向型:OpenClaw 这种,你用它做自动化的运营
这两个东西其实是不冲突的,可以配合使用。
其实我用 OpenClaw 很少,我还是喜欢 Claude Code 这种一来一往的深层次交互。就回到我刚才所说的,当我构建一个东西的时候,我希望我在跟它切磋,知道它在干啥。当它自己去抓取、查询、输出、推送的时候,我感觉自己很失控。
OpenClaw 这些东西对于某些人可能很有用,它能够帮你自动运营、自动收集。但其实它收集过来的所有东西,你需要深度分析,它才能够真正去输出。因此它解决的问题其实不是最底层的问题,对我来说它只是一个插件。
当所有东西都自动化了之后,我认为这个东西就没深度了。所以我还是喜欢这种一来一往的方式。
最后对于我们来说很重要的是,作为 Agent 时代的工程师,我们的能力应该往哪个方向转型?
工程师永远不会失业,但码农可能会失业。
什么是码农?就是单纯写代码的人。当 Agent 可以生成代码的时候,码农的价值就会被替代。
什么是工程师?是能够设计并驾驭复杂系统的人。工程师的核心能力不在于写代码,而在于:
理解系统的复杂性
抽象和结构化思维
驾驭不确定性
你程序员就是一个编码的码农,当这个农民的工作被 Agent 取代的时候,码农就失业了。但是你说我不是码农,我是一个驾驭系统的工程师,马上这个高度就立马不一样。
你所做的事情永远不是在给系统编码,你是在设计并控制这个系统,你是一个系统工程师。有没有感觉心里现在很稳?
我觉得这个世界是复杂的,复杂的世界需要有人管理。能够管理这个复杂世界的人是懂的人。朋友们,得懂。
越是在 AI 时代,我们作为个体懂得要越多,不能越少。
企业业务很重要,现在什么是我们的护城河?我们做越来越多的业务,懂企业的东西都是我们的护城河。
如果你说“我不懂,Agent 什么都能做,我没有我的立足之地”,那是因为咱们没有懂到那个层次。如果咱们懂到那个层次,你就会发现在 Agent 时代,你可以设计并驾驭的东西太多了。
我特别喜欢跟大模型深度交互。我能跟 ChatGPT 聊一整天,聊到最后特别深。因为在这个 session 里面它也足够了解我了,我也足够了解它了,我还一直把它的深度往上推。
有的时候我会问它这样的问题:“如果现在跟你谈这个问题的人是奥特曼,你会怎么回答?”我说“你不要觉得我只能想到这么深,你可以把这个回答谈得再更深一点,我想听你真正的想法”。
这种深度交互的能力,这种能够不断追问、不断深入的能力,是 Agent 时代非常重要的能力。
你给大模型什么东西,就是你能够从大模型身上得到的东西。我想的东西很深入,所以我跟大模型切磋的过程本身就比较精彩。
我们需要设计循环的策略、工具、质量审核、分发治理。核心就是:可控。我们正在设计可控的系统。
这需要我们有系统级的思维,能够从全局去看待一个 Agent 系统应该如何设计。
跟着这些核心组件的节奏,一个一个我们可以自己去研究别人的系统,可以自己去构建自己的 Harness 系统。这个就是我们未来有时间有空大家可以去自学自己玩的东西。
我现在先暂停一会儿,因为我怕大家太焦虑。我们在这个 AI 时代要稳住,不要害怕这个世界变得太快。我们是以不变应万变。
真的,我们不用啥都追,追那个是很累的事情。我们真的是要找本质。我特别期待,我相信咱们 Datawhale 的朋友不是期待着学一个什么东西然后去出去挣快钱的,我觉得那个是不长久的。
我们的思考是在纷纷乱乱复杂的世界中去思考一些不变性的主题,寻找一些本质性的东西。当我们这样做的时候,其实我们不会觉得世界变化太快,因为万变不离其宗。
有朋友问:“老师,这个 Agent 框架设计变化太快了。”
没事儿,咱们就是以不变应万变。比如说我们导出来 27 个设计模式,咱们让它固定住,然后这 27 个模式一直能够涵盖很多的东西,万变不离其宗。
不必焦虑。
今天的分享从 2026 年的关键转折点开始,深入剖析了 Agent Harness 这个战略级别的基础设施。
我们看到了一个贯穿 30 年软件工程演进的主题:工程师如何驾驭复杂系统。从面向对象到企业架构,从微服务到大数据,再到今天的 Agent,复杂性的中心一直在转移,但本质从未改变——我们需要通过抽象和结构化,把复杂的东西变得可控。
Harness 就是我们驾驭 Agent 这个“不确定性系统”的缰绳。
在这个 Agent 时代,模型智力已经在线,我们现在比拼的就是 Harness。Claude Code 的成功、DeepMind 的实验、各家的布局,都在证明 Harness 的战略价值。
对于我们工程师来说,关键是要从码农升级为系统工程师,从写代码升级为设计系统,从被动执行升级为主动驾驭。只有理解了过去,我们才能真正驾驭未来。
凡此过往,皆为序章。
朋友们,稳住,我们一起往前走。
封面来源|AGI Hunt
53AI,企业落地大模型首选服务商
产品:场景落地咨询+大模型应用平台+行业解决方案
承诺:免费POC验证,效果达标后再合作。零风险落地应用大模型,已交付160+中大型企业
2026-04-23
Image2 的六大生产级场景,电商、营销、品牌,重新定义 AI 绘画,绝了!
2026-04-23
Anthropic 最新博客:MCP 没死,它又来了
2026-04-23
Ling-2.6-flash 发布:更快响应、更强执行、更高 Token Efficiency
2026-04-23
当 AI 开始接管工作流:穿透 Workspace Agents,看懂下一代组织形态
2026-04-23
OpenAI 发布 Workspace Agents,接替 GPTs
2026-04-23
OpenAI版「龙虾」首次登场!不睡觉不离职,越PUA越聪明
2026-04-23
刚刚!OpenAI 凌晨甩出 Workspace Agents:一句话,给整个团队造一个 Agent
2026-04-23
GPTs 已死!刚刚,OpenAI 发布「云端龙虾」,限时免费
2026-01-24
2026-04-15
2026-01-26
2026-03-31
2026-03-13
2026-02-14
2026-02-03
2026-02-03
2026-02-03
2026-02-09
2026-04-22
2026-04-18
2026-04-13
2026-04-12
2026-04-07
2026-04-01
2026-03-31
2026-03-31