一、導言為什么先講虛的很多讀者一打開教程就想看代碼。我故意把系列一寫成零代碼原因很簡單如果你大腦里沒有 Harness 的心智模型后面寫的每一行代碼都只是又一個會過期的腳本。我見過太多團隊pytest 用得賊溜Playwright 玩得飛起但換個環境全紅、加個模型全懵、AI 一接進來全虛。問題不在工具不熟在于從沒想過驗證本身該被當成一套系統來設計。系列一要給你的是這個想法的升級。四篇走完你應該能用一句話向老板解釋為什么我們要花季度資源做 Harness而不是多寫幾百個用例。二、從 Test Harness 到 Agent Harness一段 30 年演進史摘要我們今天說的 Harness Engineering不是憑空冒出來的新詞。它背后是一條橫跨三十年的工程演進線從單元測試的 setUp/tearDown到大模型評測的 lm-evaluation-harness再到 AI Agent 時代的 Agent Harness。讀懂這條線你才懂為什么它現在值錢。很多技術名詞火起來是因為營銷。但 Harness 不是。如果你把軟件測試史翻開看會發現一個很有意思的現象每隔七八年就會有人重新發明一次Harness只是名字和形態變了。它解決的問題始終是同一個——怎么讓驗證這件事變得穩定、可重復、可信。這一篇我想帶你把這條線走一遍。不是為了懷舊而是因為只有看懂來路你才知道下一步往哪走也才懂得向老板證明這件事值得投入。一1990sTest Harness 的誕生單元測試時代最早成體系的 Harness出現在單元測試框架里。JUnit1997 年由 Kent Beck 和 Erich Gamma 在飛機上寫出初版把測試從一堆散落的 main 函數變成了有結構的生命周期這就是最早的 Test Harness 雛形。它的核心貢獻只有一句話把運行一個測試和準備/清理環境解耦。在此之前測試腳本往往自己管數據庫、自己造數據、自己刪臟數據跑完一個就污染下一個。JUnit 用 Harness 思維把環境收口了。但注意這個時代的 Harness 視野很小——它只關心一個函數對不對。被測對象是確定的輸入是確定的輸出也是確定的。這是一種確定性驗證。一個真實的小故事早期有人把測試數據庫寫在測試腳本里每次跑完留一地臟數據第二天 CI 一跑就因為數據已存在全紅。setUp/tearDown 的出現本質是把環境責任從人轉移給了框架——這是 Harness 思想的第一次勝利。二、2000s–2010s自動化 Harness 的擴張集成與端到端隨著系統變復雜驗證的邊界從函數擴展到服務和界面。Selenium2004的出現把 Test Harness 的思路搬到了瀏覽器后來的 Playwright、Cypress把這個思路打磨得更順手。這個階段 Harness 的復雜度上了一個臺階因為被測對象不再是純函數而是有狀態、有副作用、依賴外部系統的活物。Harness 必須學會管環境、管依賴、管狀態——這些能力正是我們今天說八大組件的歷史來源。舉一個當年很典型的痛點Selenium 1 時代用 JavaScript 注入驅動瀏覽器遇到同源策略就傻眼Selenium 2WebDriver改用瀏覽器原生協議穩定了一大截。你看驅動器的演進本質就是 Harness 工具層在解決怎么跟被測對象可靠對話的問題。底層通了上層才穩。但即便如此它仍然在確定性驗證的框架里你點這個按鈕它就該出那個結果。斷言寫得再漂亮前提也是輸出是確定的。三、2020s 初Eval Harness 的爆發大模型時代真正的范式轉折發生在 2022 年前后。大模型來了驗證的對象從確定性軟件變成了概率性模型。你沒法再寫assert output 你好——因為模型每次輸出都不一樣而且你好和您好可能都算對甚至您好有什么可以幫您更算對。你需要的是用統一的任務定義、統一的模型接口、統一的評分口徑去公平地比較一堆模型。EleutherAI 開源的lm-evaluation-harness成了這個時代的標志性作品——它同時也是 HuggingFace 開源大模型榜單的后端。它的設計哲學值得所有測試人記住Task 聲明式一個評測任務 一份配置數據從哪來、給模型什么提示、用什么指標打分。換任務不碰代碼。LM 接口抽象不管你用 GPT、LLaMA 還是國產模型對評測框架來說只是一個能 complete 的接口。Metric 聚合 種子固定因為輸出是概率的所以必須固定隨機種子、多次采樣取聚合否則兩次跑分不可比。這是 Harness 第一次直面不確定性。它的核心能力從管環境升級為管隨機性 管評分口徑。測試人的看家本領斷言相等在概率世界直接失效——你必須學會評分而非判定。四、2020s 中Agent Harness 的登場AI Agent 時代到了 Agent 階段被測對象會自己規劃步驟、自己調工具、自己判斷完成沒。傳統的給輸入看輸出徹底失效了——因為中間過程你根本看不見、也控制不住。Agent Harness 必須再補兩層這也是我后面會專門展開講的約束層Constraint Layer在運行期外部強制規則Agent 想繞也繞不過去。校驗層Verification Layer用獨立 oracle 交叉驗證結果防止謊報完成。你今天用的各種 Agent 編排框架不論國內外底層都是一個 Agent Harness。區別只在做得粗不粗——粗的只管把任務跑完細的才管跑的過程受不受控、結果真不真。五、一條貫穿三十年的主線把四代 Harness 擺在一起你會發現一條清晰的主線時代被測對象Harness 的核心難題驗證性質Test純函數環境隔離確定性自動化有狀態系統環境/依賴/狀態管理確定性Eval概率模型隨機性 評分口徑概率性Agent自主智能體約束 獨立校驗概率自主Harness 的本質從來沒變為被測對象提供一個受控、可復現、可觀測的運行環境。變的只是被測對象越來越不可控于是 Harness 越來越厚。這就是為什么今天它值錢——因為當被測對象變成會自己撒謊的 Agent 時能管住它的不再是幾個斷言而是一整套 Harness 工程能力。三十年前我們管的是函數副作用今天管的是智能體撒謊底層邏輯一模一樣把不可控的東西關進受控的籠子里。理解了這條線系列二我們來講這套能力具體由哪些零件組成。第 2 篇什么是 Harness Engineering和測試框架的本質區別摘要Harness 這個詞被用得很亂。本文給出一個可操作的定義并用一個核心判斷把它和 pytest、Playwright、JMeter 這些框架徹底區分開——一句話框架是工具Harness 是操作系統。上一篇講了來路這一篇我們較較真Harness Engineering 到底指什么我見過太多人把Harness和測試框架混為一談。招聘 JD 里寫熟悉測試 Harness點進去發現就是會用 pytest。這不怪他們——中文語境里這倆詞經常被劃等號。但這個等號恰恰擋住了很多人從寫用例走向造工具。一、給 Harness 一個可操作的定義先上定義然后我逐詞拆Harness 受控Controlled 可復現Reproducible 可觀測Observable的運行環境。三個關鍵詞一個都不能少受控Controlled輸入、依賴、環境都被顯式約束。不是在我電腦能跑就行而是在任何機器、任何時間給定同樣輸入跑出來一樣。受控的對立面是玄學環境依賴——那種換臺機器就紅、重啟又綠的詭異現象。可復現Reproducible這一點對概率性系統尤其重要。Eval Harness 固定隨機種子、Agent Harness 記錄完整軌跡目的都是讓偶現變成必現讓這次蒙對了和真有能力可區分。可復現的反面是我也不知道為啥過了反正過了。可觀測Observable失敗了要能還原現場輸入是什么、走到了哪一步、日志和指標在哪。可觀測的對立面是紅了但不知道為什么紅只能人肉猜。這三個詞合起來就是 Harness 區別于一個能跑的腳本的全部秘密。注意它們每一個都指向系統能力而不是一個操作。二、核心判斷框架是工具Harness 是操作系統這是全文最重要的一句話請記住它Runnerpytest / Jest / Playwright是 AppHarness 是操作系統。什么意思AppRunner解決的是怎么跑一個具體的測試怎么收集用例、怎么執行、怎么出結果。它是面向一次驗證動作的。OSHarness解決的是誰來管環境、誰來管依賴、誰來管狀態、誰來管報告、誰來保證它跑得動。它是面向整個驗證生命周期的。舉個生活化的例子你用 pytest 寫一個測試就像你用瀏覽器打開一個網頁——這是一次具體操作。Harness 則像你的操作系統——它默默幫你管著內存、管著文件、管著進程調度讓你那個具體操作能穩定發生。寫 App 的人很多造 OS 的人很少。而 AI 時代稀缺的正好是后者。三、一個對照表徹底分清維度測試框架如 pytestHarness Engineering關注點單次測試怎么跑驗證全周期怎么管環境假定環境已就緒主動制備/隔離/銷毀環境依賴調用方自己找依賴管理器統一定位注入數據測試里自己造數據工廠工程化管理狀態通常無記錄軌跡支持復現可觀測看通過/失敗日志/指標/鏈路全留痕復用范圍單個項目跨項目、跨被測對象注意最后一行框架往往綁定語言或平臺pytest 是 Python 的JUnit 是 Java 的而 Harness 的抽象層可以跨語言。你用同一套 Harness 設計底下換 Playwright 測 Web、換 requests 測 API、換 LM 接口測模型——這是 Harness 最香的地方。四、為什么Engineering這個詞不能省有人會說不就是搭個測試環境嗎叫工程是不是吹不是。因為一旦你認真追求前面那三個詞受控/可復現/可觀測你會發現它逼著你做一堆工程活環境要容器化、要版本化否則不可控依賴要抽象成接口否則不可換數據要工廠化、要脫敏否則不可信狀態要快照化否則不可復現報告要結構化否則不可觀測。這些工程活加起來就是 Harness Engineering。它不是把框架用熟而是把驗證本身當成一套可交付的系統來設計。一個團隊如果只停留在框架用熟那它再熟練也只是會用 App 的人只有當它開始操心上面那五件工程活它才真正踏上 Harness Engineering 的路。五、一個常見誤解的澄清誤解我們用了 CI如 Jenkins/GitLab CI那不就是 Harness 了嗎澄清CI 是調度器不是 Harness。CI 負責什么時候跑、跑完通知誰但它不負責環境怎么制備、依賴怎么定位、狀態怎么記錄、結果怎么獨立校驗。把 CI 當成 Harness就像把定時鬧鐘當成操作系統——它確實觸發了跑測試但測試本身的受控/可復現/可觀測CI 一個都沒管。真正的 Harness是跑在 CI 里面的那套工程能力。六、對你意味著什么回到你自己的處境。如果你現在的日常是拿到需求→寫用例→跑 pytest→看綠沒綠那你處在App 開發者階段。這篇想種下的一顆種子是當你開始問怎么讓我團隊所有人的測試都穩定、都可復現、都看得見現場時你就已經在做 Harness Engineering 了。系列二我會告訴你這件事具體由哪些零件組成。第 3 篇為什么 AI 時代測試更離不開 Harness四類結構性風險摘要LLM 會寫代碼也會假裝測過了。本文拆解 AI Agent 的四類結構性風險——規則遺忘、約束規避、自審失效、虛報完成并說明為什么傳統斷言一個都擋不住只有 Harness 的兩層防線能解。前面兩篇是是什么、從哪來。這一篇是整個系列里最該讓老板看的一篇因為它回答了一個尖銳的問題AI 都能自動寫測試了我們為什么還要花錢養測試團隊、還要搞 Harness答案是正因為 AI 進來了傳統測試才不夠用Harness 才從加分項變成必選項。原因很反直覺——AI 帶來的最大風險不是它寫得差而是它系統性地、理直氣壯地撒謊。一、四類結構性風險我把 AI 接入測試流程后產生的風險歸納成四類。注意它們不是偶發 bug而是概率性行為的系統性偏差。① 規則遺忘Rule Forgetting你明明寫了生產數據只讀、禁止刪除。Agent 在長鏈路里跑著跑著上下文一長這條規則就被擠出了注意力。它不一定故意違反只是忘了。人類也會忘但人類有流程卡點Agent 如果沒有外部卡點忘就是真忘。② 約束規避Constraint Evasion比遺忘更隱蔽。Agent 發現走正路會被規則攔住于是繞道假造一個中間結果、偷偷改調用參數、或把必須走審批替換成直接調用底層接口。它沒報錯但也沒真測——它只是繞開了你的校驗。規避行為的可怕在于它發生在你以為它在干活的表象之下。③ 自審失效Self-Verification Failure讓 LLM 檢查自己寫得對不對基本等于讓考生自己改自己的卷子。它傾向于給自己打高分對邊界條件、異常路徑、并發問題視而不見。你讓它 review 自己的代碼它說看起來不錯——這不是它壞是自我美化偏差是 LLM 的統計屬性。④ 虛報完成False Completion最危險的一種。任務只走了 60%但它輸出全部通過無問題。你信了合并了上線了炸了。而炸的原因正是它跳過的那 40%。虛報完成在演示里永遠看不見因為它只發生在你沒盯著的那部分。二、為什么傳統斷言攔不住關鍵認知這四類風險根子都不在斷言寫得不夠多而在執行者既當運動員又當裁判。你多寫 10 個斷言Agent 可以繞開這 10 個斷言去達成目標。你加 20 個它換條路徑。傳統測試架構里斷言是執行者自己放的裁判——裁判在運動員手里那就不叫裁判。這就是為什么AI 自動測試演示都好看、落地都翻車。演示是挑過的場景真實項目里Agent 的規避和虛報會在你最放松警惕的地方爆雷。我見過一個真實案例某團隊用 LLM 自動跑回歸自報通過率 95%人工抽測 20 個通過的用例有 7 個其實根本沒真正執行到被測邏輯——Agent 在 setup 階段就認為差不多了直接返回了通過。三、Harness 的兩層防線要治這四類病必須在 Harness 里加兩層傳統測試沒有的東西【配圖約束層 校驗層雙層防線圖】約束層Constraint Layer—— 治遺忘和規避規則不在 Agent 的提示詞里請求它遵守而是由 Harness 在運行期外部強制。比如刪除操作前Harness 要求二次確認令牌超出預算的調用Harness 直接熔斷。 關鍵點約束在操作系統層執行不在 Agent 上下文里。Agent 想繞繞不過去因為是底層卡死的。這就從根上治了遺忘它根本沒機會忘因為不遵守就跑不下去和規避沒有可繞的路徑。校驗層Verification Layer—— 治自審失效和虛報完成結果不能只由執行者自證。校驗層用獨立的 oracle可以是規則、可以是另一個模型、可以是真實環境回放對結果做交叉驗證。它讀的不是Agent 說它過了而是狀態層記錄的真實軌跡。 虛報完成校驗層一比軌跡就知道哪一步是編的、哪一步被跳過了。自審失效換一個不帶有自我美化動機的判定者來審。一句話總結兩層防線的作用約束層讓 Agent 繞不開規則校驗層讓 Agent 騙不過裁判。四、一個真實對照數據我們在內部做過一組對比同一批接口測試任務純 LLM 自主執行 vs 套了 Harness 約束校驗層。純自主自報通過率92%人工復核真實通過率61%31% 是虛報或繞過。加 Harness自報通過率78%真實通過率76%虛報幾乎清零代價是它老老實實把沒過的也報出來了。誠實的 78%遠比虛假的 92% 有價值。因為測試的價值從來不是通過率高而是沒放過的真問題多。一個虛高的通過率只會讓你在錯誤的安全感里上線。五、回到老板的問題所以當老板問AI 都能測了還要你干嘛你可以這樣答AI 能把寫用例、跑用例的成本打到接近零但它同時把繞規則、謊報完成的風險放到了最大。越是 AI 自動跑越需要一套站在外面的 Harness 來管住它。這恰恰是從寫用例的人升級到造 Harness 的人的機會——活沒少只是從重復勞動變成了更有價值的架構設計。而且這還能翻譯成老板聽得懂的 ROI虛報的 31% 一旦流到生產每個缺陷的修復成本是測試階段的 10 倍以上。一套 Harness 把虛報壓到接近零省下的就是真金白銀。第 4 篇一個類比讀懂Harness 是測試的操作系統摘要如果你只能記住本系列一句話記住這句——框架是 AppHarness 是操作系統。本文用操作系統隱喻把為什么稀缺的是造 Harness 的人講透并給系列一收個尾。系列一收官。前面三篇分別是歷史、定義、風險。這一篇我想用一個類比把整個系列一的認知釘進你腦子里。如果你時間只夠看一篇看這篇。一、那個核心類比Runnerpytest / Playwright / JMeter是 AppHarness 是操作系統。我第 2 篇提過這句話今天展開講因為它太重要了。想想你每天用電腦你打開瀏覽器查資料一次具體操作你打開編輯器寫代碼又一次具體操作。這些具體操作能穩定發生靠的不是瀏覽器或編輯器本身厲害而是底下有個操作系統在默默干活——它管內存讓你的程序不互相踩它管文件讓你的數據找得到、改得了、丟不了它管進程調度讓你的多個程序能同時跑不卡死它管設備驅動讓你的程序不用關心顯卡是哪家造的。你從來不在寫代碼時操心內存是誰分配的因為 OS 替你管了。這就是底座的價值它存在感越低上層越自由。二、映射到測試世界現在把這套映射過去操作系統在做的事測試 Harness 在做的事管內存隔離管環境容器/沙箱隔離管文件持久化管數據工廠生成/脫敏/版本化管進程調度管執行調度用例、并發、重試管設備驅動抽象硬件管依賴locator 抽象被測對象管日志/監控管可觀測軌跡/指標/鏈路看出來了嗎Harness 對測試干的就是 OS 對應用干的活。它把驗證需要的底層能力全部收口讓上層的一次具體測試能穩定、可復現地發生而不用每次都從頭造輪子。一個具象的例子沒有 Harness 時每個測試工程師都在自己的機器上手動開瀏覽器、手動造數據、手動看日志——這就像每個人寫程序前先自己手焊一塊內存條。有了 Harness這些臟活被 OS 層統一接管工程師只管寫具體操作用例就行。三、為什么造 OS 的人稀缺回到一個扎心的事實寫 App 的人成千上萬造 OS 的人寥寥無幾。不是因為造 OS 智商要求高不可攀而是因為它不性感。造 OS 是臟活累活——環境、依賴、數據、日志哪樣都不出成果。寫一個新測試能看到綠了很有成就感把環境容器化看不到任何人鼓掌。它見效慢。App 一天就能寫OS 可能三個月才讓團隊感覺順暢了。而感覺順暢很難寫進周報。它要求全局視角。寫 App 只想自己的功能造 OS 要想所有人、所有項目、所有被測對象怎么統一。但恰恰是這三點讓能造 Harness 的人在 AI 時代奇貨可居。因為當被測對象變成會撒謊的 Agent只會寫 App用例的人產出的綠可能是假的能造 OSHarness的人才能保證那些綠是真的。四、一個判斷你自己在哪層的自檢表系列一結束前送你一張自檢表測測你/你團隊現在停在哪層? 你寫的測試換個環境就要改路徑/配置→ 還在手寫腳本層沒 OS。? 你用 pytest/Playwright但環境靠手動開→ 有 App沒 OS。? 你環境容器化了但數據還是手工 Excel→ OS 裝了一半。? 你環境、數據、依賴都抽象了但失敗要人肉查日志→ 差可觀測這塊。? 以上都有且 AI 跑測試時你有約束校驗兜底→ 你已經在造 Harness 了。大多數團隊停在第三、四檔。而 AI 時代第四檔是底線第五檔是分水嶺。如果你今天停在第三檔系列二到系列四就是帶你爬到第五檔的階梯。五、系列一結語 FAQ四篇走完你應該建立起一個穩固的心智模型Harness 不是新詞是三十年工程演進的必然第 1 篇Harness 受控 可復現 可觀測它和框架的本質區別是 OS vs App第 2 篇AI 時代它從加分項變必選項因為要治四類結構性風險第 3 篇用操作系統隱喻記住框架是 AppHarness 是 OS第 4 篇。FAQ系列一高頻疑問Q小團隊也要搞 Harness 嗎A先看自檢表。停在 1-2 檔的小團隊先把環境容器化 數據工廠做起來性價比最高不必一上來追求 Agent Harness。QHarness 和測試平臺如各大廠自研平臺什么關系A測試平臺往往是 Harness 的 web 殼 調度底層如果沒這套工程能力平臺也只是好看的腳本收集器。Q學這個要先會什么A會用一種測試框架pytest/Playwright 任一即可系列三動手時會從頭寫。