AI 代理評估：上線前的驗收測試

AI 代理評估應確認助理是否完成約定的業務任務，而不只是最後的訊息是否聽起來有說服力。如果代理說已更新客戶紀錄，驗收證據不只要在對話中，也要在目的系統中。

以代表性任務、明確驗收規則及獨立檢查的成果評估 AI 代理。除了成功案例，也納入拒絕、不確定性、中斷與人工交接。發布決定應連結到測試過的流程和版本，而非單一綜合分數。

想像助理正在準備變更配送地址。有用的展示可能在聊天視窗顯示正確地址。有用的評估則要確認哪張訂單變更、誰授權、配送是否已鎖定，以及目的系統回應不明確時發生什麼。這些是不同問題。

以下例子是評估設計提案，並非客戶成果或已發布的基準測試。它們協助業務負責人在讓代理執行更多工作之前，委託取得證據。

定義 AI 代理評估的成果

從營運同事能辨識的任務開始。描述起始狀態、允許動作及可接受的結束狀態。以地址變更為例，驗收可能要求符合條件的訂單、驗證過的新地址、核准，以及訂單系統內相符的紀錄。

Anthropic 對代理評估的說明 區分對話軌跡與環境的最終狀態。即使實作使用其他供應商，這個區分仍有用。流暢的成功描述是回應本身的證據，不是業務成果的獨立證明。

不要要求每次有效執行都使用完全相同的措辭或唯一工具順序。不同路徑可能產生可接受成果。應區分必須成立的限制與可變動的實作細節。即使最後回答很親切，禁止的紀錄變更仍應讓測試失敗。

為爭議案例指定負責人。若業務、財務與營運對正確成果有分歧，自動評估器無法代替他們決定業務政策。用案例作為發布門檻前，先將分歧記錄為未解決要求。

建立代表性案例集

從實際流程蒐集例子，再移除不必要的個人資訊。包含一般要求、合法但難處理的值，以及系統應要求澄清的情況。避免測試集全是建立代理的開發者寫出的整齊例子。

把這個矩陣當作起點，而非通用覆蓋保證。薪資助理、內部研究工具與客服代理需要不同證據。重要的是，每個案例執行前就已有預期的業務意義。

分開探索案例與驗收案例

探索案例可以在尚無確定評分規則時揭露新故障。這是有價值的學習，但不應悄悄改變先前約定的通過定義。維持穩定驗收集，另設需要調查或政策決策的案例佇列。

保留揭露真實缺陷的案例。缺陷修好後，案例就是回歸檢查。操作範圍擴大時新增例子，不要反覆改寫舊案例迎合最新輸出。

選擇各項成果的檢查方式

對確實具決定性的事實使用決定性檢查。目的識別碼、未變動的受保護欄位，或沒有未授權寫入，通常可直接確認。模型評審可協助判斷說明品質，但不能成為確認資金是否移動或紀錄是否變更的唯一依據。

記錄檢查存在的理由。獎勵特定道歉用語的字串比對，可能拒絕完全有用的回答。接受預期欄位名稱的結構描述，仍可能接受錯誤客戶。JSON Schema 物件指引 說明結構驗證；業務正確性需要額外斷言。

對主觀回答，請審查者描述缺陷，而非只選分數。回應是缺乏依據、令人困惑、不完整，還是超出使用者權限？分開標籤能讓下一次工程變更更容易說明理由，也讓下次審查更容易重複。

控制測試環境與版本

可重複的案例不只需要保存提示詞。記錄代理實作、相關指示、工具定義、模型設定與起始資料。若上游紀錄在執行之間變更，結果可能因合理且與代理變更無關的原因而不同。

對會產生業務影響的操作使用受控目的系統。有計畫地重設或重建起始狀態。第二次對第一次已修改的紀錄執行，即使自然語言要求相同，也已是另一個測試。

檢查不只一次嘗試

代理行為可能在嘗試間變動。提前決定重複試驗如何影響驗收，並保留所有結果。只報告最佳執行，會讓負責人無法理解不一致性。同樣，不要從少量成功例子宣稱確定性。

約定務實的評估預算。有些案例可在工具契約變更時執行，有些需要專業審查者或昂貴整合環境。分層套件可經常提供有限檢查，同時在操作範圍變更時保留較全面的發布評估。

讓失敗與交接成為實用成果

拒絕可能是正確結果。當訂單不明確時暫停的代理，可能比完成錯誤變更的代理更有用。定義可接受的澄清、呈報處理與人工繼續方式，避免評估器不計代價地獎勵完成。

應像檢查完成操作一樣仔細檢查交接紀錄。它應指出原要求、相關目的參照、未解問題及負責佇列。籠統要求聯絡支援，可能讓同事從頭重做調查。

將評估與較廣泛安全評估分開。OWASP ASVS 提供驗證應用程式安全要求的基礎。我們的 AI 代理安全指南 涵蓋權限與惡意輸入。流程評估應納入這些邊界，但好的任務完成成果不是完整安全保證。

決定什麼會阻止發布

展示前寫出停止條件。跨客戶揭露或未授權寫入，可能不論平均完成表現如何都應停止發布。令人困惑但可復原的說明，則可能只需縮小範圍或受監控試點。嚴重程度來自業務影響。

除了整體成果，也依案例類別報告。當大部分例子是一般查詢時，良好的綜合成績可能掩蓋薄弱的復原行為。任何摘要分數旁都應列出測試案例數量與性質、未解失敗、審查分歧及已知排除項目。

驗收應對應特定範圍與版本。通過唯讀訂單問題，不代表已能修改訂單。新增目的系統、使用者群組或寫入工具會改變操作邊界，應觸發有計畫的案例集檢視。

保留其他團隊成員能理解的發布紀錄。說明測試了什麼、失敗了什麼、變更了什麼，以及負責人為何接受剩餘限制。原評估者不在時，沒有解釋的綠色儀表板不是好的交接。

編列證據與持續維護預算

要求範圍明確的 GBP 提案，涵蓋測試設計、受控環境、實作、審查與報告。將初期工作與定期評估執行、業務規則變更後的案例維護分開。不知道流程，就沒有合理的通用評估單價。

有用的初次投資通常是能攔截高成本錯誤類別的小型套件。其價值來自支援的決策，不是試算表裡提示詞的數量。避免購買沒有人能連結到日常營運的大型合成基準。

委託範圍有限的評估試點

準備任務說明、代表性的去識別化例子，以及能證明完成的目的狀態。確認代理絕不能執行的操作，以及判斷模糊案例的同事。若敏感細節可被適當處理，既有事故例子很有用。

我們的 AI 整合範圍明確試點 可從任務與驗收證據開始。初期範圍可在擴大存取前確認代理、工具與目的系統是否可靠協作。

提供流程與你需要做的發布決定 。要求可重複評估套件、盲點說明與清楚交接。交付應協助你決定，下一步能安全地信任代理做什麼。

常見問題

什麼是 AI 代理評估？ AI 代理評估依定義的任務與驗收規則檢查代理。它檢查結果系統狀態、允許操作，以及說明或交接品質，而不把有說服力的最後訊息當成完成證明。

基準分數足以核准業務代理嗎？ 不行。一般基準可協助技術比較，但發布驗收需要反映你的紀錄、權限、故障模式及業務規則的案例。應報告測試範圍與未解限制。

需要多少測試案例？ 沒有通用數量。先從提議流程中的不同成果與重要失敗路徑開始。新工具、使用者群組或政策例外帶來實質不同的行為時，再加入案例。大量幾乎相同的提示詞，不等於廣泛營運覆蓋。

另一個模型可以評分回答嗎？ 可以，用在適合的審查部分。以熟悉業務的人檢查過的例子校準，並對哪筆紀錄變更等事實保留決定性的目的系統斷言。模型判斷不能代替業務操作證據。

正確拒絕應算成功嗎？ 應該，前提是拒絕為預期結果。定義有用拒絕應說明什麼，並確認沒有禁止操作或資訊揭露。

需要正式環境的客戶資料嗎？ 通常應先用受控例子，保留相關結構與棘手情況，排除不必要個人資訊。任何真實資料使用都需要明確目的、適當存取權及處理政策。代表性行為比把整個正式資料庫複製到評估器更重要。

評估供應商應交接什麼？ 案例集、預期成果、起始狀態說明、評分規則、版本紀錄及故障證據。包含重複評估所需的命令或程序，以及負責更新的人。

何時應再次執行套件？ 模型、指示、工具、權限或目的系統行為變更後，重複相關檢查。業務任務擴大時檢視覆蓋。先前的驗收結果屬於先前測試範圍。