現代 AI 系統的「體檢表」：健康檢查與回退策略為什麼比單次成功更重要

很多 AI 系統在演示時看起來很順利：請求發出去，模型返回答案，頁面上出現結果。但真正上線以後，系統面對的不是一次請求，而是持續不斷的請求、網路波動、模型限流、上下文過長、工具呼叫失敗和偶發的超時。只要其中一個環節沒有被觀察到，問題就會從「偶發異常」變成「用戶覺得整個系統不可靠」。

健康檢查的作用，是把系統從「看起來能用」變成「知道自己哪裡能用」。一個好的健康檢查不只是訪問首頁，也不只是看進程是否存在。它需要分層：入口服務是否響應，鑑權是否正常，模型路由是否可用，關鍵依賴是否能讀寫，佇列是否積壓，失敗率是否超過閾值。每一層都應該返回明確的狀態，而不是把所有問題都摺疊成一個模糊的失敗。

回退策略則解決另一個問題：發現不健康以後怎麼辦。最簡單的回退是換一個模型或節點；更成熟的做法是根據失敗類型選擇動作。比如超時可以降級到更快的模型，限流可以排隊或切換備用供應商，工具呼叫失敗可以返回可恢復的錯誤，內容生成失敗則應該保留草稿和證據，避免把半成品發布出去。

這裡的關鍵不是追求永不失敗，而是讓失敗有邊界。沒有健康檢查時，系統只能等用戶投訴；沒有回退策略時，系統即使知道壞了，也只能繼續把請求送進同一個壞路徑。兩者結合起來，才會形成可營運的 AI 服務：先判斷當前能力，再決定是繼續、降級、重試、排隊，還是停止發布。

一個實用的設計可以從三張表開始。第一張是服務狀態表，記錄每個節點最近一次成功、失敗原因和延遲。第二張是路由策略表，定義不同失敗類型的回退順序。第三張是審計表，保存每次自動決策的輸入、輸出和證據。這樣當系統出現異常時，團隊不是靠記憶複盤，而是能直接看到哪一層先變壞、哪個回退動作生效、是否還有人工介入的必要。

AI 工程的穩定性往往不是由最強模型決定的，而是由最弱的運行環節決定的。健康檢查和回退策略看起來不如模型能力耀眼，但它們決定了系統能不能每天穩定交付。對一個日更、客服、寫作或自動化工作流來說，單次成功只是樣板；連續健康，才是生產能力。