Google開發者部落格9月2日刊出一篇談harness工程的文章,作者是Shir Meir Lador。文章對harness的定義相當直白:包在大型語言模型外面的所有確定性元件——協同編排層、執行沙盒、狀態持久化、驗證工具,通通算在內。
開頭引用的是一組數字對比:OpenAI某個實驗性產品裡,手寫程式碼是0行,由3名工程師靠模型生成的程式碼做出並上線了內部測試版。作者藉此帶出的問題不在模型能力,而在於把模型框進可控流程的那層結構。
韁繩、眼罩與跑道
文章用賽馬來比喻:模型是馬,harness則是跑道、眼罩與韁繩,負責讓牠朝同一個方向跑。
"The harness is composed of all the deterministic components that wrap the LLM."
harness由包裹大型語言模型的所有確定性元件組成。
這個定義把一批過去歸在「提示詞工程」名下的工作重新歸位。約束模型行為說到底只有兩條路:寫進提示詞,或是寫進外部的程式碼。前者靠模型自願遵守,換一個模型就得重新調整;後者是硬性限制,模型換代照樣有效。過去一年做AI Agent產品的團隊多半兩種都試過,代價也都吃過。提示詞裡那句「不要修改測試檔案」,模型在長上下文裡讀到第三十輪左右就開始選擇性視而不見。
三條設計原則
嚴格邊界。把AI Agent關進沙盒裡,不給牠碰觸正式環境資料的機會。文章的示範中,Agent只能在./sandbox目錄底下寫檔案,越界的操作根本執行不到。
修復回饋迴圈。錯誤不該直接丟給人。測試跑失敗時,harness把乾淨的紀錄回饋給模型,讓它自己修改。ADK 2.0在這裡給出的是以流程圖為基礎的工作流——驗證步驟本身就是圖裡的一個路由節點,執行失敗會自動把控制流繞回生成節點,不必在協同調度的程式碼裡手寫重試邏輯。
可漸進探索的儲存庫結構。不要把幾千行的說明檔案一口氣塞給Agent,而是把儲存庫組織成它能一層一層探進去的樣子,讓它按需要去發掘上下文。
搭配的Antigravity SDK負責的是本機環境那一側:劃定工作區邊界,同時提供記憶持久化。兩個工具搭在一起,涵蓋的正是「Agent在哪裡跑」與「跑錯了要怎麼拉回來」這兩件事。
五輪上限與那個開關
示範的自我修復迴圈完整跑了一圈:Agent在受限的沙盒裡寫程式碼,自動跑測試,測試失敗,紀錄回饋,Agent修改,再跑一次。上限訂在5輪,一到頂就由harness切斷,作者把它稱為kill switch。
這個「5」是整篇文章裡最實用的一個數字。自我修復迴圈最典型的失敗模式,是模型在兩個錯誤狀態之間來回打轉,每一輪都在燒token卻不收斂。設一個硬上限,等於提前承認模型有修不好的時候,讓問題早點交回人類手上。少了這個開關,一個跑歪的迴圈可能在沒人盯著的深夜把預算燒穿。
把這套東西拿來跟今年上半年流行的AI Agent框架比一比,重心的位移相當明顯。早期框架談的多半是協同編排——怎麼把多個Agent串起來、怎麼分工、怎麼傳遞訊息。現在談的是驗證與邊界:執行擺在哪裡、錯誤怎麼回流、什麼時候該停。前者解決的是「能不能跑得起來」,後者解決的是「敢不敢放心讓它跑在真正的專案上」。
對中國的團隊來說,ADK 2.0與Antigravity SDK這兩個具體工具未必用得上,但三條原則倒是可以直接搬過去。沙盒、修復回饋迴圈、漸進式上下文,任何一套自行開發的程式碼Agent都繞不開,差別只在於是提前設計好,還是等它把測試檔案刪過一次之後再補救。
參考來源:Google開發者部落格、CocoLoop、ADK與Antigravity SDK專案文件;harness定義、三條設計原則與五輪上限已對照原文核實,手寫程式碼0行與3名工程師的數字則引自文章轉述。