前面幾天談過模型選擇、Primary／Fallback，以及不同工作交給不同模型。到了多機器人系統真正開始每天跑之後，我才發現，fallback 不是在設定檔裡多列幾個模型名稱就算完成。

真正要回答的是：誰是主要供應者？什麼情況算失敗？下一個模型能不能接手？切換之後，使用者是否仍然得到可驗證的結果？

這篇整理我在 Hermes Agent 實際處理多 Provider 時，最後收斂出的容錯方法。重點不是「永遠找到一個能回覆的模型」，而是讓系統在故障時仍能維持可預期的服務品質。

一開始的直覺：模型越多越安全

最初的想法很簡單：設定一個主要模型，再加幾個備援模型。主要模型掛了，就換下一個；下一個也掛了，再換最後一個。

這個想法方向沒有錯，但很快會遇到幾個問題：

1. 不同 Provider 的模型識別方式不同，設定欄位也可能不同。
2. 有些錯誤是暫時性錯誤，有些是認證、額度或設定錯誤，不能用同一種方式處理。
3. fallback 模型可能有不同的上下文長度、工具能力與輸出品質。
4. 系統成功產生文字，不代表任務真的完成。
5. 如果同一個模型因不同名稱重複出現在 chain 中，故障時只是在浪費重試時間。

因此，fallback chain 應該被視為一個小型的可靠性設計，而不是模型清單。

我的實際 Provider 分工

目前的設計大致分成三層：

主要 Provider：Nous Portal

主要工作是一般 Agent 對話、需要較完整推理的任務，以及與 Hermes 本身整合較深的操作。它放在 chain 的第一順位，原因不是單純追求模型排行榜上的最強，而是綜合考量延遲、成本、上下文與日常使用體驗。

第一層備援：OpenAI Codex 訂閱

這一層使用 GPT-5.6 Luna，適合固定格式、日常彙整與成本敏感的工作。它的價值在於即使主要 Provider 暫時不可用，系統仍能繼續完成許多標準化任務。

最後保險：GMI Cloud

GMI 放在最後，是因為它涵蓋不同模型供應來源。前面 Provider 發生區域性故障、認證異常或服務不可用時，至少還有一個不同路徑可以嘗試。

完整 chain 可以抽象成：

Primary：Nous
Fallback 1：OpenAI Codex／Luna
Fallback 2：GMI

這個順序不是永久不變的規則。它會隨著價格、延遲、服務穩定性與工作品質重新評估。但順序必須是明確的，不能讓每次重啟後由預設值或模糊設定決定。

fallback_providers 與 fallback_model 的差異

在實際維護時，最容易踩到的是把不同世代的設定欄位混在一起看。

fallback_model 通常表達「某一個模型失敗後，改用另一個模型」。它的概念簡單，但當系統需要跨 Provider 時，光靠單一模型欄位通常不夠清楚。

fallback_providers 則是以 Provider 為單位描述備援順序。這比較適合現在的需求，因為 Provider 不只是模型名稱，還包含認證、API endpoint、模型映射與可用能力。

我在檢查設定時會先確認三件事：

第一，實際使用的欄位是目前版本支援的欄位，而不是從舊文章複製過來的名稱。

第二，Provider 順序與模型順序沒有互相矛盾。例如設定上說先走 Luna，但實際預設模型仍然固定在另一條路徑。

第三，同一個實體模型沒有用不同 alias 重複放入 chain。否則系統看起來有三層備援，實際上可能只是同一個故障點重試三次。

什麼錯誤應該 fallback

不是所有錯誤都適合立刻切換模型。

比較適合 fallback 的情況包括：

• Provider timeout
• 暫時性的 5xx 回應
• 連線中斷
• 明確表示服務忙碌或暫時不可用
• 區域性 endpoint 無法連線

不應該只靠 fallback 解決的情況包括：

• API key 錯誤
• 帳號沒有權限
• 額度用完
• 模型名稱拼錯
• 工具或系統設定本身錯誤
• 請求內容超過所有候選模型的限制

如果是認證錯誤，直接換模型可能只是把真正問題藏起來；如果是工具設定錯誤，換 Provider 也不會讓工具突然變正確。

所以容錯設計至少要把錯誤分成兩類：可以暫時繞過的服務故障，以及必須修正根因的設定故障。

模型能回覆，不代表任務完成

這是我最重視的一點。

假設主要 Provider 掛掉，fallback 模型成功回傳一段文字。從 API 角度看，請求成功了；從系統交付角度看，可能完全沒有完成工作。

例如一個財務日報任務，真正的完成標準包含：

• 讀到正確的 Google Sheet
• 使用指定的完成區與收入欄位
• 排除未完成與預計匯款
• 產生固定格式報告
• 寫入指定輸出位置
• 發送後能讀回確認

fallback 模型只生成一段「看起來像報告」的文字，不能算完成。

因此我的驗證順序仍然是三段式：

本機變更：檔案是否真的產生，內容是否符合規格。

服務載入：設定、程序或 gateway 是否真的讀到最新狀態。

外部效果：目標平台是否出現正確結果，並且可以讀回驗證。

這個原則同樣適用於模型 fallback。Provider 切換成功只是中間事件，不是最後交付。

切換 Provider 時的能力落差

不同模型之間不只差在回答品質。對 Agent 來說，更重要的是能力契約可能不同。

需要特別確認：

• 是否支援相同的工具呼叫格式
• 是否能讀取相同的上下文
• 是否支援要求的輸出格式
• 是否有相同或足夠的上下文長度
• 是否允許相同的並行與 timeout 設定
• 是否會改變中文、Markdown 或 JSON 的輸出行為

如果主要模型擅長長文推理，而備援模型只適合短格式任務，就不能把所有工作不加區分地交給它。比較好的做法是把任務分級：

高風險任務：即使 fallback，也要停在人工確認或重新執行，不可自動宣稱完成。

標準化任務：可以交給成本較低的 fallback，但仍要做格式與資料驗證。

低風險查詢：可以容許較寬鬆的 fallback，優先維持可用性。

一次實際的排查方法

遇到「模型好像沒有 fallback」時，我不會先改一堆設定，而是按照下面順序查：

先看目前實際載入的設定，而不是只看編輯中的檔案。

再確認主要 Provider 的錯誤類型，判斷是 timeout、5xx、認證還是模型名稱問題。

接著從 log 找出 fallback 是否真的被觸發，以及切換到哪個 Provider。

然後用一個低風險測試任務驗證備援模型能否正常回覆。

最後用一個需要工具與外部讀回的測試，確認它不是只有文字回覆成功。

這樣可以避免把「設定看起來正確」誤判成「容錯實際運作」。

我最後留下的設計原則

第一，fallback chain 要短。

候選越多不代表越可靠。每多一層，就多一組認證、能力與觀測問題。通常一個 primary 加兩個不同路徑的 fallback，已經足夠覆蓋大部分日常故障。

第二，fallback Provider 要盡量異質。

如果所有備援都依賴同一個 endpoint、同一組認證或同一個上游服務，表面上有多個模型，實際上仍然只有一個故障域。

第三，記錄切換原因。

至少要知道原本用了誰、為什麼失敗、切到誰、最後任務是否完成。沒有這些資訊，之後無法判斷是 Provider 不穩、設定錯誤，還是某類工作本來就不適合自動 fallback。

第四，不能讓 fallback 掩蓋認證問題。

服務暫時故障可以切換；認證失效要進入認證修復流程。否則系統每天都在用備援撐著跑，直到所有備援一起失效才被發現。

第五，容錯要配合成本管理。

主要模型不一定永遠最划算，備援也不一定永遠比較便宜。要把延遲、token、重試次數、失敗率與任務品質放在一起看，而不是只看單次 API 價格。

結語：容錯的目的，是維持可信賴的交付

多 Provider 的價值，不是讓 Agent 在任何情況下都吐出一段回答，而是讓重要工作在可接受的品質與成本下持續交付。

我的最終配置可以濃縮成一句話：Primary 走 Nous，第一層 fallback 走 OpenAI Codex／Luna，最後由 GMI 提供不同 Provider 的保險；每次切換都必須記錄原因，任務完成仍要靠實際結果驗證。

如果今天只做一件事，我會建議先畫出自己的故障域：哪些服務共用同一組認證、哪些模型共用同一個 endpoint、哪些任務不能只看文字回覆。畫完之後，fallback chain 通常會比原本更短，也更可靠。

真正成熟的 Agent 系統，不是永遠不出錯，而是出錯時知道能不能切換、切換後做了什麼，以及最後到底有沒有完成。