AI Agent 出錯時要怎麼收？例外、轉人工與操作紀錄

先列出它不該硬撐的幾種情況

每條流程的例外不盡相同，但有幾類幾乎都會出現。資料不夠：缺訂單編號、缺公司統編、對話裡用暱稱對不到客戶。超出範圍：問到報價折扣、法律責任、其他部門的事。工具失敗：CRM 逾時、重複建檔、通知沒送出。低把握：知識來源互相衝突，或根本找不到依據。還有一種常被忽略：使用者已經在生氣，或明確要求找人。

這些情況不該共用同一句「請稍後再試」。缺資料時應問還缺什麼，或請人補件；超出範圍應停止推測並轉交；工具失敗要留下半成品和錯誤原因；低把握則把依據不足標出來，而不是換一種說法再講一次。分類愈清楚，後面的人工佇列才不會變成一個什麼都往裡丟的黑洞。

例如客服 Agent 遇到「我上次那個能不能退」。沒有訂單編號、也沒有退貨政策來源時，比較安全的路徑是收集必要資訊並轉給有權限的人，而不是先安慰再猜一種退款說法。語氣可以溫和，權限不能跟著溫和。

• 缺資料：列出缺口，不要填假的完整答案
• 超範圍：停止動作，保留上下文後升級
• 工具失敗：記錄錯誤、可重試次數與目前狀態

轉人工要帶著脈絡，而不是只丟一句「請洽專人」

客戶最受不了的，是跟機器人講了五分鐘，轉到人之後又從頭說一次。內部也一樣。若 Agent 只在後台產生一張空白工單，值班人員還是得回去翻聊天紀錄。轉交時至少應帶原始問題、已嘗試的查詢、引用來源、卡在哪一條規則，以及建議的下一步。

人工佇列也要有主人。誰在營業時間看、逾時誰接手、假日怎麼辦，都要比模型參數更早講清楚。否則「會轉人工」只是一句安心的話，晚上和週末仍然沒人接。

AgentTech 設計轉交時，會把 Agent 的中間結果當成待確認案件，而不是失敗紀錄。很多時候它已經整理出有用的摘要，人要做的是判斷和放行，不是重做一遍。這也讓團隊比較能接受：轉人工不是 Agent 沒用，而是流程依規則把風險交給對的人。

操作紀錄要能回答「當時為什麼這樣做」

日誌若只存完整對話，出事時仍然很難查。比較有用的是結構化事件：何時觸發、讀了哪些資料識別碼、呼叫了哪個工具、回傳成功或失敗、哪一條規則把關、誰在何時核准。內容本身可以依個資規則保存或遮罩，但事件鏈要能還原。

這對內部溝通也很實際。業務說 Agent 建錯客戶，工程可以對出當時用的電話與來源表單，而不是各憑印象。之後要調整提示詞或規則，也才知道改的是哪一段，而不是整組重訓的模糊感覺。

保留多久、誰可以看，要和現有的客戶資料政策一致。Agent 不是另類資料庫，不該把聊天紀錄無限期堆在模型供應商能看到的地方。能存在自己系統裡的狀態與事件，就不要只依賴第三方的會話歷史。

重試要有限度，回復也要想過

工具呼叫失敗時，盲目重試可能建出兩筆客戶、寄出兩封通知。哪些動作可重試、要以什麼鍵值去重，必須在設計時寫下。建立客戶可以用來源訊息編號去重；送通知則要能查出「這筆已經送過」。

有些動作失敗後要能回復，有些只能標記為需人工處理。例如草稿可以作廢；已經對客戶送出的訊息沒辦法默默收回，只能留下紀錄並由人決定要不要更正。不要假設 Agent 永遠能「再試一次就好」。

用例外原因改善流程，而不是只盯著成功率

成功率高很好看，但例外原因更有資訊。若大量失敗是缺訂單編號，也許表單該改、或 LINE 選單該先問編號。若大量是知識衝突，該整理文件而不是把模型換大。若大量是超出範圍，可能是對外說明讓人以為它什麼都能決定。

試點驗收時，除了準備成功案例，也要準備故意缺件、故意越權、故意讓 API 失敗的例子。能正確地停、正確地轉、正確地留下紀錄，這條 Agent 才算能進正式環境。只會在完美輸入上表演，還不算進營運。