从 ChatMemory 到 Mem0：我终于理解了 Agent 里的“记忆”到底是什么

一、为什么 Agent 一定需要“记忆”刚开始学习大模型应用时我一直觉得用户问一句模型答一句不就够了吗但真正做 Agent 项目的时候会发现这种方式只能完成一次性问答。如果用户连续追问或者过几天再回来继续之前的问题模型很容易“忘掉前面发生过什么”。比如我正在做一个智能运维 Agent用户第一次说这个项目主要排查 Java 服务、MySQL、Redis 和日志异常。第二天用户再问昨天那个服务又报警了你帮我继续分析一下。如果 Agent 没有记忆它其实不知道“昨天那个服务”是什么也不知道用户之前关注的是 Java 服务、MySQL、Redis还是日志系统。所以 Agent 记忆要解决的不是“让模型变聪明”这么简单而是解决三个很实际的问题1. 当前会话能不能接得住 2. 跨会话以后还能不能想起来 3. 记住的信息会不会越来越乱、越来越贵这也是为什么现在很多 Agent 框架都会单独设计 Memory 模块。IBM 对 AI Agent Memory 的解释中也提到长期记忆可以让 Agent 在不同会话之间存储和召回信息从而提升个性化和连续性常见实现会涉及数据库、知识图谱或向量嵌入等方式。二、先区分一个核心概念上下文 ≠ 记忆我之前容易把“上下文”和“记忆”混在一起。现在可以这样理解概念作用生命周期例子Context 上下文当前这次对话里给模型看的内容通常只在当前请求或当前会话中有效最近几轮聊天记录ChatMemory管理对话历史让模型能连续聊天通常按 sessionId 管理当前用户这个会话的历史消息Long-term Memory 长期记忆把有价值的信息长期保存下来跨会话、跨时间存在用户偏好、项目背景、常用工具、历史故障模式RAG 知识库给模型补充外部知识通常是文档级、知识级公司文档、接口说明、运维手册所以上下文更像临时草稿纸记忆更像长期笔记本。如果只是把最近几轮对话塞进 prompt这叫上下文管理。如果能把有价值的信息提取出来、保存起来、以后按需召回这才更接近 Agent Memory。三、Agent 里的几种常见记忆类型Agent 记忆可以按照不同维度划分。为了好理解我按实际开发中最常遇到的方式来总结。1. 短期记忆解决“当前对话别断片”短期记忆主要负责当前会话。比如用户连续问用户我这个项目用了 Milvus。 用户那它里面的 collection 是什么 用户那 vector 字段又是什么第三个问题里的“它”其实依赖前面的上下文。如果没有短期记忆模型可能不知道用户是在问 Milvus。在项目里短期记忆通常可以用sessionId - 最近 N 轮聊天记录比如MapString, ListMessage chatHistoryMap;或者更工程化一点MongoDB / Redis / MySQL 按 sessionId 存储用户最近对话短期记忆的重点不是“永久保存”而是让模型在当前会话里保持连续性。2. 长期记忆解决“下次还能想起来”长期记忆保存的是跨会话仍然有价值的信息。比如用户正在学习 Java AI Agent 用户目前准备找实习 用户项目是智能运维 Agent 用户更关注面试表达和项目包装 用户不希望把项目说成真实公司上线项目这些信息不是某一轮对话临时用一下而是后面很多次回答都会影响结果。比如下次用户问帮我写一下这个项目的面试回答。如果 Agent 有长期记忆它就应该知道不能包装成真实企业上线项目 应该说成导师 AI 方向启发下自主设计实现 要偏实习面试表达 要突出 Java Agent 工程能力这就是长期记忆的价值。Mem0 官方对自己的定位就是给 AI Agent 和应用提供持久化记忆层让上下文能够跨会话、跨 Agent 保留下来。3. 语义记忆记住“事实”语义记忆更像事实库。例如用户的项目技术栈是 Spring Boot Spring AI Alibaba Milvus DashScope。 RAG 的核心流程是文档切分、Embedding、向量检索、上下文增强、生成回答。 用户的 Agent 架构包含 Planner、Executor、Replanner。这些是事实型内容。以后用户问项目、简历、面试时这些事实可以被重新召回。4. 情节记忆记住“发生过什么”情节记忆更像经历记录。例如用户之前问过 Milvus collection 和 vector 字段的区别。 用户之前对 RAG 和 Memory 的边界有疑惑。 用户最近在连续写 CSDN 学习记录。 用户之前写过 Skill、RAG、Agent 工作流相关内容。这种记忆不是单纯事实而是“过去发生过的学习过程”。它可以帮助 Agent 更好地衔接用户当前学习阶段。LangChain 关于 Agent Memory 的文章里也提到Episodic Memory 更偏向回忆过去事件或过去行动序列常用于让 Agent 在之后执行类似任务时参考之前经验。5. 程序性记忆记住“怎么做”程序性记忆可以理解为 Agent 的操作习惯或执行方法。比如写 CSDN 时 1. 先总结今天学习内容 2. 标题要有吸引力 3. 内容要按初学者视角展开 4. 结合项目理解 5. 最后给出总结和下一步学习方向这类记忆不是“用户说了什么”而是“以后遇到类似任务应该怎么处理”。这和 Skill 有点像。Skill 更偏向把某类任务的执行方式沉淀成文件或工作流程序性记忆则更偏向 Agent 自己长期形成的执行经验。Mem0 的相关文章中也把长期记忆拆成 semantic、episodic、procedural 三类分别对应事实知识、历史经历和行为方式。四、ChatMemory 和真正的 Agent Memory 有什么区别很多框架里都有 ChatMemory比如 Spring AI 里也有类似对话记忆的设计。但 ChatMemory 更多解决的是当前 session 内如何把历史消息带给模型它通常做的是用户消息 - 存起来 AI 回复 - 存起来 下次请求 - 取最近几轮 - 拼进上下文这个东西非常重要但它还不等于完整的 Agent Memory。完整的 Agent Memory 还要进一步考虑哪些内容值得记 什么时候记 存成什么结构 旧记忆冲突了怎么办 用户删除记忆怎么办 如何避免召回无关记忆 记忆太多时如何压缩和筛选所以可以这样理解ChatMemory 对话历史管理 Agent Memory 信息提取 存储 更新 检索 注入上下文这也是我今天最大的一个认知变化记忆不是简单存聊天记录而是从聊天记录中提炼长期有价值的信息。五、Memory 和 RAG 到底有什么区别这个问题非常容易混。因为 Memory 也可能用向量数据库RAG 也用向量数据库。所以看起来它们好像是一个东西。但它们的目标不一样。1. RAG 更像“外挂知识库”RAG 主要解决的是模型不知道某些外部知识 所以需要从文档库里检索相关内容 再交给模型回答比如公司内部文档 产品说明书 接口文档 运维手册 项目 README 日志分析规则RAG 的数据通常是“外部知识”。它的核心流程是文档上传 文本解析 文本切分 Embedding 向量化 存入向量数据库 用户提问 相似度检索 拼接上下文 模型生成回答2. Memory 更像“用户和 Agent 的长期经验”Memory 主要解决的是Agent 如何记住用户、任务、偏好和历史经历比如用户喜欢什么回答风格 用户正在做什么项目 用户之前遇到过什么问题 某个运维告警之前怎么处理过 某个 Agent 执行任务时有哪些成功经验Memory 的数据通常来自“交互过程”。它的核心流程更像用户对话 提取有价值信息 判断是否需要保存 和旧记忆对比 新增 / 更新 / 删除 未来提问时召回相关记忆 注入 prompt 生成更贴合上下文的回答3. 一句话区分RAG让模型知道外部资料。 Memory让 Agent 记住用户和经历。再具体一点RAG 解决“知识不足” Memory 解决“连续性不足”当然底层实现上它们可能都会用向量数据库。Mem0 的资料中也提到一种常见做法是把 memory 转成 embedding并通过向量相似度进行召回也可以用图结构来保存实体和关系。所以不能简单说用了向量数据库就是 RAG。更准确地说向量数据库只是一种存储和检索手段。 RAG 和 Memory 是两种不同的应用目标。六、Mem0 是什么Mem0 可以理解为一个专门给 AI Agent 做长期记忆的 Memory Layer。它不是单纯的数据库也不是简单的聊天记录表而是帮我们处理记忆提取 记忆存储 记忆搜索 记忆更新 记忆去重 记忆关联Mem0 的 GitHub 介绍中提到它的目标是增强 AI 助手和 Agent 的记忆能力让系统能够记住用户偏好、适应用户需求并随着交互持续学习。一个非常简单的理解是不用 Mem0 开发者自己判断哪些内容要存、怎么存、怎么查、怎么更新。 使用 Mem0 把对话交给 Memory Layer它负责从中提取有价值记忆并在后续按需召回。七、Mem0 的基本使用思路Mem0 的典型使用方式一般离不开两个核心动作add添加 / 更新记忆 search搜索相关记忆也就是说用户说了一些有价值的信息 - memory.add() 用户再次提问 - memory.search()伪代码可以这样理解from mem0 import Memory memory Memory() # 1. 存储记忆 memory.add( messages[ {role: user, content: 我正在做一个基于 Spring AI 的智能运维 Agent 项目} ], user_iduser_001 ) # 2. 搜索记忆 related_memories memory.search( query用户的 Agent 项目是什么, user_iduser_001 ) # 3. 把召回的记忆放进 prompt这个流程和 RAG 很像但对象不同。RAG 检索的是文档知识。Memory 检索的是用户长期交互中沉淀下来的个人化信息、偏好和任务背景。Stackademic 的一篇 Mem0 介绍中也提到memory.add()通常触发提取和更新流程而memory.search()负责执行向量搜索。八、那 Mem0 的数据到底存在哪里这个问题我之前也比较疑惑。现在可以这样理解Mem0 本身是 Memory Layer不一定等于最终存储层。它可以把记忆存到不同后端里例如向量数据库用于语义相似度检索 图数据库用于保存实体关系 普通数据库用于保存结构化信息 KV 存储用于快速读写所以使用 Mem0 并不代表不需要数据库。更准确地说Mem0 负责“记忆管理逻辑” 数据库负责“记忆持久化存储”这就像Spring Data JPA 不是 MySQL 它只是帮你更方便地操作 MySQL Mem0 不是向量数据库 它是帮你更方便地管理 Agent MemoryMem0 新版本迁移文档中也提到了混合搜索、实体链接等能力这说明它不只是简单保存文本而是在向更完整的记忆管理方向发展。九、为什么不能把所有聊天记录都存起来最简单的想法是用户说过什么我都存下来不就有记忆了吗但这样会有几个问题。1. 噪声太多用户可能会说很多临时信息等一下 这个不对 我刚才说错了 你重新回答 这个先不用这些内容如果全部保存成长期记忆会污染后续回答。2. 成本太高如果每次都把全部历史聊天塞给模型token 成本会越来越高。而且上下文窗口是有限的不可能无限塞。3. 旧信息可能过期比如用户之前说我项目用的是 Redis 存记忆后来改成我项目实际用的是 MongoDB 存会话如果系统不更新旧记忆模型以后可能会混淆。4. 隐私和安全问题不是所有内容都应该被长期保存。比如密码 密钥 身份证号 个人隐私 临时敏感信息这些内容不仅不应该随便存还要支持用户查看、修改和删除。十、一个比较合理的 Agent Memory 架构如果我现在给自己的智能运维 Agent 设计 Memory我会拆成四层。1. 当前上下文层负责当前请求用户当前问题 最近几轮对话 当前 Agent 执行状态 当前工具调用结果适合放在Prompt / State / OverallState2. 会话记忆层负责当前 session 的连续对话sessionId 最近 N 轮聊天 历史摘要 用户当前任务状态适合放在MongoDB / Redis / MySQL例如sessionId abc123 summary 用户正在分析一次 Java 服务接口超时问题 recentMessages 最近 10 轮对话3. 长期记忆层负责跨会话的稳定信息用户偏好 项目背景 常用技术栈 历史问题 常见故障模式适合放在Mem0 Vector Store / Graph Store4. 外部知识层负责文档和知识库项目 README 接口文档 日志规范 运维手册 数据库说明适合放在RAG Milvus / Elasticsearch / 其他向量数据库最终结构可以画成这样用户问题 ↓ 当前上下文 ↓ 读取 session 最近对话 ↓ 搜索长期记忆 ↓ 检索 RAG 知识库 ↓ 组合 Prompt ↓ LLM 推理 ↓ 工具调用 / Agent 执行 ↓ 生成回答 ↓ 提取有价值信息并更新 Memory十一、结合我的智能运维 Agent 项目怎么落地如果把 Memory 放到我的智能运维 Agent 项目里我不会一上来就做得特别复杂而是按阶段推进。第一阶段先做好 session 级 ChatMemory先保证用户当前会话不断片。例如每个用户创建一个 sessionId 保存最近 N 轮对话 超过长度后做摘要压缩 下一轮请求时加载摘要 最近消息这样可以解决多轮追问 上下文连续 避免 token 爆炸对应项目里的表达可以是基于 sessionId 实现用户会话隔离通过历史摘要压缩 最近窗口加载的方式在保证多轮对话连续性的同时控制上下文长度。这句话放到简历或者面试里也比较合适。第二阶段提取长期用户画像比如用户长期和 Agent 交互后系统可以沉淀用户常用服务order-service 用户常查日志error.log / access.log 用户常用环境test / prod 用户关注指标接口耗时、错误率、数据库连接池 用户偏好回答先给结论再给排查步骤以后用户再问又出现接口超时了帮我看一下。Agent 就可以优先召回用户之前经常排查 order-service 用户之前关注 MySQL 慢查询 用户喜欢先看错误率和耗时指标这样 Agent 的回答就会更像“熟悉系统的助手”而不是每次从零开始。第三阶段沉淀故障经验智能运维 Agent 特别适合做情节记忆。例如一次故障处理过程现象接口响应时间超过 3s 排查Prometheus 发现 CPU 正常MySQL 慢查询升高 日志出现大量 timeout 结论数据库索引缺失导致查询变慢 处理添加索引后恢复这类信息以后可以作为经验召回。下次出现类似问题时Agent 可以提示历史上类似现象曾由 MySQL 慢查询导致建议优先检查慢 SQL、索引和连接池状态。这就比普通 RAG 更进一步。RAG 只能告诉你“文档里写了什么”。Memory 可以告诉你“以前类似问题怎么处理过”。第四阶段让 Memory 参与 Replan在 Plan-Execute-Replan 架构中Memory 还可以参与重规划。比如 Agent 原计划是1. 查 Prometheus 指标 2. 查日志 3. 查数据库状态 4. 生成报告执行到第二步发现日志里有大量 Redis timeout。如果 Memory 中记录过这个服务历史上多次因为 Redis 连接池耗尽导致接口超时那么 Replanner 可以调整计划1. 优先检查 Redis 连接池 2. 查询 Redis 慢命令 3. 再分析数据库这时 Memory 不只是“回答问题时补充上下文”而是参与 Agent 的决策。十二、Memory 什么时候存存多少这是实际开发中非常关键的问题。我的理解是Memory 不应该每句话都存也不应该完全不存而是按价值存。1. 应该存什么适合保存的内容用户长期偏好 项目长期背景 稳定技术栈 重要历史问题 成功解决方案 用户明确要求记住的信息 Agent 执行任务中的关键经验例如用户正在做 Spring AI Agent 项目。 用户希望项目介绍偏实习面试表达。 用户的智能运维项目采用 Planner-Executor-Replanner 架构。 某次接口超时最终由 MySQL 慢查询导致。2. 不应该存什么不适合保存的内容临时闲聊 明显错误的信息 重复信息 敏感信息 一次性命令 用户已经否定的内容例如“等一下” “你重新说” “刚才那个不要了” “我的密码是……”这些都不应该进入长期记忆。3. 什么时候存可以有三种策略第一种用户显式要求保存比如用户说你记住我之后写 CSDN 都要按这种风格。这种应该直接保存。第二种对话结束后自动总结每轮对话后不一定马上存可以在一次任务结束后总结本次对话产生了哪些长期有价值的信息 是否需要更新用户画像 是否出现新的项目事实 是否产生新的故障经验这种方式更稳。第三种关键事件触发保存比如项目配置发生变化 用户确认某个事实 故障处理完成 用户给出明确反馈 Agent 执行任务成功或失败这些节点更适合写入长期记忆。十三、Memory 会不会让 Agent 产生幻觉会。如果 Memory 设计不好它不仅不能减少幻觉反而可能制造新的幻觉。比如记忆召回错了 旧记忆没有更新 相似但不相关的信息被召回 用户已经改口但系统还记着旧版本所以 Memory 系统要有几个控制点1. 记忆要带来源 2. 记忆要有时间 3. 记忆要能更新 4. 记忆要能删除 5. 召回后不要直接当事实要让模型判断相关性 6. 重要信息最好让用户确认比较合理的记忆格式应该包含{ user_id: u001, memory: 用户的智能运维 Agent 项目采用 Planner-Executor-Replanner 架构, type: project_fact, source: conversation, created_at: 2026-06-03, confidence: 0.92 }这样后续出现冲突时系统可以判断这条记忆是什么时候来的 是否还可信 是否需要被新信息覆盖Mem0 的论文介绍中也提到记忆提取之后还需要更新阶段对候选事实和已有记忆进行比较从而维护一致性并减少冗余。十四、今天的学习总结今天对 Agent Memory 的理解比之前清晰了很多。以前我觉得记忆就是把聊天记录存起来。现在更准确的理解是Agent Memory 是从交互过程中提取、存储、更新和召回有长期价值的信息让 Agent 具备跨会话连续性、个性化和经验复用能力。它和 RAG 的关系也更清楚了RAG 是外部知识增强。 Memory 是历史经验增强。如果把 Agent 比作一个人Context 是他当前脑子里正在想的内容。 ChatMemory 是他刚刚聊天的短期印象。 RAG 是他手边可以查的资料库。 Long-term Memory 是他长期积累下来的经验和偏好。 Skill 是他掌握的一套做事方法。所以一个真正好用的 Agent不应该只是会调用工具也不应该只是能检索文档。它还应该能记住用户、记住任务、记住经验并且在下一次执行时变得更懂你。这也是我觉得 Agent 和普通 ChatBot 最大的区别之一普通 ChatBot 更像一次性问答工具。 真正的 Agent 更像一个会持续成长的助手。