*圖 1｜可靠性不是無限重試，而是依錯誤類型選擇 Retry、Fallback 或停止*
## 逾時（Timeout）：不要讓整個工作流程永遠卡住 每個外部工具呼叫（Tool Call）都應該有合理的等待上限。如果模型或 API 超過時間仍沒有回應，系統應該主動結束這一次呼叫，記錄錯誤，再決定下一步。 沒有 Timeout 的最大問題不是「使用者多等一下」，而是整條 Workflow 可能一直佔用資源，前端也不知道到底還在處理還是已經壞掉。 ## Retry：只重試值得重試的錯誤 不是所有錯誤都適合 Retry。像暫時性網路問題、429 或部分 5xx 錯誤，可以搭配 exponential backoff 重試；但如果是憑證錯誤、權限不足或輸入格式錯誤，重試十次也不會變好。 因此 Retry policy 應該先分類錯誤，再決定重試次數與等待時間。這比寫一個無條件 `try again` 更可靠。 ```text theme={null} 429 / temporary 5xx → retry with backoff 401 / 403 → stop, check credential or permission bad input → stop, return actionable error ``` ## Fallback：主要服務不可用時，還有沒有下一條路？ 對語言模型可以準備 fallback model；對某些資料來源，也可以在主來源暫時不可用時回傳最近一次可信快取，前提是明確標示資料時間。Fallback 的目的是維持服務可用性，不是偷偷用比較舊或不同的資料假裝一切正常。 如果沒有可靠 fallback，最好的做法就是清楚告知目前哪一段無法完成，而不是讓模型自行補答案。 實作時可以把這四個機制放進同一張對照表，避免彼此的責任混在一起： | 機制 | 解決什麼問題 | | ------------ | --------------- | | Timeout | 限制單次等待時間 | | Retry | 暫時性失敗時重新嘗試 | | Fallback | 主模型不可用時切換替代模型 | | Verification | 檢查回答是否符合工具結果與來源 | 驗證時可以刻意製造失敗情境：故意填錯 API Key，確認會收到認證錯誤而不是無限轉圈；模擬 Timeout，確認前端的 Loading 真的能結束；讓主要模型持續失敗，確認系統會切換到備援模型，並讓使用者知道目前用的是備援服務；最後檢查後端 Log——它應該保留足夠分類資訊方便除錯，但不能記錄完整 Prompt、API Key 或使用者敏感資料。 ## Verification 也屬於可靠性 可靠性不只是服務「有沒有回」。即使 Tool 成功回傳，也可能回空結果、欄位變動或不完整資料。因此在 Workflow 中保留 Verification Node 很重要：檢查結果是否可用、來源是否存在，以及回答是否超出工具證據。 這裡可以把 Day 22 的原則放進正式產品：資料不足就補查，問題不清楚就 clarification，來源失敗就回報狀態，而不是一律進最終生成。 ## 錯誤訊息要讓使用者知道下一步 「Something went wrong」對使用者幾乎沒有幫助。比較好的錯誤訊息會區分：資料來源目前無法連線、權限不足、模型暫時忙碌、查不到符合條件的資料，或輸入需要補充。 例如「目前無法讀取 Google Sheets，文件查詢仍可使用」就比整頁跳錯誤更有價值，因為使用者知道哪些功能還能繼續。 ## 在 Data Machi 中放在哪裡？ 可靠性最好不要只散落在每個 Tool 裡。Tool 自己負責基本 Timeout 與 API error handling，Workflow 層則負責 Retry、Fallback、Verification 與使用者可見狀態。這樣每一層責任比較清楚。 ## 進階理解｜不同任務，不一定用同一種可靠性策略 模型呼叫可以依任務性質分成兩條路徑。像「判斷要不要查資料」「確認問題類型」這類快速任務，可以使用較快的模型、較短 timeout；長篇摘要或最終回答則可以允許較長時間，失敗後再考慮 Retry 或 Fallback。換句話說，可靠性不是設定一個全系統共用的 30 秒，而是根據任務重要性與使用者等待成本調整。 另外還要注意一種常被忽略的失敗：**輸出被截斷**。服務有回應，不代表內容完整；如果要求固定 JSON 或長篇報告，仍需要檢查格式是否完整，再決定是否重試。