正式環境前的 AI 代理評估

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

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

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

選擇評分器前先定義行為

每個案例都需要：

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

使用程式碼檢查工具名稱、引數結構描述、政策決策、結構化欄位、資料庫變更、延遲上限及禁止的呼叫。這些檢查可重複，也容易偵錯。

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

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

新類別、裁判歧見及高影響失敗交由人類處理。記錄裁定，再將穩定的決策轉成更清楚的斷言或評分規則。

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

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

完整工作分數可能掩蓋失敗出現的位置。應分別評分：

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

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

不要讓線上裁判自動觸發影響重大的動作。依明確政策遮蔽正式環境資料並取樣，再將可能的回歸交由審查或受控回復流程。

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

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

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

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

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

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