我刷推刷到，朋友圈刷到，群里也在聊，微信指数又莫名其妙一根穿云箭了。

几乎每隔两三天就有人来问我，卡兹克你能不能讲讲这个到底是什么。

所以想了想，我还是尽我可能，花了将近一整天的时间，给大家写一下我理解的Harness Engineering到底是个啥。

大家其实不要觉得AI行业喜欢造概念或者喜欢搞抽象，主要还是AI这玩意实在变得太快了，很多东西也都是随着时间和行业的发展不断的前进的。

一个东西在24年可能还满足当时的语境，但是25年可能就不够了，因为模型的进步速度太快了，于是25年大家只能用一个新的词来解释，结果，26年，这个词又不够用了。

这个大概就是如今的现状。

跟AI跟的比较久的朋友，可能已经能猜到我上面说的是哪几个词了。

，。

还有今天的Harness Engineering。

这三个词，几乎完美地标记了我们跟AI协作方式的三次进化。

而我恰好，这三个阶段都亲身经历过。

从2023年大家都在研究怎么写一个好Prompt，到2025年开始研究怎么给AI更好的塞上下文，到现在2026年，大家开始聊，怎么给AI设置马具。

三年。

说短不短，说长也不长。

但回头看，这三次变化，其实都映射的，是我们人类对AI的认知。

打个游戏玩家都能秒懂的例子吧。

第一阶段，就是你在玩《只狼》这种动作游戏。

也就是每一招格挡、每一次见切都得你手搓，按一下键它出一招。

一招没按对，屏幕上就会出现巨大的死。你就是AI唯一的操作者，AI每一个动作都得你亲自按键下令，动一下回一下，也就是我们传统的ChatBot。

第二阶段，就是你在玩类似《金铲铲之战》这种自走棋。

你其实可以不用再自己手搓每一个动作了，你的活其实全在前期配置。

选英雄、凑羁绊、配装备、排站位。

配完了，棋子就自己上场打回合，你只能吃瓜看戏。而决定胜负的，全靠你前期把信息和资源喂得对不对。

这一个阶段，就是模型能力还不够强的时候的前Agent时代。

第三阶段，就类似是你在玩《全面战争》这种即时战略游戏。

场上几千个单位自己在跑，你根本摇不过来每一个兵，只能靠编队、阵型、AI指令、战场规则去驾驭整盘战局。

单位越聪明、越自主，你越得靠一整套系统去约束它们的行为。

从操作一个角色，到带一个小队，再到指挥一整支军队。

玩家的控制粒度越来越粗，AI的自主度越来越高，你需要的约束方式也越来越系统。

而这三个阶段，我觉得就对应了Prompt Engineering、Context Engineering、Harness Engineering的三次跃迁。

所以，聊Harness Engineer到底是什么，我觉得最重要的，就是你要知道这一路的跃迁究竟是什么样的。

想理解现在，最好的方式，就是读懂历史。

所以，今天这篇文章，我就希望能真的让你明白Harness Engineering到底是个啥，它的来龙去脉，以及他能解决的问题。

如果你是技术大佬，希望能给你提供一些新的思考角度，如果你是非技术的小白用户，我也会尽量让你看得明白。

话不多说，我们开始。

先从头捋。

先把时间倒回到2023年。

2022年底到2023年，ChatGPT横空出世，整个世界炸了。

我还记得23年的春节，春节回来之后，所有人都在聊ChatGPT，而那之后，那段时间最火的一个词。

就是Prompt Engineer，提示词工程师。

当时硅谷可以给Prompt Engineer开出了年薪30万美金的offer。

然后国内也是，23年的图，大家肯定都见过。

然后当时有无数的Prompt框架出现，因为彼时模型智能水平不够，所以很多时候，模型的输出不稳定，我那时候还在做AI产品，这里可以提一嘴，国内金融领域的第一个算法备案是我拿的

我们每天做的最多的事，其实就是在Prompt上做约束，怎么设计好Prompt，能让模型输出更稳定的json格式，从而跟我的数据库进行交互。

当然，也有另一部分，就是写好Prompt约束，让模型生成更好更稳定的回答。

那个年代，同一个问题，你换一种问法，AI给你的答案质量就可能会天差地别。

比如你直接问ChatGPT“帮我写一篇关于AI的文章”，它给你吐出来的东西大概率是一坨正确的废话。

但你如果说“你是一个科技领域的资深记者，风格偏口语化，擅长用类比来解释复杂概念，现在需要写一篇3000字的文章，主题是AI对普通人生活的影响，要有具体案例，语气不要太正式”，那出来的东西就完全不一样了。

所以你看，Prompt Engineering那个年代，做的最多的事就是怎么设计Prompt，能让AI给你最好的回答。

这事儿在2023年确实是有价值的，因为那时候大模型刚出来，输出也确实不稳定，大家都还在摸索跟它交流的方式。

谁能把问题问得更好，谁把Prompt约束的更好，就能从AI那里榨出更多价值，这个技能差异是真实存在的。

你不用再像伺候大爷一样去精心构造Prompt了，Claude 3.5 Sonnet出来的时候，你随便跟它说句话，它都能理解你的意思，那个时候我记得我还写了李继刚的汉语新解，也算是一代风潮。

那个时代，Prompt技巧的边际收益在急速下降。

因为人们发现，当模型足够聪明的时候，你怎么问已经没那么重要了。

重要的是，你问的时候，它手里有没有关于你问题的足够且合适体量的信息，在有限的性能之下，来给你一个好答案。

所以我后来甚至都发了一篇文章，我觉得那些Prompt技巧真的没啥用，核心的是6个心法：

至此，这就引出了第二个阶段。

2025年年中，Andrej Karpathy转发了一条推，大概意思是说，赞同把Context Engineering放在Prompt Engineering之上。

因为在实际的工业级AI应用里，真正的活不是在那雕花一个Prompt，是需要更多的考虑工程化，要精心设计AI的上下文窗口里到底该塞什么信息。

因为那个年代，上下文窗口真的太小了。

Karpathy的原话是，Context Engineering是“填充上下文窗口的精妙艺术与科学”。

于是，Context Engineering，上下文工程，这个概念在2025年下半年迅速成为了所有做AI应用的人的共识。

因为他确实切中了当时行业人们的痛点。

在这里我还是想再次表达一下，很多时候，造词这事分两种情况，有一种我觉得就是为了炒概念，比如xxx 4.0，而有的时候，真的只是行业太快，人们更需要一个精准的表达。

词语，从来都是为表达而服务的。

Context Engineering解决的问题，就类似于你让AI帮你改一段代码，如果你只给它这段代码本身，它可能改得乱七八糟。

但如果你同时给它这段代码所在的文件、相关的依赖、项目的技术栈说明、团队的代码规范，它改出来的东西质量会高几个量级。

而如何优雅的、省Token的给出最精准的信息，就是真正的Context Engineering。

这里我依然觉得，让我学到的最多，还是的25年7月18号发的那篇文章。

到这里，其实已经比Prompt Engineering进了一大步了。

人们开始研究的是，从怎么约束单个Prompt，变成了如何在有限的上下文空间里，尽可能的给模型精准的信息。

就这样，过了又将近8个月的时间。

他们在设计架构边界，制定依赖规则，写自动化测试，配置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(feedforward controls) ，引导。

就是在AI行动之前，提前给它设好规则，让它沿着正确的方向走。

这有点像高速公路上的护栏，你不需要每一秒都去纠正司机别开到山沟沟里，因为只要护栏在那里，车就几乎不会开到山沟沟里面去。

CLAUDE.md文件就是一种Guide，代码规范文档也是，架构决策记录也是，这些东西在AI动手之前就已经在那了，它们是前馈控制。

第二类叫Sensors (feedback controls) ，检测器。

就是在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定一个最核心的概念。

那我还是想用我昨天说的那4个字。

约束先行。

就像我们所设计的权限系统，你可以给AI Agent设置不同级别的权限，有些操作它可以自己做，有些操作它必须先问你，有些操作它绝对不能碰。

比如读文件可以它自己来，删文件必须先问，而像格式化硬盘这种操作，你永远想都别想。