有狀態 vs 無狀態代理設計：可擴充套件代理系統的權衡
本文探討了AI代理中狀態管理的兩種正規化——無狀態和有狀態設計，分析了各自的擴充套件性權衡，並透過Groq API的程式碼示例說明了實現方式。無狀態代理易於水平擴充套件但需客戶端傳遞完整對話歷史，有狀態代理透過資料庫管理記憶體但增加架構複雜性。
在AI代理的部署中，一個關鍵的設計決策是代理如何管理狀態——即對話歷史和上下文。狀態管理方式不僅影響代理的實現，還決定了整個部署架構。本文深入比較了無狀態和有狀態兩種正規化，並透過具體程式碼示例展示了它們的實際運作方式。
無狀態代理將每個請求視為完全獨立的事件。代理接收使用者提示，呼叫LLM推理引擎，輸出結果後立即遺忘所有資訊。這種設計的核心優勢在於水平擴充套件極其簡單：由於後端不儲存任何使用者記憶，傳入請求可以轉發給任意可用例項，無需擔心狀態同步問題。然而，在多輪對話中，前端必須隨每個新請求重新傳送完整的對話歷史。隨著對話進行，上下文視窗像滾雪球一樣增長，導致令牌消耗迅速增加。文中使用Groq API和Llama 3.1 8B Instant模型展示了一個無狀態代理的簡化實現：stateless_agent函式接受當前提示和可選的先前歷史，但自身不保留任何狀態。測試表明，若不提供歷史，代理無法記住使用者在前一輪中提供的姓名和學習主題。
有狀態代理則主動承擔記憶負擔。客戶端只需傳送最新的使用者提示和唯一的會話識別符號，代理從資料庫中檢索會話歷史，追加新訊息，呼叫LLM，然後將更新的上下文儲存回資料庫。這種方式在客戶端側體驗更簡潔，也支援複雜的非同步工作流，例如代理需要暫停執行等待工具響應或人工審批。但代價是架構的複雜性顯著增加：需要引入持久化資料庫層，並且在水平擴充套件場景中，可能需要像Redis這樣的集中式記憶體快取來避免“區域性失憶”——即某個會話的歷史被孤立在僅處理過早期輪次的單一例項上。文中透過一個使用SQLite記憶體資料庫的stateful_agent函式演示了基本原理：該函式根據session_id檢索歷史，處理新提示，並更新資料庫。測試顯示，客戶端只需提供會話ID，代理即可準確回憶使用者姓名。
選擇哪種設計取決於具體用例。無狀態代理適用於簡單、任務導向的管線，如文本提取、摘要或單輪分類聊天機器人。它們保持架構輕量，避免資料庫瓶頸，實現無縫水平擴充套件。有狀態代理則更適合長期執行的助手、編碼助手或多輪客服機器人。由於代理擁有歷史，客戶端負載保持較小，且對話可以在服務端進行修剪或總結，無需隨著對話增長重新傳送完整內容。最終，決定應匹配基礎設施與工作流需求，平衡擴充套件性與功能性。