有了 ngrok 打通網路，我們的系統看似無懈可擊。但資深的軟體工程師深知一個鐵律：永遠不要相信外部的 API 是穩定的。

在 AI 應用的世界裡，這個問題更加嚴重。大語言模型 (LLM) 伺服器經常會因為流量過載而回傳 500 錯誤，或是因為生成文本太長而導致連線 Timeout。如果在 n8n 的自動化流程中只考慮「理想狀態 (Happy Path)」，一旦中間某個節點報錯，整個流程就會像骨牌一樣崩潰，導致資料遺失或卡死。

為了打造企業級的高可用性系統，我們必須在 n8n 中導入防禦性系統設計 (Defensive Design)：

1. 遇到失敗不要輕言放棄：重試機制 (Retry Mechanism)
網路波動或 API 瞬斷是常態。在 n8n 的 HTTP Request 節點或 Dify 呼叫節點中，我們必須開啟 Retry on Fail（失敗時重試）功能。
實務上，我們會採用「指數退避 (Exponential Backoff)」的策略：例如第一次失敗後等待 2 秒重試，第二次失敗等待 5 秒，第三次等待 15 秒。這樣既能給予對方伺服器喘息的時間，也能大幅降低因為瞬斷而導致的任務失敗率。

2. 設立安全網：錯誤觸發器 (Error Trigger)
如果重試了三次還是失敗，我們絕對不能讓這個錯誤默默消失。
在 n8n 中，我們可以建立一個專門的「錯誤處理工作流 (Error Workflow)」，並使用 Error Trigger 節點作為起點。當主流程發生無法挽救的崩潰時，系統會自動跳轉到這裡。

3. 妥善的善後處理 (Fallback & Alert)
進入錯誤處理流程後，我們可以設計兩條路徑：

• 警報 (Alerting)： 擷取錯誤代碼 (Error Message) 與失敗的節點名稱，透過 Slack 節點發送帶有紅色警示的訊息給工程團隊：「 AI 分類總機呼叫 Dify API 失敗，請即刻排查！」

• 降級機制 (Fallback)： 如果 AI 暫時無法分析郵件，我們可以在資料庫或工單系統中，將這封信暫時標記為「待人工處理」，確保業務邏輯不會因為 AI 當機而徹底停擺。

經歷了這兩天的架構淬鍊，我們的 AI 系統不僅聰明，而且具備了強大的容錯韌性。接下來，我們終於可以放心地擴充大模型的感官能力。明天 [Day 19]，我們將解鎖 AI 的「視覺」：多模態模型 (Multimodal) 實戰！