2026 年 2 月，"Harness Engineering"這個詞在 AI 工程圈突然火了。Mitchell Hashimoto 首先命名了這個實踐，OpenAI 跟著發(fā)了一份百萬行代碼的實驗報告，Martin Fowler 補上深度分析——短短幾周，它就成了繞不開的話題。

這個術(shù)語背后的東西其實一句話就能說清：Agent = Model + Harness。模型負責(zé)推理，剩下的全部是工程——工具系統(tǒng)、上下文管理、權(quán)限控制、反饋回路。過去大家以為瓶頸在模型不夠聰明，現(xiàn)在發(fā)現(xiàn)錯了：瓶頸在外圍工程。

一、模型智力已過線，真正的問題是工程

2024 年我們還覺得自己比 GPT 聰明，2025 年開始承認模型比自己高明，到 2026 年模型的推理能力已經(jīng)遠超普通人類水平。繼續(xù)卷模型，普通人已經(jīng)感受不到差異了。

關(guān)鍵問題從"模型夠不夠聰明"變成了"能不能幫我把事兒做成"。

有個實驗很說明問題：Can.ac 僅僅改了 Grok Code Fast 1 的工具接口格式，編碼基準分數(shù)就從 6.7% 跳到了 68.3%。沒有動任何模型權(quán)重，只改了 Harness。LangChain 也通過 Harness 改進，在 Terminal Bench 2.0 上從第 30 名飆到第 5 名。

DeepMind 的 Agents 團隊做了更直接的驗證：固定模型不變，只換 Harness（也就是模型外圍的基礎(chǔ)設(shè)施），性能就產(chǎn)生了巨大差距。Claude Code 的商業(yè)價值蒸蒸日上，它的本質(zhì)就是在做 Harness 工程。

二、上下文窗口不是越大越好

給 Agent 塞一堆 MCP 工具、冗長文檔和對話歷史，不會讓它變聰明——只會讓它變笨。

Dex Horthy 給了量化數(shù)據(jù)：以 168K token 的上下文窗口為例，用到大約 40% 就開始走下坡路。前 40% 是 Smart Zone——推理聚焦且準確；超過這個閾值就是 Dumb Zone——幻覺、死循環(huán)、格式錯誤的工具調(diào)用齊上陣。

Anthropic 的 Carlini 在 C 編譯器項目里花了大量精力做"上下文污染緩解"：日志寫文件不輸出控制臺、用 grep 友好的錯誤格式、預(yù)計算聚合統(tǒng)計而不是甩原始數(shù)據(jù)出來。原因很簡單——上下文一旦爆了，Agent 直接掉進 Dumb Zone。

經(jīng)驗公式記住一條就夠了：上下文利用率保持在 40% 以下。更多 token 不等于更好結(jié)果。

三、什么是 Harness？

馬具的隱喻

"Harness"本意是馬具——韁繩、鞍具那一套。LLM 就像一匹蠻力十足但方向感不太行的馬：跑得快，但容易跑偏。不加 Harness 的 Agent 像草原上的野馬，Harness Engineering 就是給它套上韁繩：讓人類能穩(wěn)穩(wěn)騎乘，同時確保馬往正確的方向跑，陷進泥潭時能把它拉出來。

三層工程的關(guān)系

很多人會把 Prompt、Context、Harness 混為一談。它們是嵌套關(guān)系，層層遞進：

• ? Prompt Engineering——告訴模型"做什么和怎么做"
• ? Context Engineering——讓模型"做得更好"
• ? Harness Engineering——確保模型"可控地做"

Phil Schmid 的比喻最到位：模型是 CPU，Harness 是操作系統(tǒng)。 CPU 再強，OS 拉胯也白搭。

四、Harness 的四大支柱

OpenAI、Anthropic、Carlini 等多個獨立團隊的實踐反復(fù) converged 到四個共同模式。

1. 上下文分層：恰好夠用，不多不少

每個團隊都發(fā)現(xiàn)：把所有指令塞進一個文件根本沒法擴展。解決方案是分層加載、漸進披露。

OpenClaw 的 Skills 機制是個好例子。默認不加載所有技能的詳細內(nèi)容，先掃描技能列表（只看名字和描述），判斷需要用哪個再去讀對應(yīng)的 SKILL.md。既省了上下文空間，又保持了靈活性。

OpenAI 的做法類似：從單個巨大的 AGENTS.md 遷移到分層架構(gòu)，構(gòu)建小型入口文件指向深層的事實源（設(shè)計文檔、架構(gòu)圖、執(zhí)行計劃）。一個后臺 Agent 定期掃描過期文檔并提交清理 PR——由 Agent 為 Agent 維護的文檔。

2. Agent 專業(yè)化：專才優(yōu)于通才

專注于特定領(lǐng)域、擁有受限工具的 Agent，永遠比擁有全部權(quán)限的通用 Agent 靠譜。

這不是純組織考慮——專業(yè)化本身就是上下文管理策略。每個專家攜帶更少的無關(guān)信息，所以天然運行在 Smart Zone 內(nèi)。

Carlini 的 C 編譯器項目把 Agent 分為四類角色：編譯器核心、去重、性能優(yōu)化、文檔。LLM 生成的代碼經(jīng)常重新實現(xiàn)已有功能，他專門分配了一個"去重 Agent"來解決。Vasilopoulos 部署了 19 個領(lǐng)域特定的 Agent。

3. 持久化記憶：狀態(tài)存在文件系統(tǒng)上，不在上下文窗口里

每次新 Agent 會話從零開始，通過文件系統(tǒng)制品重建上下文。就像一個項目組全是輪班工程師——每個人上崗時對之前的進展一臉懵，只能靠交接文檔恢復(fù)狀態(tài)。

Anthropic 的兩階段方案很經(jīng)典：初始化 Agent 建立 init.sh、進度文件和初始 git 提交；后續(xù)編碼 Agent 每次做出增量進展后留下結(jié)構(gòu)化更新。關(guān)鍵發(fā)現(xiàn)是：用 JSON 追蹤 feature 狀態(tài)比 Markdown 更有效，因為 Agent 不太會不小心破壞結(jié)構(gòu)化數(shù)據(jù)。

OpenClaw 的雙層記憶也值得參考：長期記憶（MEMORY.md，每次自動注入）+ 每日記憶（追加寫入、按需搜索），檢索用 BM25 + 向量雙路召回，還有時間衰減機制。

4. 結(jié)構(gòu)化執(zhí)行：先規(guī)劃，再動手

Boris Tane 說得最干脆："永遠不要讓 Agent 在你審查和批準計劃之前寫一行代碼。"

把思考與執(zhí)行分開：理解 → 規(guī)劃 → 執(zhí)行 → 驗證。Anthropic 把這個做到了極致——初始化 Agent 先生成超過 200 個功能的結(jié)構(gòu)化列表，全部標為 failing，后續(xù) Agent 每次只處理一個，完成后提交 git 和進度更新。

Huntley 的 Ralph Wiggum Loop 提供了反壓思路：上游給確定性設(shè)置和一致上下文，下游用測試、類型檢查、Lint、CI 拒絕無效工作。

五、五大落地難題與解法

無限循環(huán)

Agent 遇到無法解決的錯誤時，可能在同一個死角無限重試。

解法： 上下游反壓機制。上游保證輸入確定，下游通過測試和 CI 拒絕無效工作。Claude Code 的循環(huán)在執(zhí)行完一輪后會確認問題解決才返回結(jié)果，不會無腦重來。

上下文爆炸

一味堆 Prompt、歷史記錄和工具返回結(jié)果，推理耗時劇增、成本飆升。

解法：** 壓縮 + 修剪 + 記憶分層。OpenClaw 支持三種壓縮策略自適應(yīng)切換，工具返回結(jié)果頭尾保留中間省略（裁剪不超過 50%），長期記憶按需注入、每日記憶搜索獲取。

權(quán)限失控

Agent 刪文件、調(diào)外部 API 時缺乏審批或熔斷。

解法： 三層縱深防御——沙箱 + Hook + 權(quán)限分級。OpenClaw 的文件系統(tǒng)沙箱限范圍、命令執(zhí)行白名單 + 人工確認、網(wǎng)絡(luò)白名單。Hook 系統(tǒng)可以在工具執(zhí)行前攔截校驗參數(shù)：比如阿里云 ECS 實例 ID 必須以 i- 開頭，通過正則校驗直接攔住錯誤參數(shù)，迫使模型修正而不是盲目執(zhí)行。

質(zhì)量不可控

Agent 寫完代碼就跑個單元測試，壓根沒做端到端驗證。

解法： 強制測試閉環(huán) + CI 流水線。OpenAI 的自定義 Linter 不僅標記違規(guī)，還在錯誤消息里直接告訴 Agent 怎么修——工具在 Agent 工作時順便教會它。Carlini 的總結(jié)很到位："我必須不斷提醒自己，我是在為 Claude 寫測試框架，不是為自己寫。"

成本不透明

上下文塞滿導(dǎo)致 token 消耗飆升，效果反而下降。

解法： 控制在 40% 利用率以內(nèi) + 可配置壓縮模型 + KV Cache 優(yōu)化。OpenClaw 支持用便宜模型做上下文壓縮，壓縮操作設(shè)超時防止卡死。

六、頂級團隊的實戰(zhàn)

OpenAI：零手寫的百萬行代碼

三名工程師五個月構(gòu)建百萬行代碼產(chǎn)品，手寫代碼 0 行，合并約 1,500 個 PR，效率提升約 10 倍。

核心原則就幾條：設(shè)計環(huán)境而非編寫代碼（Agent 卡住時診斷缺什么能力讓它自己補上）、依賴方向用 Linter 機械化 enforce、所有知識放代碼倉庫當唯一事實源（Slack 和 Google Docs 對 Agent 等于不存在）、對抗熵（最初每周五手動清理 AI Slop，后來自動化為后臺任務(wù)）。

Anthropic：16 個 Agent 造 C 編譯器

兩周、16 個并行 Opus 4.6 實例、約 2,000 次 Claude Code 會話、產(chǎn)出 10 萬行 Rust 代碼。GCC torture test 通過率 99%，能編譯 PostgreSQL、Redis、FFmpeg、CPython、Linux 6.9 Kernel 等 150+ 真實項目，總 API 成本約 $20,000。

幾個關(guān)鍵設(shè)計：日志寫文件不占上下文、確定性測試子采樣解決 Agent 時間盲區(qū)、四類專業(yè)化分工。

Stripe：推個 Slack 任務(wù)就走的無人值守

開發(fā)者發(fā)個 Slack 任務(wù)就離開，Agent 從寫代碼、跑 CI 到提 PR 全程包辦，人只在最后審查環(huán)節(jié)介入。Toolshed MCP 提供近 500 個工具，隔離的 Devbox 環(huán)境與人類工程師用同樣的開發(fā)環(huán)境。核心洞察：Agent 需要和人類工程師一樣的上下文和工具——不是事后補上的集成，而是一開始就得是一等公民。

Hashimoto 的 Ghostty：每天最后的 30 分鐘

AGENTS.md 的每一行對應(yīng)一個過去的 Agent 失敗案例——現(xiàn)在被永久預(yù)防。工作模式：每天最后 30 分鐘啟動 Agent，讓它非工作時間干活，第二天早上拿到"暖啟動"的成果開始上班。

七、Harness vs Workflow：主導(dǎo)權(quán)之爭

很多人問：Workflow 也能約束 Agent，為什么要搞 Harness？

區(qū)別在于主導(dǎo)權(quán)是誰。Workflow 把大模型當成節(jié)點，按預(yù)設(shè)流程 A→B→C 執(zhí)行；Harness 把大模型當成主體，給它自主決策的空間但套上韁繩?；A(chǔ)模型越來越強的當下，Harness 更能發(fā)揮模型能力，同時確保不過失。

八、業(yè)界共識與分歧

六大共識

1. 1. 瓶頸在基礎(chǔ)設(shè)施，不在模型智能。 Can.ac 改 Harness 就讓分數(shù)翻倍是最直接證據(jù)。
2. 2. 文檔必須是活的。 AGENTS.md 每一行對應(yīng)一個歷史失敗案例，后臺 Agent 定期清理過期內(nèi)容。
3. 3. 思考與執(zhí)行必須分離。 所有團隊獨立發(fā)現(xiàn)了"先規(guī)劃再執(zhí)行"模式。
4. 4. 上下文不是越多越好。 40% 甜區(qū)有量化數(shù)據(jù)支撐。
5. 5. 約束必須機械化。 "不能機械執(zhí)行的規(guī)則，Agent 一定會偏離。"
6. 6. 工程師角色在變。 從寫代碼轉(zhuǎn)向設(shè)計環(huán)境和管理。

三大空白區(qū)

這些方向最值得探索：

• ? 棕地改造： 所有成功案例都是綠地項目。十年歷史的遺留代碼庫怎么引入 Harness？零方法論。Martin Fowler 打比方："在從沒跑過靜態(tài)分析的代碼庫上跑靜態(tài)分析——你會被警報淹沒。"
• ? 行為驗證： 大家擅長約束 Agent 不做錯事，但驗證 Agent 做對了事遠未解決。
• ? 長期可維護性： 怎么防止"功能沒問題但維護性很差"的代碼滲進代碼庫？沒人回答。

九、30 年軟件工程的一條暗線

Harness 的出現(xiàn)不是偶然?；仡櫲?，工程師一直在跟系統(tǒng)復(fù)雜度打架：

• ? 1994 GOF 設(shè)計模式 → 駕馭對象復(fù)雜性
• ? 2002 企業(yè)應(yīng)用架構(gòu)模式 → 駕馭架構(gòu)復(fù)雜性
• ? 2010 微服務(wù) → 駕馭分布式復(fù)雜性
• ? 2017 DDIA → 駕馭數(shù)據(jù)系統(tǒng)復(fù)雜性
• ? 2026 Harness → 駕馭智能體不確定性

貫穿三十年的不變主題是抽象。加上結(jié)構(gòu)化，把混亂中的本質(zhì)拎出來——設(shè)計模式是抽象，微服務(wù)是抽象，云計算是抽象，Harness 也是抽象。

我們第一次在駕馭一個不確定性的系統(tǒng)。 以前的復(fù)雜系統(tǒng)都是確定性的——代碼寫什么就執(zhí)行什么。Agent 不同，它是概率機器，你期待一個輸出，但它不一定照做。Harness 就是那條韁繩。

十、工程師的能力轉(zhuǎn)型

工程師不會失業(yè)，但碼農(nóng)會。

碼農(nóng) = 只寫代碼的人。Agent 能生成代碼，碼農(nóng)的價值就被替代。

工程師 = 能設(shè)計并駕馭復(fù)雜系統(tǒng)的人。核心能力不在寫代碼，而在三件事：理解系統(tǒng)復(fù)雜性、抽象和結(jié)構(gòu)化思維、駕馭不確定性。

業(yè)務(wù)理解是你的護城河。不是 Agent 能做什么，而是你懂什么決定了你能設(shè)計和駕馭什么。在 AI 時代，個體需要懂的更多而不是更少。

十一、立即可做的八件事

1. 1. 創(chuàng)建并維護 AGENTS.md——每次 Agent 犯錯就更新一條，不是一次性文檔
2. 2. 代碼倉庫當唯一事實源——團隊知識版本控制，別放 Slack 或 Wiki
3. 3. 構(gòu)建帶修復(fù)建議的自定義 Linter——工具教 Agent 怎么修
4. 4. 提供端到端測試工具——瀏覽器自動化顯著提升驗證質(zhì)量
5. 5. 增量執(zhí)行——每次會話處理一個功能，完成后提交 git 和進度
6. 6. 分層管理上下文——Tier 1/2/3 漸進式披露，避免單文件堆疊
7. 7. 上下文利用率控制在 40% 以下——更多 token 不代表更好結(jié)果
8. 8. 定期垃圾回收——自動化 Agent 清理技術(shù)債

"AI 編碼的興起并沒有取代軟件工程的工藝——它抬高了工藝的門檻。" —— Addy Osmani

凡此過往，皆為序章。模型越強，Harness 越重要。與其等更強的模型出來，不如先把韁繩套上馬背。