039、Agent的记忆持久化Redis与SQLite那天下午我差点把服务器砸了。客户那边报了个诡异的问题Agent跟用户聊了二十分钟一切正常。但只要服务一重启Agent就像失忆了一样用户刚才报的工单号、车牌号、甚至自己刚才说过的话全都不记得了。用户当场炸毛“这破AI是金鱼吗”我上去一看代码发现对话历史存在一个全局MapString, ListMessage里。进程活着的时候一切美好进程一死记忆跟着GC一起烟消云散。这事儿不怪Agent怪我没给Agent装上“永久记忆”——也就是所谓的记忆持久化。今天这期博客就聊聊我做Agent记忆持久化时趟过的两条路Redis 和 SQLite。别指望我给你列个表对比完事我会直接把调试现场和踩坑记录摊开给你看。先说Agent的记忆到底长什么样。一个正经Agent它的记忆分两层短期记忆是当前会话的上下文窗口比如最近几轮对话、临时状态长期记忆是跨会话的持久信息比如用户偏好、历史事实、业务数据。这两层需求完全不一样短期要高吞吐低延迟长期要稳定可靠不丢失。于是很多人犯了和我一样的错什么都往内存里塞或者什么都往数据库里写。我后来把短期记忆放在Redis里把长期记忆丢给SQLite。先说Redis。用Redis做Agent的短期记忆核心价值在一个“快”字。对话过程中每一轮消息都要读写用户还在等响应你搞个SQL查询动辄几十毫秒体验直接崩了。Redis 是纯内存操作延迟通常在亚毫秒级刚好满足这个场景。我用的是redis-py典型的结构是这样importredisimportjson rredis.Redis(hostlocalhost,port6379,db0)# 把一整轮对话存成一条hash记录key是session_id# 别用string硬拼后面取字段会哭的session_keyfagent:session:{session_id}r.hset(session_key,mapping{round:round_num,role:role,content:content,time:timestamp})# 同时设置过期时间比如30分钟无操作就自动清空r.expire(session_key,1800)这里有个坑我差点没哭出来。Redis的key如果设置了TTL过期之后整个会话就没了。我当时给所有会话key都配了60分钟过期结果用户聊到第59分钟时打了个长电话回来继续聊Agent直接失忆。更尴尬的是因为Redis里的历史没了Agent还跟用户说“我们第一次聊天吧”。你说气不气。解决方式很简单每次有新消息写入时都要重新刷新过期时间或者干脆在业务逻辑里做成滑动窗口——每次读写都重新expire。再说说为什么别把所有历史一股脑全塞进Redis。内存不是无限的而且Redis本身是缓存定位你把所有用户几十万条聊天记录都塞进去等机器内存报警就等着被运维请喝茶吧。我的建议是Redis里只保存当前会话的近期上下文比如最近10轮对话。更早的打包丢到SQLite里去存档。这个“导出压缩”的动作我用的是异步任务不影响主流程。代码大概长这样# 注意这里别同步做会卡住对话响应defarchive_memory(session_id,cutoff_time):# 从Redis取出这个session下早于cutoff_time的所有消息# 批量写入SQLite对应的表中# 然后从Redis里删掉这些消息或者只保留最近N轮pass接下来是SQLite。一开始我有点瞧不上这玩意儿觉得就是个小文件数据库能行吗后来发现行得很。Agent的长期记忆恰恰不需要每秒几千次的写入它要的是可靠和结构化。SQLite 单文件、零运维、事务支持好特别适合在单机环境里存长期记忆。我建了一张表记录用户长期事实比如姓名、车辆信息、服务偏好还有一张表存历史会话的归档消息。每次Agent启动时先查SQLite把该用户的事实加载到自己的长期知识库里。SQLite 的写入锁是个真坑。刚开始我用多线程写SQLite结果一有并发写直接报database is locked。后来才明白SQLite同一时刻只允许一个写事务写多读少的场景还好如果你边聊天边写历史用户正在疯狂发消息多个线程同时写就会阻塞。解决方案有两个一是把所有SQLite写操作丢到同一个单线程队列里二是开启 WAL 模式它能让读和写并发执行。我建议两个都上importsqlite3 connsqlite3.connect(agent_memory.db,check_same_threadFalse)# 开启WAL模式这里亲自试过并发读写靠谱多了conn.execute(PRAGMA journal_modeWAL;)# 顺便把busy_timeout设长一点别一锁就报错conn.execute(PRAGMA busy_timeout5000;)写入的时候一定要用参数化查询别拼字符串。有次我把用户输入直接拼进SQL结果用户发了句“are you sure”单引号差点没把库给炸了。这个教训和Python的SQL注入警告一样深刻。长期记忆的表结构我建议别搞太死板。因为Agent的记忆类型会变今天记的是用户生日明天可能记的是用户关注的股票代码。这时候最好用“实体-属性-值”的方式或者干脆存JSON。SQLite 支持JSON字段配合Python的字典操作舒服得很。比如# 别用text字段硬存你迟早会想查某个属性的conn.execute( CREATE TABLE IF NOT EXISTS long_term_memory ( user_id TEXT, memory_key TEXT, memory_value TEXT, updated_at TIMESTAMP, PRIMARY KEY (user_id, memory_key) ) )# 存的时候序列化memory_valuejson.dumps({stock:[AAPL,TSLA],preference:low_risk})conn.execute(INSERT OR REPLACE INTO long_term_memory (user_id, memory_key, memory_value, updated_at) VALUES (?, ?, ?, ?),(user_id,investment_preferences,memory_value,datetime.now()))读出来的时候再json.loads一下搞定。再聊聊两个方案怎么配合。我的习惯是用户进来先查SQLite把长期事实加载到Agent的上下文里对话过程中每轮消息先写Redis的短期窗口保证当前逻辑能快速取到上下文当一轮对话结束或者达到归档阈值就把Redis中的本轮记录搬进SQLite的历史表同时把Redis里对应的key清掉或者缩短TTL。这样Agent既有短期的高频响应能力又有长期的稳定记忆。还有一个血泪教训记忆持久化一定要加版本号或者时间戳。Agent的记忆不是静态的用户今天说喜欢运动风明天可能就改成商务风了。如果你只存一个值没有时间维度Agent就会把昨天的旧信息和今天的新信息混在一起产生“记忆混乱”。我后来在SQLite表里加了个version字段每次用户确认新信息都会递增版本读取的时候取最高版本。虽然有点丑但确实有效。顺便提一句Redis的持久化配置也别忽视。虽然Redis是内存数据库但你至少可以开启AOF或RDB来做落盘。我遇到过一台机器断电重启Redis所有会话数据全没的情况。后来我开了AOF但代价是写入性能略有下降。取个平衡如果你只是把Redis当短期缓存丢了也不致命那就别开AOF省点事但如果Redis里存了用户当下没归档的重要上下文那就开AOF而且注意设置appendfsync everysec别每写一次都同步磁盘慢。那到底该选Redis还是SQLite说实话不冲突。有一类Agent只用Redis做短期长期直接扔给后端MySQLSQLite反而多余。但如果你做的是本地运行、单机部署、边缘设备上的AgentSQLite就是最佳选择因为它不需要额外服务存在本地文件里随拿随走。反过来如果你的Agent是云端多实例部署需要多个进程共享同一个短期记忆那SQLite的文件锁就不合适了必须上Redis这种独立的KV服务。我见过有的方案把SQLite放在网络盘上然后多实例共用。别这么干SQLite的锁机制在网络文件系统上会出各种怪异问题比你想象中难缠得多。再聊聊序列化的事。Agent记忆里不光有文本还可能包含状态机、对象图、甚至函数调用的缓存结果。你在存Redis或者SQLite之前一定要设计好序列化格式。我现在统一用JSON但记住JSON只能保存基本数据类型。如果你的记忆里有datetime、Decimal、bytes这类对象得先转换成字符串或整型。不然json.dumps直接报TypeError。这里有个小技巧自定义一个JSON编码器把常见类型都转好免得每个地方都写转换逻辑。importjsonfromdatetimeimportdatetimeclassMemoryEncoder(json.JSONEncoder):defdefault(self,o):ifisinstance(o,(datetime,)):returno.isoformat()ifisinstance(o,bytes):returno.decode(utf-8,errorsignore)# 还有别的类型自己扩展returnstr(o)然后json.dumps(memory_obj, clsMemoryEncoder)省心。最后说下测试。我建议你写一套模拟“重启后记忆恢复”的集成测试。别等到线上用户骂娘才来后悔。做法很简单启动Agent跟它聊几轮存一些关键信息然后模拟进程崩溃强制退出别客气直接kill -9再重启Agent看它能不能正确回忆出刚才聊的内容。这个测试跑通了你的持久化策略才算基本合格。我自己的经验是记忆持久化不要追求一步到位。先做最简单的方案跑起来再根据真实使用场景慢慢优化。如果你刚开始就把Redis和SQLite玩出花来反而容易被复杂逻辑带偏。毕竟Agent的核心是智能记忆只是它的地基。地基塌了楼再漂亮也没用。下次你的Agent再“失忆”先查一下它到底有没有长期记忆的落库别只怪模型不行。
039、Agent的记忆持久化Redis与SQLite那天下午我差点把服务器砸了。客户那边报了个诡异的问题Agent跟用户聊了二十分钟一切正常。但只要服务一重启Agent就像失忆了一样用户刚才报的工单号、车牌号、甚至自己刚才说过的话全都不记得了。用户当场炸毛“这破AI是金鱼吗”我上去一看代码发现对话历史存在一个全局MapString, ListMessage里。进程活着的时候一切美好进程一死记忆跟着GC一起烟消云散。这事儿不怪Agent怪我没给Agent装上“永久记忆”——也就是所谓的记忆持久化。今天这期博客就聊聊我做Agent记忆持久化时趟过的两条路Redis 和 SQLite。别指望我给你列个表对比完事我会直接把调试现场和踩坑记录摊开给你看。先说Agent的记忆到底长什么样。一个正经Agent它的记忆分两层短期记忆是当前会话的上下文窗口比如最近几轮对话、临时状态长期记忆是跨会话的持久信息比如用户偏好、历史事实、业务数据。这两层需求完全不一样短期要高吞吐低延迟长期要稳定可靠不丢失。于是很多人犯了和我一样的错什么都往内存里塞或者什么都往数据库里写。我后来把短期记忆放在Redis里把长期记忆丢给SQLite。先说Redis。用Redis做Agent的短期记忆核心价值在一个“快”字。对话过程中每一轮消息都要读写用户还在等响应你搞个SQL查询动辄几十毫秒体验直接崩了。Redis 是纯内存操作延迟通常在亚毫秒级刚好满足这个场景。我用的是redis-py典型的结构是这样importredisimportjson rredis.Redis(hostlocalhost,port6379,db0)# 把一整轮对话存成一条hash记录key是session_id# 别用string硬拼后面取字段会哭的session_keyfagent:session:{session_id}r.hset(session_key,mapping{round:round_num,role:role,content:content,time:timestamp})# 同时设置过期时间比如30分钟无操作就自动清空r.expire(session_key,1800)这里有个坑我差点没哭出来。Redis的key如果设置了TTL过期之后整个会话就没了。我当时给所有会话key都配了60分钟过期结果用户聊到第59分钟时打了个长电话回来继续聊Agent直接失忆。更尴尬的是因为Redis里的历史没了Agent还跟用户说“我们第一次聊天吧”。你说气不气。解决方式很简单每次有新消息写入时都要重新刷新过期时间或者干脆在业务逻辑里做成滑动窗口——每次读写都重新expire。再说说为什么别把所有历史一股脑全塞进Redis。内存不是无限的而且Redis本身是缓存定位你把所有用户几十万条聊天记录都塞进去等机器内存报警就等着被运维请喝茶吧。我的建议是Redis里只保存当前会话的近期上下文比如最近10轮对话。更早的打包丢到SQLite里去存档。这个“导出压缩”的动作我用的是异步任务不影响主流程。代码大概长这样# 注意这里别同步做会卡住对话响应defarchive_memory(session_id,cutoff_time):# 从Redis取出这个session下早于cutoff_time的所有消息# 批量写入SQLite对应的表中# 然后从Redis里删掉这些消息或者只保留最近N轮pass接下来是SQLite。一开始我有点瞧不上这玩意儿觉得就是个小文件数据库能行吗后来发现行得很。Agent的长期记忆恰恰不需要每秒几千次的写入它要的是可靠和结构化。SQLite 单文件、零运维、事务支持好特别适合在单机环境里存长期记忆。我建了一张表记录用户长期事实比如姓名、车辆信息、服务偏好还有一张表存历史会话的归档消息。每次Agent启动时先查SQLite把该用户的事实加载到自己的长期知识库里。SQLite 的写入锁是个真坑。刚开始我用多线程写SQLite结果一有并发写直接报database is locked。后来才明白SQLite同一时刻只允许一个写事务写多读少的场景还好如果你边聊天边写历史用户正在疯狂发消息多个线程同时写就会阻塞。解决方案有两个一是把所有SQLite写操作丢到同一个单线程队列里二是开启 WAL 模式它能让读和写并发执行。我建议两个都上importsqlite3 connsqlite3.connect(agent_memory.db,check_same_threadFalse)# 开启WAL模式这里亲自试过并发读写靠谱多了conn.execute(PRAGMA journal_modeWAL;)# 顺便把busy_timeout设长一点别一锁就报错conn.execute(PRAGMA busy_timeout5000;)写入的时候一定要用参数化查询别拼字符串。有次我把用户输入直接拼进SQL结果用户发了句“are you sure”单引号差点没把库给炸了。这个教训和Python的SQL注入警告一样深刻。长期记忆的表结构我建议别搞太死板。因为Agent的记忆类型会变今天记的是用户生日明天可能记的是用户关注的股票代码。这时候最好用“实体-属性-值”的方式或者干脆存JSON。SQLite 支持JSON字段配合Python的字典操作舒服得很。比如# 别用text字段硬存你迟早会想查某个属性的conn.execute( CREATE TABLE IF NOT EXISTS long_term_memory ( user_id TEXT, memory_key TEXT, memory_value TEXT, updated_at TIMESTAMP, PRIMARY KEY (user_id, memory_key) ) )# 存的时候序列化memory_valuejson.dumps({stock:[AAPL,TSLA],preference:low_risk})conn.execute(INSERT OR REPLACE INTO long_term_memory (user_id, memory_key, memory_value, updated_at) VALUES (?, ?, ?, ?),(user_id,investment_preferences,memory_value,datetime.now()))读出来的时候再json.loads一下搞定。再聊聊两个方案怎么配合。我的习惯是用户进来先查SQLite把长期事实加载到Agent的上下文里对话过程中每轮消息先写Redis的短期窗口保证当前逻辑能快速取到上下文当一轮对话结束或者达到归档阈值就把Redis中的本轮记录搬进SQLite的历史表同时把Redis里对应的key清掉或者缩短TTL。这样Agent既有短期的高频响应能力又有长期的稳定记忆。还有一个血泪教训记忆持久化一定要加版本号或者时间戳。Agent的记忆不是静态的用户今天说喜欢运动风明天可能就改成商务风了。如果你只存一个值没有时间维度Agent就会把昨天的旧信息和今天的新信息混在一起产生“记忆混乱”。我后来在SQLite表里加了个version字段每次用户确认新信息都会递增版本读取的时候取最高版本。虽然有点丑但确实有效。顺便提一句Redis的持久化配置也别忽视。虽然Redis是内存数据库但你至少可以开启AOF或RDB来做落盘。我遇到过一台机器断电重启Redis所有会话数据全没的情况。后来我开了AOF但代价是写入性能略有下降。取个平衡如果你只是把Redis当短期缓存丢了也不致命那就别开AOF省点事但如果Redis里存了用户当下没归档的重要上下文那就开AOF而且注意设置appendfsync everysec别每写一次都同步磁盘慢。那到底该选Redis还是SQLite说实话不冲突。有一类Agent只用Redis做短期长期直接扔给后端MySQLSQLite反而多余。但如果你做的是本地运行、单机部署、边缘设备上的AgentSQLite就是最佳选择因为它不需要额外服务存在本地文件里随拿随走。反过来如果你的Agent是云端多实例部署需要多个进程共享同一个短期记忆那SQLite的文件锁就不合适了必须上Redis这种独立的KV服务。我见过有的方案把SQLite放在网络盘上然后多实例共用。别这么干SQLite的锁机制在网络文件系统上会出各种怪异问题比你想象中难缠得多。再聊聊序列化的事。Agent记忆里不光有文本还可能包含状态机、对象图、甚至函数调用的缓存结果。你在存Redis或者SQLite之前一定要设计好序列化格式。我现在统一用JSON但记住JSON只能保存基本数据类型。如果你的记忆里有datetime、Decimal、bytes这类对象得先转换成字符串或整型。不然json.dumps直接报TypeError。这里有个小技巧自定义一个JSON编码器把常见类型都转好免得每个地方都写转换逻辑。importjsonfromdatetimeimportdatetimeclassMemoryEncoder(json.JSONEncoder):defdefault(self,o):ifisinstance(o,(datetime,)):returno.isoformat()ifisinstance(o,bytes):returno.decode(utf-8,errorsignore)# 还有别的类型自己扩展returnstr(o)然后json.dumps(memory_obj, clsMemoryEncoder)省心。最后说下测试。我建议你写一套模拟“重启后记忆恢复”的集成测试。别等到线上用户骂娘才来后悔。做法很简单启动Agent跟它聊几轮存一些关键信息然后模拟进程崩溃强制退出别客气直接kill -9再重启Agent看它能不能正确回忆出刚才聊的内容。这个测试跑通了你的持久化策略才算基本合格。我自己的经验是记忆持久化不要追求一步到位。先做最简单的方案跑起来再根据真实使用场景慢慢优化。如果你刚开始就把Redis和SQLite玩出花来反而容易被复杂逻辑带偏。毕竟Agent的核心是智能记忆只是它的地基。地基塌了楼再漂亮也没用。下次你的Agent再“失忆”先查一下它到底有没有长期记忆的落库别只怪模型不行。
