有状态与无状态代理设计：可扩展代理系统的权衡
内容提要
本文探讨AI代理设计中无状态与有状态两种架构的权衡。无状态代理将每次请求视为独立，易于水平扩展，但需客户端每次发送完整对话历史，导致token消耗增加。有状态代理通过数据库管理自身记忆，客户端只需发送新提示和会话ID，体验更佳，但扩展需持久化数据库层，可能需Redis缓存避免会话历史丢失。选择取决于工作流：简单任务用无状态，复杂多轮对话用有状态。
延伸解读
无状态代理的扩展优势与成本
无状态代理将每次请求视为独立，后端不存储用户记忆，因此可以轻松地将请求分发到任意实例，实现水平扩展。然而，这种设计要求前端在每次多轮对话中重新发送完整的对话历史，导致上下文窗口像滚雪球一样增长，token消耗迅速增加。对于简单、单轮的任务（如文本提取、摘要），这种架构轻量且高效，但若用于多轮对话，成本会显著上升。
有状态代理的体验与扩展挑战
有状态代理通过数据库管理自身记忆，客户端只需发送新提示和会话ID，即可获得连贯的对话体验，也便于支持复杂的异步工作流。但扩展性面临挑战：需要引入持久化数据库层，且在水平扩展时，可能需要Redis等集中式缓存来避免会话历史“局部失忆”——即历史被绑定在某个实例上，导致其他实例无法访问。
架构选择取决于工作流复杂度
选择无状态还是有状态架构，应基于具体工作流：简单、特定任务（如单轮分类聊天机器人）适合无状态，保持架构轻量并避免数据库瓶颈；而长期运行的助手、编码助手或多轮客服机器人，则更适合有状态设计，因为代理拥有历史，客户端负载小，且可在服务端裁剪或总结对话，而非每次完整重发。
Q&A
无状态代理和有状态代理的主要区别是什么？
无状态代理将每次请求视为独立，不保留对话历史，需要客户端在每次请求中发送完整对话历史；有状态代理通过数据库管理自己的记忆，客户端只需发送新提示和会话ID。
无状态代理在扩展性方面有什么优缺点？
无状态代理易于水平扩展，因为后端不存储用户记忆，请求可转发到任何实例；但多轮对话时，客户端必须重新发送整个对话历史，导致token消耗增加。
有状态代理在扩展时面临哪些挑战？
有状态代理扩展时需要一个持久化数据库层，并且可能需要Redis等集中式缓存来避免会话历史丢失，因为会话历史可能被存储在单个实例上，导致水平扩展时出现'局部失忆'。
在什么场景下应该选择无状态代理？
无状态代理适合简单、面向特定任务的工作流，如文本提取、摘要或单轮分类聊天机器人，这些场景不需要复杂多轮对话，保持架构轻量且易于扩展。
在什么场景下应该选择有状态代理？
有状态代理适合需要长期运行或多轮对话的应用，如编码助手、客户服务机器人等，因为代理自己管理历史，客户端负载小，且可以在服务端进行对话修剪或总结。
无状态代理如何实现多轮对话？
无状态代理本身不保留记忆，多轮对话时，前端必须将之前的对话历史作为参数传递给代理，代理将其与当前提示一起发送给LLM，否则代理无法理解上下文。
有状态代理如何管理对话记忆？
有状态代理使用数据库（如SQLite）存储会话历史，客户端发送会话ID和新提示，代理从数据库检索历史，追加新消息，调用LLM后更新数据库中的历史。
