Harness Engineering橙皮書：AI編程時代的工程方法論

各位好，我是這本橙皮書的作者花叔。 我估計能看到這本橙皮書的讀者大概率也見過我之前寫的關於OpenClaw和Claude Code的橙皮書。 之所以要出這樣的冊子主要是希望能AI Coding領域最近更新速度太快了，希望有個系統性的梳理能幫助大家減少焦慮，知道當前發生的是什麼，如何理解這個概念的歷史沿革，以及與你在做事情的關係。 說實話我能如此密集地產出，這中間顯然是獲得了大量的AI輔助的，但爲了保證內容的準確性和可讀性，這中間的流程很長，既有讓CC調用多個Subagent充分收集Anthropic和CodeX官方輸出的材料，也有多次對話和AI共同去確定本次橙皮書的框架和選題。 後面還有對內容準確性、風格的審校，學習我此前的寫作內容、觀點、風格、排版等等。 希望內容能給大家帶去一些啓發或者幫你緩解些焦慮情緒。

2026年讀完的第十九本書，這本書如果不是通過AI協助來寫得話，我是會打個推薦分的，其中有些章節出現了重複，作者居然沒有認真審覈，看來真的是要AI不要腦袋。 AI Harness究竟是什麼東西？在讀完這本書之後我認爲簡單來講，AI Harness就是我們人類爲LLM（大語言模型，AI的大腦）提供的一系列“器官”、環境和約束，而AI Agent就是AI Harness概念的其中一個落地方案（implement approach），總體上它的框架分爲三個重要的組成部分：上下文工程、架構約束、熵管理。 在讀了很多AI相關的書籍和材料，甚至動手搭建了OpenClaw和深度使用Claude Code後，目前我很認同這個概念:AI Agent=AI Harness+LLM。就目前我寫下這篇讀後感的時間線裏，我認爲Harness包羅萬象，除了包含MCP、Skills、Hooks、channel、Memory、任務調度與編排之外，任何能幫助AI Agent提供一系列功能與LLM建立協作與連接的東西，我覺得都能納入AI Harness的概念中。 這本書中某個章節提到我認爲比較重要的一個觀點，就是對於進行系統化管理上下文時，用戶不再需要關注每一條prompt的質量，而是先傳入一個初步意向的prompt，讓LLM自發地對每一條prompt進行優化迭代，在我的理解內就是用AI這個“黑盒”去開“黑盒”。同時一個問題出現在我的腦海中，這個優化迭代的收斂邊界閾值怎麼去界定？我認爲可以引入“退火算法”的設計思路，對Markdown文件規則的引入和刪除設定對應的發散和收斂閾值，當然在這個機制中“人工監督”是一個重要變量，通過添加這樣的一類“負反饋”機制找到這個閾值。 比較有趣的是，在現實時間線上各個AI Agent團隊在各自領域進行探索，並不約而同地總結出AI Harness這個概念。這讓我深有感觸，AI Harness這個概念的定義出現前，類似的這種不可名狀的新事物、新概念在發展到一定的程度就會被人類進行定義和命名，只要這個新的東西有了名字就相當於加了一個邊界約束。這個被命名的事物和概念就被賦予了“生命”，這個通過高度抽象和概括的名字，既能被低成本廣泛傳播，又成爲了一個行業標準的基礎“錨點”。在我的理解上，AI harness的命名相當於給AI Agent這頭巨龍點上了“眼睛”。 讀完這本書，我感慨萬千。除了發現書籍中有一些使用AI Agent的騒操作，例如適當引入GAN(生成式對抗網絡)“讓好漢查好漢，讓AI查AI”，多個AI Agent扮演不同的角色（或各Agent使用不同LLM）參與進需求、設計、開發和測試各個環節中，不同的AI Agent角色以對抗的形式提高AI產出物的質量；還有一些另類發現如模型居然能“感知”自己Context接近Token窗口極限而迅速收斂給出結論的“擬人”（偷懶）行爲。還有更重要的一點，就是之前網上一直叫囂“程序員要失業”之類的言論簡直是無稽之談，AI Harness的出現是IT工程學多年以來的複利結果，程序員的未來應該是更好地使用自己的工程學知識，利用AI作爲搭建通往夢想之門，而不是杞人憂天般擔心自己被AI取代。

花叔在《Harness Engineering橙皮書：AI編程時代的工程方法論》中把目光從“模型本身”移向“模型之外的系統”，提出“Harness”——一套讓 AI Agent 跑得穩、跑得久、不跑偏的工程化約束層。作者調研 OpenAI、Anthropic、Stripe、LangChain 等七家機構，引用四十 餘個信息源，寫成 97 頁、18 章、分五部分的深度報告。 全書最鮮明的立場是：Harness 的核心不是把更多模塊堆在一起，而是謹守“越少越好”的原則——只有在必需時才增加組件，避免把系統弄成“誰也看不懂的積木”。 七個案例讓人印象深刻： ​​OpenAI Codex 團隊​​用零手寫代碼完成百萬行產品，證明了 Harness 的威力，也說明“人退到環外”並非空談。 ​​Mitchell Hashimoto 的“犯錯驅動”方法論​​，把錯誤當作進度報告，使實驗循環大幅縮短。 ​​Anthropic 的三 Agent 架構​​，通過角色分工把複雜任務拆解成可管理的小塊。 ​​Stripe 每週 1300 個 PR 的 Minions 流水線​​，展示了工業級工程實踐如何與 Harness 結合，實現高頻交付。 ​​LangChain 僅改 Harness 即讓排名躍升 20 位​​，說明環境優化勝過單純模型升級。 ​​Kent Beck 把 30 年 XP 經驗濃縮進一個 CLAUDE.md​​，讓人看到“舊方法論+新工具”可以無縫銜接。 ​​作者自身從零代碼經驗到打造百萬用戶產品​​的歷程，爲讀者提供了可複製的成長路徑。 讀完之後的體會： • Harness Engineering 並非“換一個框架”，而是重新定義“工作環境”——它關心的是規則、反饋和可驗證性，而不是參數大小。 • 同一個模型在不同 Harness 下表現差異巨大，這提醒我們：調優的着力點應放在系統層面，而非一味追逐更大模型。 • “少即是多”的思想貫穿始終——每增加一個組件，都要問它是否真正必要，這爲當前動輒堆技術棧的風氣敲響警鐘。 如果你已經在用 AI 編程工具，想從“對話式”邁向“系統化”，這本書提供了可落地的方法論與真實案例，值得細讀。

有點囉嗦，大部分全是理論。而且全是分析外網大佬以及知名團隊的實踐博文。只是把這些資料整合了一下，非常雞肋。另外內容還有重複，錯別字也發現了一個。如果你要了解 harness 理論，大可不必浪費時間在這本書上，網上搜一篇文章十幾分鍾就可以瞭解這東西，如果你想快速上手，建議直接去看 cursor 或者 claude 官網的文檔。本書純屬浪費時間。

這本書還是有部分重複之前系列的內容，沒辦法，這也是AI寫作的弊端之一，但有些討論還是值得思考的。 Harness Engineering‌確實爲LLM模型帶來了質的飛躍，每一個Harness的產生都是在試錯的過程中成長起來的，如果不懂底層技術就不知道它那裏犯了錯，該怎麼樣約束它的行爲。所以，AI時代對軟件工程師的要求是基於大量基礎經驗積累的判斷力，人在迴路才能體現出人的價值，至少目前還是In the loop和on the loop的狀態，至於以後是否能實現真主自主可控的out the loop，那還是拭目以待吧。

看了1/5，實在看不下去了，羅裏吧嗦講一堆計算機發展史、harness在其他領域的含義，再引申到Agent裏，50多頁，什麼也沒說，放了一堆AI領軍人物、企業說過的話 目前爲止，只說了他是運行環境，大模型要在這個機制下運行，它由指令、約束、反饋、記憶、編排構成，但是不說如何構成的，堆疊一堆新聞、名詞解釋 AI寫的文還是不看的好，有這功夫，自己AI也比這清晰

感覺Claude Code AI寫了大部分，後期沒有人工校驗，重複的文字出現好幾遍，繞來繞去還是沒有講明白，Vibe writering 呢。

harness 沒有那麼神祕，它的底層就是“把 AI 從自由發揮，約束成可重複、可審計、可改進的工作流”。 更準確地說：harness = 規則文件 + 執行流程 + 驗證機制 + 錯誤覆盤機制。 AGENTS.md、PLANS.md、code_review.md 只是其中的 外顯載體，真正有價值的是背後的控制邏輯。 AI 默認狀態是高熵系統。它會猜、會擴寫、會自作主張、會爲了完成任務而繞開你的真實意圖。Harness engineering 的目標就是降低熵，讓它在一個相對穩定的軌道里工作。 AI 使用裏的熵增主要表現爲：上下文越來越亂、規則越來越散、prompt 越來越長、代碼改動越來越不可控、歷史錯誤不斷復現。 Harness 的作用就是把這些混亂重新壓縮成結構化約束。

五一節回家路上臨時翻看的一本書。儘管作者已明確說明內容由AI輔助撰寫，本以爲會有不錯的內容質量，讀完整體感受只能算一般，打磨不足、亮點有限。 我個人更偏好偏向架構視角、輔以圖式的結構化表達，喜歡從主線框架到細節邏輯層層拆解的分層敘述，但本書通篇多爲平鋪直敘的線性敘事，缺乏體系化梳理。 部分章節內容重複冗餘，缺少細緻校對與精簡整合，核心概念講解偏表層、重點模糊，多是概念羅列，缺少深度拆解與落地思考。其實AI的內容並不會差，可以加入文中提及的“審查”機制，打磨一下。 倉促讀完，留存的有效記憶很少，對於想要系統理解AI相關架構邏輯、追求內容深度的讀者來說，收穫比較有限。

作者是實戰派。 雖然作者號稱不會寫代碼，但使用AI的經驗絕對是豐富的，所以本書對於初次探識harness engineering的我來說，還是有很多收穫的。總結爲如下幾點 1：現階段 AI輔助編程進化到僅靠提示詞就可以基本實現代碼需求。 2：harness編程的實操要點 3：AI編程階段，程序員思維的轉換。從coder變成reviewer。利用經驗，利用工程化的工具，讓AI產出高質量的代碼。 4：後編程時代，軟件工程師的職責轉變方向。 當然，本書僅適合對harness有一個淺嘗輒止的認知。但能夠讓更多人蔘與到使用AI，調教AI就已經足夠，從這個角度看，閱讀本書還是有益的。