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