---
title: "AI 客服 API 當機怎麼辦？Timeout、Retry、熔斷與人工降級標準"
description: "AI 客服遇到上游 API timeout、429 或 5xx 時，不能無限重試。本文整理 timeout、backoff、circuit breaker、靜態 FAQ、人工轉接與高風險寫入的驗收標準。"
canonical: "https://yotron-ai.com/blog/ai-customer-service-api-outage-circuit-breaker"
published: "2026-09-16"
last-updated: "2026-09-16"
---

# AI 客服 API 當機怎麼辦？Timeout、Retry、熔斷與人工降級標準

AI 客服遇到上游 API timeout、429 或 5xx 時，不能無限重試。本文整理 timeout、backoff、circuit breaker、靜態 FAQ、人工轉接與高風險寫入的驗收標準。

AI 客服 API 當機時，正確行為不是繼續重試到恢復，而是快速停止風險操作，切換到靜態 FAQ、人工轉接或收件後回覆。Timeout、retry、backoff、circuit breaker 與 idempotency 必須在程式和 SLA 兩邊同時存在，才能避免小故障變成重複訂單或錯誤承諾。

優創智能或其他導入廠商若把 AI 客服接到模型、LINE OA、ERP、CRM 或促銷服務，企業應要求以故障注入做驗收。本文的數值是可用來開始談判與壓測的示意參數，不是服務保證或法律意見。

## AI 客服 SLA 不能只寫 uptime

### 四個可用性層次要分開看

平台網頁正常，不代表顧客能查到訂單；模型回應正常，也不代表 CRM 寫入成功。SLA 至少要拆成下列層次：

| 層次 | 觀察內容 | 失效時的影響 |
| --- | --- | --- |
| 平台 | 網站、Webhook、排程是否可用 | 客服入口可能完全失效 |
| 模型 | 上游模型回應、延遲、錯誤率 | 生成與分類停滯 |
| 資料整合 | ERP、CRM、訂單、促銷 API | 不能保證即時資料正確 |
| 人工接手 | 轉人工、工單與回電流程 | 決定顧客是否被遺漏 |

合約如果只有「每月 uptime 99.9%」，仍沒有回答上游模型掛掉時要不要切換、人工多久接手，以及錯誤折扣或重複退款由誰處理。

## Timeout、Retry 與 Circuit Breaker 建議值

### 從可觀測的基準開始設定

先量測正常時的 P50、P95、P99 延遲、429／5xx 比例與實際客服可接受等待時間，再設定門檻。沒有基準時，可以把以下表格當作 PoC 起始討論值：

| 控制項目 | 建議起始值 | 驗收方式 |
| --- | --- | --- |
| 互動請求 timeout | 目前 P95 延遲加 20% 的硬上限 | 模擬慢回應與連線中斷 |
| 讀取型 retry | 0–1 次，exponential backoff + jitter | 確認不放大上游流量 |
| 寫入型 retry | 沒有 idempotency key 時禁止自動重試 | 模擬重複訂單與重複折扣 |
| 開啟熔斷 | 連續 5 分鐘錯誤或 timeout 超過 5% | 切到靜態 FAQ 或人工 |
| 半開探測 | 熔斷 60 秒後少量測試 | 恢復前不大量放流 |
| 關閉熔斷 | 連續探測成功且錯誤率回到門檻內 | 驗證逐步恢復 |

這些值不能脫離服務量與風險使用。客服查詢可以容忍短暫降級，付款、退款、庫存或折扣寫入則應優先保護資料一致性。

### 為什麼寫入型請求不能照搬讀取型 retry？

讀取失敗再查一次，通常只增加延遲；寫入失敗再做一次，可能新增第二筆訂單、重複發送折扣或重複建立 CRM 活動。寫入工具至少要有 idempotency key、結果查詢與人工處理狀態，否則寧可停下來建立待辦。

```text
請求送出
→ timeout／429／5xx
→ 查詢請求是否已被接受
→ 有 idempotency key 才允許安全重試
→ 無法確認時轉人工，不重複寫入
```

## API 故障時的 AI 客服降級路徑

### 降級不是顯示一個紅色錯誤頁

對顧客而言，系統應提供可完成的下一步。建議依風險設計：

| 情境 | 降級方式 | 不應做的事 |
| --- | --- | --- |
| FAQ 查詢失敗 | 提供已快取且有版本的靜態答案 | 用模型自由猜測 |
| 訂單查詢失敗 | 建立人工查詢工單 | 回傳舊訂單狀態當最新狀態 |
| CRM 建單失敗 | 暫存必要資訊並提示稍後處理 | 反覆建立多張工單 |
| 折扣服務失敗 | 停止發放，轉人工核准 | 自行產生折扣碼 |
| 模型完全不可用 | 靜態 FAQ、人工、Email 回覆 | 把內部錯誤與堆疊資訊外露 |

靜態 FAQ 也要標示版本和有效期。若政策、價格或庫存已不確定，顯示「暫時無法確認」比提供過期答案安全。

### 轉人工時要保留哪些上下文？

人工收到的內容至少要包括使用者已驗證的身分狀態、問題摘要、已查詢的資料來源、失敗類型、請求 ID、是否曾嘗試寫入以及需要人工決定的欄位。不要把整份含個資的原始對話無限制轉交給所有客服。

## AI 客服故障演練與事件後檢查

### 每次模型或 API 更新都應重跑什麼？

至少模擬：timeout、429、5xx、DNS 或網路中斷、認證失效、回傳格式錯誤、半開恢復、重複點擊、人工接手失敗與靜態答案過期。演練結果要記錄時間、版本、錯誤率、切換時間、遺失案件與復原步驟。

事件後的根因分析不應只寫「上游服務異常」。要再問：是否有無限 retry、是否誤把讀取策略用到寫入、是否通知了人工、是否能辨識已成功但未收到回應的交易，以及哪些監控在故障前就已經升高。

AWS [REL05-BP05 可靠性指引](https://docs.aws.amazon.com/wellarchitected/2024-06-27/framework/rel_mitigate_interaction_failure_client_timeouts.html)也把 timeout、retry、backoff 與避免副作用操作重複執行列為互動失敗的設計重點。

## 優創智能 AI 客服 SLA 應要求寫清楚什麼？

詢問[AI 客服服務](/services/ai-applications/ai-customer-service)時，可把以下欄位放進書面規格：

1. P1／P2／P3 事件定義、首次回應與緩解時間。
2. 平台、模型、串接與人工服務的可用性計算方式。
3. timeout、retry、熔斷、半開探測與降級行為。
4. 高風險寫入的停用、查詢已接受狀態與人工處理。
5. 請求 ID、模型／規則版本、事件時間線與根因報告。

真正成熟的 AI 客服不是永遠回答，而是在不能可靠回答時知道如何停下來。企業可以先用只讀 FAQ 做故障演練，再逐步加入訂單、CRM 或折扣流程，將容災能力當成導入驗收的一部分。