生產環境前的 AI 代理評估

AI 代理評估會針對明確的預期執行一項有版本的任務，並記錄代理是否選擇正確的工具、遵守限制、完成工作，而且沒有產生禁止的副作用。實用的評估套件會結合確定性斷言、重複試驗、在有需要時使用的模型裁判，以及對爭議案例的人員審查。

第一批案例應來自真實失敗和高影響工作流程，而不是與生產環境無關的冷知識問題。

OpenAI 的建立代理實用指南建議建立評估基準，並隨代理複雜度增加持續使用評估。以下評分設計把這項建議具體化。

選擇評分器前先定義行為

每個案例都需要：

對訂單狀態代理，確定性評分器可以斷言它呼叫 get_order、從未呼叫 update_order、傳入已驗證的訂單 ID，並傳回權威狀態。模型裁判可以評估表達是否清晰，但當追蹤數據能明確回答時，不應由它判斷是否曾發生禁止的寫入。

使用程式碼檢查工具名稱、參數結構描述、政策決定、結構化欄位、數據庫變更、延遲上限和禁止的呼叫。這些檢查可以重複，而且容易除錯。

當多種答案都有效時，請使用範圍明確的評分規則。說明必要事實、不可接受的主張、語氣限制和代理可用的證據。不要只提供「質素 1 至 10 分」這類含糊分數。

對難以編碼的語意屬性使用裁判，再以人員標記進行校準。不要讓裁判看見實驗組名稱，要求它提供結構化說明，並追蹤意見分歧。裁判模型可能出現漂移，也可能與受測系統具有相同偏差，因此不能作為安全或財務副作用的唯一門檻。

新類別、裁判意見分歧和高影響失敗應交由人員處理。記錄裁定，再把穩定的決定轉化為更清晰的斷言或評分規則。

單次通過無法估計可靠性。涉及模型選擇、隨機檢索或可變工具的案例應重複執行，並報告試驗次數、成功次數和不確定性，而不只是一個百分比。

保留固定的核心集合以比較發佈版本，另建探索集合測試新行為，避免把提示組合的改變誤認為趨勢。這對生產環境的提示監察也很重要：測試問題的差異，可能比系統本身的改變更大幅影響表面上的可見度或成功率。

整體任務分數可能掩蓋失敗出現的位置。應分別評分：

針對選錯工具的問題，可先凍結執行，只測試選擇；針對重複寫入，則使用隔離後端並中斷操作。錯誤工具除錯指南和生產環境檢查清單提供了具體案例。

離線套件在發佈前使用 fixture、mock 或隔離資源執行，可支援版本比較和安全的失敗注入。線上評估則在部署後抽樣真實追蹤，用來偵測流量變化和離線集合遺漏的案例。

不要讓線上裁判自動觸發高影響操作。請按明確政策遮蔽生產環境數據並取樣，再把可能的回歸交由審查或受控回復流程處理。

模型、提示、工具、結構描述、檢索、政策、重試行為和供應商版本變更後，都要執行評估套件。在相同案例和重複試驗上比較候選版本與目前基準。

發佈門檻可以要求禁止操作為零、確定性測試沒有回歸，而且分級質素或成本的變化在限制內。請按任務類別拆分結果，因為穩定的平均值可能掩蓋某一項工作流程的嚴重回歸。

可觀察性系統發現失敗時，請保存已移除識別數據的追蹤、初始狀態和預期行為，並在修正錯誤前先加入案例。這可防止日後的模型或提示變更重新引入問題。

可觀察性指南說明重建 fixture 所需的追蹤欄位。

先從十個具代表性的案例開始，不要一開始便建立數百個含糊提示。案例應包括正常路徑、缺少情境、未獲授權的請求、工具衝突、供應商逾時、未知寫入結果、惡意檢索內容，以及不應呼叫任何工具的請求。

下方提示會在不編輯儲存庫的情況下，把一項現有失敗轉化為完整案例。斷言可信後，實作便會很直接，團隊也會得到一個具體的回歸門檻。