有状态 vs 无状态代理设计：可扩展代理系统的权衡
本文探讨了AI代理中状态管理的两种范式——无状态和有状态设计，分析了各自的扩展性权衡，并通过Groq API的代码示例说明了实现方式。无状态代理易于水平扩展但需客户端传递完整对话历史，有状态代理通过数据库管理内存但增加架构复杂性。
在AI代理的部署中，一个关键的设计决策是代理如何管理状态——即对话历史和上下文。状态管理方式不仅影响代理的实现，还决定了整个部署架构。本文深入比较了无状态和有状态两种范式，并通过具体代码示例展示了它们的实际运作方式。
无状态代理将每个请求视为完全独立的事件。代理接收用户提示，调用LLM推理引擎，输出结果后立即遗忘所有信息。这种设计的核心优势在于水平扩展极其简单：由于后端不存储任何用户记忆，传入请求可以转发给任意可用实例，无需担心状态同步问题。然而，在多轮对话中，前端必须随每个新请求重新发送完整的对话历史。随着对话进行，上下文窗口像滚雪球一样增长，导致令牌消耗迅速增加。文中使用Groq API和Llama 3.1 8B Instant模型展示了一个无状态代理的简化实现：stateless_agent函数接受当前提示和可选的先前历史，但自身不保留任何状态。测试表明，若不提供历史，代理无法记住用户在前一轮中提供的姓名和学习主题。
有状态代理则主动承担记忆负担。客户端只需发送最新的用户提示和唯一的会话标识符，代理从数据库中检索会话历史，追加新消息，调用LLM，然后将更新的上下文保存回数据库。这种方式在客户端侧体验更简洁，也支持复杂的异步工作流，例如代理需要暂停执行等待工具响应或人工审批。但代价是架构的复杂性显著增加：需要引入持久化数据库层，并且在水平扩展场景中，可能需要像Redis这样的集中式内存缓存来避免“局部失忆”——即某个会话的历史被孤立在仅处理过早期轮次的单一实例上。文中通过一个使用SQLite内存数据库的stateful_agent函数演示了基本原理：该函数根据session_id检索历史，处理新提示，并更新数据库。测试显示，客户端只需提供会话ID，代理即可准确回忆用户姓名。
选择哪种设计取决于具体用例。无状态代理适用于简单、任务导向的管线，如文本提取、摘要或单轮分类聊天机器人。它们保持架构轻量，避免数据库瓶颈，实现无缝水平扩展。有状态代理则更适合长期运行的助手、编码助手或多轮客服机器人。由于代理拥有历史，客户端负载保持较小，且对话可以在服务端进行修剪或总结，无需随着对话增长重新发送完整内容。最终，决定应匹配基础设施与工作流需求，平衡扩展性与功能性。