最近處理 AI Agent 的故障時，我又被提醒了一次：看到「某個機器人沒反應」，第一件事不一定是重啟它，而是先問——它真的是自己壞掉嗎？還是它只是整條依賴鏈裡最先被看見的那個受害者？
這種問題在傳統系統也會發生，但在 AI Agent 上特別容易誤判。因為 Agent 的外觀很像一個獨立服務：有自己的容器、有自己的設定、有自己的聊天入口、有自己的 log。使用者看到的是「我敲它，它不回」，工程師第一反應也很自然：那就看這個 bot、這個 container、這個 process。
可是 AI Agent 通常不是一個單純的 web service。它背後可能串了模型供應商、推論 gateway、工具執行環境、資料庫、向量記憶、聊天平台、排程器，甚至還有一層自己寫的 fallback。它看起來像一個角色，實際上比較像一個小型分散式系統。
所以「沒反應」這三個字，資訊量其實非常低。
不要太快相信第一個故障表象
我以前也會犯一個錯：看到某個 Agent 掛掉，就一路往那個 Agent 裡鑽。容器是不是 healthy？設定檔是不是壞了？token 有沒有過期？gateway 有沒有連上？
這些都要查，但順序很重要。
如果同一時間，另一個使用相同模型通道的 Agent 也開始出現非典型錯誤，那問題就不該再被視為單點故障。這時候繼續只盯著第一個 bot，很可能只是把自己帶進錯的洞裡。
我現在會先做一個很粗但很有效的判斷：
- 是不是只有這個入口壞？
- 還是所有走同一個模型 provider 的流程都壞？
- 排程任務有沒有同類錯誤？
- 互動式 Agent 跟背景 cron 是不是同時受影響？
- 錯誤訊息是應用層錯誤，還是上游連線／回應格式異常？
這些問題問完，故障範圍通常會清楚很多。
AI Agent 的共同依賴，比你想像中多
多數團隊在導入 AI Agent 時，很容易把每個 Agent 當成獨立單位管理：客服 Agent、報告 Agent、知識庫 Agent、開發助理，各自有不同任務、不同 prompt、不同技能。
但從維運角度看，它們可能共享同一批東西：
- 同一個模型通道
- 同一個 provider token
- 同一個工具執行沙盒
- 同一個資料庫
- 同一個聊天 gateway
- 同一套排程 runtime
- 同一個 host 的 Docker daemon 或虛擬化環境
只要其中一個共同依賴不穩，表面上會像很多個 Agent 同時「各自壞掉」。但本質上，它們可能只是被同一個上游拖下水。
這也是為什麼我現在看 AI Agent 故障，不太喜歡只看單一服務的 health check。container healthy 只能代表 process 還活著，不代表它能完成任務。聊天 gateway connected 也只能代表入口還在，不代表模型端真的能產生可用回應。
Agent 的健康狀態，應該包含「它能不能完成一個最小閉環」。例如：接收訊息、呼叫模型、執行一個無害工具、回傳結果。少了其中一段，只看 process 狀態會太樂觀。
fallback 不是有寫就算數
另一個常見陷阱是 fallback。
很多系統設定檔裡都有 fallback provider，看起來很安心。但真的壞掉時才發現：fallback 清單是空的、備援模型沒有相容的輸出格式、或錯誤分類沒有把這種失敗導到 fallback 流程。
更糟的是，錯誤訊息還可能說「正在嘗試 fallback」，但實際上沒有任何可切換的目標。這種狀況在維運上很危險，因為它給人一種系統已經有韌性的錯覺。
我現在會把 fallback 當成需要定期演練的功能，而不是設定檔上的裝飾。至少要問三件事：
- 主通道失敗時，真的有第二條路嗎？
- 第二條路的輸出格式，後段流程吃得下嗎？
- fallback 發生時，使用者或維運者看得出來嗎？
如果答案是否定的，那就不要假裝有 fallback。誠實地報錯，通常比假裝恢復來得安全。
技術主管要建立的是故障地圖
站在技術主管的角度，我覺得這類事件最有價值的地方，不是把某個服務救回來，而是補上一張「故障地圖」。
這張圖不一定要很正式，但至少要知道：哪些 Agent 共用哪些 provider、哪些排程共用哪些 token、哪些服務依賴同一個 runtime、哪些 dashboard 只是觀測層、哪些資料源才是真正的 source of truth。
有了這張圖，事故發生時才不會被第一個警報牽著走。
AI Agent 越多，這件事越重要。因為 Agent 很會讓人產生「它是一個獨立人格」的錯覺，但維運上它不是人格，它是依賴鏈。人格可以有名字，系統還是要有邊界。
我現在的處理原則
如果要把這次經驗整理成幾條原則，大概是這樣：
- 先判斷故障範圍，再重啟服務。
- 同時壞掉的 Agent，優先懷疑共同依賴。
- health check 要測任務閉環，不只測 process 存活。
- fallback 要能被驗證、被觀測、被明確標記。
- 上游異常時，不要把所有錯都歸因到最後一層應用。
這些都不是很炫的技術，但很實用。
做 AI Agent 到最後，我越來越覺得 prompt、模型、工具能力當然重要，但真正能不能長期穩定運作，靠的是很老派的工程紀律：依賴盤點、錯誤分類、觀測性、降級策略、事故後修正。
Agent 可以很聰明，但系統不能只靠它聰明。
它需要被當成一個真正的生產系統看待。壞掉時，別只問「誰沒回我」。也要問：「它跟誰共用了一條會斷的路？」