超越無狀態：為什麼 LLM 正在挑戰傳統系統設計

二十年來，可擴展 Web 架構的藍圖一直非常一致：狀態儲存在資料庫中，而運算則是無狀態的。在這種模型中，任何請求都可以命中負載平衡器後面的任何伺服器，而資料庫則作為絕對的單一事實來源。這種設計透過將應用程式伺服器視為可拋棄的商品，讓網際網路得以擴展到數十億用戶。

然而，大型語言模型 (LLM) 和自主代理 (autonomous agents) 的出現，正開始瓦解這一長期存在的假設。雖然「無狀態運算」模型適用於傳統的 CRUD 應用程式，但它日益不符合代理式 AI (agentic AI) 的需求。

無狀態架構的三大裂痕

代理式工作流 (agentic workflows) 帶來了三個傳統無狀態請求-響應週期無法有效處理的特定挑戰：

長時間運行的工作：一個正在執行複雜任務的 AI 代理——例如研究一個主題並撰寫報告——可能需要十分鐘才能完成。這不再是 HTTP 意義上的「請求」；它是一個長時間運行的非同步處理程序。
有狀態的運算：代理依賴於累積的上下文 (context)、對對話中先前回合的記憶，以及多次工具調用的結果。這種狀態不僅僅是「資料庫狀態」（例如使用者個人資料）；它是運行中處理程序的活動記憶。
雙向互動：使用者不僅想要最終答案；他們還想即時觀看代理「思考」的過程、中斷其進度，或重新導向其軌跡。這將互動從對一個無狀態 API 的查詢，轉變為與一個運行中處理程序的即時對話。

為了處理這個問題的執行部分，業界已轉向使用「持久化執行」框架（例如 Temporal, Inngest, 或 Restate）。這些工具使處理程序具有韌性，確保如果伺服器崩潰，工作流可以從中斷處恢復。

但持久化執行解決的是「處理程序」問題，而非「互動」問題。由於標準的負載平衡器和 HTTP 無法將請求路由到特定的運行中處理程序，開發者通常會退回到輪詢。客戶端輪詢資料庫端點以查看持久化處理程序是否已寫入更新。

正如原始資料所述，這本質上是將資料庫視為訊息匯流排 (message bus)——這是對根本路由缺陷的權置法。

輪詢會引入延遲、增加資料庫負載，並為串流數據提供糟糕的使用者體驗。

為了超越輪詢，我們需要一種能夠針對「處理程序」而非僅僅是伺服器或資料庫的路由原語。目標是能夠說：「將此訊息傳遞給目前正在為工作流 X 產生輸出的人」， 而不需要知道特定的伺服器副本或 IP 地址。

WebSockets 提供雙向通訊，但它們是一種「連接」，而非「地址」。如果 WebSocket 連接中斷——例如因為使用者進入隧道——地址就會丟失。在沒有外部路由機制的情況下，沒有原生方式可以重新連接到完全相同的處理程序狀態。

A 更穩健的解決方案是使用具名的 pub/sub 通道。在此模型中，客戶端和伺服器處理程序都不是地址；傳輸通道 (transport channel) 才是地址。客戶端和伺服器都連接到一個具名的通道。如果連接中斷，客戶端只需重新連接到同一個具名通道，即可恢復數據串流。

透過將持久化執行與持久化傳輸 (pub/sub) 相結合，開發者可以建立代理式應用程式，使工作流具有韌性，且通訊是無縫的，從而消除為了韌性而必須將每個 token 透過資料庫傳遞的必要性。

轉向有狀態路由的趨勢並非沒有批評者。一些工程師認為，這些「問題」並非新問題。長時間運行的工作、webhooks 和 job IDs 已被使用數十年來處理非同步工作。批評者建議，「資料庫中的單一事實來源」是一個經過驗證的模式，應該繼續作為系統設計的核心。

其他人則指出，現有的技術已經解決了這些問題，例如：

如果這些模式已經存在，為什麼現在很重要？區別在於 LLM 的本質：它們是 非決定性的 (non-deterministic) 且 昂貴的。

在傳統系統中，如果連接中斷，你通常可以重試請求並獲得相同的結果。使用 LLM 時，重試請求可能會產生不同的答案，並且會消耗更多的 token。你無法承擔因為網路閃斷而浪費昂貴的運算，或丟失複雜、非決定性的思維鏈 (chain of thought) ござい的狀態。

LLM 並未發明這些問題，但它們放大了這些問題，使得這 20 年來無狀態 Web 架構的權衡取捨變得比以往任何時候都更加痛苦且顯而易見。