Qoder Better Harness：用證據審視同改善 AI Coding Agent 工作流

Qoder 嘅 Better Harness，係一個開源工具，用嚟檢視同改善 Coding Agent 周邊嘅工作流程。佢唔係只睇某次模型回答得好唔好、或者一個 code diff 啱唔啱；反而會睇整個專案點樣畀 agent 做嘢：有冇清楚指引、適當控制、驗證途徑、agent 設定，以及喺支援情況下，有冇真實工作 session 嘅紀錄可供查證。

目的係搵出流程斷點，提出範圍有限嘅修復方案，之後再跑一次，驗證改善有冇真係留下可查嘅證據。124

據當時報道，Qoder 喺 2026 年 7 月 28 日宣布於 GitHub 開源 Better Harness。5

重點唔係淨係評模型，而係評「harness」

Coding Agent 從來唔係單獨運作。佢周圍仲有 repository 指引、規格、工具、權限、腳本、測試、code review 要求、發版檢查同人手交接。Qoder 將呢套環境叫做 harness。官方文件所講嘅 harness，可以包括 repository instructions、rules、skills、hooks、plugins、connectors、scripts、test commands、release checks，同埋人手 review 步驟。2

分別好重要：就算模型本身幾叻，外圍流程含糊或者缺乏監測，交付都可以唔穩定。譬如專案有測試指令，但冇講清楚 agent 幾時必須執行；又或者有 rule file，但 agent 根本冇用；失敗任務帶來嘅教訓，亦未必有方法保存成可長期維護嘅專案資產。Better Harness 想找出嘅，就係呢類操作層面問題，而唔係見到有設定檔就當成流程已經有效。145

三層框架點樣運作？

Better Harness 被定位為一個三層框架，將工程實踐、評估模型同可實際運行嘅實作連埋一齊。5

1. Harness Engineering 實踐

第一層係影響 agent 工作質素嘅實際機制，包括 session 同 CLI 模式、可觀測性、rules、skills、MCP 設定、memory、hooks 同自動化。5

用白話講，呢層會問：

• Agent 有冇收到清晰目標、限制同 repository 背景？
• 佢嘅執行路徑同權限，有冇適當限制？
• 測試、檢查同 review，有冇接入佢實際做嘅工作？
• 任務學到嘅有用教訓，可唔可以變成持續維護嘅專案資產，而唔係隨 session 消失？

Better Harness 會先描繪現有 harness，包括目標、背景、執行入口、回饋循環、交付機制同學習紀錄方式。1

2. Agent Work Loop 評估

第二層會將上述實踐轉成五個互相連接嘅交付維度：任務理解、受控執行、改動驗證、可靠交付、學習紀錄。14

換句話講，問題由「agent 有冇寫到似樣嘅 code？」轉為：整套由頭到尾嘅流程，係咪可以重複地產出容易理解、受控、驗證過、可交付，而且有吸收舊經驗嘅改動？

框架要找嘅，正正係工作循環入面嘅斷點，例如少咗某個機制、整合冇接通、某一步從未實際執行，或者結果冇足夠證據支持。1

3. 可運行嘅工程實作

第三層係令前兩層唔止停留喺原則同文件，而係真係可喺項目中運行。Better Harness 透過 Coding Agent 執行，在支援情況下收集專案同 session 證據，然後輸出有優先次序、可驗證嘅下一步改善建議。4

Qoder 目前資料指出有 10 個 host adapters；開源時嘅報道則點名支援 Claude Code、Codex、Qoder 同 Cursor 等 Coding Agent 環境。56

支援範圍會隨版本改變，所以如果要確認某個宿主環境可唔可以整合，應以項目最新 adapter 文件為準。現有提供嘅資料並未證實支援 OpenClaw。

三路取證：設定、專案，同真實 session

Better Harness 一個關鍵設計，係將收集證據同最終評估分開做。Qoder 表示，主分析流程先收集原始資料，再交畀三個獨立、唯讀嘅 sub-agents 分析，最後先整合結果。1

三個角度包括：

• Project Harness：repository 嘅工程基礎，例如指引、腳本、檢查同交付控制。
• Agent Customization：agent 專屬嘅 rules、skills、hooks 同其他設定。
• Session Evidence：agent 喺真實工作中實際做過乜嘅紀錄；前提係相關證據可取得。

呢種分工，幫到團隊分清「設計上應該有」同「實際上真係做過」。專案同設定證據可以證明能力存在；session 證據就有助證明 agent 喺某個真實任務入面有冇適當使用呢項能力。14

有測試唔等於測試真係發揮過作用

Better Harness 最實用嘅原則之一，就係：有工件存在，唔等於有效。

例如 repository 有自動化測試，最多只證明具備潛在能力；但單靠測試套件存在，唔能夠證明 agent 改完 code 後有執行相關測試、正確理解結果，或者真係靠結果阻止咗錯誤交付。Rules、hooks、skills 同審批閘口，都係同一道理。15

因此，Better Harness 會盡量將證據鏈講清楚。報告會將有支持嘅缺口化成按優先次序排列嘅 findings，列出影響、預期產出、範圍清晰嘅修復方式同驗收檢查；冇證據嘅地方，會明確保留，而唔會偷偷變成一個充滿把握嘅分數。46

一個有用嘅 finding，應該畀團隊檢查到以下幾點：

1. 觀察到乜嘢：來自專案、設定或 session 紀錄嘅具體訊號。
2. 點解重要：佢會點樣影響交付循環。
3. 建議修復乜嘢：例如新增 rule、skill、hook、script、自動化，或者人手批准步驟。
4. 點樣驗證：修復實施後，要用咩驗收條件重測。

改善唔係做一次 audit 就完：檢視、修復、再量度

Better Harness 並唔係一次性審計工具，而係一個迭代流程：

1. 描繪目前 harness；
2. 找出工作流斷點同證據缺口；
3. 為有支持嘅 finding 建立範圍有限嘅修復任務；
4. 依照預先定義嘅驗收檢查驗證修復；
5. 再次運行檢視，查看更新後嘅證據。14

呢個先係佢所講「持續改善」嘅基礎：工具可以顯示流程有冇變，以及新證據係咪支持較強嘅評估。但佢本身唔能夠證明每一個修復，都必然令所有專案、所有 host 環境嘅 agent 表現更好。Qoder 資料強調觀察到嘅證據同明確限制，而唔會將分數升跌當成因果證明。46

點睇「30 個真實 GitHub 項目」嘅初步檢視？

開源時報道提到，框架曾用於一項涉及 30 個真實 GitHub 項目嘅初步演練。5 呢個較適合視為探索性應用：展示框架可以喺不同 repository 搵到重複出現嘅 harness 缺口，而唔係一項受控實驗，證明 Better Harness 會提升每一個 Coding Agent 或每一個專案。

現有一手文件足以支持其證據模型、findings 結構同迭代修復方式；但提供嘅來源未有足夠一手細節，讓人獨立評估呢 30 個項目嘅樣本選取、評分程序或整體結果。要將 Better Harness 同正式 benchmark 比較，或者作出廣泛效能宣稱時，呢些限制尤其重要。14

想建立更可量度嘅 Agent 工程方法

Qoder 更大嘅主張係，Harness Engineering 應該成為 AI 輔助軟件開發嘅品質基礎設施：有共同詞彙、工作流控制、可觀察證據、可比較嘅交付維度，以及可以重複執行嘅改善循環。12

Better Harness 就係將呢個想法落地嘅一種做法。對使用支援 host 嘅團隊而言，佢提供一個方法去檢視 agent 工作條件、用證據而唔係印象討論問題，並喺後續運行中測試流程修復係咪站得住腳。

佢嘅價值唔係保證每次修改都會改善結果，而係令 AI Coding Agent 工作流變得更容易檢查、review，同埋被證偽。46