在生产级 Agent 开发里面，状态不能全部堆在内存，也不能一股脑直接落库，核心思路是按访问速度、存活周期、故障恢复要求、分布式共享需求分层存放，单次循环里临时变量放进程内存，跨实例、跨轮次的会话运行状态放到 Redis，需要永久留存、支持审计、任务恢复、跨会话复用的可靠数据存入持久化数据库。进程内存读写速度最快，但是进程重启、扩缩容、负载均衡切换节点之后数据直接丢失，所以只适合本轮推理循环里面的临时中间值；Redis 属于分布式共享高速缓存，带过期时间，适合保存活跃会话的当前任务快照、近期对话、工具返回临时结果，多机部署时不同服务实例可以读到同一份会话状态，还能设置 TTL 自动清理过期会话；持久化数据库用来保存业务上不能丢的数据，就算服务集群全部宕机，任务记录、用户档案、审计日志、最终成果依然可以找回，同时支持复杂查询、事务和归档，代价是读写延迟更高。线上标准做法一般是每一轮 Agent 执行，先从 Redis 加载会话快照，本轮计算临时变量放内存，本轮结束把更新后的检查点写回 Redis，同时把关键事件、任务记录异步写入数据库。
三类存储存放内容对照表格
| 存储位置 | 适合存放的 Agent 状态 | 典型特征 | 风险与约束 |
|---|---|---|---|
| 进程内存 | 本轮循环临时变量、模型即时输出、临时过滤结果、循环标记、临时缓冲区 | 访问最快、不需要跨实例共享、丢了可以重新计算 | 进程崩溃、重启、切实例直接丢失，不能做分布式共享 |
| Redis | 活跃会话快照、当前任务状态、最近多轮对话、工具中间返回、限流幂等、检查点 | 跨实例共享、毫秒读取、支持 TTL 自动清理，可做断点恢复 | 默认不是强持久，Redis 宕机有丢会话风险，适合短期活跃任务 |
| 持久化数据库（MySQL/PostgreSQL） | 用户档案、任务主记录、完整审计流水、最终交付结果、长期用户记忆、历史归档、收费记录 | 永久保存、支持事务、复杂检索、合规审计 | 读写延迟更高，频繁同步会拉高数据库压力，一般异步落库 |
进程内存存放明细清单
- 当前这一轮推理里面临时构造的 prompt 片段、临时过滤后的文档片段
- 工具调用拿到还没合并到会话快照的一次性返回数据
- 循环控制标记、临时排序结果、临时统计值
- 仅当前函数内部使用、不需要带到下一轮 Agent 循环的临时变量
- 临时校验标记、临时缓存，本轮跑完直接丢弃，不影响任务连续性
Redis 存放明细清单
- 会话维度的当前状态机：规划中、等待用户输入、工具执行中、完成、失败
- 当前任务计划、待执行子任务列表、已完成步骤快照
- 最近 N 轮对话消息、摘要、实体信息，用来组装上下文
- 可恢复检查点：任务跑到一半的快照，失败后可以直接从这里继续跑
- 幂等 key、频率限制、锁、多 Agent 协作的临时共享标记
- 配置合理的 TTL，会话长时间不活跃自动失效，释放存储资源
持久化数据库存放明细清单
- 用户基础资料、长期稳定偏好、跨会话的用户记忆
- 任务主表：任务 ID、归属用户、创建时间、最终状态、结果地址
- 完整审计链路：每一次模型调用、工具调用、入参、返回、耗时
- Agent 最终产出文档、报告、文件索引、收费、调用账单记录
- 历史会话归档，会话过期后从 Redis 迁移到数据库长期保存
- 权限配置、Agent 模板、插件配置这类基础业务配置
标准执行步骤（线上分层流转）
- 用户发起请求，携带 session_id，服务从 Redis 读取该会话最新检查点状态
- 加载状态进入 Agent 执行循环，本轮计算产生的临时中间数据放在进程内存
- Agent 完成规划、工具调用、模型生成，更新会话状态
- 将更新后的会话快照写回 Redis，作为下一轮访问的检查点
- 通过异步队列，把关键事件、任务变更、审计数据写入持久化数据库
- 如果会话长时间无交互，Redis 到期自动清除；数据库里面任务记录永久留存或者按归档策略保留
- 如果任务失败、服务重启，优先从 Redis 的检查点恢复；Redis 丢失时，再从数据库归档重建状态
容易踩坑的几个关键点
- 不要把全部对话历史一直塞 Redis，长会话要做摘要压缩，控制存储体积
- Redis 只做活跃会话，不要当成永久存储；重要任务要异步落库兜底
- 不要把跨实例依赖的状态放在进程内存，负载均衡切换节点之后状态丢失，任务断裂
- 检查点不能太频繁，频繁写入 Redis 会增加延迟；也不能太少，崩溃后大量工作重做
- 长期记忆和短期会话状态分开，长期记忆走数据库或者向量库，不要混在会话快照里
【相关 FAQ】
问题 1：Agent 状态管理怎么划分，哪些状态放内存，哪些放 Redis，哪些进持久化数据库？
回答 1：Agent 状态管理按照生命周期、共享需求、可靠性分层，单次循环临时计算数据放进程内存；活跃会话快照、当前任务进度、近期对话、断点检查点放到 Redis；不能丢失、需要审计归档、跨会话复用的业务记录、用户档案、任务最终结果存入持久化数据库。
问题 2：Agent 状态管理里面，Redis 里面的 Agent 会话快照如果丢了怎么办？
回答 2：Agent 状态管理方案里面，Redis 只作为高速中间层，每一轮关键变更都会异步把任务事件和审计记录写入持久化数据库，如果 Redis 会话快照丢失，可以根据数据库里面的历史记录重建任务上下文，代价是恢复速度更慢，部分中间临时细节无法还原。
问题 3：分布式部署多个 Agent 服务实例，能不能把 Agent 的任务状态直接放在进程内存？
回答 3：不可以，分布式场景下 Agent 状态如果放在进程内存，用户下一次请求被调度到别的服务节点就读不到状态，任务直接中断；跨实例共享的运行状态，统一放到 Redis 来保证所有节点读到同一份 Agent 状态。
问题 4：做 Agent 状态管理的时候，是不是所有对话记录都要直接写入数据库？
回答 4：不需要，近期活跃对话先放在 Redis 用于快速组装上下文，会话结束或者过期之后，再把完整记录或者摘要异步迁移进持久化数据库，这样兼顾访问速度，同时避免高频写入压垮数据库。
【参考资料】
[2026-09-20]（面试官：Agent 聊几十轮，状态怎么管，不能只存 Redis）51CTO
[2026-09-24]（Azure Managed Redis：AI Agent 短期会话与长期记忆实践）Microsoft Learn
[2026-06-01]（AI Agent State Management：Checkpointing、Shared State、Crash Recovery）OpenLegion
[2026-05-12]（LangGraph + Redis 实现有状态 Agent 记忆）Redis 官方博客
[2026-04-10]（Multi-agent Reference Architecture 会话与状态存储规范）Microsoft Open Source
【免责声明】
本内容基于大模型 Agent 工程实践、LangGraph、Redis 官方文档以及技术社区面试资料整理；Agent 状态管理方案需要结合业务并发、任务时长、成本、合规要求调整，不同框架、不同业务场景下存储策略会存在差异；本内容仅作为面试学习、技术方案参考，不直接等同于生产环境最终架构，上线前需要做好断电、宕机、并发冲突的压测与兜底方案。