Google研究團隊10月1日在arXiv提交論文，公開了一套名為VeriHarness的AI代理驗證框架，程式碼同步放上GitHub，採用Apache 2.0授權。它要解決的問題很具體：AI代理執行一個要跑幾十步的長任務，交出一份試算表、一份報告或一個修改過的檔案，誰來判斷這份東西對不對。
VeriHarness的做法，是讓生成答案的那個模型自己當複核員。同一道題先讓模型獨立跑多次，得到多份結果，再把這些結果攤開比對，依「分歧」和「共識」兩類分別處理。
兩條複核路線
第一條處理分歧。幾份結果在某個結論上說法不一致，複核員就回到任務環境裡找證據，比如重新打開原始檔案、查試算表裡的特定單元格，用環境裡能查到的東西排除掉錯誤的說法。
第二條處理共識。幾份結果意見一致，框架也不直接放行，會主動挑毛病，專門找能推翻這個結論的證據，同時檢查是不是所有結果都漏掉了任務裡的某項要求。論文的出發點是，多次執行得出相同答案，並不能保證答案正確，模型完全可能每次都犯同一個錯。
兩條路線跑完，進入裁定環節：選出一份底子最好的結果當基礎，根據查到的證據提出修訂，必要時整個重做，並把仍然沒查清的問題另外記下來。框架給複核員配了工作區、取證工具和一組可重複使用的「驗證技能」，論文稱這些技能還能依失敗回饋自我改進。
測了什麼，提升多少
評測涵蓋五個長程工作區基準：APEX-Agents、Workspace-Bench Lite、WorkBuddy Bench、SpreadsheetBench 2和JobBench，多數是辦公文件、試算表、求職資料這類要交付檔案的任務。生成和複核都用同一款模型，測了兩款：Gemini 3.5 Flash和Claude Opus 4.8，皆透過Vertex AI呼叫。
依論文和README的說法，VeriHarness在五個基準上的「選擇分數」都排第一，對照組包括單次執行和先前的LLM-as-a-Verifier類方法。加上證據驅動的修訂後，相較單次生成，Gemini 3.5 Flash平均提升6.2分，Claude Opus 4.8平均提升6.4分。
團隊同時在Hugging Face公開了約2.6萬條執行軌跡，兩款模型在五個基準上每題各跑10次，附帶渲染後的執行過程、交付檔案和評分。基準的輸入和標準答案沒有公開。論文提到，產出這批資料花了超過10萬美元。
跟「多跑幾次取多數」差在哪
讓模型多跑幾次再投票，是業界常用的提分方法，成本低、好實現，在短問答上效果明顯。放到長任務上就有兩個麻煩：交付物是一個檔案，沒辦法簡單投票；幾份結果一致時，投票會把共同的錯誤原樣保留下來。VeriHarness的兩條路線，分別對準這兩個麻煩。
另一種常見做法是找一個模型當裁判，讀完幾份結果直接打分。這種做法依賴裁判的閱讀判斷，不會回頭到環境裡核對。VeriHarness把「能不能在環境裡找到證據」放在核心，代價是複核本身也變成一段要呼叫工具、要花token的AI代理任務。論文沒有給出複核環節相對生成環節的額外開銷比例，企業要算這筆成本，目前只能自己跑一遍。
本站此前報導過微軟的ThinkingBox基準，它要求同一任務重複評測20次，看的是AI代理結果穩不穩。兩項工作放在一起看，方向一致：長任務裡單次成績的參考價值有限，多次執行之間的差異本身就是訊號，一個拿來衡量穩定性，一個拿來抓錯。
能不能直接拿來用
README寫明執行環境為Linux，需要Python 3.10以上、Node.js 22.19以上、Docker，以及非特權使用者命名空間；底層跑在開源的pi執行環境上，pi支援的模型供應商都能接。專案頁面也寫了一句話：
「這不是Google官方支援的產品。」
也就是說，它目前只是一份研究用的程式碼，Google不承諾維護。論文測試的兩款模型都不是各家最新一代，換成Gemini 4或Opus 5.5之後提升幅度還剩多少，作者沒有測，這部分只能等第三方重現。
參考來源：arXiv論文《VeriHarness: Scaling Agentic Verification for Long-Horizon Tasks》、Google Research GitHub專案頁、CocoLoop、Hugging Face資料集頁；論文與README核驗五個基準名稱、兩款模型的平均提升分數、約2.6萬條執行軌跡及執行環境要求。