馬上又來了一個亟需被認證的新詞 Harness。

　　這年頭想要在 AI 圈子里當個「全面發(fā)展的專業(yè)人士」，每天要學習的概念是真的多。從最早一個 ChatGPT 能指代一切 AI，我能知道 ChatGPT 就已經(jīng)領先身邊大多數(shù)人。

　　到后面慢慢發(fā)展到，我要去學習什么是 Prompt，是提示詞還是文令、「已死的」MCP，是被 CLI 替代的模型上下文協(xié)議、RAG 是風靡一時的檢索增強生成、Agent 不是代理，是智能體、Skills 是技能，也是專家、Claude Code 是代碼助手。

　　還有因為爪子 Claw 得名龍蝦的 OpenClaw、以及龍蝦太火需要大量消耗的 Token = xxx……

　　這些堪比「顆粒度」、「對齊」的職場黑話，如果你都聽過，大概率還是能在一些聊 AI 的飯局上稍微顯露一波的。

　　之前 MiniMax M2.7 模型介紹博客里提到的 Agent Harness 能力

　　但現(xiàn)在，新的詞又來了，什么是 Harness。有網(wǎng)友在社交媒體上用一張?zhí)詫毸阉鞯慕貓D回應，表示「很好理解」。

　　很離譜，但是我們把 AI 當牛馬去指揮它干活，Harness 翻譯成套在 AI 身上的馬具/束縛，也并不是全無道理。

　　其實 Harness 最早被真正放進 Agent 領域，還是在 Anthropic 去年十一月的一篇博客，文章里他們探討了現(xiàn)在的 Agent 要執(zhí)行的任務越來越長，需要一個有效的 Harness 來確保 Agent 的運作正常。

　　博客鏈接：https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents

　　到了今年本地運行的 Agent 重新搬上臺面，一眾 AI 開發(fā)者和研究員在自己的技術博客里，也頻繁提到 Harness 這個詞。知名博主 Mitchell 提到 Harness Engineering 的理念是，「每當發(fā)現(xiàn)某個智能體犯錯時，就花時間設計一個解決方案，確保它以后不再犯同樣的錯誤?！?/p>

　　緊接著 OpenAI 在今年二月也發(fā)了幾篇博客，講的也是 Harness engineering，在他們看來，未來工程師的工作，不是寫代碼，而是設計智能體的「工作環(huán)境」，Harness 就是這個工作環(huán)境。

　　在 OpenAI 官網(wǎng)選擇中文后，直接翻譯成了「工程技術」，博客鏈接：https://openai.com/zh-Hans-CN/index/harness-engineering/

　　為什么 Harness 開始被重視

　　無論是 Anthropic 最早的博客，還是后面 OpenAI 的 Harness 工程，它們在文章里面描述的故事都是一樣的。

　　Harness 是一種包含環(huán)境配置、多 Agents 協(xié)作機制、嚴格架構約束和上下文管理的系統(tǒng)，它彌補了 AI 的「上下文焦慮」和易錯性。

　　兩家頂級 AI 實驗室都用大量的內(nèi)部工程實踐證明了，讓大模型自主寫出百萬行代碼的關鍵，并非模型本身有多聰明，而在于構建了一個強大的 Harness（工作流框架 / 護欄系統(tǒng)）。

　　我們讓 Claude 畫了一張圖，來完整介紹一下 Agent Harness，Harness = Agent 的運行容器 + 安全邊界 + 調(diào)度控制器

　　在 Anthropic 的內(nèi)部實驗中，研究員們發(fā)現(xiàn) AI 竟然也會有「心理問題」。

　　當 Claude 執(zhí)行長周期的代碼任務時，一旦它感覺到自己的上下文窗口快要填滿了，它就會產(chǎn)生「上下文焦慮」。就像快要下班的打工人，開始瘋狂敷衍，試圖趕緊結束任務。

　　要命的是，Claude 并不覺得自己在敷衍，當研究員要求 AI 評估這些「為了下班趕緊結束任務」所編寫的代碼時，它發(fā)現(xiàn)不了其中的問題。

　　面對這種毛病，傳統(tǒng)的提示詞設計毫無用處。Anthropic 的研究員給出的 Harness 解法是：改變組織架構。

　　他設計了一個包含三個角色的 Harness 閉環(huán)：

　　規(guī)劃師（Planner）：負責把一句話需求擴寫成詳細的產(chǎn)品文檔。

　　生成器（Generator）：純粹的牛馬，只負責按文檔寫代碼。

　　評估器（Evaluator）：極其冷酷的 QA 兼產(chǎn)品經(jīng)理，手握自動化測試工具。

　　Anthropic 的報告中提到，應用了 Harness 框架的 Agent 在生成網(wǎng)頁質(zhì)量上要好很多，但是成本和時間更長。

　　要求是開發(fā)一個游戲制作器，沒有 Harness 的那組，AI 跑了 20 分鐘，花了 9 美元。結果是界面能看，但核心功能是壞的——游戲里的角色出現(xiàn)在屏幕上，但對任何鍵盤操作都沒有反應，游戲沒法玩。

　　有 Harness 的那組，跑了 6 小時，花了 200 美元。結果是游戲不只是能玩，還有動畫系統(tǒng)、音效、AI 輔助的關卡設計。

　　在這套 Harness 里，生成器寫完一段代碼，評估器就會像真實用戶一樣去點擊、測試，一旦發(fā)現(xiàn) Bug 或是那種充滿「AI 塑料味」的平庸設計，直接打回重做。

　　包括我們經(jīng)常用來測試 AI Coding 能力的網(wǎng)頁生成，Anthropic 也發(fā)現(xiàn)，Harness 的潛力相當大。在一個設計荷蘭藝術博物館網(wǎng)頁的任務中，前 9 次迭代，AI 都在老老實實地畫平庸的網(wǎng)頁。

　　但在評估器不斷施壓下，第 10 次迭代，AI 突然拋棄了所有常規(guī)模板。它交出了一個特立獨行的 3D 空間：畫作懸掛在透視棋盤格的房間里，用戶需要像走迷宮一樣穿梭。

　　如果說 Anthropic 的 Harness 側重于組織架構，去探索 Harness 的設計原理，OpenAI 的 Codex 團隊則是把這件事做成了一種工程文化，更多地把 Harness 當作一種工作流框架。

　　他們的核心約束只有一條，那就是沒有人工手寫的代碼。所有代碼——業(yè)務邏輯、測試、CI 配置、文檔、內(nèi)部工具、生產(chǎn)監(jiān)控儀表盤——都由 Codex 寫。工程師的工作不是寫代碼，而是設計讓 AI 能可靠工作的環(huán)境。

　　一開始他們用一個超長的 AGENTS.md 文件告訴 AI 所有的規(guī)則。但很快就因為上下文限制，導致 AI 只會進行本地模式匹配，沒有真正理解。而且文件很快過時，沒有人維護，AI 開始被一堆可能不再成立的規(guī)則誤導。

　　一套完整的工作流程

　　后來的做法是：AGENTS.md 只有 100 行，只充當一個「目錄」，把 AI 指向結構化的 docs/ 文件夾。架構文檔、產(chǎn)品規(guī)格、設計決策、技術債務追蹤，全部是可以被 AI 直接讀取的版本化文件。每個 doc 由 AI 寫，由 AI 維護，定期有「文檔園丁」Agent 掃描過時的文檔來自動更新。

　　他們不在乎 AI 怎么寫具體的邏輯，但在 Harness 中設置了極其嚴格的 Linter（代碼檢查工具）和物理依賴邊界。業(yè)務代碼只能單向調(diào)用，越界就會被系統(tǒng)無情切斷，根本合并不進項目主分支。

　　在這個 Harness 中，我們所設置的規(guī)則，變成了 AI 不可違背的意志。AI 就像生活在「楚門的世界」里，它擁有寫代碼的絕對自由，但這種自由，永遠在人類設定的結界，即 Harness 之內(nèi)。

　　把這些研究放在一起，其實 harness 的本質(zhì)就是一套系統(tǒng)，用來補償當前 AI 不擅長的事。

　　AI 不擅長長期記憶，Harness 就用進度文件、git 歷史、結構化來補。

　　AI 評價自己太寬松，用獨立的評估 Agent，帶著具體標準和真實環(huán)境測試。

　　AI 在復雜任務里容易偏航，用任務分解、結構化、合約約定來約束范圍。

　　AI 不具備對代碼庫架構品味的直覺，因此需要用文檔和自動化規(guī)范檢查，將人類的判斷轉化為系統(tǒng)規(guī)則。

　　Claude 生成的 Harness 在 AI 領域的位置信息圖

　　有意思的是，隨著模型能力增強，harness 的有些部分會變得不再必要，但新的部分又會出現(xiàn)。

　　Anthropic 在升級到 Opus 4.6 之后，發(fā)現(xiàn)之前為了對抗「上下文焦慮」設計的「上下文重置」機制可以直接去掉了，因為新模型已經(jīng)能自己處理了。

　　但同時，他們發(fā)現(xiàn)了新的方向，用 harness 來讓 AI 在應用里自動集成 AI 功能，這是之前模型做不到的事。

　　對 Harness 來說，模型越強，Harness 不是變得更簡單，而是要去做更難的事。

　　怎么翻譯 Harness

　　在那篇詢問「繼 token、Agent 之后，又來了一個難以翻譯的詞：Harness」推文下，除了給出那張炸裂的「戰(zhàn)術胸帶 Harness」截圖外，還有很多網(wǎng)友給出了自己的翻譯。

　　有人說應該叫「線束」，因為這個詞在汽車行業(yè)已經(jīng)很多年了。還有「駕馭層」、「駕馭系統(tǒng)」、「Agent 框架」、「控制框架」、「管控層」、「錨定層」、「= Scaffold 腳手架」……

　　更有意思的回復是「安全套」、「套馬桿」、以及約束牛馬該做什么不該做什么的「槽具」。

　　微博上關于 Harness 怎么翻譯的討論也很多，Token 可以翻譯成智元的話，那 Harness 就叫智馭吧……也有人覺得和 MCP 現(xiàn)在無人問津的狀態(tài)一樣，Harness 這個概念只是現(xiàn)在熱，過一段時間又會有新的詞被造出來、被流行。

　　我們問了問 Claude，它給了好幾個答案。

　　「框架」，它認為很多東西都叫框架，framework 可以，architecture 也可以；「執(zhí)行框架」，強調(diào)了運行層面，但中性，沒有「約束」的感覺。

　　「駕馭層」中文語境下不太用這種說法；「管控層」強調(diào)了「約束」，但是沒有「執(zhí)行」；「套具」在 AI 領域完全是陌生的概念。

　　所以最后它說比較實用的方案是，不翻譯，就用 Harness。

　　一個概念如果能被一個詞完整概括，翻譯本來順理成章的事。Harness 之所以又是一個不容易確定的詞，是因為它在 LLM 這套流程里，同時包含了「約束」、「執(zhí)行」、「環(huán)境」、「系統(tǒng)」等幾層意思，拆開來哪個都只說對了一半。

　　和 Token 最終被認證為「詞元」，Harness 大概率也會有自己的官方中文。在那天之前，你在技術文章里看到這個詞，知道它在說什么就夠了。

　　然后在某個聊到 AI 的飯局上，記得說一句，「在未來，會寫提示詞和 Skills 都不是核心競爭力。真正的頂級人才，是那些懂得如何設計 Harness 的人。」

　　關于 Harness 的詳細內(nèi)容，還可以閱讀下面這些文章：

　　1、Anthropic, Harness design for long-running application development, 適用于長時間運行應用程序開發(fā)的 Harness 設計, 2026-03-24, https://www.anthropic.com/engineering/harness-design-long-running-apps

　　2、OpenAI, Harness engineering: leveraging Codex in an agent-first world, Harness 工程：在智能體優(yōu)先的世界中利用 Codex, 2026-02-11, https://openai.com/index/harness-engineering/

　　3、Mitchell Hashimoto, My AI Adoption Journey, 我的 AI 應用之旅, 2026-02-05, https://mitchellh.com/writing/my-ai-adoption-journey

　　4、OpenAI, Unlocking the Codex harness: how we built the App Server, 解鎖 Codex 的 Harness：我們?nèi)绾螛嫿?App Server, 2026-02-04, https://openai.com/index/unlocking-the-codex-harness/

　　5、Anthropic, Effective harnesses for long-running agents, 適用于長期運行 Agents 的有效 Harness, 2025-11-26, https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents