🎯 什麼情境該想到我
當你「改了 prompt、換了模型或工具，想在 CI 擋住 agent 退化，卻發現同樣的輸入每次輸出都不一樣」的時候。
⚙️ 怎麼用（步驟 / 公式）
核心：agent 跟傳統軟體最大的差別是同樣的輸入，輸出不固定。所以金字塔越底層越要用確定性的檢查，把 LLM 評審留給確定性方法判斷不了的部分（回答品質）。
1. 五層分工
| 層 | 測什麼 | 用什麼 | 頻率 |
|---|---|---|---|
| 單元測試 | 工具的商業邏輯、prompt 組裝、schema 驗證 | pytest／jest，不呼叫模型 | 每次 commit |
| 確定性 agent 測試 | 有沒有呼叫該呼叫的工具、有沒有呼叫禁止的工具、格式、個資 | 題庫＋軌跡比對＋程式寫的評估器 | 每次 PR |
| 品質回歸 | 正不正確、有沒有幫助、有沒有捏造 | 題庫＋LLM 評審（附標準答案或斷言） | 合併主線、換 prompt／模型時 |
| 情境擴展 | 多輪、使用者不照劇本走 | LLM 扮演使用者（simulation） | 上線前、每週 |
| 正式監控 | 品質趨勢、找低分 session | 線上抽樣評估 | 持續，不擋部署 |
★ 軌跡比對是投報率最高的一層：不花 token、結果確定，而且抓得到 agent 最常見的退化，也就是「該查資料卻沒查」「多叫了不該叫的工具」。
2. 軌跡比對：三種嚴格度
預期 [calculator, weather] 時：
| 模式 | 規則 | 例 |
|---|---|---|
| 完全一致（Exact） | 工具與順序都一樣，不能多 | [calculator, weather, calculator] ✗ |
| 依序出現（InOrder） | 依序出現即可，中間可夾別的 | [calculator, search, weather] ✓ |
| 都出現（AnyOrder） | 順序不拘 | [weather, calculator] ✓ |
- 預設用 InOrder。Exact 太嚴，模型多查一次資料就失敗，測試會很抖；只有「多做一步就是錯」的流程才用它。
- 軌跡比對只比工具名稱，不比參數；參數要另外用評估器檢查。
3. 門檻：依評估器類型分開設
| 評估器 | 門檻 | 理由 |
|---|---|---|
| 程式寫的不變式（「回覆不能有 email」「不能呼叫刪除類工具」） | min = 1.0 | 任何一題違規就是失敗 |
| 軌跡比對 | min = 1.0，或容許少數題失敗 | 評分確定，但 agent 行為本身不確定 |
| LLM 評審 | 看 mean，min 設寬鬆 | 單題有雜訊 |
- ★ 反例：AgentCore 官方 CI 範例對每個評估器「保留最高分」再跟 0.8 比，等於只要一題過就過，幾乎不可能失敗。
- 門檻跟主線基準比（例如不能比基準低超過 0.05），不要用絕對值：題庫變難時絕對門檻會一直紅，變簡單時又抓不到退化（判斷）。
- 平台通常沒有「低於多少就失敗」的設定，門檻要在 CI 腳本自己判斷。
4. 題數要夠：用標準誤估算
分數是 0／1 的通過率，平均的標準誤 = √(p(1−p)/n)。以通過率 p = 0.7 為例：
| 題數 n | 標準誤 |
|---|---|
| 10 | √(0.21/10) ≈ 0.14 |
| 50 | ≈ 0.065 |
| 200 | ≈ 0.03 |
題數太少時，正常浮動就大於你想抓的退化幅度。想抓 0.05 的退化，10 題根本看不出來。
5. 讓測試不要太抖
- 失敗的題目自動重跑一次，兩次都失敗才算真失敗。
- agent 的 temperature 能設 0 就設 0。
- PR 只擋確定性層；LLM 評審的結果以留言呈現，由人判斷。
- 區分「沒有結果」和「分數太低」：評估資料要先進監控系統（AgentCore 要等 2–5 分鐘），沒等到通常是基礎設施問題，不該算成品質退化。做法是先短暫等待，再輪詢到有結果；用不同的結束碼區分（原研究的 gate 腳本：通過 0、分數太低 1、缺結果 2）。
- 題庫版本要固定：CI 引用不可修改的題庫版本，不同次的分數才能比較。
6. 成本分層
依原研究（查證 2026-09-30），AgentCore 內建 LLM 評估器每次約 6，還沒算 agent 本身的模型費。軌跡比對不花 token。每次 PR 跑幾乎免費的確定性層，合併主線才跑 LLM 評審。
機制細節 → AgentCore Evaluations與Optimization
🧪 我實際套用的紀錄
- 2026-09-30：原研究的 CI gate 腳本在本機測過三種情況：全部通過 exit 0；有一題很差 exit 1（
Correctness mean 0.68 < 0.8；min 0.30 < 0.5）；缺評估器結果 exit 2。沒有在 AWS 上跑過。
⚠️ 注意 / 什麼時候不適用
- 程式寫的評估器最容易錯在 span 欄位名稱：不同框架的 trace 結構差很多，接真實 agent 前先撈一份真的 trace 對照（原研究推論）。
- LLM 評審本身要先校準才能信（見 LLM-as-Judge）；拿沒校準的評審當門檻，擋下的可能是評審的偏誤。
- simulation 的對話事先無法預測，只能用斷言，不能比標準答案或軌跡。
- 平台配額會卡並行 CI：AgentCore 的 batch 評估同時只能 5 個 job，多個 PR 一起跑要排隊或重試。
- 這張卡管「CI 怎麼擋」。上線後的逐案 diff、子群崩壞、版本回退見 上線閘門與線上評估。
🔗 相關工具
- 上線閘門與線上評估 —— 平台中立的五層閘門與線上評估；這張卡補上 agent 專屬的軌跡比對與 CI 實作
- LLM-as-Judge —— 評審的偏誤與校準
- Agent 評估 —— agent 的評估指標
- AgentCore Evaluations與Optimization —— 評估器、A/B、Optimization 的平台細節