你有沒有想過，如果你每天依賴的 AI 服務突然掛了，你的工作流會怎樣？
我想過。但「想過」跟「真的遇到」是兩回事。
災難的開始
那天早上我照慣例打開電腦，準備讓 AI Agent 幫我處理一些開發任務。結果迎接我的是一個冰冷的數字：529。
HTTP 529，Anthropic 的 overloaded 回應。好吧，API 偶爾抖一下很正常，等等就好了。
等了十分鐘。還是 529。
等了三十分鐘。還是 529。
打開 Anthropic 的 status page，上面寫著「Degraded Performance」。好，那就等。身為一個把大量工作流建立在 Claude 上的技術主管，我能做的就是——等。
然後我等了一整天。
24 小時內第二次
更慘的是，這不是第一次。前一天也掛了一次，只是時間比較短，我僥倖覺得是個案。結果隔天又來，而且這次是全天性的大規模故障。
這時候我才認真面對一個事實：我的整個 AI 工作流是單點故障的。
我的 Agent 系統跑在 OpenClaw 上，主力模型是 Claude Opus。Sub-agent 派工、程式碼審查、郵件處理、甚至每日站會報告——全部吃 Anthropic API。一掛，全停。
第一個念頭：換一個備用模型
想法很直覺：設一個 fallback model，Anthropic 掛了就跳到 OpenAI。
但實際操作比想像中麻煩。首先，你不能隨便拿一個 ChatGPT 帳號的 OAuth token 當 API key 用——它們是兩套不同的認證系統。我一開始就在這裡卡了半小時，拿著 ChatGPT 的 token 一直打 API，一直被拒。
後來搞清楚了：如果你有 OpenAI 的 Codex 訂閱（或 API 方案），需要用對應的認證流程。我最終是透過 openclaw onboard --auth-choice openai-codex 把 OpenAI Codex 的認證串起來的。
不只一個備胎：Fallback Chain
一個備用模型夠嗎？經歷了連續兩天的故障，我的答案是：不夠。
原因很簡單——如果你的 Plan B 也掛了呢？雖然兩家同時故障的機率很低，但我不想再賭了。所以我建了一條完整的 Fallback Chain：
- Anthropic Claude Opus — 主力，品質最好
- OpenAI GPT-5.3 Codex — 第一備援，程式碼能力強
- OpenAI GPT-5.2 Codex — 第二備援
- OpenAI GPT-5.2 — 第三備援
- Anthropic Claude Sonnet — 最後保底
你可能會問：為什麼 Sonnet 放最後？因為以我的使用場景來說，Sonnet 的推理品質跟 Opus 差距明顯，放在倒數是為了「至少還有東西能動」的情境。而 GPT-5.3 Codex 在程式碼任務上表現不錯，當 Opus 的第一替補綽綽有餘。
設定的眉角
建立 fallback chain 的過程中，有幾個實際踩到的坑：
認證方式不統一。 Anthropic 用 API key，OpenAI Codex 走 OAuth，每家的認證流程都不一樣。如果你的 Agent 平台不支援統一管理多個 provider 的認證，光是設定就會讓你懷疑人生。
Context window 差異。 Claude 跟 GPT-5.3 Codex 都是 200K context（Claude 甚至可以擴到 1M extended thinking），但不同模型對長 context 的處理能力不同。我有一個 session 撞到 212K 超過 200K 上限被拒——壓縮機制來不及介入，訊息直接被擋。這在設計 fallback 時要考慮：切換模型後，context 可能需要重新壓縮。
模型行為差異。 這是最微妙的。同樣的 system prompt，Claude 和 GPT 的回應風格、工具呼叫習慣、甚至錯誤處理方式都不同。如果你的 Agent 有很細的行為規範（像我的有身份設定、記憶系統、多 skill 架構），換模型後可能會出現一些「微妙的不對勁」。不至於壞掉，但你會感覺到那不是同一個人在回話。
不是所有模型都能用。 我本來想試 GPT-5.3 Codex Spark（更快的版本），結果發現它不支援 ChatGPT 帳號認證。這種「看起來可以但實際不行」的情況，只有真正去試才會發現。
為什麼不早點做？
說實話，有點心虛。
身為技術主管，我天天跟團隊講系統要有 redundancy、要考慮 failover、不能有 single point of failure。結果自己的 AI 工作流就是一個巨大的單點故障。
原因也很典型：因為一直都沒出過事。 Anthropic 的 API 在過去幾個月穩定到讓人放鬆警惕。就像你知道該做備份，但硬碟一直沒壞過，所以備份軟體裝了從來沒跑過。
直到硬碟真的壞了。
給同樣依賴 AI API 的你
如果你也把 AI 服務深度整合到工作流裡，幾個建議：
現在就設好 fallback。 不要等到出事才急。多模型的認證設定、模型間的行為差異測試，這些需要時間。在平靜的時候做，比在故障時手忙腳亂好太多。
定期測試備援路徑。 設好了不代表能用。每隔一段時間手動觸發 fallback，確認整條 chain 是通的。我就是因為沒測過，才在故障當天花了好幾個小時在搞認證問題。
接受品質會降低。 Fallback 的意義不是「跟主力一樣好」，而是「至少能動」。從 Opus 切到 GPT-5.3 Codex，有些任務的品質確實會下降。但能動比不能動好。完美是進步的敵人，在災難面前更是如此。
記錄你的 fallback chain。 寫下來，放在團隊文件裡。包括每個模型的認證方式、已知限制、切換條件。未來不一定是你在處理故障，讓其他人也能照著做。
後記
故障恢復後，我的 Agent 又回到 Claude Opus 運行。但現在我看著那條 fallback chain 的設定，心裡踏實多了。
AI 服務不是水電，不會 99.999% 在線。特別是在這個各家 provider 都在瘋狂迭代、流量暴增的階段，故障只會越來越常見。
你的 AI 工作流有 Plan B 嗎？如果這篇能讓你今天就花半小時把 fallback 設好，那我這兩天的焦慮就沒白費了。