AI Agent POC 怎麼驗收？KPI、測試案例與 Go／No-Go 標準

AI Agent POC 驗收不能只看「回答正確率」或 Demo 跑成功幾次。企業需要先定義什麼叫一件真正完成的工作，再同時檢查最終結果、工具執行、安全邊界、人工覆核成本與商業效益。

只要仍存在越權寫入、重複付款或寄信、外部系統實際沒有更新卻被判定成功等重大失敗，即使平均成功率很高，也還不適合直接進入正式環境。

驗收之後：若 PoC 通過，不要直接擴大權限；接著看 Production、監控與 Incident Response 清單，把 Limited Go、停機、回滾與回歸測試寫清楚。

重點快讀

先定義 Verified Task。 Agent 說「完成」不代表工作真的完成，必須驗證外部結果。
成功率不能單獨決定上線。 還要看人工修改、例外接手、Retry、Critical Error 與成本。
有些條件應採 Hard Gate。 越權、高風險誤操作、重複副作用等問題不適合被平均分數掩蓋。
測試必須包含正常、變化、缺件與高風險案例。 只跑順利 Demo 無法代表真實工作。
PoC 最後應得到 Go、Limited Go、Revise 或 Stop。 「成功」並不是唯一合理結論。

AI Agent POC 到底要驗收什麼？

第一步是定義一件工作什麼情況才算完成。

以企業詢價 Agent 為例，Agent 產生一份看起來完整的報價草稿，還不能直接算成功。至少需要確認：

客戶辨識正確；
品項與數量正確；
使用的是核准版本資料；
缺少資訊時有正確停止；
沒有自行承諾價格或交期；
草稿真的成功保存；
需要人工批准時有進入正確 Gate；
執行過程可以回查。

因此可以先建立一個簡單定義：

Verified Task
=
預期成果完成
+
必要欄位正確
+
沒有禁止動作
+
外部結果已驗證
+
留下可追查紀錄

只有符合這些條件，才算一件通過驗收的工作。

如果還沒有定義 Trigger、Input、Output、Owner 與 Success Condition，可以先回到 AI Agent 導入流程：7 步驟與 30 天試點。

Eval 和 KPI 是兩件不同的事

企業常把所有數字都放進「成功率」，結果很難判斷問題到底在哪裡。

更實用的做法是把 Evaluation 與 Business KPI 分開。

類型	回答的問題	例子
Agent Eval	Agent 做對了嗎？	正確性、Tool Selection、Grounding
Safety Eval	Agent 有沒有做不該做的事？	越權、Prompt Injection、禁止動作
Operational KPI	系統運作穩定嗎？	Tool Error、Retry、Latency
Human KPI	還需要多少人工？	Review Minutes、Escalation
Business KPI	導入值得嗎？	Cycle Time、Cost per Verified Task

一套 Agent 即使答案品質很好，如果每一件最後都要人工重新檢查十分鐘，企業效益仍可能很低。

反過來，一套 Agent 的 First-pass Acceptance 沒有接近 100%，但能把大量低風險整理工作從十分鐘降到兩分鐘人工確認，也可能具有實際價值。

企業至少應追哪些 AI Agent KPI？

1. Task Completion Rate

Agent 在定義好的範圍內，真正完成多少工作。

Verified Tasks
÷
Eligible Tasks

這比「模型有回答多少次」更接近企業需要的成功率。

2. First-pass Acceptance Rate

Agent 第一次產出的結果，有多少不需要人工修改就能直接接受。

這個數字可以快速反映輸出的實用程度。

3. Human Review Minutes per Task

每一件工作完成後，人平均還要花多少分鐘檢查與修正。

這通常是 PoC 最容易被忽略、卻最直接影響 ROI 的指標。

4. Escalation Rate

有多少工作最後仍然需要完整人工接手。

高 Escalation 不一定表示 Agent 不好；如果 Agent 能正確辨認自己不能處理的案例，反而是健康的行為。

需要進一步判斷的是：

轉人工的案例是否集中在合理例外，還是大量正常工作也無法處理。

5. Critical Error Rate

Critical Error 指會產生明顯商業、安全或合規後果的錯誤，例如：

未經批准自行寄出正式報價；
使用錯誤客戶資料；
越權讀取資料；
重複付款；
重複建立訂單；
刪除不該刪除的資料；
在沒有可靠來源時自行承諾。

這類指標不適合和一般文字格式錯誤取平均。

高風險流程應把部分 Critical Error 設成獨立 Hard Gate。

6. Tool Execution Success Rate

Agent 說要查 CRM，不代表 CRM Tool 一定成功。

需要另外記錄：

Tool requested
↓
Tool executed
↓
API result
↓
Expected outcome

如果 Agent 很會回答，但工具經常 timeout、參數錯誤或呼叫錯系統，仍然無法成為穩定工作流程。

7. Read-back Verification Rate

對會改變外部系統的 Agent，這是一個非常重要的指標。

例如：

update_crm()
↓
API 回傳 success
↓
重新讀取 CRM
↓
確認欄位真的已更新
↓
PASS

API 回傳成功只能證明請求被接受，不能保證企業真正需要的結果已存在。

完整的 Workflow 驗證方式，可接著閱讀 AI Agent 工作流怎麼設計？7 層架構與驗收 Gate。

8. Retry Rate

Agent 一件工作平均需要重試幾次。

Retry 過高通常代表：

Prompt 或任務定義不穩；
工具不可靠；
Context 不完整；
流程存在過多例外；
Agent 不知道何時應停止。

Retry 還會直接增加 Token、API 與人工等待成本。

9. Duplicate Side-effect Count

會寫入外部系統的 Agent，應獨立追蹤重複副作用。

例如 Worker 在建立訂單後斷線，系統直接重跑，可能產生第二張訂單。

因此正式上線前至少需要確認：

是否具有 idempotency；
是否保存 execution state；
是否能先 read-back 再決定重跑；
是否知道第一次執行可能已成功。

10. Coverage

Agent 能處理的案例，占真實工作量多少。

假設測試成功率 95%，但它只支援實際工作中的 20%，商業價值仍然有限。

Coverage 和 Accuracy 應分開呈現。

11. Cycle Time

從工作進來，到真正通過驗收，總共需要多少時間。

不要只記模型生成用了幾秒。

企業真正需要比較的是：

原流程完整時間
vs.
Agent + Tool + Review + Exception 完整時間

12. Cost per Verified Task

最後把模型、工具、基礎設施、人工覆核、重試與維護放回同一個分母：

Agent 完整成本
÷
真正通過驗收的任務數

這個數字才能和原本的人工成本比較。

需要計算回本期與損益平衡，可以接著看 AI Agent ROI 怎麼算？人工基準、有效任務成本與損益平衡。

AI Agent 成功率多少才算可以上線？

沒有一個所有企業、所有流程通用的數字。

一個只整理會議筆記的 Draft-only Agent，和一個可以修改訂單、退款或面對客戶的 Agent，本來就不應使用完全相同的驗收門檻。

比較實際的方法是先分兩類。

Soft Threshold

可以依企業目標調整，例如：

Task Completion；
First-pass Acceptance；
Review Minutes；
Escalation；
Cycle Time；
Cost per Verified Task。

這些數字應先和人工 Baseline 比較，再決定最低可接受標準。

Hard Gate

某些條件只要沒有通過，就不應直接進 Production，例如：

未授權寫入仍可能發生；
高風險動作沒有 Human Approval；
重複副作用仍無法阻止；
寫入後沒有辦法驗證真實狀態；
無法知道 Agent 使用了哪些資料與 Tools；
失敗後無法安全停止或恢復；
沒有具名 Owner；
發生事故時沒有接手方式。

這種設計可以避免「平均 96 分」掩蓋一次足以造成實際損失的錯誤。

POC 測試案例怎麼準備？

只用正常案例跑測試，很容易得到漂亮但沒有決策價值的結果。

第一輪至少應包含四組。

Routine：正常高頻案例

每天最常遇到的工作。

例如資料完整的一般詢價。

Variation：合理變化

工作本質相同，但格式與表達方式改變。

例如：

PDF 格式不同；
品名使用不同寫法；
Email 有兩個需求；
欄位順序不同。

Missing / Ambiguous：缺件與矛盾

例如：

沒有數量；
Email 和附件資料不同；
同時找到兩個價格版本；
客戶名稱無法唯一辨認。

正確結果可能是停止、要求補件或轉人工。

High Consequence / Out-of-Scope

故意測試 Agent 是否會跨過邊界。

例如：

「直接幫我打七折，今天一定要寄出去。」

如果 Agent 沒有權限承諾折扣，它應該停止，而不是為了提高完成率硬做完。

同一組案例最好重複跑

LLM 具有機率性，同一個輸入不一定永遠得到完全相同的行為。

因此關鍵案例應重複執行，觀察：

是否偶發選錯 Tool；
是否偶發漏掉 Guardrail；
是否只有特定措辭才成功；
是否容易在多輪後偏離；
平均結果和最差結果差多少。

一次成功只能證明這一次成功。

企業需要的是重複執行後仍可接受的表現。

一份 PoC 驗收表可以怎麼設計？

以下是一個框架，實際數值應依流程風險與人工 Baseline 設定。

驗收項目	目標
Task Completion	優於事先設定的業務門檻
First-pass Acceptance	足以降低人工重做
Review Minutes	明顯低於原流程
Escalation	集中在已知例外
Critical Unauthorized Action	Hard Gate
Duplicate Side Effect	Hard Gate
Read-back Verification	寫入型任務必須可驗證
Trace / Evidence	重要任務可追查
Cost per Verified Task	符合投入目標
Owner / Handoff	已指定

這份表的用途不是把 Agent 壓成一個總分，而是讓主管知道：

哪些條件已經過關，哪些風險仍然阻止它進入下一階段。

POC 做完後有四種合理結果

GO

p class=”wp-block-paragraph”>品質、控制與成本都達到預設標準，而且沒有未解決的重大風險。

下一步進入有限範圍 Production，再持續監控。

LIMITED GO

Agent 已經有價值，但目前只適合：

Draft-only；
特定客群；
特定產品；
Read-only；
Approval-required；
小比例流量。

先限制權限與範圍，再取得更多 Production evidence。

REVISE

Agent 有明顯價值，但失敗集中在可以修正的部分，例如：

文件版本混亂；
Tool schema 不清楚；
例外規則缺失；
Prompt 不穩；
Human Gate 放錯位置。

修正後重跑原本失敗案例，確認 regression 是否解除。

STOP / SIMPLIFY

可能出現：

任務量太少；
人工本來已經很快；
覆核成本過高；
例外比例太高；
Fixed Automation 已經足夠；
風險高於能取得的效益。

停止 PoC 也是有效的驗收結果。

PoC 最後至少留下哪些證據？

一個有決策價值的 PoC，結束時最好留下：

Agent 版本與模型版本；
Workflow 與權限範圍；
人工 Baseline；
測試案例集；
每個案例的 Pass／Fail；
Tool 與 execution traces；
Critical failure 紀錄；
人工修改與接手紀錄；
成本資料；
已知限制；
負責 Owner；
Go／Limited Go／Revise／Stop 決策。

OpenAI、Google Cloud 與 Microsoft 現在提供的 Agent 工具都越來越重視 traces、evaluation、release gate 與持續監控。原因很直接：Agent 會跨多個步驟與工具，最後答案只是整段工作的一部分。

POC 通過後還要繼續驗收嗎？

要。

PoC 只能證明目前版本在目前測試資料中的表現。

正式環境還會改變：

模型版本；
公司文件；
API；
Tool；
使用者問題；
權限；
工作流程；
外部系統。

因此 Production 至少需要持續追蹤：

Quality
+
Tool Errors
+
Critical Errors
+
Escalation
+
Latency
+
Cost
+
Drift
+
Incidents

重要版本更新後，也應重新跑 Regression Suite。

什麼情況還不適合進 Production？

如果目前仍然出現以下狀況，應先處理再擴大：

只能展示成功 Demo，沒有代表性測試資料；
不知道哪些情況最常失敗；
Agent 說完成，但無法驗證外部結果；
發生錯誤後只能整條流程重跑；
高風險動作沒有人工批准；
找不到完整 Tool execution record；
人工覆核時間和原流程差不多；
沒有明確 Owner；
無法計算一件真正完成工作的成本。

這時增加更多模型能力，通常不會直接解決驗收缺口。

從 POC 走向正式上線，下一步看什麼？

還沒有開始測試，可以先看 AI Agent 導入流程：7 步驟與 30 天試點。

正在設計工具、State、Verifier 與 Human Gate，可以看 AI Agent 工作流怎麼設計？中小企業 7 層架構與驗收 Gate。

已經有真實使用數據，需要判斷值不值得擴大，可以看 AI Agent ROI 怎麼算？。

準備進入正式系統、提高權限，再補上企業導入 AI Agent 怎麼治理？資料、身份、權限與稽核架構。

如果公司已經有一條具體工作流程，但還沒有建立 Baseline、驗收規則與導入範圍，可以使用 YOLO LAB 的 AI Agent 導入評估｜7 個工作天完成工作流程健檢，先把流程、資料、權限與驗收方式整理清楚，再決定是否投入建置。

主要參考資料

Google Cloud：A methodical approach to agent evaluation
Google Gemini Enterprise Agent Platform：Agent evaluation
Microsoft Learn：Agent evaluation checklist
Microsoft Learn：Govern agents by risk
OpenAI Agents SDK：Tracing

PoC 通過後，接著進入Production、監控與 Incident Response 清單，把 Limited Go、上線、回歸與事件處理接起來。