（系列：《AI 維運實戰：我用 Hermes 把 Agent 變成企業同事的 30 天》）
（主題：將 AI 模型整合進實際系統與產品的工程實踐）

模型選得再好，只要上游暫時故障，Agent 就可能整個停住。

我遇過的情況不是模型能力不足，而是主 Provider 呼叫失敗。對聊天助手來說，重按一次也許可以接受；對定時財務報告、社群雷達或無人值守的 Cron，失敗就代表今天沒有交付。

因此我開始把模型路由分成兩件事：Primary 決定平常由誰工作，Fallback 決定主路徑失效後，系統能不能繼續完成這一輪。

────────────────────────────────

Fallback 不是換一個模型名稱

真正的容錯，要避開同一個故障域。

如果主模型與備援模型共用同一個 Provider、同一組認證或同一個 API 入口，遇到帳號失效、額度耗盡或服務中斷時，兩條路可能一起倒下。模型名稱不同，不代表基礎設施真的獨立。

我後來用 provider:model 當路由身份檢查重複，而不是只看模型名。設計順序也改成：先選能接手日常工作的不同 Provider，再放最後保險。

當時的分工是：主路徑負責日常任務，OpenAI Codex 的 Luna 作第一備援，GMI 作最後保險。這不是永久不變的排行榜，而是當下依品質、成本、授權方式與故障域做出的配置。Provider 或模型狀態改變，順序就要重評。

────────────────────────────────

第一個坑：我同時看見兩代設定欄位

早期設定中，我看到的是單一備援欄位 fallback_model。它只能描述一組 Provider 與模型。後來 Hermes 的現行格式改為 fallback_providers，用清單表示多個備援，並依順序嘗試。

這裡最容易踩的雷，是以為兩個欄位會合併。實際規則是：舊的 fallback_model 仍為相容性保留；若兩者同時存在，新的 fallback_providers 優先。

也就是說，舊欄位裡即使還留著 GMI，新的清單若只有 Luna，執行時也不能想當然地認為會自動形成「Luna → GMI」。設定檔看起來有兩份備援，不等於有效鏈真的有兩層。

我的修正方式不是繼續堆欄位，而是把有效順序收斂到同一份清單，逐項明確填入 provider 與 model。缺少任一欄的項目會被忽略，所以不能只寫服務商名稱，也不能依賴工具猜模型。

────────────────────────────────

第二個坑：設定存在，不代表備援可用

Fallback 不是一張願望清單。每一條路都需要自己的認證、正確模型識別與可連線端點。

主 Provider 正常時，錯誤的備援可能長期藏著。直到真正發生 429、401、403、404、伺服器錯誤，或上游持續回傳空內容，系統才切換；此時才發現備援 Token 過期，已經太晚。

所以我把驗證拆成三層：

1. 設定層：確認有效欄位、順序及 provider:model 沒有重複。
2. 認證層：每個 Provider 分別通過登入或 API preflight。
3. 故障層：刻意讓主路徑不可用，確認實際請求由備援完成，而不是只看到程式結束。

真正的驗收證據應包含使用到的 Provider、模型、任務輸出，以及訊息或排程結果。只有 YAML 寫入成功，不能算容錯完成。

────────────────────────────────

切換有代價，不該無限串接

Fallback 保住可用性，卻不是免費午餐。

模型切換後，原本依 Provider 與模型建立的 Prompt Cache 通常無法沿用。長對話需要重新讀取上下文，輸入成本與延遲都會上升。不同模型的工具使用習慣也可能不同，固定格式輸出仍要重新驗證。

因此我不追求十幾層備援。鏈越長，認證越多，維護面越大，也越難判斷最後到底由誰完成。比較務實的做法，是保留少量、角色清楚、真的測過的路徑。

Hermes 的切換以每一輪為單位。某輪主模型失敗後可改由備援接手；下一輪仍會重新嘗試主模型。這避免短暫故障讓整個 session 永久漂到備援，也避免操作人員忘了切回。

────────────────────────────────

今天的結論

企業 Agent 的可靠性不能只看模型回答得多聰明，還要看上游故障時能否繼續交付。

Primary 是平常的品質與成本選擇。Fallback 是故障時的生存設計。兩者必須跨故障域、明確排序、分別認證，並用真實切換測試驗證。

我最大的教訓是：設定檔裡出現備援名稱，不代表備援鏈真的成立。先釐清 fallback_model 與 fallback_providers 的優先規則，再檢查每個 provider:model 身份，最後用失敗情境驗收，才算把 Agent 從「偶爾能用」推進到「可以值班」。

下一篇 D7：模型能容錯後，還需要一套不隨對話漂移的行為規則。我會拆解 SOUL.md／USER.md，說明共通原則與各 Bot 專屬身份為什麼不能混在一起。