你的 AI 代理在線上，但工作真的完成了嗎？

AI 代理可以成功呼叫它的工具，卻仍然沒有達成使用者的目標。AWS 在其正式環境監控的實作導覽中明確點出這個區別：執行過程正常，並不代表完成了有用的工作。它舉的例子之一，是一個訂位代理停止完成訂位，但記錄檔卻顯示工具都執行成功。AWS

對於已上線的代理，我們建議建立一個完成度閉環：定義指派的任務、檢查下游紀錄、把不一致之處交給負責人處理，並在修復後驗證結果。該計入的是約定的成果，而不是代理自己宣稱的完成。Anthropic 明確說明了背後的區別：對話中的一則訂位確認，和資料庫裡的一筆訂位紀錄，是兩回事。Anthropic

先定義什麼叫「完成」

以我們為一個既有的接單代理所提出的營運設計為例。給它一項範圍明確的任務：依照經授權的請求建立相符的訂單草稿，或把語意不明的請求轉交給指定的審查人員。訂單核准與出貨履約則不在這項任務範圍內。這是在應用一項評估原則：在評斷表現之前，先定義輸入與成功標準。Anthropic

在接上監控之前，我們會先和你的流程負責人約定驗收證據：請求識別碼、客戶參考編號、品項與數量、預期的草稿狀態，以及審查人員的轉交對象。這些是需要進一步確認的條件，而不是宣稱你的 ERP 已經提供了所需的紀錄。

代理任務與更廣泛的業務工作要分成不同欄位記錄。依照這份約定，一次已獲確認的升級轉交，就可以算是完成了代理的任務，即使訂單本身仍未解決。我們建議要求接手的負責人確認收到，而不是把「通知已送出」視為交接完成。明確的角色分工與持續更新的應變紀錄，是既有事件管理實務的做法。Google SRE

讓一項任務走完經過檢查的結案流程

以下是我們建議的工作流程，應用了 Anthropic 以環境狀態檢查成果的做法，以及 Google SRE 明確指定事件負責人的原則。這是一份導入建議，並非描述這兩家公司任何一家的訂單處理系統。Anthropic · Google SRE

1. 記錄任務內容。保留經授權的請求、預期成果、驗收檢查項目與負責的審查人員。明確規定「成功」指的是一份已驗證的草稿，還是一次已獲確認的升級轉交。除非明確屬於任務的一部分，否則不要把核准或出貨履約納入。
2. 讀取下游證據。當代理回報已建立草稿時，使用約定的識別碼獨立調出這筆訂單。將客戶、品項、數量與狀態和原始請求比對。在啟用這項檢查之前，先確認讀取權限、識別碼比對、紀錄的即時性與重複偵測都沒有問題。
3. 不靠猜測，轉交不一致之處。如果證據缺漏、過時或無法讀取，就將這項任務標示為未驗證。不要把證據缺漏當成可以重試的許可。把不一致之處轉交給指定的審查人員，並記錄對方的確認、缺少的資訊與下一步行動。未獲確認的交接，一律視為尚未結案。
4. 核准修復後再次檢查。在對訂單、客戶承諾、權限或代理行為做出重大變更之前，必須取得人工核准。保留經核准的修正內容，並在結案前獨立檢查修正後的紀錄。若是相關聯的失敗，則指定一位事件負責人，並保留調查紀錄。

開始之前，先和業務負責人約定審查頻率與升級期限。在這套設計中，相符的草稿代表「草稿準備已驗證」，而不是「訂單已履約」。經過修正的草稿則記為「修正後已驗證」，而不能直接算作一次就成功。這些是針對特定任務的驗收規則，並非通用的門檻，也不是實測結果。

品質評分與紀錄檢查並列呈現

最有力的反方論點是：代理評估本來就涵蓋了完成度。AWS 的實作導覽會抽樣一定比例（可設定）的正式環境請求，並以模型擔任評審，評估回答是否有幫助、是否正確以及是否達成目標，每個評分都附上評判理由。這並不是忽略成果的監控。AWS

請保留這些評分。我們建議把它們和紀錄比對分開呈現：「評估者判定這次互動成功」和「所要求的草稿通過了業務紀錄檢查」，回答的是不同的問題。當兩者不一致時，用來挑選需要審查的工作，而不是捨棄其中任何一個訊號。這項建議參考了 AWS 的互動評估，以及 Anthropic 將「成果」定義為環境最終狀態的說法。AWS · Anthropic

我們建議的做法有個取捨：需要額外的整合與審查工作。我們目前還不知道你的系統能否提供足夠可靠的證據。在承諾自動結案之前，請先確認能取得這些資料；若無法取得，就讓結果維持未驗證，並指派專人處理。

第一個決定，從小處著手

我們會先把一項代理任務對應到作為權威來源的業務紀錄，實作驗收檢查，並和你的流程負責人一起處理不一致事項的待辦佇列。保留修正過的案例，供後續評估使用；Anthropic 說明了評估如何讓失敗與行為變化在代理的整個生命週期中清楚可見。Anthropic

你的第一個決定，是能否以證據讓一項具代表性的任務結案。請測試一份相符的草稿、一筆無法讀取的紀錄，以及一次未獲確認的交接。只有在團隊能證明什麼條件讓任務結案——以及未能結案時由誰負責——之後，才擴大導入。