Better Harness 如何讓 AI 程式代理的工作流變得可檢驗

Qoder 在 2026 年 7 月 28 日宣布於 GitHub 開源 Better Harness。它不是用來評判某一次 AI 寫的程式碼「好不好」的單點評測器，而是檢視程式代理（coding agent）執行工作時，周邊整套工程流程是否可靠：任務說明是否清楚、權限與工具是否受控、測試與審查有沒有接上、交付是否可驗證，以及失敗經驗能否留下來供後續使用。125

換句話說，Better Harness 關注的是代理所處的「護欄與跑道」，而不只盯著它最後交出的程式碼差異（diff）。

什麼是 Harness？問題往往不只出在模型

Qoder 將代理周圍的工程環境稱為 harness。依其文件，這個環境可包含程式庫指示、規則、技能、hooks、外掛、連接器、腳本、測試命令、發版檢查與人工審查步驟等。2

即使模型能力很強，若工作流缺乏明確指引或可觀測性，結果仍可能不穩定。例如，專案雖然有測試指令，代理卻不知道何時該跑；規則檔雖然存在，卻沒有被代理採用；某次任務的教訓，也可能隨著工作階段結束而消失。Better Harness 的目的，正是找出這些流程上的斷點，而不是把「有一個設定檔」直接等同於「流程已經有效運作」。145

三層架構：從工程實務到可執行的改善循環

Better Harness 將 Harness Engineering、評估模型與可執行實作串成三層架構。5

1. Harness Engineering 實務層

第一層處理實際影響代理工作的機制，包括工作階段與 CLI 模式、可觀測性、規則、技能、MCP 設定、記憶、hooks 與自動化等。5

這一層要回答的其實是幾個很務實的問題：

• 代理是否得到明確的目標、限制與程式庫背景？
• 它的執行路徑與權限是否受到適當控制？
• 測試、檢查與審查是否真的連結到它所做的變更？
• 有價值的經驗能否沉澱成持續維護的專案資產？

Better Harness 會先描繪目前的 harness，包括目標、上下文、執行入口、回饋迴路、交付機制與學習紀錄方式。1

2. Agent Work Loop 評估層

第二層把上述工程實務轉成五個彼此相連的交付面向：任務理解、受控執行、變更驗證、可靠交付、學習捕捉。14

這改變了評估問題。重點不再是「代理有沒有產生看起來合理的程式碼」，而是：整個端到端流程能否反覆產出可理解、可控制、已驗證、可交付，且能從過往工作中受益的變更？

評估模型會尋找該迴路中的破口，例如缺少必要機制、整合未串起來、某步驟從未真正執行，或結果缺乏足夠佐證。1

3. 可執行實作層

第三層讓前兩層不只停留在原則或文件。Better Harness 透過程式代理執行，在支援的情況下蒐集專案與工作階段證據，產生已排序的改善建議與可驗證的下一步。4

Qoder 的現行資料稱支援 10 個宿主介接器；在開源時的報導中，明確列出 Claude Code、Codex、Qoder 與 Cursor 等程式代理環境。56 不過介接器支援範圍可能隨版本改變，特定宿主是否支援仍應以專案最新文件為準；目前提供的資料未能證實 OpenClaw 支援。

三類證據：把「設計上有」與「實際有做」分開

Better Harness 的特色之一，是將資料蒐集與最終判斷分離。Qoder 表示，其主要分析流程先蒐集原始資料，再交由 3 個獨立、唯讀的子代理分別檢視，最後才彙整結果。1

三種視角分別是：

• Project Harness（專案 Harness）：程式庫的工程基礎，例如指示、腳本、檢查與交付控制。
• Agent Customization（代理客製化）：代理專屬的規則、技能、hooks 與其他設定。
• Session Evidence（工作階段證據）：在可取得時，代理於真實任務中實際做過什麼的紀錄。

前兩者可以說明某項能力是否「具備條件」；工作階段證據則有助於確認代理是否在真實任務中正確使用了該能力。14

有測試，不等於測試真的守住了品質

這套框架最重要的原則是：工件存在，不等於它有效。

以自動化測試為例，專案裡有測試套件，只能證明具備潛在能力；它無法單獨證明代理在修改後跑了相關測試、正確解讀測試結果，或確實利用結果避免錯誤交付。規則、hooks、技能與核准關卡也是同樣道理。15

因此，Better Harness 嘗試讓證據鏈保持清楚。報告會把有支持證據的缺口整理成依優先順序排列的 findings（發現），並附上影響、預期輸出、範圍受限的修復方案與驗收檢查；缺少的證據會被明確保留，而不是悄悄轉換成看似精準的分數。46

對團隊而言，一項有用的 finding 至少應能說清楚：

1. 在專案、設定或工作階段紀錄中觀察到什麼；
2. 它為何影響交付迴路；
3. 建議採取何種有限範圍的修復，例如新增規則、技能、hook、腳本、自動化或人工核准；
4. 修復完成後，要如何重新驗證。

不只是稽核：檢視、修復、再量測

Better Harness 的定位不是一次性的健檢，而是一個反覆運作的改善循環：

1. 描繪現有 harness；
2. 找出工作流斷點與證據缺口；
3. 為有證據支持的問題建立範圍受限的修復任務；
4. 依預先定義的驗收條件驗證修復；
5. 再次執行檢視，觀察更新後的證據。14

這也是它所說「持續改善」的基礎：工具能呈現工作流是否已改變，以及新證據是否支持更好的評估。但這不代表它能自行證明某次修復在所有專案或所有代理宿主中，都因果性地提升了代理表現。Qoder 的材料強調可觀察到的證據與明確限制，而非把分數變化當作因果證明。46

如何看待「30 個真實 GitHub 專案」的初步檢視？

開源時的報導提到，該框架曾初步應用於 30 個真實 GitHub 專案。5 這較適合視為探索性的實作案例：它展示框架可用來找出不同程式庫反覆出現的 harness 缺口，而不是一項能證明 Better Harness 對每個代理、每個專案都有效的受控實驗。

現有第一方資料足以支持其證據模型、finding 結構與反覆修復流程；但提供的來源沒有足夠第一手細節，讓外界獨立檢視這 30 個專案的抽樣方式、評分方法或彙總成果。因此，若要將它與正式基準測試相比，或據此提出廣泛效能主張，仍須保持審慎。14

把 Harness Engineering 變成可討論的品質基礎設施

Qoder 更大的主張，是讓 Harness Engineering 成為 AI 輔助軟體開發的品質基礎設施：建立共享語言、可觀察證據、可比較的交付面向，以及可重複執行的改善循環。12

Better Harness 提供的是這個構想的實作版本。它讓團隊能跨支援的代理宿主檢視代理工作所處的條件，以證據而非印象討論問題，並在後續執行中驗證修復是否站得住腳。它的價值不在保證每一次修正都會改善成果，而在讓 AI 程式代理工作流變得更可檢視、可審查，也更能被證偽。46