以下案例經去識別化處理

這篇分享的情境來自實務觀察，機構名稱、系統細節、具體數字皆已改寫，僅保留方法論本身有參考價值的部分。

情境：轉接率在兩天內從 6% 升到 31%

某企業的客服 Agent 運行數月一直穩定，某個週三開始，人工轉接率明顯上升。這正是 Day 1 開場提到的場景，這裡完整走一遍用可觀測性排查的流程。

第一步：從告警到定位範圍

行為異常告警（Day 22 設計的那類）在轉接率偏離 7 日基準線時觸發，出現在每日摘要中。工程師打開 Dashboard，先確認幾件事：

• 是全面性還是特定類型？ 依任務類型分組後發現，只有「帳務查詢」這一類的轉接率暴增，其他類型正常。範圍立刻縮小。
• 技術指標有異常嗎？ 錯誤率、延遲、可用性都正常——所以不是系統故障。
• 時間點對應到什麼？ 上升起點大致對應到某次例行部署。

第二步：從聚合資料到單次執行

挑一次代表性的轉接執行，打開 Trace（Week 3 的能力），看到的 Span 樹顯示：Agent 呼叫了帳務查詢工具、工具成功回傳（沒有錯誤）、然後 Agent 下一步就選擇轉接人工。

這裡出現了關鍵疑問：工具明明成功了，為什麼 Agent 還是決定轉接？

第三步：從 Trace 跳到日誌

從該 Span 跳轉到對應日誌（Day 17 設計的關聯能力），看到那一步的 decision_summary 大意是：工具回傳的資料缺少必要欄位，無法組出完整回應。

再看工具回傳結果的紀錄，發現回傳的 JSON 結構確實少了一個欄位——這是上游系統在那次部署中做的一個「無害的」欄位重新命名。

根因與修復

上游團隊改了欄位名稱，認為這是內部實作細節；但 Agent 的工具接口依賴這個欄位，欄位消失後工具「技術上成功、實質上無用」，Agent 判斷資訊不足，於是走了轉接人工這條保守路徑。

這個案例的關鍵在於：所有技術指標都正常。 沒有錯誤、沒有超時、沒有失敗——傳統監控完全看不到問題。能抓到根因，靠的是三個設計：任務品質層級的指標（發現異常）、Trace（看到工具成功但仍轉接的矛盾）、決策日誌（看到 Agent 判斷資訊不足的理由）。

三個可帶走的教訓

教訓一：技術指標正常不代表沒問題。 Agent 系統需要任務品質層級的監控，這是 Day 20 的核心論點在真實場景的驗證。

教訓二：decision_summary 這個欄位值得那些額外工夫。 如果日誌只記錄「呼叫工具 → 轉接人工」，這個案例的排查會困難得多。

教訓三：Agent 的上游依賴需要納入變更管理。 上游團隊不知道自己的欄位改動會影響 Agent 行為——這是組織流程問題，不是技術問題。

這篇的檢查清單

• [ ] 現有監控能否偵測「技術指標正常但任務品質下降」的狀況？
• [ ] Agent 依賴的上游系統變更，是否有納入影響評估？

💡 關於作者 我是 Fngi，專注在 AI 安全與雲端資安領域。如果這篇對你有幫助，歡迎追蹤 Instagram @aid3fend，我在那裡分享更多 AI 資安的實務筆記與趨勢觀察。