一文帶你看懂，火爆全網的Harness Engineering到底是個啥。

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

Harness Engineering。

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

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

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

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

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

這個大概就是如今的現狀。

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

Prompt Engineering，Context Engineering。

還有今天的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那里榨出更多價值，這個技能差異是真實存在的。

但問題來了。

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

你不用再像伺候大爺一樣去精心構造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。

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

到這里，其實已經比Prompt Engineering進了一大步了。

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

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

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

如果是我自己印象中，第一次在AI領域看到關于 Harness的描述，應該是去年11月 Anthropic發的blog。

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

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

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

直到2026年2月，OpenAI的一篇Blog，把 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(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設置不同級別的權限，有些操作它可以自己做，有些操作它必須先問你，有些操作它絕對不能碰。

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

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

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

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

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

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

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

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

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

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

你需要一個系統來約束它、監控它、在它犯錯的時候自動糾正它。

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

聊天機器人 → AI助手 → 自主Agent。

而你，跟它的關系也變了。

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

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

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

所以啊，其實3個時代的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幫你寫郵件，你能不能事先告訴它，「永遠不要用感嘆號結尾」「收件人是老板的時候語氣要正式」「涉及數字的時候要double check」。這就是你的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了。

僅此而已。

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

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

只是現在。

輪到你了。

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

>/ 作者：卡茲克

>/ 投稿或爆料，請聯系郵箱：wzglyay@virxact.com