在可靠地服務 LLM 的同時，保持 Agent 行為

傳統的軟體可靠性主要在於保持系統在線。如果伺服器發生故障，流量會轉移到其他地方，應用程式會繼續運行。

對於 AI Agent 來說，可靠性更加微妙。單個 Agent 的行為來自多個 LLM 在不同的推論任務中協同工作。這些任務，如分類、工具調用和響應生成，都由最適合該特定工作的模型提供支持（參見模型星座）。

這種模型級別的精確性提出了一個新的可靠性挑戰：在適應供應商不穩定性的同時，保持一致的 Agent 行為。本文將分解我們構建的基礎設施，以保持高可用性，而不影響 Agent 的品質。

服務問題：多供應商現實，單一行為期望

LLM 通常可以通過多個服務供應商獲得。例如，像 GPT 這樣的模型可以通過 OpenAI 的基礎設施以及像 Azure 這樣的雲端託管部署來訪問。每個都有自己的容量限制和速率限制行為。

在實踐中，中斷很少以乾淨、統一的停機形式出現。相反，我們觀察到波動的速率限制、各區域之間不均勻的容量、流量轉移過快時的路由不穩定，以及需求暫時超過總可用容量的時期。

當推論任務因為供應商受到限制而靜默切換到不同的模型時，Agent 的決策可能會改變。在這種情況下，簡單的故障轉移是不夠的。

可靠地服務 Agent 需要解決兩個獨立的問題：對供應商不穩定性做出反應，以及保護定義 Agent 行為的模型選擇。我們通過兩個互補的層來解決這個問題：

多模型路由器：自動故障轉移，不改變 Agent 行為

多模型路由器 (MMR) 執行 Sierra Agent SDK 為每個推論任務定義的優先模型列表。

對於每個任務，MMR 根據以下內容選擇模型：

在正常情況下，MMR 為任務選擇首選模型。當該模型受到限制時，它會評估是否允許回退，如果允許，則選擇優先級列表中下一個預先驗證的替代方案。

在某些情況下，回退是不合適的。例如：

在這些情況下，如果切換到替代模型會對 Agent 行為產生負面影響，MMR 將不會切換。

擁塞感知供應商選擇器：檢測停機和速率限制

擁塞感知供應商選擇器負責在面對波動的容量和速率限制時，保持供應商層的穩定性。

在沒有擁塞控制的情況下，多供應商路由很容易演變成振盪，尤其是在速率限制條件下。例如：

這個循環會在供應商之間轉移過載，並破壞路由的穩定性。為了防止這種情況，我們引入了一個准入控制器。

准入控制器通過使用加性增加/乘性減少 (AIMD) 來維持動態准入分數，從而限制受限供應商可以接收的流量，類似於 TCP 擁塞控制：

這平滑了流量轉移，避免了不必要的故障轉移，同時保持了首選模型的有效利用。

當必須減少流量時，我們會為每個請求附加一個優先級分數，並首先捨棄較低優先級的流量。這會向 MMR 發出信號，如果合適，MMR 可以針對另一個模型重試。高優先級請求被保留，而低優先級流量則優雅地降級。

通過穩定供應商流量，我們降低了臨時基礎設施問題改變服務於每個任務的模型的可能性——從而降低了改變 Agent 行為的可能性。由於這種機制是動態調整的，因此我們不依賴於嚴格的配額限制或繁重的工作負載隔離來維持穩定性。

沒有妥協的彈性

隨著 AI Agent 變得越來越複雜，彈性不能僅僅停留在正常運行時間上。它必須擴展到行為。通過將模型意圖與供應商適應分開，我們確保 Agent 在正常運行下保持穩定，並且僅在約束需要時以受控的、有意的方式降級。

對於在 Sierra 上構建的團隊來說，這意味著基礎設施的不穩定性永遠不會表現為不一致的 Agent 行為。Agent 下方的基礎設施可能會實時變化，但用戶體驗到的 Agent 行為不應發生變化。