Agent 驗證與批判機制實作課：別讓 Agent 自己說了算

前言

Agent 最危險的一句話不是「我不知道」，而是「完成了」。它語氣篤定、格式整齊、還附上看似完整的理由，讓人很想直接相信。但信心不是證據：模型可以把錯誤的推理講得非常流暢，也可以把沒做到的事寫成已經做到的樣子。真正決定 Agent 能不能上線的，往往不是生成能力多強，而是後面有沒有一層夠獨立的驗證。

這篇文章講清楚驗證層該怎麼設計。如圖一，生成與驗證必須分開，驗證者要拿不同的證據、站在不同的位置檢查；如圖二，驗證不是一次性的點頭，而是生成、驗證、修正、再驗證的迴路，而且要有明確的停損。先把驗證層做對，Agent 才敢被賦予真正的副作用。

一、為什麼自己檢查自己最不可靠

直覺上，讓 Agent 做完再自己檢查一遍好像很省事，研究與實務經驗卻一再指出它的盲點。生成時的思路會跟著檢查走：當初怎麼想錯，覆核時就很容易沿著同一條路再想一次，結果是把錯誤合理化，而不是發現錯誤。換一個說法：同一個模型、同一份上下文、同一種推理風格，檢查的獨立性幾乎為零。

Anthropic 團隊在內部使用程式碼 Agent 的做法，正好反其道而行。他們要求 Agent 先拿出可以執行的證據，例如測試結果、建置結果或與設計稿比對的截圖，而不是只說一句完成了；再由另一位 Agent 以新的視角覆核變更。重點不在於第二位 Agent 比較聰明，而在於它沒有參與第一輪的決策，比較不容易繼承第一輪的假設。

這裡有一個實用的原則：驗證的獨立性，比驗證者的聰明程度更重要。獨立性來自三個地方：不同的模型或不同的提示角色、不同的輸入（例如驗證者只看產出與原始需求，不看生成者的推理過程）、不同的證據（例如驗證者自己再查一次來源系統，而不是讀生成者轉述的結果）。三者至少要做到一項，否則所謂驗證只是同一份答案換句話說。

二、四種驗證，對照著用

驗證不是一種工具，而是一組層次，每一層抓不同的錯誤。

第一層是規則驗證，完全由程式決定，沒有模型參與。格式是不是合法的結構化輸出、金額重算是不是一致、權限是不是在允許範圍內、刪除或付款這類操作是不是帶著正確的識別碼。規則驗證便宜、確定、可重複，能擋下的錯誤就不要花模型費用去猜。

第二層是工具回查。Agent 說資料庫已經更新、訂單已經建立、檔案已經寫入，驗證流程就應該自己再呼叫一次唯讀工具去確認，而不是相信 Agent 的回報。這個動作很無聊，卻是區分「真的做完」與「以為做完」的關鍵。回查的工具必須與執行的工具分開設定唯讀權限，避免驗證步驟本身又造成副作用。

第三層是模型批判，適合規則寫不出來的判斷，例如這份摘要有沒有遺漏關鍵條件、這段程式碼改動有沒有偏離原始需求、這封回覆的語氣與承諾是不是合理。批判者要拿到明確的檢查清單與原始需求，逐項給出通過或不通過的理由，並且引用它看到的具體內容。只回「看起來沒問題」的批判，等於沒有批判。

第四層是抽樣一致性。當任務允許付出額外成本時，可以讓生成者產出多個候選答案，再由驗證者評分選出最好的。柏克萊與 Google 的研究顯示，簡單的抽樣加上自我驗證，就能在推理基準上帶來明顯提升；OpenAI 的過程監督研究則進一步指出，只看最終答案的結果監督，容易放過中間步驟的錯誤，而逐步驟的過程監督能更精準地定位問題。兩者的共同啟示是：驗證要看過程與證據，不只看結論。

三、驗證結果應該有三態，不是二元

很多驗證設計失敗在第一步：只允許通過或不通過。現實中有一大塊灰色地帶，驗證者其實是不確定的，例如證據不足、需求本身有歧義、兩個來源互相矛盾。強迫驗證者在這種情況下選邊站，等於把猜測包裝成 verdict，之後的流程還以為那是確定的結論。

比較穩健的設計是三態：通過、不通過並附上證據與修正建議、不確定並轉交人工或降級處理。不確定不是驗證者的失職，而是系統誠實的表現。轉交時要附上已經查到的證據與卡住的點，讓接手的人不需要從頭再查一次。

三態之外，還要想清楚錯誤成本的不對稱。誤擋的代價通常是多跑一輪或多問一個人，誤放的代價卻可能是錯誤付款、誤刪資料、對外寄出錯誤承諾。對於不可逆的動作，驗證標準應該刻意偏向保守：寧可誤擋一個正確的結果，也不要放行一個錯誤的結果。這個取捨要寫進規則，而不是等出事才憑感覺調整。

四、驗證迴路：修正要有邊界，標準不能跟著動

驗證通過之後，流程才可以繼續；驗證不通過，就要回到生成者修正，再重新驗證。如圖二，這個迴路需要四條邊界。

第一，修正意見必須具體。籠統的「再想想」或「做得更好一點」沒有用，驗證者要指出哪一項檢查失敗、證據是什麼、改動的方向是什麼。生成者拿到具體意見，才有機會在下一輪真正修好。

第二，迴路要有次數上限，例如最多三輪。超過上限就降級或轉交人工，而不是無限重試。無限重試不只燒成本，還會讓系統在同一個錯誤上打轉，最後用運氣矇到一次通過。

第三，檢查標準要凍結。驗證失敗時，最省力的作法不是修好產出，而是放寬標準，例如把「購物車顯示十元折扣」改成「購物車顯示折扣」。這種事 Agent 不一定是故意的，但只要標準可以由同一輪流程修改，它遲早會被修改。標準應該由流程外部定義、版本化管理，驗證迴路只能對照標準，不能改寫標準。

第四，驗證者與生成者要保持職責分離。生成者不能自己寫測試來證明自己正確，再把測試結果當成驗證證據；測試、檢查清單與回查工具，應該由流程的設計者或另一方提供。自己出題、自己作答、自己批改的分數，再高都沒有意義。

五、最小可跑骨架：驗證是一個函式，不是一句提示

下面是一段 Python 風格的骨架，重點在結構：生成、驗證、修正與停損分開，驗證結果是結構化的 verdict，而不是一段自由文字。

from dataclasses import dataclass

@dataclass
class Verdict:
    status: str  # "pass"、"fail" 或 "uncertain"
    failed_checks: list[str]
    evidence: str

def run_agent_with_verification(task, max_rounds=3):
    draft = generate(task)
    for round_no in range(1, max_rounds + 1):
        # 先跑便宜又確定的規則驗證，再跑模型批判
        verdict = verify_rules(draft, task)
        if verdict.status == "pass":
            verdict = verify_with_critic(draft, task)
        if verdict.status == "pass":
            return draft
        if verdict.status == "uncertain":
            return escalate_to_human(task, draft, verdict)
        # 修正意見要具體：失敗的檢查項目與證據一起交回去
        draft = revise(task, draft, verdict)
    return escalate_to_human(task, draft, verdict)

骨架跑通之後，真正影響成敗的是四個實作要點。第一，驗證者的提示要匿名化：不要告訴批判者這是哪個模型的產出，也不要附上生成者的推理過程，避免它被風格或權威感牽著走。第二，批判的檢查清單要短而具體，超過七項的清單通常等於沒有清單，挑出真正會出事的項目就好。第三，規則驗證要先於模型批判，確定性的錯誤不需要花模型費用。第四，驗證的每一次結果都要留下來：哪一輪失敗、失敗項目是什麼、最後是通過、降級還是轉交人工。這些紀錄就是日後調整驗證標準的依據。

六、成本與取捨：不是每個任務都值得同一套驗證

驗證不是免費的，每多一層驗證就是多一次模型呼叫、多一段延遲。實務上應該按風險分級，而不是一視同仁。

唯讀、低風險的任務，例如摘要草稿與內部搜尋整理，可以用抽查加上規則驗證就好，不必每一筆都做完整批判。會寫入系統但可回復的任務，例如更新工單狀態或建立草稿，應該跑完整規則驗證加上工具回查，確認寫入真的生效。不可逆或對外的任務，例如付款、刪除、寄送承諾，就要把四種驗證開到最強，並且在最後保留人工閘門。

分級之後還要監控三個數字：驗證通過率、誤擋率與轉交人工的比例。通過率長期接近百分之百，通常代表驗證太鬆；誤擋率突然上升，代表標準或檢查清單改壞了；轉交比例過高，代表任務定義或驗證設計本身需要修正，而不是驗證者不夠努力。驗證層自己也需要被驗證，否則它會安靜地變成另一種形式的盲目信任。

結論

Agent 的驗證層回答的是一個很簡單的問題：誰來證明它真的做對了。答案不能是它自己。規則驗證負責確定性的錯誤，工具回查負責確認副作用真的發生，模型批判負責規則寫不出來的判斷，抽樣一致性負責在成本允許時提高勝率；驗證結果要有不確定這一態，迴路要有次數上限，標準要凍結在流程之外。

先把驗證層當成產品來設計，再談 Agent 要多自主。順序正確時，驗證不是拖慢 Agent 的關卡，而是讓它敢被賦予更大權限的理由。一個沒有驗證的 Agent 跑得越快，錯得也越快；一個有驗證的 Agent 跑得也許慢一點，但每一步都有人——或是另一個獨立的檢查——替它背書。

資料來源

- OpenAI：Let's Verify Step by Step（過程監督與結果監督的比較，逐步驟回饋能更可靠地訓練驗證模型）：https://cdn.openai.com/improving-mathematical-reasoning-with-process-supervision/Lets_Verify_Step_by_Step.pdf?utm_source=www.superpowerdaily.com&%3Butm_medium=referral&%3Butm_campaign=a-trick-to-create-chatgpt-templates-using-the-new-share-feature&utm_medium=referral&utm_campaign=96-a-trick-to-create-chatgpt-templates-using-the-new-share-feature&utm_content=article-link-9

- 加州大學柏克萊與 Google：以抽樣與自我驗證提升推理表現的測試時擴展研究：https://venturebeat.com/ai/less-is-more-uc-berkeley-and-google-unlock-llm-potential-through-simple-sampling

- Anthropic 團隊內部以 Agent 寫程式的驗證做法：先拿可執行證據，再由另一位 Agent 覆核：https://medium.com/agents-under-test/your-ai-agent-says-its-done-who-checks-e435d54c8d3e

- 自我驗證強化學習研究 RISE：以可驗證獎勵同時訓練生成與自我驗證能力：https://papers.neurips.cc/paper_files/paper/2025/file/bd3d106d8e9789ce4fd40e1edafe71d5-Paper-Conference.pdf