AI Agent Definition of Done：如何定義完成條件
可靠的 AI Agent 不靠更流暢的回覆，而靠可觀察的完成條件。從任務、結果、失敗案例到人工校準，建立可維護的驗收方法。
本文整理 Anthropic／Claude 公開的工程與產品文件，並加入 Gwarket 對可驗證 AI 工作流的分析；不是 Anthropic 官方文件或產品承諾。
一個 agent 最容易讓人失望的時刻，不是它答錯，而是它看起來做得很好，卻沒有人能說清楚它到底算不算完成。
只靠感覺來評估，流程一改、模型一換、工具一更新，大家只能猜它是不是變差了。於是修正變成反覆試 prompt：這次好像可以，下次又不知道為什麼壞掉。
先定義任務，再評估 Agent
驗收不是最後才加上的 QA。它從一開始就迫使我們回答：這個任務的輸入是什麼？最後的正確狀態是什麼？哪些錯誤不能接受？
以「整理研究」為例，不能只寫「請做一份高品質摘要」。可把標準改成：
- 每一個重要結論都要能回到來源。
- 已知與推論要分開。
- 資料不足時要列出未知，而不是補成肯定句。
- 結果要包含讀者下一步可以使用的判斷或方法。
這些條件讓人與系統都知道何謂完成。
產出者與驗證者分開
最簡單的模式是 generator-verifier：一個 agent 先產出，另一個依明確條件檢查，未通過才附帶具體原因退回。它適合有清楚驗收標準的高品質工作，不適合完全主觀、連人都無法穩定判斷的題目。
驗證者也不必是 AI。關鍵不是「一定多一個模型」，而是不能讓產出者憑自己的敘述宣告成功。程式可用測試，資料可用規則與比對，內容可用來源檢核與人工校準。
三個讓驗收可長期使用的做法
- 測最後狀態，不只測回覆。 例如檔案是否存在、資料是否正確、外部紀錄是否成立。
- 保留失敗案例。 真正有價值的測試集不只放順利案例，也記錄曾經誤解、漏做或過度宣稱的情況。
- 定期用人校準。 若結果要服務人，評估標準不能永遠由模型自己決定。
成熟的 agent 系統不是永遠不犯錯，而是每次犯錯都能被看見、被定位，並成為下一輪工作標準的一部分。
為什麼「看起來不錯」不夠
內容、研究與策略的評估確實比程式測試更主觀，但主觀不代表只能靠印象。你仍可把討論拆成可校準的維度：事實是否成立、推論是否說明、讀者問題是否被回答、語氣是否符合情境、是否保留必要限制。
這些維度不會讓文章變成考卷，卻能讓編輯與作者討論同一件事。否則一句「我覺得不太對」雖然真實，卻很難轉化成下一次可重複的改進。
對需要高度判斷的任務，最實用的方式是讓 AI 先依準則自查，再由人定期抽樣校準。人不必逐字重寫，但要確認系統的標準沒有偏離真正想服務的讀者。
評估要防止兩種假進步
第一種是假通過：agent 學會迎合格式，卻沒有真的解決問題。例如它每次都附上引用，但引用與結論沒有關係。
第二種是假退步：流程改得更謹慎，文字看起來變保守，卻把以前常被隱藏的未知項誠實列出。若只用「看起來多不多、快不快」衡量，可能誤把可靠性提升當成品質下降。
所以一套好的評估要同時看產出與過程：最後結果是否成立，關鍵步驟是否遵守邊界，遇到不知道的事是否能正確停下來。Anthropic 對 agent eval 的區分值得借用：task、trial、trace、grader 與 outcome 都是不同對象，不能混成一個模糊的分數。
從十個案例開始就夠了
不需要等到有一百個完整 benchmark 才開始評估。挑十個最常見或最痛的真實案例：五個正常案例、三個容易出錯的案例、兩個必須拒絕或等待確認的案例。每次改流程後都跑一遍，並把新失敗加入其中。
這樣累積下來，你得到的不是一份漂亮的 AI 評分表，而是一個能反映真實工作風險的學習系統。
評估結果要能改變下一步
最後一個容易忽略的問題是：測完之後誰來決定改什麼？如果每次分數下降都立刻調 prompt，很容易修掉表面現象，卻破壞別的任務。
較好的做法是先看 trace 與最後狀態：它是在理解任務時出錯、取資料時出錯、使用工具時越界，還是完成後沒有被正確驗收？不同原因需要不同修正。可能是補一份 Skill、縮小工具權限、改善資料格式，也可能只是把不合理的完成標準修正。
評估的目的不是製造一個漂亮分數，而是讓改善不再靠猜。當每次變更都能回到同一批真實案例檢查，AI 工作流才會逐漸成為可維護的系統，而不只是偶爾靈驗的技巧。
這也會改變你選擇工具的方式。你不再只問哪個模型最強，而會問：哪一種組合能在我的任務、限制與驗收條件下持續產生可接受的結果？這個問題比較不炫，但它才是真正能落地的問題。
讀者保存卡
先定義正確的最後狀態，再選擇 agent、流程與驗證方法；沒有完成定義，就沒有可靠自動化。