Agent 上線後最難回答的問題是：它到底有沒有變好？
只看使用者滿意度太慢，只看單次 demo 太假，只看平均成功率又會忽略高風險失敗。Amazon Bedrock AgentCore dataset management 的切入點，是讓團隊建立可版本化、可重複執行的 agent 測試資料集。
為什麼 agent 需要固定測試集？
Agent 不像一般 chatbot。它會多步驟推理、呼叫工具、讀寫資料、保留狀態，有時還會產生副作用。
如果每次改 prompt、換模型、加工具都只靠人工試幾題，很容易漏掉 regression。
固定測試集能提供：
| 價值 | 說明 |
|---|---|
| Offline baseline | 改版前後可比較 |
| Regression detection | 找出原本會做、改版後不會做的任務 |
| Risk testing | 測拒答、權限、工具失敗 |
| Cost testing | 測長任務是否失控 |
| Release gate | 上線前自動檢查 |
Online signal 不夠嗎？
Online feedback 很重要，但它有延遲，而且不穩定。
使用者每天問的問題不同，流量組成也會變。今天成功率上升，可能只是簡單問題變多；今天失敗率下降，可能是高風險功能沒人用。
固定 offline baseline 則像 unit test：每次改版都跑同一組任務，才能知道變化來自 agent，而不是流量。
測試集應該包含什麼？
一個 production agent 測試集至少要有：
| 類型 | 範例 |
|---|---|
| Happy path | 正常任務成功完成 |
| Edge cases | 欄位缺失、格式錯誤、模糊指令 |
| Refusal tests | 使用者要求越權或危險操作 |
| Tool failure | API timeout、錯誤 response |
| Permission tests | 無權資料是否被拒絕 |
| Long-running tasks | 多步驟任務是否能維持狀態 |
| Cost guardrails | 是否超過工具呼叫或模型呼叫上限 |
| Human approval | 高風險步驟是否等待批准 |
不要只測 agent 做得到什麼，也要測它知道什麼時候不該做。
測試套件要怎麼長大？
最好的測試案例來自真實事故。
流程可以這樣：
- Agent 在 production 出錯。
- 團隊標記錯誤原因。
- 把該案例轉成測試資料。
- 加入 baseline dataset。
- 修正 prompt、工具或 policy。
- 每次 release 都重新跑。
這樣測試套件會逐漸反映真實風險，而不是只包含一開始想得到的漂亮案例。
評測指標不能只看成功率
Agent 評測可以拆成多個指標：
- 任務成功率。
- 工具呼叫正確率。
- 權限違規率。
- 幻覺率。
- 平均成本。
- 平均 latency。
- 人工接手率。
- 拒答正確率。
- 失敗復原能力。
不同 agent 的指標權重不同。財務 agent 可能更重視權限與正確性，客服 agent 可能更重視 latency 與轉人工時機。
結論
AgentCore dataset management 的重要性，在於把 agent 評測從「感覺它變好了」變成「有固定基準可比較」。
Production agent 不應只靠 demo 或使用者回饋。固定測試集、版本化案例、online signal 與 release gate 要一起存在。
Agent 越能做事，就越需要像軟體一樣測。測試集不是附加工作，而是 production agent 的安全地基。