最近這個詞實在是太火了。

Harness Engineering。

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

幾乎每隔兩三天就有人來問我，卡茲克你能不能講講這個 Harness 到底是什么。

所以想了想，我還是盡我可能，花了將近一整天的時間，給大家寫一下我理解的 Harness Engineering 到底是個啥。

大家其實不要覺得AI行業(yè)喜歡造概念或者喜歡搞抽象，主要還是AI這玩意實在變得太快了，很多東西也都是隨著時間和行業(yè)的發(fā)展不斷的前進(jìn)的。

一個東西在24年可能還滿足當(dāng)時的語境，但是25年可能就不夠了，因為模型的進(jìn)步速度太快了，于是25年大家只能用一個新的詞來解釋，結(jié)果，26年，這個詞又不夠用了。

這個大概就是如今的現(xiàn)狀。

跟AI跟的比較久的朋友，可能已經(jīng)能猜到我上面說的是哪幾個詞了。

Prompt Engineering，Context Engineering。

還有今天的Harness Engineering。

這三個詞，幾乎完美地標(biāo)記了我們跟AI協(xié)作方式的三次進(jìn)化。

而我恰好，這三個階段都親身經(jīng)歷過。

從2023年大家都在研究怎么寫一個好Prompt，到2025年開始研究怎么給AI更好的塞上下文，到現(xiàn)在2026年，大家開始聊，怎么給AI設(shè)置馬具。

三年。

說短不短，說長也不長。

但回頭看，這三次變化，其實都映射的，是我們?nèi)祟悓I的認(rèn)知。

打個游戲玩家都能秒懂的例子吧。

第一階段，就是你在玩《只狼》這種動作游戲。

也就是每一招格擋、每一次見切都得你手搓，按一下鍵它出一招。

一招沒按對，屏幕上就會出現(xiàn)巨大的死。你就是AI唯一的操作者，AI每一個動作都得你親自按鍵下令，動一下回一下，也就是我們傳統(tǒng)的ChatBot。

第二階段，就是你在玩類似《金鏟鏟之戰(zhàn)》這種自走棋。

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

選英雄、湊羈絆、配裝備、排站位。

配完了，棋子就自己上場打回合，你只能吃瓜看戲。而決定勝負(fù)的，全靠你前期把信息和資源喂得對不對。

這一個階段，就是模型能力還不夠強的時候的前Agent時代。

第三階段，就類似是你在玩《全面戰(zhàn)爭》這種即時戰(zhàn)略游戲。

場上幾千個單位自己在跑，你根本搖不過來每一個兵，只能靠編隊、陣型、AI指令、戰(zhàn)場規(guī)則去駕馭整盤戰(zhàn)局。

單位越聰明、越自主，你越得靠一整套系統(tǒng)去約束它們的行為。

從操作一個角色，到帶一個小隊，再到指揮一整支軍隊。

玩家的控制粒度越來越粗，AI的自主度越來越高，你需要的約束方式也越來越系統(tǒng)。

而這三個階段，我覺得就對應(yīng)了Prompt Engineering、Context Engineering、Harness Engineering的三次躍遷。

所以，聊 Harness Engineer到底是什么，我覺得最重要的，就是你要知道這一路的躍遷究竟是什么樣的。

想理解現(xiàn)在，最好的方式，就是讀懂歷史。

所以，今天這篇文章，我就希望能真的讓你明白Harness Engineering到底是個啥，它的來龍去脈，以及他能解決的問題。

如果你是技術(shù)大佬，希望能給你提供一些新的思考角度，如果你是非技術(shù)的小白用戶，我也會盡量讓你看得明白。

話不多說，我們開始。

先從頭捋。

先把時間倒回到2023年。

2022年底到2023年，ChatGPT橫空出世，整個世界炸了。

我還記得23年的春節(jié)，春節(jié)回來之后，所有人都在聊ChatGPT，而那之后，那段時間最火的一個詞。

就是Prompt Engineer，提示詞工程師。

當(dāng)時硅谷可以給Prompt Engineer開出了年薪30萬美金的offer。

然后國內(nèi)也是，23年的圖，大家肯定都見過。

然后當(dāng)時有無數(shù)的Prompt框架出現(xiàn)，因為彼時模型智能水平不夠，所以很多時候，模型的輸出不穩(wěn)定，我那時候還在做AI產(chǎn)品，這里可以提一嘴，國內(nèi)金融領(lǐng)域的第一個算法備案是我拿的

我們每天做的最多的事，其實就是在Prompt上做約束，怎么設(shè)計好Prompt，能讓模型輸出更穩(wěn)定的json格式，從而跟我的數(shù)據(jù)庫進(jìn)行交互。

當(dāng)然，也有另一部分，就是寫好Prompt約束，讓模型生成更好更穩(wěn)定的回答。

那個年代，同一個問題，你換一種問法，AI給你的答案質(zhì)量就可能會天差地別。

比如你直接問ChatGPT“幫我寫一篇關(guān)于AI的文章”，它給你吐出來的東西大概率是一坨正確的廢話。

但你如果說“你是一個科技領(lǐng)域的資深記者，風(fēng)格偏口語化，擅長用類比來解釋復(fù)雜概念，現(xiàn)在需要寫一篇3000字的文章，主題是AI對普通人生活的影響，要有具體案例，語氣不要太正式”，那出來的東西就完全不一樣了。

所以你看，Prompt Engineering那個年代，做的最多的事就是怎么設(shè)計Prompt，能讓AI給你最好的回答。

這事兒在2023年確實是有價值的，因為那時候大模型剛出來，輸出也確實不穩(wěn)定，大家都還在摸索跟它交流的方式。

誰能把問題問得更好，誰把Prompt約束的更好，就能從AI那里榨出更多價值，這個技能差異是真實存在的。

但問題來了。

2024年下半年開始，一個趨勢越來越明顯，就是模型越來越聰明了。

你不用再像伺候大爺一樣去精心構(gòu)造Prompt了，Claude 3.5 Sonnet出來的時候，你隨便跟它說句話，它都能理解你的意思，那個時候我記得我還寫了李繼剛的漢語新解，也算是一代風(fēng)潮。

那個時代，Prompt技巧的邊際收益在急速下降。

因為人們發(fā)現(xiàn)，當(dāng)模型足夠聰明的時候，你怎么問已經(jīng)沒那么重要了。

重要的是，你問的時候，它手里有沒有關(guān)于你問題的足夠且合適體量的信息，在有限的性能之下，來給你一個好答案。

所以我后來甚至都發(fā)了一篇文章，我覺得那些Prompt技巧真的沒啥用，核心的是6個心法：

至此，這就引出了第二個階段。

2025年年中，Andrej Karpathy轉(zhuǎn)發(fā)了一條推，大概意思是說，贊同把 Context Engineering放在Prompt Engineering之上。

因為在實際的工業(yè)級AI應(yīng)用里，真正的活不是在那雕花一個Prompt，是需要更多的考慮工程化，要精心設(shè)計AI的上下文窗口里到底該塞什么信息。

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

Karpathy的原話是，Context Engineering是“填充上下文窗口的精妙藝術(shù)與科學(xué)”。

于是，Context Engineering，上下文工程，這個概念在2025年下半年迅速成為了所有做AI應(yīng)用的人的共識。

因為他確實切中了當(dāng)時行業(yè)人們的痛點。

在這里我還是想再次表達(dá)一下，很多時候，造詞這事分兩種情況，有一種我覺得就是為了炒概念，比如xxx 4.0，而有的時候，真的只是行業(yè)太快，人們更需要一個精準(zhǔn)的表達(dá)。

詞語，從來都是為表達(dá)而服務(wù)的。

Context Engineering解決的問題，就類似于你讓AI幫你改一段代碼，如果你只給它這段代碼本身，它可能改得亂七八糟。

但如果你同時給它這段代碼所在的文件、相關(guān)的依賴、項目的技術(shù)棧說明、團(tuán)隊的代碼規(guī)范，它改出來的東西質(zhì)量會高幾個量級。

而如何優(yōu)雅的、省Token的給出最精準(zhǔn)的信息，就是真正的 Context Engineering。

這里我依然覺得，讓我學(xué)到的最多，還是Manus的25年7月18號發(fā)的那篇文章。

到這里，其實已經(jīng)比Prompt Engineering進(jìn)了一大步了。

人們開始研究的是，從怎么約束單個Prompt，變成了如何在有限的上下文空間里，盡可能的給模型精準(zhǔn)的信息。

就這樣，過了又將近8個月的時間。

Harness Engineering正式登上了屬于它的舞臺。

如果是我自己印象中，第一次在AI領(lǐng)域看到關(guān)于 Harness的描述，應(yīng)該是去年11月 Anthropic發(fā)的blog。

這篇報告解決的核心問題是，就是如何讓Agent跨越多個上下文窗口有效工作而不丟失狀態(tài)。

他們把他們的Claude Agent SDK稱為，"一個強大的通用Agent Harness"。

不過他們并沒有用 Harness Engineering這樣的描述。

直到2026年2月，OpenAI的一篇Blog，把 Harness Engineering寫在了巨大的標(biāo)題上，于是， Harness開始正式進(jìn)入大眾視野。

這篇也是有價值內(nèi)容極多的一篇文章。

大概說的就是，OpenAI內(nèi)部有一個團(tuán)隊，用了五個月的時間，用Codex搭了一個將近一百萬行代碼的產(chǎn)品。

其中人類手寫的代碼量，是0行。

所有代碼都是Codex Agent生成的，人類工程師全程沒有寫一行代碼。

人類工程師做的工作，就是一直在做Harness Engineering。

他們在設(shè)計架構(gòu)邊界，制定依賴規(guī)則，寫自動化測試，配置lint規(guī)則，搭建CI/CD流水線，設(shè)計反饋循環(huán)機(jī)制。

他們在建一個籠子，一個讓AI Agent能在里面安全、高效、可控地干活的籠子。

這個籠子，就叫Harness。

Harness這個詞，來源于馬具，就是馬鞍、韁繩、嚼子那一整套東西。

馬是一種非常強大的動物，速度快、力量大，但如果你不給它套上韁繩，它大概率會跑偏，甚至把你甩下來。

就像那句著名的臺詞：

Harness的作用，就是把這股野蠻的力量，引導(dǎo)到你需要的方向上。

AI Agent就是那匹馬。

模型現(xiàn)在本身的能力已經(jīng)極其強大了，它能寫代碼、能做分析、能跟外部工具交互、能自主決策。

但如果你不給它套上Harness，它就會跑偏，會犯錯，會在你不知道的地方搞出幺蛾子。

所以，Agent = Model + Harness。

這個公式是LangChain在博客上提出來的，我覺得這可能是2026年到目前為止，關(guān)于AI工程最精辟的一句話。

雖然Birgitta B?ckeler說這個定義很泛，但是我覺得還是很形象的。

模型是馬，Harness是韁繩，光有馬不行，你還得有一整套駕馭它的系統(tǒng)。

昨天我發(fā)的文章，其實一直在強調(diào)一個理念，叫約束先行。

其實這就是Harness Engineering中很重要的一環(huán)。

而一個真正的Harness到底長啥樣呢，Birgitta我覺得寫的框架我覺得還是比較清晰的。

她分成了兩類控制機(jī)制。

第一類叫Guides(feedforward controls) ，引導(dǎo)。

就是在AI行動之前，提前給它設(shè)好規(guī)則，讓它沿著正確的方向走。

這有點像高速公路上的護(hù)欄，你不需要每一秒都去糾正司機(jī)別開到山溝溝里，因為只要護(hù)欄在那里，車就幾乎不會開到山溝溝里面去。

CLAUDE.md文件就是一種Guide，代碼規(guī)范文檔也是，架構(gòu)決策記錄也是，這些東西在AI動手之前就已經(jīng)在那了，它們是前饋控制。

第二類叫Sensors (feedback controls) ，檢測器。

就是在AI做完事之后，用各種手段去檢測它做的對不對。

自動化測試是Sensor，代碼lint是Sensor，CI流水線也是Sensor，它們是反饋控制。

好的Harness，是Guides和Sensors的組合，前者防患于未然，后者亡羊補牢，兩個加在一起，形成一個閉環(huán)。

而每當(dāng)你發(fā)現(xiàn)Agent犯了一個錯誤，你就花時間去設(shè)計一個方案，讓它永遠(yuǎn)不可能再犯同樣的錯誤。

這就是Harness Engineer的日常。

從來都不只是在寫代碼，最重要的工作，其實都是在設(shè)計一個讓Agent如何不再放錯的系統(tǒng)。

就像我昨天那篇文章里面聊得，就是Claude Code的規(guī)則體系怎么從全局CLAUDE.md一層一層穿透到項目級、再到文件夾級的事，約束從上往下走，一層管著一層。

這個其實雖然非常的簡單，但是底層邏輯，其實跟OpenAI在那個百萬行代碼項目里做的事是一模一樣的。

他們強制定義了一套分層架構(gòu)，Types → Config → Repo → Service → Runtime → UI，六層，每一層只能依賴它下面的層，不能反向依賴。

有了約束，速度才不會下降，架構(gòu)才不會漂移。

規(guī)則從來不是靠口頭約定，是靠自動化測試來強制執(zhí)行的。

如果你非要我給 Harness Engineering定一個最核心的概念。

那我還是想用我昨天說的那4個字。

約束先行。

就像我們所設(shè)計的權(quán)限系統(tǒng)，你可以給AI Agent設(shè)置不同級別的權(quán)限，有些操作它可以自己做，有些操作它必須先問你，有些操作它絕對不能碰。

比如讀文件可以它自己來，刪文件必須先問，而像格式化硬盤這種操作，你永遠(yuǎn)想都別想。

所以你其實回過頭來看，這三個階段的演變很有意思。

Prompt Engineering的時代，AI是一個聊天機(jī)器人。

你跟它的交互方式是一輪對話，你說一句，它回一句。

在這個模式下，你唯一能影響輸出的杠桿，就是你的Prompt，所以大家拼命研究怎么寫Prompt。

Context Engineering的時代，AI變成了一個助手。

它不再只是回答問題，它開始幫你做事了，它要讀你的文檔，理解你的項目，調(diào)用你的工具，在這個模式下，光靠Prompt不夠了，你還需要給它提供充足的上下文。

Harness Engineering的時代，AI變成了一個自主行動的Agent。

它不是在等你的指令，它可以自己在那跑，它自己寫代碼，自己測試，自己提交，自己部署。

在這個模式下，Context也不夠了，因為Agent是自主運行的，你沒法一直盯著它。

你需要一個系統(tǒng)來約束它、監(jiān)控它、在它犯錯的時候自動糾正它。

所以這三個階段的演變，對應(yīng)的其實是AI角色的三次升級。

聊天機(jī)器人 → AI助手 → 自主Agent。

而你，跟它的關(guān)系也變了。

其實我上個月也寫過一篇短文，叫，講的就是腳本→Skill→Agent這個金字塔。

這個思路其實也跟Harness Engineering的理念差不多，能用確定性規(guī)則約束的地方就用規(guī)則，能用自動化檢測的地方就用檢測，只有那些真正需要判斷力的部分，才留給Agent自由發(fā)揮。

你不會用大炮打蚊子，同樣的道理，你也不該在可以用確定性規(guī)則解決的地方引入不確定性。

所以啊，其實3個時代的Engineering，從來都不是什么替代關(guān)系，而是一層一層升維、隨著時代前進(jìn)的嵌套關(guān)系。

Harness Engineer需要懂Context Engineering，因為給AI提供正確的上下文信息本身就是Harness的一部分。

Context Engineer也需要懂Prompt Engineering，因為最終跟AI溝通的單元還是一條條的Prompt。

每一層都沒有過時，只是被更大的框架包裹住了。

那我知道，看到最后，你可能會問了，我又不是程序員，Harness Engineering跟我有什么關(guān)系？

這是個好問題，我也知道很多看我文章的朋友不是技術(shù)背景。

我自己更不是程序員出身，我是用戶體驗設(shè)計師。

坦率的講，Harness Engineer這個角色，目前確實主要出現(xiàn)在軟件開發(fā)領(lǐng)域，因為現(xiàn)如今，AI Agent目前最成熟的落地場景，那就是寫代碼、開發(fā)產(chǎn)品。

但我覺得，Harness Engineering的思維方式，其實是普適的。

比如很多朋友現(xiàn)在用AI做任何稍微復(fù)雜一點的事情，可能都會遇到這種問題，比如AI有時候莫名其妙就跑偏了，你得反復(fù)糾正它。

這就是缺少Harness。

比如你能不能給AI設(shè)一些規(guī)則，讓它在這些規(guī)則的框架內(nèi)干活？比如你讓AI幫你寫郵件，你能不能事先告訴它，「永遠(yuǎn)不要用感嘆號結(jié)尾」「收件人是老板的時候語氣要正式」「涉及數(shù)字的時候要double check」。這就是你的Harness。

比如你能不能設(shè)計一些檢查點，在AI輸出之后自動驗證？比如你讓AI幫你做數(shù)據(jù)分析，能不能設(shè)一個規(guī)則讓它每次算完都自己驗算一遍？這也是Harness。

20世紀(jì)的偉大科學(xué)成就之一，控制論，里面最核心的一個思想，就是任何復(fù)雜系統(tǒng)的穩(wěn)定運行，都依賴于反饋機(jī)制。

恒溫器之所以能保持房間溫度恒定，從來都不是因為它知道應(yīng)該是多少度，是因為它有一個傳感器能感知當(dāng)前溫度，然后跟目標(biāo)溫度做比較，然后不斷的進(jìn)行調(diào)整。

這些思維方式，就是Harness Engineering的內(nèi)核，從來不是說，讓你直接做技術(shù)去寫代碼，是需要你思考清楚，怎么讓AI在我不盯著的時候也能干好活，是如何設(shè)計一個系統(tǒng)，能讓你不用盯著的時候，這個系統(tǒng)也能自己運行起來。

其實我們馴服AI的過程，真的跟人類馴服大自然的歷史，也有著極高的相似度。

最早人類學(xué)會用火，你得小心翼翼地喂它柴火，火太小不行，太大也不行。這是Prompt Engineering，你的每一次輸入都直接決定輸出。

后來人類學(xué)會了建爐子，你把火關(guān)在一個結(jié)構(gòu)里，通過調(diào)節(jié)進(jìn)氣口和煙囪來控制火勢。這是Context Engineering，你通過設(shè)計上下文來影響火的行為。

再后來人類發(fā)明了蒸汽機(jī)，火不再是你直接操控的對象了，它在一個精密的系統(tǒng)里自動運行，有鍋爐、有氣缸、有調(diào)節(jié)閥、有安全閥，你無需再管火怎么燒，你管的是這套系統(tǒng)怎么設(shè)計。這是Harness Engineering。

從火焰到蒸汽機(jī)，人類花了幾千年。

從Prompt Engineering到Harness Engineering，AI只花了三年。

甚至我覺得，如何使用AI演變到最后，其實就是人類歷史上出現(xiàn)的那一門一門的古老的學(xué)科。

Harness就是控制論。

Skill其實就是分類學(xué)。

Prompt其實就是語言學(xué)。

Context其實就是信息科學(xué)。

Reasoning其實就是認(rèn)知心理學(xué)。

多Agent協(xié)同其實就是管理學(xué)。

所以，很多人天天說什么文科已死，我每次都會說這是放屁，從來沒有什么文科已死理科已死的。

這世界就不應(yīng)該再分文理。

兩端融合，才是真正的王道。

多學(xué)科融合背景，有理工科的嚴(yán)謹(jǐn)，有文科的審美。

有結(jié)構(gòu)化的理性，也有人文的洞察。

這樣的人，在未來十年里，我才覺得會是整個社會里，能把AI、Agent用的最牛逼，同時也是未來最稀缺的那批人。

所以，根本不要焦慮。

Harness Engineering根本不是什么新詞。

它就是人類幾千年來一直在做的那一件老事。

就是怎么把一股更快、更強、更不受控的力量，安全地、持續(xù)地、可復(fù)制地，引導(dǎo)到我們想要的方向上去。

火是這樣，蒸汽是這樣，電是這樣，核能也是這樣。

從我們學(xué)會用火開始，那幾十萬年的歷史。

從來都是這樣。

只不過，這一次，輪到AI了。

僅此而已。

當(dāng)一個東西比你更快、比你更強、比你更自主的時候，你怎么還能讓它，為你所用。

這件事，你的祖先做過，你的父輩做過。

只是現(xiàn)在。

輪到你了。

以上，既然看到這里了，如果覺得不錯，隨手點個贊、在看、轉(zhuǎn)發(fā)三連吧，如果想第一時間收到推送，也可以給我個星標(biāo)?～謝謝你看我的文章，我們，下次再見。

>/ 作者：卡茲克

>/ 投稿或爆料，請聯(lián)系郵箱：wzglyay@virxact.com