💾 状态管理与持久化
🎯 为什么 Agent 需要状态管理
Agent 是有状态的服务——它在多轮交互中积累上下文、在执行任务过程中维护中间状态、在长期运行中积累知识和经验。没有可靠的状态管理，Agent 的服务重启、崩溃恢复、水平扩容都将导致数据丢失和用户体验断裂。
📋 会话状态管理
会话状态是 Agent 在一次对话/任务中的临时上下文，包括对话历史、当前执行计划、中间推理结果、待完成的子任务等。
会话状态的三个层次
| 层次 | 内容 | 生命周期 | 存储要求 |
|---|---|---|---|
| 请求级状态 | 单次 LLM 调用的输入/输出、工具调用参数/结果 | 单次请求 | 内存（无持久化） |
| 会话级状态 | 对话历史、执行计划、中间步骤、上下文窗口 | 单次会话（分钟~小时） | Redis / 内存数据库 |
| 用户级状态 | 长期记忆、偏好设置、历史行为模式 | 跨会话（天~永久） | PostgreSQL / MongoDB / 向量数据库 |
🔑 会话标识（Session ID）
每次会话分配唯一 Session ID，所有状态以 Session ID 为键进行索引和查询。支持：
- 基于 Session ID 的状态读取/写入
- 会话过期自动清理（TTL 机制）
- 用户与会话的一对多映射
📦 状态序列化
Agent 状态对象（对话历史、执行计划等）需要高效序列化：
- JSON：通用格式，可读性好
- MessagePack：二进制格式，更紧凑
- Pickle：Python 原生，有安全风险
🔄 状态同步
在多实例部署场景下，确保同一会话的请求路由到同一实例（会话亲和性），或使用共享存储：
- Sticky Session：负载均衡层绑定
- 共享 Redis：无状态实例 + 集中存储
💿 Agent 状态持久化方案
选择持久化方案时需要综合考虑性能、一致性、可用性三个维度：
方案一：内存 + 定期快照
运行时状态保持在内存中，定期将完整状态快照写入磁盘或对象存储。适合对持久化要求不高的场景。
- 优点：实现简单，读写极快
- 缺点：快照间隔内的状态丢失，恢复粒度粗
- 适用：原型阶段、非关键任务
方案二：Redis / 内存数据库
使用 Redis 作为会话状态的热存储层，提供毫秒级读写。支持 TTL 自动过期、主从复制、集群模式。
- 优点：极低延迟、内置过期机制、支持发布订阅
- 缺点：纯内存成本高、数据量受内存限制
- 适用：会话状态、在线服务的主流方案
方案三：关系型数据库 (PostgreSQL/MySQL)
使用关系型数据库存储结构化的 Agent 状态（用户偏好、任务记录、审计日志等）。支持复杂查询和事务。
- 优点：ACID 事务、复杂查询、成熟生态
- 缺点：读写延迟高于内存数据库，JSON 字段查询效率受限
- 适用：长期存储、需要事务保证的元数据
方案四：文档数据库 (MongoDB)
使用 MongoDB 存储半结构化的 Agent 状态，Schema-less 特性适合 Agent 状态的灵活变化。
- 优点：灵活的 Schema、良好的横向扩展
- 缺点：复杂查询能力弱于关系型数据库
- 适用：状态结构频繁变化的场景
🧠 长期记忆存储
Agent 的长期记忆超越了单次会话的范围，需要专门的存储架构来支持语义检索和知识演化：
长期记忆存储架构
| 记忆类型 | 存储引擎 | 检索方式 | 典型内容 |
|---|---|---|---|
| 事实记忆 | 向量数据库（Pinecone / Milvus / pgvector） | 语义相似度检索 | 用户姓名、偏好、历史问题 |
| 经验记忆 | 图数据库（Neo4j） | 关系图谱遍历 | 任务执行经验、成功/失败模式 |
| 知识记忆 | 文档数据库 / 对象存储 | 全文检索 + 向量检索 | 学习到的领域知识、规则 |
| 事件记忆 | 时序数据库 / 日志系统 | 时间范围查询 | 完整的交互历史时间线 |
🔄 状态恢复与故障转移
生产环境中，Agent 服务可能因各种原因中断（崩溃、重启、迁移）。状态恢复机制确保服务恢复后无缝继续：
恢复策略对比
| 策略 | 恢复粒度 | 数据丢失窗口 | 实现复杂度 |
|---|---|---|---|
| 冷恢复 | 从持久化存储重新加载完整状态 | 最后一次写入到故障时刻 | 低 |
| 热恢复 | 通过 Redis Sentinel / Cluster 自动故障转移 | 秒级（主从切换延迟） | 中 |
| 实时同步 | Write-Ahead Log (WAL) 逐操作回放 | 毫秒级 | 高 |
| 主动-主动 | 多实例同时处理，通过一致性协议同步 | 接近零 | 极高 |
💡 最佳实践
推荐采用 Redis + PostgreSQL 双层架构：Redis 作为会话级状态的热存储（高性能读写 + TTL），PostgreSQL 作为用户级状态的冷存储（持久化 + 复杂查询）。定期将 Redis 中的关键状态异步写入 PostgreSQL，兼顾性能和可靠性。
📊 状态管理方案对比
| 方案 | 读写延迟 | 持久化 | 扩展性 | 查询能力 | 运维复杂度 | 适用场景 |
|---|---|---|---|---|---|---|
| 内存 (Dict) | 纳秒级 | 无 | 单机 | 无 | 无 | 原型开发 |
| Redis | 毫秒级 | RDB/AOF | 集群 | Key-Value + 简单聚合 | 低 | 会话状态、缓存 |
| PostgreSQL | 毫秒~十毫秒 | ACID 强持久 | 主从/分片 | SQL + JSON | 中 | 元数据、审计日志 |
| MongoDB | 毫秒级 | 副本集 | 分片集群 | 文档查询 + 聚合管道 | 中 | 半结构化状态 |
| 向量数据库 | 十毫秒级 | 持久化 | 水平扩展 | 语义相似度 | 中-高 | 长期记忆语义检索 |
| 图数据库 | 毫秒~十毫秒 | ACID | 主从 | 图遍历/关系 | 高 | 经验记忆关系推理 |