先區分故障類型，再決定是否切換
模型 API 回傳錯誤只是最明顯的異常。實務上還會遇到連線逾時、限流、串流中斷、回應格式不符、工具呼叫參數錯誤、安全過濾突然變嚴，以及模型雖然成功回覆但品質明顯下降。若系統把所有問題都視為同一種故障並立即切換，可能把應用程式本身的提示詞、資料或程式錯誤帶到下一家供應商，造成連鎖失敗與重複成本。
因此，路由層應先把錯誤分成可重試、可切換、應立即停止三類。短暫網路錯誤可以在有限次數內重試；限流或區域性服務異常適合切換端點或供應商；驗證失敗、權限錯誤、敏感資料政策衝突與明確的輸入錯誤則不應盲目重送。逾時也應依任務設定：互動式助理需要快速回應，離線文件摘要則可以排隊等待，兩者不應共用同一組門檻。
用能力契約管理模型，而不是只替換名稱
備援模型必須符合應用需要的能力契約。除了文字生成，還要確認上下文長度、繁體中文表現、結構化輸出、函式或工具呼叫、影像輸入、安全規則、資料落地區域及供應商的資料保留設定。聲稱相容同一 API 格式，不代表語意、錯誤行為與輸出穩定性相同；尤其 RAG、ERP 寫入與多步代理流程，常依賴非常具體的格式和工具選擇。
我們通常為每一類工作建立路由設定，而不是設定一個全站通用的第一順位與第二順位。知識問答、文件擷取、分類、程式碼生成與具副作用的工具操作，應有各自的候選模型、逾時、重試與驗證規則。
- 能力符合度：候選模型是否支援必要的結構化輸出、工具呼叫與上下文容量。
- 風險邊界：資料是否允許送往該區域與供應商，日誌及提示內容應如何遮罩。
- 輸出相容性：欄位名稱、列舉值、引用格式與工具參數能否通過同一套驗證。
- 成本與容量：備援路徑是否能承受尖峰流量，降級後是否需要縮短上下文或限制輸出。
- 任務重要性：低風險查詢可以接受較弱模型，付款、建檔或權限操作則可能應暫停。
建立分層降級，而非只有主備切換
可靠的降級策略通常是一條能力階梯。第一層可在同一供應商內切換區域、部署或等級相近的模型，降低輸出差異；第二層才切到另一家供應商，並套用經過測試的提示模板與輸出轉接器；第三層縮小功能，例如停用影像、減少檢索文件、縮短對話歷史或改用純文字回答；最後一層則回傳快取結果、提供搜尋連結、建立稍後處理的工作，或清楚告知使用者目前無法安全完成。
降級必須保留業務語意。若企業助理無法取得最新 ERP 資料，不應用舊資料生成看似確定的答案；若 LINE 機器人無法完成訂單寫入，也不應只回覆成功訊息。系統應把回答能力與執行能力分開：前者可以切換到較小模型，後者則必須依冪等鍵、交易狀態與驗證結果決定重試、排隊或停止。
- 對唯讀問答，可切換模型並標示資料時間與引用來源。
- 對長時間生成，可保存工作狀態，改由背景佇列延後處理。
- 對具有副作用的操作，先查詢交易結果，再決定是否重送，避免重複建單或通知。
- 對無法維持安全或格式保證的功能，直接停用通常比產生不可信結果更好。
讓切換可觀測、可演練，也能安全切回
路由服務至少要記錄供應商、模型、區域、任務類型、逾時階段、重試次數、切換原因、驗證結果與最終降級層級，同時避免把敏感提示或完整文件直接寫入日誌。監控不能只看 HTTP 成功率；還要觀察首字延遲、完整回應時間、空回覆、JSON 驗證失敗、工具呼叫失敗、引用缺漏、內容過濾與佇列累積。這些訊號共同決定是否啟動斷路器，而不是靠單一錯誤碼。
斷路器應有冷卻時間、有限探測流量與明確的恢復條件。供應商恢復後，不宜立刻把所有流量切回；先以健康檢查或影子請求驗證延遲、格式及關鍵任務品質，再逐步恢復。若同時送出競速請求以降低尾端延遲，必須控制額外成本，並確保任何可能觸發工具或寫入的請求只會執行一次。
最後，定期演練比文件更能發現問題。測試應涵蓋逾時、限流、串流中斷、格式損壞、單一區域失效、主要與備援供應商同時不可用，以及復原後切回。每次演練都要確認使用者看到的訊息、告警責任人、佇列處理、交易一致性與事後追蹤。整合團隊的價值不只是接上第二個 API，而是把模型、資料、流程與營運控制組成一套真正可預期的系統。