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了。
仅此而已。
当一个事物比你更快、比你更强、比你更自主的时候，你如何还能让它，为你所用。
这件事，你的祖先做过，你的父辈做过。
只是现在。
轮到你了。
以上，既然看到这里了，如果觉得不错，不妨点个赞、在看，如果觉得有收获，也欢迎分享给你身边的朋友。如果想第一时间收到推送，也欢迎给我一个星标。谢谢你看我的文章，我们，下次再见。