Agent 状态持久化：基于 Redis 的多轮交互上下文存储方案

一、 引言 (Introduction)1.1 钩子从 Siri 答非所问到 AI Agent 的「失忆症噩梦」你有没有遇到过这种令人血压升高的场景早上起床对着家里的智能音箱假设它搭载了最新的「多轮对话」AI Agent说“嘿帮我查下今天北京到上海虹桥的最早一班高铁是什么时候”AI Agent 立刻回答“今天北京南站到上海虹桥站的最早一班高铁是 G1 次07:00 发车11:36 到达二等座余票充足。”你满意地点点头接着说“帮我订一张二等座靠窗的。”结果AI Agent居然一脸懵或者说输出一段毫无关联的废话“抱歉我没有找到靠窗座位的相关信息。请问您需要查询什么天气、新闻还是其他服务”你是不是瞬间想把音箱砸了为什么它刚才还知道你要查「北京→上海虹桥最早一班高铁」现在就忘了要「订这一班的二等座靠窗」这种情况背后的核心痛点就是AI Agent 的「短期记忆能力有限」与「长时多轮上下文依赖」之间的矛盾——传统的 LLM大语言模型单次输入的 Token 上限是固定的比如 GPT-4o-mini 是 128KGPT-4o 是 200M但商用版的部署成本极高且超过一定阈值后推理效率骤降如果我们每次交互都把所有历史对话包括用户输入、Agent 思考、工具调用结果、中间推理状态一股脑塞给 LLM很快就会触发 Token 溢出导致对话中断或质量急剧下降如果我们只保留最近的 3-5 轮对话又会像刚才的例子一样丢失关键的长时依赖信息让 Agent 变成「三分钟热度的金鱼」。解决这个问题的关键就是Agent 状态持久化技术——我们需要一个专门的「记忆仓库」能够精准存储不仅存文本对话还要存 Agent 的中间状态比如工具调用的上下文、任务的执行进度、用户的偏好配置高效检索当 LLM 需要时能快速从记忆仓库中「捞」出最相关的上下文片段而不是全部塞给 LLM持久化保存即使 Agent 重启、服务器宕机记忆也不会丢失灵活管理支持记忆的追加、修改、删除、压缩、归档等操作高并发支持在多用户、多 Agent 实例的场景下仍然能保持低延迟、高吞吐。在众多的记忆仓库方案中Redis无疑是目前最热门、最成熟、性价比最高的选择之一——它的高性能读写、丰富的数据结构、灵活的内存管理、完善的持久化机制完美契合了 Agent 状态持久化的需求。1.2 定义问题/阐述背景AI Agent 时代为什么「记不住事」会成为瓶颈要理解为什么 Agent 状态持久化如此重要我们首先要搞清楚什么是 AI Agent根据 OpenAI 在 2023 年发布的《AgentGPT》、LangChain 创始人 Harrison Chase 的定义以及行业内的共识AI Agent 是一种能够感知环境、根据目标自主制定计划、调用工具执行任务、并根据反馈不断调整的智能体——它不再是传统的「问答机器人」一问一答单次交互而是一个「有记忆、有思考、有行动能力的数字员工」。目前AI Agent 的应用场景已经非常广泛个人助理帮你订机票、酒店、安排日程、管理财务、处理邮件客服机器人处理多轮的售后问题比如用户先问「退款流程」再补充「我是昨天在天猫旗舰店买的 iPhone 16 Pro Max有划痕」最后又问「退款多久能到账」代码助手帮你写代码、调试代码、重构代码——比如你先让它「写一个 Python 爬虫爬取豆瓣 Top250 电影的信息」接着让它「修改一下把数据存到 MySQL 数据库」然后让它「再加一个功能生成可视化的电影评分柱状图」游戏 NPC在开放世界游戏中NPC 能记住玩家的行为比如你之前帮过它或者你偷过它的东西并根据这些记忆做出不同的反应企业业务流程自动化比如一个「财务报销审核 Agent」它需要记住报销单的审核进度比如第一步是「审核发票真实性」第二步是「审核金额是否合理」第三步是「提交给部门经理审批」、之前审核过的类似报销单的处理方式、部门经理的审批偏好比如部门经理不喜欢超过 1000 元的餐饮报销。在这些场景中「记不住事」会直接导致 Agent 的可用性、可靠性、用户体验急剧下降个人助理场景如果订机票时忘了航班号、忘了出发地目的地、忘了用户的身份证号那这个助理就是个摆设客服机器人场景如果忘了用户的订单号、忘了用户之前反映的问题、忘了客服之前给出的解决方案那用户只会越来越生气最终转接人工反而增加了企业的成本代码助手场景如果忘了之前写的代码逻辑、忘了用户的需求细节那修改出来的代码肯定会有 bug游戏 NPC 场景如果忘了玩家的行为那开放世界游戏的「沉浸感」就会荡然无存企业业务流程自动化场景如果忘了审核进度、忘了类似报销单的处理方式、忘了部门经理的审批偏好那报销审核的效率不仅不会提高反而会出错。既然「记不住事」是瓶颈那我们该怎么解决呢1.3 传统方案的局限从本地内存到关系型数据库为什么它们都不行在正式介绍「基于 Redis 的 Agent 状态持久化方案」之前我们先来看看传统的记忆存储方案以及它们为什么不适合 AI Agent1.3.1 方案一本地内存存储最简单的记忆存储方案就是把 Agent 的状态比如历史对话、中间推理状态、任务进度直接存到本地内存比如 Python 的字典、Java 的 HashMap、Go 的 Map里。这种方案的优点很明显速度极快本地内存的读写延迟是纳秒级别的完全不需要网络开销实现简单不需要安装任何额外的软件直接用编程语言自带的数据结构就行。但它的缺点也非常致命无法持久化一旦 Agent 重启、服务器宕机、进程崩溃所有的记忆都会丢失无法共享状态如果你的 Agent 是部署在多台服务器上的比如 Kubernetes 集群里的多个 Pod或者你有多个 Agent 实例需要共享同一个用户的记忆比如用户在手机上用助理订了机票又在电脑上查机票信息那本地内存存储完全做不到内存容量有限本地内存的容量是有限的比如一台普通的服务器只有 128GB 或 256GB 内存如果要存储大量用户的记忆比如 1000 万用户每个用户平均 1MB 记忆那就是 10TB本地内存根本不够无法高效管理记忆比如你想压缩某个用户的记忆把不重要的对话删掉或者用摘要代替、归档某个用户的历史记忆把 3 个月前的记忆存到冷存储里、或者搜索某个用户的特定记忆比如「用户之前提到的「生日蛋糕店」在哪里」用本地内存存储会非常困难效率也很低。因此本地内存存储只能用于开发测试阶段或者单用户、单实例、不需要持久化的场景完全不适合生产环境。1.3.2 方案二关系型数据库存储接下来我们试试把记忆存到关系型数据库比如 MySQL、PostgreSQL、Oracle里。关系型数据库的优点也不少可以持久化数据存到硬盘上即使服务器宕机数据也不会丢失可以共享状态多个 Agent 实例可以连接到同一个关系型数据库共享用户的记忆可以高效管理数据支持 SQL 查询可以方便地追加、修改、删除、搜索、统计数据容量大可以通过分库分表、读写分离等方式无限扩展存储容量事务支持可以保证数据的一致性比如在追加记忆的同时修改任务进度这两个操作要么都成功要么都失败。但它的缺点也很突出尤其是在 AI Agent 这种「高并发、低延迟、读写混合且读多写少、数据结构半结构化或非结构化」的场景下读写延迟高关系型数据库的读写延迟是毫秒级别的比如 MySQL 的单次查询延迟大概是 1-10ms而且需要网络开销如果数据库和 Agent 不在同一台服务器上——对于 AI Agent 这种「每轮交互都需要读写记忆」的场景来说10ms 的延迟可能会导致整个交互的延迟增加到 100ms 以上因为 LLM 本身的推理延迟就有几十到几百毫秒严重影响用户体验半结构化/非结构化数据存储效率低Agent 的状态通常是半结构化或非结构化的——比如历史对话是一段段的文本中间推理状态可能是一个 JSON 对象工具调用结果可能是一个列表用户的偏好配置可能是一个键值对。关系型数据库虽然可以用 TEXT、BLOB 等字段存储这些数据但存储效率、查询效率都很低——比如你想搜索某个用户的历史对话中包含「生日蛋糕店」的所有记录用 MySQL 的 LIKE 查询SELECT * FROM conversations WHERE user_id 123 AND content LIKE %生日蛋糕店%是非常慢的因为 LIKE 查询无法使用索引高并发支持差关系型数据库的高并发支持主要依赖于「读写分离」和「分库分表」但这两种方案的实现复杂度都非常高——而且即使实现了关系型数据库的并发读能力也很难超过 10万 QPS每秒查询次数并发写能力更难超过 1万 QPS。对于 AI Agent 这种「可能有几百万甚至几千万用户同时在线每轮交互都需要读写记忆」的场景来说关系型数据库的高并发支持是远远不够的无法支持「会话超时自动清理」等功能AI Agent 的记忆通常有「有效期」——比如我们只需要保留用户最近 7 天的对话7 天前的对话可以自动清理掉。用关系型数据库实现这个功能要么需要写一个定时任务比如每天凌晨 3 点扫描整个数据库删除 7 天前的记录效率非常低要么需要用 MySQL 的「事件调度器」或者 PostgreSQL 的「pg_cron」插件但实现起来也比较麻烦而且性能也不好。因此关系型数据库可以作为 Agent 记忆的「冷存储」比如归档 3 个月前的记忆但不适合作为「热存储」比如存储用户最近 7 天的记忆每轮交互都需要读写。1.3.3 方案三NoSQL 文档型数据库存储既然关系型数据库不行那我们试试NoSQL 文档型数据库比如 MongoDB、CouchDBNoSQL 文档型数据库的优点包括可以持久化数据存到硬盘上持久化能力和关系型数据库差不多可以共享状态多个 Agent 实例可以连接到同一个文档型数据库半结构化/非结构化数据存储效率高文档型数据库天生就是用来存储 JSON/BSON 对象的Agent 的状态历史对话、中间推理状态、任务进度、用户偏好可以直接作为一个 JSON 对象存进去不需要做任何的 schema 设计或者可以做灵活的 schema 设计可以高效查询半结构化/非结构化数据文档型数据库支持对 JSON 对象的字段进行索引比如你想搜索某个用户的历史对话中包含「生日蛋糕店」的所有记录可以用 MongoDB 的「文本索引」db.conversations.createIndex({ content: text })查询效率比 MySQL 的 LIKE 查询高很多高并发支持比关系型数据库好文档型数据库通常采用「分片集群」的架构可以横向扩展高并发能力——比如 MongoDB 的分片集群可以支持几十万甚至几百万 QPS 的并发读几万 QPS 的并发写。但它的缺点还是存在尤其是在「低延迟读写」方面读写延迟仍然较高文档型数据库的读写延迟虽然比关系型数据库低比如 MongoDB 的单次查询延迟大概是 0.5-5ms但仍然是毫秒级别的而且需要网络开销——对于 AI Agent 这种「每轮交互都需要读写记忆」的场景来说5ms 的延迟可能还是会导致整个交互的延迟增加到 50ms 以上内存使用效率不如 Redis文档型数据库虽然也会把热数据缓存在内存里但它的内存管理机制不如 Redis 灵活——比如 MongoDB 的内存是「按需分配」的可能会导致内存浪费而 Redis 的内存是「完全可控」的你可以设置最大内存容量然后选择合适的内存淘汰策略比如 LRU、LFU**无法支持「键值对」以外的更丰富的数据结构不等一下——MongoDB 也支持数组、嵌套对象等数据结构但 Redis 支持的数据结构更丰富比如字符串、哈希、列表、集合、有序集合、位图、HyperLogLog、Geo、Stream 等而且这些数据结构都是专门为「高性能读写」设计的——比如 Redis 的列表可以支持 O(1) 复杂度的「头部插入」、「尾部插入」、「头部弹出」、「尾部弹出」操作而 MongoDB 的数组虽然也支持这些操作但复杂度是 O(n)如果数组很大的话性能会很差。因此NoSQL 文档型数据库可以作为 Agent 记忆的「温存储」比如存储用户最近 1 个月的记忆偶尔需要读写但仍然不适合作为「热存储」。1.4 亮明观点/文章目标为什么 Redis 是 Agent 状态持久化的最佳选择既然本地内存、关系型数据库、NoSQL 文档型数据库都不行那我们该选什么呢答案就是——RedisRedisRemote Dictionary Server远程字典服务器是一个开源的、基于内存的、支持多种数据结构的高性能键值对存储系统——它的核心优势完美契合了 AI Agent 状态持久化的需求极高的读写性能Redis 的读写延迟是微秒级别的比如单次 SET/GET 操作的延迟大概是 0.1-0.5ms而且支持极高的并发能力比如 Redis 的单实例可以支持 10万-100万 QPS 的并发读10万-50万 QPS 的并发写如果用 Redis 集群的话并发能力可以无限扩展——这对于 AI Agent 这种「每轮交互都需要读写记忆」的场景来说简直是完美的丰富的数据结构Redis 支持10 种专门为不同场景设计的数据结构——比如字符串可以存用户的基本信息、Agent 的任务进度摘要、哈希可以存用户的偏好配置、Agent 的中间推理状态、列表可以存用户的历史对话按时间顺序排列、集合可以存用户的兴趣标签、有序集合可以存用户的历史对话按重要性排序用于检索、Stream可以存用户的对话流支持消费者组用于多 Agent 实例协作——这些数据结构可以让我们非常灵活、高效地存储和管理 Agent 的状态完善的持久化机制Redis 虽然是基于内存的但它支持两种持久化机制——RDBRedis Database快照持久化和 AOFAppend Only File日志持久化——可以让我们在保证高性能的同时也能保证数据的安全性即使服务器宕机数据也不会丢失或者只会丢失很少的数据灵活的内存管理机制Redis 支持设置最大内存容量并且支持8 种内存淘汰策略比如 LRU最近最少使用、LFU最不经常使用、volatile-lru只淘汰设置了过期时间的键的最近最少使用的键、allkeys-lru淘汰所有键的最近最少使用的键——可以让我们非常灵活地管理内存避免内存溢出支持键的过期时间Redis 支持给键设置过期时间比如 EXPIRE、PEXPIRE、EXPIREAT、PEXPIREAT 命令——可以让我们非常方便地实现「会话超时自动清理」等功能比如我们给每个用户的记忆键设置 7 天的过期时间7 天后 Redis 会自动删除这些键不需要我们写任何的定时任务支持发布订阅模式Redis 支持发布订阅模式Pub/Sub——可以让我们实现「多 Agent 实例协作」的功能比如当一个 Agent 实例修改了某个用户的记忆时它可以发布一个消息其他 Agent 实例可以订阅这个消息然后更新自己的本地缓存开源、免费、生态成熟Redis 是完全开源的使用 BSD 许可证我们可以免费使用它——而且 Redis 的生态非常成熟有很多优秀的客户端库比如 Python 的 redis-py、Java 的 Jedis/Lettuce、Go 的 go-redis、管理工具比如 RedisInsight、Redis Commander、监控工具比如 Prometheus Grafana、集群方案比如 Redis Cluster、Codis可以让我们非常方便地使用和管理 Redis支持 Lua 脚本Redis 支持Lua 脚本——可以让我们把多个 Redis 命令打包成一个原子操作保证数据的一致性比如在追加历史对话的同时更新用户的最近活跃时间这两个操作可以用一个 Lua 脚本实现要么都成功要么都失败支持模块扩展Redis 支持模块扩展比如 RedisJSON、RedisSearch、RedisTimeSeries、RedisGraph——可以让我们把 Redis 变成一个「多模型数据库」比如用 RedisJSON 存储和查询半结构化/非结构化的 JSON 数据用 RedisSearch 实现全文检索用 RedisTimeSeries 存储和查询时间序列数据比如 Agent 的调用日志用 RedisGraph 存储和查询图数据比如用户的社交关系、任务的依赖关系——这些模块可以让我们更高效地存储和管理 Agent 的状态。正是因为这些核心优势Redis 已经成为了目前AI Agent 领域最热门、最成熟、性价比最高的记忆存储方案——比如 OpenAI 的 Assistants API 就是基于 Redis 来存储对话历史的虽然 OpenAI 没有明确说但从 Assistants API 的 API 设计、性能表现、功能特点来看它的底层记忆存储肯定是 RedisLangChain、LlamaIndex、AutoGPT、AgentGPT 等主流的 Agent 框架也都支持 Redis 作为记忆存储。1.5 文章结构预告接下来我们会讲什么在接下来的文章中我们会从零开始通过一个实战案例学习如何利用 Redis 构建一个高性能、高可用、可扩展的 Agent 状态持久化方案。具体来说文章的结构如下第二章基础知识/背景铺垫我们会先解释一些读者在理解文章核心内容前必须知道的关键术语和基本原理——比如什么是 AI Agent 的「状态」什么是「多轮交互上下文」什么是 RedisRedis 的核心数据结构、持久化机制、内存管理机制是什么第三章核心内容/实战演练这是文章的主体部分——我们会先介绍一个实战案例一个「智能财务报销审核 Agent」然后一步步地教大家如何用 Redis 来存储和管理这个 Agent 的状态包括步骤一环境准备安装 Redis、安装 Python 相关的依赖库redis-py、LangChain、OpenAI SDK 等步骤二系统功能设计设计这个 Agent 的核心功能比如报销单上传、发票真实性审核、金额合理性审核、部门经理审批、财务付款、报销进度查询步骤三系统架构设计设计整个系统的架构比如 Agent 层、记忆层、工具层、LLM 层以及记忆层的架构比如 Redis 的部署方式、数据结构的选择、键的命名规范步骤四系统接口设计设计记忆层的核心接口比如记忆的初始化、追加、查询、更新、删除、压缩、归档步骤五系统核心实现源代码用 Python 实现整个系统的核心代码包括记忆层的实现、Agent 的实现、工具的实现第四章进阶探讨/最佳实践在读者掌握了基本操作后我们会提供更有价值的深度内容——比如常见陷阱与避坑指南指出新手在实践中容易犯的错误比如键的命名不规范、数据结构选择不当、内存淘汰策略选择不当、持久化机制配置不当以及如何避免性能优化/成本考量探讨如何让方案更高效、更经济比如 Redis 集群的部署、内存的优化、缓存的使用、成本的控制最佳实践总结提供一些专家级的建议和原则第五章结论我们会总结文章最重要的观点或步骤展望该技术的未来发展趋势并且给读者留下一个开放性问题引发其进一步思考附录我们会提供一些进一步学习的资源链接相关文章、官方文档、开源项目等。好了话不多说让我们开始吧