Harness Engineering全面解析:从Prompt到AI驾驭术的三次跃迁
近期,Harness Engineering这个术语在科技圈出现的频率极高。
无论你是在浏览社交媒体,还是在行业群组中潜水,都能看到关于它的讨论。相关的指数也常常呈现陡然的上升趋势。
许多人都在好奇,这个Harness究竟指的是什么。
因此,我花了几乎一整天的时间,梳理并写下我对Harness Engineering的理解。
大家不必认为AI行业热衷于创造概念或偏爱抽象表述,这主要是因为AI领域的演变速度极快,许多事物都随着时间的推进和行业的发展而不断演进。
某个术语在2024年可能还贴合当时的语境,但到了2025年,随着模型能力以惊人的速度提升,它便显得力不从心。于是,行业在2025年不得不采用一个新词来解释,然而到了2026年,这个新词可能又不够用了。
这正是我们如今所面临的现实。
长期关注AI领域的朋友,或许已经能猜到我指的是哪几个词了。
Prompt Engineering,Context Engineering。
以及如今的Harness Engineering。
这三个词,近乎完美地标注了我们与AI协作方式的三个进化阶段。
而我本人,恰好完整地经历了这三个阶段。
从2023年人们研究如何写出一个优秀的Prompt,到2025年探索如何更有效地为AI填充上下文,再到如今2026年,我们开始讨论如何为AI配置“马具”。
三年时间。
说短不短,说长也不算长。
但回望过去,这三次转变,其实都映射出我们人类对AI认知的深化。
打一个游戏玩家都能立刻理解的比方。
第一阶段,犹如你在玩《只狼》这类动作游戏。
每一次格挡、每一次弹反都需要你亲手操作,按一次键,它出一招。
一招失误,屏幕上便会出现巨大的“死”字。你就是AI唯一的操控者,它的每一个动作都必须由你亲自按键下令,动一下,回应一下。这便是我们传统的聊天机器人模式。
第二阶段,则如同你在玩《金铲铲之战》这类自走棋。
你其实不必再亲手操控每一个动作了,你的工作全部集中在前期配置上。
选择英雄、凑齐羁绊、搭配装备、排列站位。
配置完成,棋子便会自行上场战斗,你只能旁观。而决定胜负的,完全取决于你前期对信息和资源的配置是否正确。
这个阶段,对应的是模型能力尚不够强大时的前智能体时代。
第三阶段,就好比你在玩《全面战争》这类即时战略游戏。
战场上成千上万的单位在自主行动,你根本无法逐一操控每一个士兵,只能依靠编队、阵型、AI指令和战场规则来驾驭整个战局。
单位越聪明、自主性越高,你便越需要一整套系统来约束它们的行为。
从操控一个角色,到带领一支小队,再到指挥一整支军队。
玩家的控制粒度越来越粗放,AI的自主程度越来越高,你所需的约束方式也愈发系统化。
而这三个阶段,我认为恰好对应了Prompt Engineering、Context Engineering、Harness Engineering的三次跃迁。
因此,要理解Harness Engineering到底是什么,我认为最关键的就是要明晰这一路的跃迁究竟是如何发生的。
想理解当下,最好的方式,就是读懂历史。
所以,今天这篇文章,我希望能真正让你明白Harness Engineering到底是什么,它的来龙去脉,以及它能够解决什么问题。
如果你是技术领域的资深人士,希望能为你提供一些新的思考角度;如果你是非技术背景的普通用户,我也会尽力让你看得明白。
我们这就开始。
先从源头梳理。
让时间倒回到2023年。
2022年底至2023年,ChatGPT横空出世,整个世界为之轰动。
我还记得2023年的春节,假期归来,所有人都在谈论ChatGPT。在那之后,当时最火的一个词,就是Prompt Engineer,提示词工程师。
那时,硅谷可以为一位提示词工程师开出30万美元年薪的工作机会。
国内的情况也同样火热,2023年的那张流传甚广的图片,大家肯定都见过。

当时,有无数Prompt框架涌现。因为彼时模型的智能水平尚不足够,很多时候,模型的输出并不稳定。我那时还在从事AI产品工作,值得一提的是,国内金融领域的第一个算法备案是我拿下的。

我们每天做得最多的事,就是在Prompt上施加约束,思考如何设计出好的Prompt,能让模型输出更稳定的JSON格式,以便与我的数据库进行交互。
当然,另一方面,就是写出良好的Prompt约束,让模型生成更优质、更稳定的回答。
在那个年代,同一个问题,换一种问法,AI给你的答案质量可能会有天壤之别。
比如,你直接问ChatGPT“帮我写一篇关于AI的文章”,它产出的内容大概率是一堆正确的废话。
但你如果说:“假设你是一位科技领域的资深记者,风格偏口语化,擅长用类比来解释复杂概念。现在需要撰写一篇3000字的文章,主题是AI对普通人生活的影响,要有具体案例,语气不要太正式。”那么生成的效果就会完全不同。
所以你看,在Prompt Engineering那个年代,我们做得最多的事就是研究如何设计Prompt,才能让AI给出最好的回答。
这在2023年确实很有价值,因为那时大模型刚刚问世,输出确实不稳定,大家也都在摸索与它交流的方式。
谁能把问题问得更好,谁能把Prompt约束得更精妙,谁就能从AI那里挖掘出更多价值,这种技能上的差异是真实存在的。
但问题随之而来。
从2024年下半年开始,一个趋势变得愈发明显:模型变得越来越聪明了。
你不再需要像伺候大爷那样去精心构建Prompt了。当Claude 3.5 Sonnet发布时,你随便跟它说句话,它都能理解你的意图。我记得当时我还写了李继刚的“汉语新解”,也算是一时风潮。

在那个时代,Prompt技巧的边际收益在急剧下降。
因为人们发现,当模型足够聪明时,你怎么提问已经没那么重要了。
重要的是,当你提问时,它手里是否掌握了关于你问题的、足够且体量合适的信息,在有限的性能条件下,为你生成一个理想的答案。2025年年中,Andrej Karpathy转发了一条推文,大意是赞同将Context Engineering置于Prompt Engineering之上。

因为在实际的工业级AI应用中,真正的工作不是去雕琢一个华丽的Prompt,而是需要更多地考虑工程化,要精心设计AI的上下文窗口里到底该放入什么信息。
因为在那个年代,上下文窗口实在太小了。
Karpathy的原话是,Context Engineering是“填充上下文窗口的精妙艺术与科学”。
于是,Context Engineering,上下文工程,这个概念在2025年下半年迅速成为所有AI应用从业者的共识。
因为它确实切中了当时行业人员的痛点。
在此,我仍想再次表达,很多时候,造词这件事分为两种情况:有一种我认为纯粹是为了炒作概念,比如某某4.0;而另一种,则确实是行业发展太快,人们迫切需要一种更精准的表达。
词语,从来都是为表达而服务的。
Context Engineering解决的问题,就好比你让AI帮你修改一段代码,如果你只给它这段代码本身,它可能改得乱七八糟。
但如果你同时提供这段代码所在的文件、相关的依赖项、项目的技术栈说明、团队的代码规范,它产出的代码质量会高几个量级。
而如何优雅、省Token地给出最精准的信息,这就是真正的Context Engineering。
在这方面,我依然觉得让我获益最多的,还是Manus在2025年7月18日发布的那篇文章。

至此,我们已经比Prompt Engineering时代前进了一大步。
人们开始研究的,从如何约束单个Prompt,转变为如何在有限的上下文空间里,尽可能地为模型提供精准的信息。
就这样,又过了将近8个月的时间。
Harness Engineering正式登上了属于它的舞台。
如果追溯我的个人印象,第一次在AI领域看到关于Harness的描述,应该是去年11月Anthropic发布的博客文章。

那篇报告解决的核心问题是,如何让智能体跨越多个上下文窗口有效工作而不丢失状态。
他们将自家的Claude Agent SDK称为,“一个强大的通用Agent Harness”。
不过,他们当时并未使用Harness Engineering这样的描述。
直到2026年2月,OpenAI的一篇博客文章,将Harness Engineering写在了醒目的标题上。于是,Harness开始正式进入大众视野。

这也是内容极具价值的一篇文章。
大致意思是,OpenAI内部有一个团队,用了五个月时间,利用Codex构建了一个代码量接近一百万行的产品。
其中,人类手写的代码量是0行。
所有代码均由Codex Agent生成,人类工程师全程未写一行代码。
人类工程师所从事的工作,便是持续进行Harness Engineering。
他们在设计架构边界,制定依赖规则,编写自动化测试,配置lint规则,搭建CI/CD流水线,设计反馈循环机制。
他们在构建一个笼子,一个能让AI Agent在其中安全、高效、可控地工作的笼子。
这个笼子,就叫做Harness。
Harness这个词,来源于马具,即包括马鞍、缰绳、嚼子等在内的一整套驭马装备。

马是一种力量巨大、速度极快的动物,但如果你不给它套上缰绳,它大概率会偏离方向,甚至将你甩下马背。
就像那句著名的台词所言:

Harness的作用,正是将这股原始的力量,引导到你期望的方向上去。
AI Agent就是那匹马。
如今,模型本身的能力已经极其强大,它能编写代码、进行分析、与外部工具交互、自主做出决策。
但如果你不给它套上Harness,它便会跑偏,会犯错,会在你不知道的地方引出难以预料的麻烦。
因此,一个广为流传的公式出现了:Agent = Model + Harness。
这个公式是由LangChain在其博客上提出的,我认为这可能是2026年到目前为止,关于AI工程最精辟的一句话。

尽管Birgitta Böckeler认为这个定义非常泛化,但我依然觉得它很形象。
模型是马,Harness是缰绳,光有马不行,你还需要一整套驾驭它的系统。
我在昨天发布的文章里,一直在强调一个理念,叫“约束先行”。
这其实就是Harness Engineering中至关重要的一环。
而一个真正的Harness究竟长什么样呢?我认为Birgitta所写的框架还是比较清晰的。
她将其分为两类控制机制。

第一类叫Guides(前馈控制),即引导。
就是在AI开始行动之前,提前为它设定好规则,让它沿着正确的方向行进。
这有点像高速公路上的护栏,你不需要每一秒都去纠正司机,防止他开到山沟里去,因为只要护栏在那里,车辆就几乎不会掉入山沟。
CLAUDE.md文件就是一种Guide,代码规范文档也是,架构决策记录同样如此。这些东西在AI动手之前就已经存在,它们就是前馈控制。
第二类叫Sensors(反馈控制),即检测器。
就是在AI完成工作之后,运用各种手段去检测它做得是否正确。
自动化测试是Sensor,代码lint是Sensor,CI流水线也是Sensor,它们都是反馈控制。
优秀的Harness,正是Guides和Sensors的组合。前者防患于未然,后者亡羊补牢,两者结合,形成一个闭环。
而每当发现Agent犯了一个错误,你便会花时间去设计一个方案,让它永远不可能再犯同样的错误。
这就是Harness Engineer的日常工作。
他们从来都不只是在写代码,最重要的工作,其实都是在设计一个让Agent如何不再犯错的系统。
就像我在昨天那篇文章里谈到的,Claude Code的规则体系如何从全局的CLAUDE.md一层层穿透到项目级、再到文件夹级。约束从上往下传递,一层管着一层。
这个虽然看似非常简单,但其底层逻辑,其实与OpenAI在那个百万行代码项目中所做的事情如出一辙。
他们强制定义了一套分层架构,Types → Config → Repo → Service → Runtime → UI,共六层,每一层只能依赖它下面的层,不能形成反向依赖。

有了约束,速度才不会下降,架构才不会发生漂移。
规则从来不是靠口头约定来维系的,而是依靠自动化测试来强制执行的。
如果非要我给Harness Engineering定一个最核心的概念。
那我还是想用我昨天说的那四个字。
约束先行。
就像我们设计的权限系统,你可以为AI Agent设置不同级别的权限:有些操作它可以自行完成,有些操作它必须首先征得你的同意,而有些操作,它绝对不能触碰。
比如,读取文件它可以直接进行,删除文件则必须先询问,而像格式化硬盘这类操作,则想都别想。
所以,回过头来看,这三个阶段的演变非常有意思。
在Prompt Engineering的时代,AI是一个聊天机器人。
你与它的交互方式是一轮对话,你说一句,它回应一句。
在这个模式下,你唯一能影响输出的杠杆,就是你的Prompt。所以,大家会拼命研究如何写出更好的Prompt。
在Context Engineering的时代,AI变成了一个助手。
它不再仅仅是回答问题,它开始帮你处理事务。它需要阅读你的文档,理解你的项目,调用你的工具。在这个模式下,光靠Prompt已经不够了,你还需要为它提供充足的上下文。
在Harness Engineering的时代,AI变为了一个能够自主行动的智能体。
它不是在等待你的指令,它可以自行运转,自己编写代码,自己进行测试,自己提交,自己部署。
在这个模式下,Context也不够了。因为Agent是自主运行的,你无法一直盯着它。
你需要一个系统来约束它、监测它,并在它犯错时自动纠正它。
所以,这三个阶段的演变,对应的其实是AI角色的三次升级。
聊天机器人 → AI助手 → 自主Agent。
这个思路其实也与Harness Engineering的理念相似:能用确定性规则约束的地方就用规则,能用自动化检测的地方就用检测,只有那些真正需要判断力的部分,才留给Agent去自由发挥。
你不会用大炮去打蚊子,同理,你也不应该在可以用确定性规则解决问题的地方引入不确定性。
所以,这三个时代的Engineering,从来都不是什么替代关系,而是一层层升维、随着时代前进的嵌套关系。
Harness Engineer需要懂Context Engineering,因为为AI提供正确的上下文信息,本身就是Harness的一部分。
Context Engineer也需要懂Prompt Engineering,因为最终与AI沟通的单元,还是一条条的Prompt。
每一层都没有过时,只是被更大的框架包裹住了。
我知道,读到这里,你可能会问,我又不是程序员,Harness Engineering跟我有什么关系?
这是一个好问题,我也明白许多看我文章的朋友并非技术背景出身。
我自己更不是程序员出身,我是一名用户体验设计师。
坦率地讲,Harness Engineer这个角色,目前确实主要出现在软件开发领域,因为当下AI Agent最成熟的落地场景,就是编写代码、开发产品。
但我认为,Harness Engineering的思维方式,其实是具有普适性的。
比如,很多朋友现在用AI做任何稍微复杂一点的事情,可能都会遇到这样的问题:AI有时会莫名其妙地跑偏,你需要反复去纠正它。
这就是缺少了Harness。
比如,你能不能为AI设定一些规则,让它在这些规则的框架内工作?假设你让AI帮你写邮件,你能否事先告诉它,“永远不要用感叹号结尾”“当收件人是老板时语气要正式”“涉及数字时要进行二次核对”?这就是你的Harness。
比如,你能否设计一些检查点,在AI输出之后进行自动验证?如果你让AI帮你做数据分析,能否设置一个规则,让它每次计算完后都自行验算一遍?这也是Harness。
20世纪的伟大科学成就之一,控制论,其中最为核心的一个思想,就是任何复杂系统的稳定运行,都依赖于反馈机制。
恒温器之所以能保持房间温度恒定,从来不是因为它知道设定温度应该是多少,而是因为它有一个传感器能感知当前温度,然后与目标温度进行比较,并不断进行调整。
这些思维方式,正是Harness Engineering的内核。它从来不是说,让你直接去做技术、去写代码,而是需要你去思考清楚,如何让AI在你不盯着的时候也能干好活,如何设计一个系统,使得在你无需实时监控的情况下,这个系统也能自行运转起来。
其实,我们驯服AI的过程,真的与人类驯服大自然的历史有着极高的相似度。
最早,人类学会用火,你需要小心翼翼地添柴,火太小不行,太大也不行。这就是Prompt Engineering,你的每一次输入都直接决定输出。
后来,人类学会了建造炉子,你把火封闭在一个结构中,通过调节进气口和烟囱来控制火势。这就是Context Engineering,你通过设计上下文来影响火的行为。
再后来,人类发明了蒸汽机,火不再是你直接操控的对象了,它在一个精密的系统中自动运行,有锅炉、有气缸、有调节阀、有安全阀。你无需再管火怎么烧,你管理的是这套系统如何设计。这就是Harness Engineering。
从火焰到蒸汽机,人类用了几千年。
从Prompt Engineering到Harness Engineering,AI只用了三年。
我甚至觉得,如何使用AI这件事演变到最后,其实就对应了人类历史上出现的那一门门古老的学科。
Harness就是控制论。
Skill其实就是分类学。
Prompt其实就是语言学。
Context其实就是信息科学。
Reasoning其实就是认知心理学。
多Agent协同其实就是管理学。
所以,很多人天天说什么“文科已死”,我每次听到都会说这是无稽之谈。从来没有什么文科已死或是理科已死。
这个世界,本就不应该再分文理。
两端融合,才是真正的出路。
拥有多学科融合的背景,兼具理工科的严谨与文科的审美,既有结构化的理性,也有人文的洞察。
这样的人,在未来十年里,我才觉得会是整个社会里,能把AI、Agent用得最为出色,同时也是未来最为稀缺的那批人。
所以,根本无需焦虑。
Harness Engineering根本不是什么新词。
它就是人类几千年来一直在做的同一件老事。
就是研究如何将一股更快、更强、更不受控制的力量,安全地、持续地、可复制地,引导到我们想要的方向上去。
火是这样,蒸汽是这样,电是这样,核能也是这样。
从我们学会用火开始,那几十万年的历史,从来都是如此。
只不过,这一次,轮到AI了。
仅此而已。
当一个事物比你更快、比你更强、比你更自主的时候,你如何还能让它,为你所用。
这件事,你的祖先做过,你的父辈做过。
只是现在。
轮到你了。
以上,既然看到这里了,如果觉得不错,不妨点个赞、在看,如果觉得有收获,也欢迎分享给你身边的朋友。如果想第一时间收到推送,也欢迎给我一个星标。谢谢你看我的文章,我们,下次再见。