AI API 可靠性設計：超時、重試與冪等性如何協同

AI 應用從原型走向生產環境後，請求失敗不再只是偶爾出現的技術問題，而會直接影響使用者體驗、業務流程和系統資源。一次模型呼叫可能涉及用戶端、應用服務、AI 接入層、模型提供商以及後續業務處理。任何一個環節出現延遲、連接中斷或服務異常，都可能讓整條請求呼叫鏈陷入不確定狀態。

傳統 API 系統已經積累了超時、重試、熔斷和冪等性等可靠性設計方法，但 AI API 並不能簡單照搬所有傳統實踐。模型生成通常具有更長的回應時間、動態變化的計算成本，以及非確定性的輸出。尤其是在串流生成、工具呼叫和多步驟 Agent 工作流中，一次失敗可能意味著部分內容已經返回，甚至某項外部操作已經執行。

因此，AI API 可靠性設計的關鍵，不是讓每一次請求都無限嘗試直到成功，而是明確請求能夠等待多久、哪些錯誤值得重試、重複請求會產生什麼影響，以及系統在無法恢復時應該如何結束流程。理解這些邊界，才能讓 AI 應用在複雜網路和多模型環境中保持可控。

AI API 為什麼需要不同於傳統介面的可靠性設計

普通 API 請求通常圍繞明確的輸入和輸出展開。用戶端發送請求，伺服器端執行相對確定的操作，然後返回結果。雖然資料庫查詢、支付介面和第三方服務也可能出現長時間等待或部分失敗，但其業務語義通常比較清晰，系統可以根據請求狀態判斷是否重新執行。

AI API 的請求過程更加複雜。模型可能需要較長時間完成推理和生成，回應內容可能以串流方式逐步返回；同樣的輸入也不一定產生完全一致的輸出。此外，一些 AI 應用會在模型回應後繼續執行工具呼叫、資料庫寫入或其他業務操作。這意味著模型呼叫成功與業務流程成功並不是同一件事。

例如，一個客服 Agent 收到退款請求後，可能先呼叫模型分析使用者意圖，再呼叫訂單系統查詢交易記錄，最後通過退款介面執行操作。如果模型生成階段出現超時，應用可以考慮重新發起推理；但如果退款介面已經成功執行，只是返回結果在網路中丟失，那麼直接重試就可能造成重複退款。不同階段的失敗必須採用不同的恢復策略。

AI 請求還具有明顯的資源成本。一次重試不僅消耗額外的網路和計算資源，也可能再次產生 Token 費用。對於持續生成的長文字、程式碼或多模態任務，重複執行的成本可能相當可觀。因此，可靠性設計必須同時考慮成功率、回應時間、業務正確性和資源消耗，而不能只關注請求是否最終返回了一個成功狀態碼。

超時預算：先確定請求最多可以等待多久

超時是請求可靠性設計的第一道邊界。如果沒有明確的超時設定，應用可能長期等待已經失去回應能力的服務，導致連接、線程和任務隊列持續占用。隨著等待中的請求不斷累積，原本局部的模型服務波動就可能擴散成整個應用的性能問題。

開發者需要區分不同層級的超時。連接超時用於限制建立網路連接所需的時間；讀取超時用於限制等待服務返回資料的時間；總請求超時則限制整個請求從開始到結束的最長時長。對於串流生成，還需要考慮兩次資料塊之間允許的最大空閒時間，避免連接雖然沒有關閉，卻長時間不再輸出內容。

更重要的是，超時應當圍繞業務目標分配，而不是給每個環節設定互不相關的固定數值。假設一個使用者請求的整體回應預算為 30 秒，應用需要在這段時間內完成模型呼叫、結果處理和必要的業務驗證，那麼模型呼叫就不能獨佔全部 30 秒。系統必須為後續步驟預留時間，並在剩餘預算不足時及時停止不必要的操作。

這種設計通常稱為超時預算。它要求請求在不同服務之間傳遞時攜帶剩餘時間，而不是每進入一個新環節就重新獲得完整等待時間。否則，一個包含多個串行呼叫的工作流可能在每一層都等待數十秒，最終遠遠超過使用者可以接受的回應時間。

超時也不等於取消已經發生的操作。用戶端停止等待，並不一定意味著上游模型服務或外部工具已經停止執行。對於支援取消機制的請求，應用應儘可能向下游傳遞取消信號；對於無法確認是否終止的任務，則需要記錄狀態，並在後續通過任務查詢或結果核對判斷實際執行情況。

重試策略：不是所有失敗都值得再次請求

重試能夠提高系統對短暫故障的容忍度，但錯誤的重試策略也會放大故障。當某個模型服務已經過載，大量用戶端同時重試可能進一步增加請求壓力，形成重試風暴。因此，重試應該是一種有邊界的恢復機制，而不是預設的失敗處理方式。

首先需要判斷錯誤類型。連接建立失敗、短暫網路中斷、部分伺服器端錯誤或明確表示可以稍後重試的回應，可能適合有限次數的重試。相比之下，參數格式錯誤、權限不足、模型名稱無效或輸入超出限制等問題，通常不會因為再次發送相同請求而消失。對於這類錯誤，應用應當直接返回可診斷的資訊，避免浪費額外資源。

其次，重試次數必須受到限制。開發者可以為每個請求設定最大嘗試次數，並結合指數退避逐步增加重試間隔。例如，第一次失敗後等待較短時間，後續嘗試再逐漸延長等待時間。為了避免大量請求在相同時間點重新發起，還可以加入隨機抖動，使重試時間分散。

重試還必須考慮剩餘超時預算。如果請求已經接近整體截止時間，即使錯誤本身可以重試，也未必值得再次發送。一個合理的策略應當同時檢查錯誤類型、剩餘時間、重試次數和請求成本，只有滿足條件時才繼續嘗試。

對於支援多模型的應用，還需要區分重試與模型切換。重新向同一個模型發送請求，屬於對原呼叫的再次嘗試；切換到另一個模型，則意味著改變了執行路徑。不同模型的輸出能力、上下文處理方式和結果格式可能存在差異，因此模型切換不能被視為完全透明的重試。應用應當確認備用模型能夠滿足當前任務的最低要求，並在必要時記錄實際使用的模型和切換原因。

冪等性：防止重複請求變成重複操作

冪等性是可靠性設計中經常被忽略、卻直接關係到業務正確性的機制。簡單來說，如果同一個業務請求因為網路重試或用戶端重複提交而被執行多次，系統應能夠識別這些請求屬於同一次操作，並避免產生多份業務結果。

在 AI 應用中，冪等性至少需要區分兩種情況。第一種是純模型推理，例如文字分類、摘要生成或問答。重複執行可能產生不同輸出，也可能產生額外費用，但通常不會直接修改外部業務狀態。第二種是包含副作用的操作，例如建立訂單、發送郵件、執行退款、更新資料庫或呼叫鏈上交易介面。對於這類操作，重複執行可能造成真實的業務損失。

因此，冪等性不能只依賴模型輸出內容是否相同。更可靠的做法是由應用層為每個業務操作生成唯一的冪等鍵，並將其與使用者、任務類型和業務對象關聯。伺服器端收到請求後，先檢查該鍵是否已經處理過；如果已經完成，就返回之前保存的結果或當前任務狀態，而不是再次執行操作。

在 Agent 工作流中，冪等性尤其重要。模型可能在一次對話中多次提出相同工具呼叫，也可能因為上游回應丟失而讓應用無法判斷工具是否已經執行。此時，工具執行層應當承擔最終的重複操作保護責任。模型可以負責提出行動建議，但是否執行以及是否允許再次執行，應由具有明確狀態管理能力的業務系統決定。

冪等鍵還需要合理設定有效期和作用範圍。有效期過短可能無法覆蓋延遲到達的重試請求；範圍過寬則可能錯誤地把兩次獨立業務操作識別為同一次請求。對於重要操作，系統還應保留執行狀態、請求摘要和最終結果，以便在發生不確定狀態時進行核對。

熔斷機制：避免局部故障擴散成系統性問題

重試主要處理短暫、可恢復的錯誤，而熔斷機制解決的是持續性故障。當某個上游模型或服務在一段時間內持續失敗，繼續向它發送請求通常只會增加等待時間和資源消耗。熔斷器通過觀察失敗情況，暫時阻止請求進入故障服務，讓系統有機會恢復。

典型熔斷機制包含三個狀態。關閉狀態下，請求正常通過，系統持續統計失敗率和回應情況；當失敗達到設定閾值時，熔斷器進入打開狀態，暫時拒絕或繞過相關請求；經過一定冷卻時間後，熔斷器進入半開狀態，只允許少量探測請求通過，以判斷上游是否恢復。如果探測成功，熔斷器恢復關閉；如果再次失敗，則重新打開。

對於 AI 應用，熔斷判斷不能只依賴單一的錯誤狀態碼。模型回應慢、連接失敗、限流回應和伺服器端錯誤可能代表不同的問題。系統應根據實際架構選擇觀測指標，並區分短暫波動與持續異常。對於串流請求，還需要考慮首個資料塊延遲、生成過程中的中斷率以及整體請求完成情況。

在多模型架構中，熔斷器也可以與備用模型策略配合使用。當某個上游服務進入熔斷狀態時，系統可以根據任務類型和備用模型能力決定是否切換。需要注意的是，備用模型並不一定在所有任務上都能提供相同品質的結果。如果請求涉及嚴格格式、特定上下文或特定能力，系統應當明確備用模型的適用範圍，而不是為了追求請求成功率而犧牲業務正確性。

將可靠性機制組合成完整的請求生命週期

超時、重試、冪等性和熔斷並不是四個獨立的配置項，而應當共同構成一個完整的請求處理流程。只有在請求進入系統時就明確其業務目標、截止時間和執行語義，後續機制才能在正確的邊界內發揮作用。

一個較為穩健的請求生命週期可以從生成請求 ID 和業務冪等鍵開始。應用首先檢查輸入、權限和任務狀態，然後根據業務優先級設定總超時預算。請求經過統一 AI 接入層發送給模型服務，系統根據錯誤類型判斷是否需要重試；如果上游服務持續異常，則由熔斷機制阻止請求繼續進入故障節點。對於可能產生副作用的工具呼叫，執行層在操作前驗證冪等鍵，並在執行後持久化結果。

實際實現時，還應當讓請求狀態可以被追蹤。除了記錄請求開始和結束時間，還需要記錄嘗試次數、錯誤類別、實際使用的模型、是否發生模型切換、是否觸發熔斷，以及工具操作是否已經提交。對於串流請求，首個 Token 時間、資料塊間隔和連接中斷位置也可能是重要的診斷資訊。

這套機制可以與 MegaRouter 的統一模型接入能力結合。應用通過統一介面管理不同模型的呼叫方式，再在自身業務層實現請求截止時間、重試策略、冪等鍵和工具執行狀態管理。MegaRouter 的多模型接入與自動故障切換能力可以為請求恢復提供基礎，但具體業務是否允許重試、何時切換模型，以及外部操作是否已經執行，仍需要由應用根據業務語義作出判斷。

如何驗證 AI API 的可靠性設計

可靠性機制不能只通過程式碼審查來確認。系統需要在可控環境中模擬不同類型的故障，觀察請求是否按照預期結束，以及故障是否會擴散到其他服務。

第一類測試應關注延遲和超時。通過模擬連接緩慢、回應延遲、串流輸出停滯等情況，檢查各層超時是否生效，整體請求是否遵守截止時間。尤其要驗證請求在上游已經開始執行、但用戶端停止等待時，系統能否正確處理後續狀態。

第二類測試應關注重試邊界。模擬網路中斷、限流、伺服器端錯誤和無效請求，確認只有符合策略的錯誤才會觸發重試，並檢查最大嘗試次數、退避間隔和剩餘時間判斷是否有效。還應觀察多個請求同時失敗時，重試機制是否造成請求量突然增加。

第三類測試應關注重複執行。對於建立訂單、發送通知、支付和資料庫更新等操作，模擬用戶端重複提交、回應丟失以及任務恢復，確認相同冪等鍵不會造成重複業務結果。對於 Agent 工具呼叫，還需要驗證模型重複提出相同動作時，工具執行層是否能夠正確識別並阻止重複操作。

最後，應通過故障注入驗證熔斷與恢復流程。人為讓某個上游服務持續失敗，再觀察熔斷器是否及時打開、備用路徑是否按預期工作，以及上游恢復後是否能夠通過探測請求重新接入。可靠性指標不應只有整體成功率，還應包含超時率、重試率、重複操作率、故障恢復時間和單位成功請求的額外成本。

結語

AI API 的可靠性並不是單純追求更高的請求成功率，而是在系統遇到異常時，仍然能夠保持清晰的執行邊界和可預測的業務結果。超時預算決定請求能夠等待多久，重試策略控制失敗後的恢復行為，冪等性防止重複執行造成副作用，熔斷機制則幫助系統隔離持續性故障。

在多模型和 Agent 應用中，這些機制需要共同工作。統一模型接入可以降低不同上游介面的集成複雜度，但應用仍然需要理解每個請求的業務語義，區分可重複的推理操作和不可隨意重複的外部操作。只有把模型呼叫、工具執行和業務狀態管理納入同一套可靠性設計，AI 應用才能從“偶爾能夠運行”走向穩定、可維護的生產系統。

FAQ

AI API 請求超時後，是否應該立即重試？

不一定。首先需要判斷超時發生在哪個階段，以及上游操作是否可能已經執行。對於可以安全重複的推理請求，可以在剩餘超時預算充足且重試次數未達到上限時有限重試；對於可能產生外部副作用的操作，則應先確認執行狀態，避免重複提交。

指數退避為什麼適合 AI API 重試？

指數退避可以逐步拉長重試間隔，減少系統在上游服務異常時持續施加壓力。加入隨機抖動後，還能降低大量用戶端同時重試造成請求集中到達的風險。不過，退避策略仍需受到總超時預算和最大嘗試次數的約束。

模型切換可以看作普通重試嗎？

不能完全等同。普通重試通常再次執行相同的呼叫，而模型切換會改變實際執行請求的上游模型。不同模型可能具有不同的能力、輸出格式和回應特徵，因此切換前應確認備用模型滿足任務要求，並記錄切換過程。

冪等性是否意味著相同請求一定返回相同結果？

不是。冪等性主要用於保證同一業務操作不會因為重複提交而產生多次副作用，並不要求模型每次生成的文字完全一致。對於純推理任務，重複呼叫仍可能得到不同結果；對於支付、訂單和工具執行等操作，則應通過業務冪等鍵控制重複執行。

MegaRouter 能否替代應用自身的可靠性設計？

不能。統一模型接入和自動故障切換能夠幫助應用管理多模型呼叫及上游異常，但業務層仍需負責請求截止時間、重試條件、冪等性、工具執行狀態和最終結果驗證。平台能力與應用層可靠性機制應當相互配合，而不是彼此替代。