Mem0：给AI装上长期记忆

Mem0 让 AI Agent 能从长期交互中提取有效信息，在未来任务中按需找回，让智能体真正拥有跨会话记忆。1 为什么需要记忆普通大模型的记忆主要来自当前上下文窗口。用户第一次说：我主要使用 Python 开发，也做 Android， 平时更喜欢 Python 技术栈。模型在当前对话中可以理解这些信息。新的会话开始后，如果应用没有重新提供这些内容，大模型通常无法继续使用之前的信息。一种简单方案是保存所有聊天记录：系统提示词 + 历史消息 1 + 历史消息 2 + …… + 历史消息 10000 + 当前问题这种方案会快速遇到几个问题：上下文越来越长 Token 成本持续增加 模型推理延迟升高 大量历史信息与当前任务无关 有效信息容易被无关内容淹没 最终超过模型上下文容量智能体真正需要的不是无限保存聊天内容，而是从历史交互中筛选出未来仍有价值的信息。例如：用户主要使用 Python 用户开发 Android 应用 用户偏好 FastAPI 当前项目使用 PostgreSQL这些信息可以跨越多次会话继续参与推理。Mem0 就是专门完成这项工作的长期记忆层。2 Mem0怎样工作Mem0 可以放在 Agent 和大模型之间：用户输入 ↓ 检索长期记忆 ↓ 生成相关记忆上下文 ↓ 大模型进行推理 ↓ 生成回答 ↓ 分析本轮对话 ↓ 提取新的长期记忆 ↓ 写入持久化存储整个循环可以概括成：读取记忆 → 推理 → 回答 → 写入记忆例如用户曾经说：我喜欢使用 FastAPI 写 Python 后端。Mem0 可能保存为：用户偏好使用 FastAPI 开发 Python 后端。几天后用户问：帮我选一个 AI Agent 后端框架。Mem0 会先搜索与这个问题相关的长期记忆，找到：用户偏好 Python 用户偏好 FastAPI再将这些信息加入模型上下文：相关长期记忆： - 用户偏好 Python - 用户偏好 FastAPI 当前问题： 帮我选一个 AI Agent 后端框架。模型就能结合用户历史偏好给出更有针对性的方案。3 记忆不是聊天记录Mem0 与普通向量知识库最大的区别，在于它不会默认把整段聊天直接作为长期记忆。普通向量检索通常采用：文档 ↓ 文本切片 ↓ 向量化 ↓ 向量数据库 ↓ 相似度检索Mem0 的处理链路多了一层记忆提取：用户对话 ↓ 大模型分析 ↓ 提取长期有效事实 ↓ 生成独立记忆 ↓ 向量化 ↓ 持久化例如原始对话：最近项目准备从 MySQL 换成 PostgreSQL，主要因为我们需要使用 pgvector。长期记忆可以被拆成：项目计划迁移到 PostgreSQL。项目需要使用 pgvector。这里完成了一次重要的信息压缩：自然语言对话→长期有效事实。聊天消息记录用户说了什么。长期记忆记录未来还有什么值得知道。4 记忆如何写入调用 Mem0 的 add() 后，并不是简单执行一次数据库插入。当前版本可以抽象成以下处理流程：新的对话 ↓ 检索相关已有记忆 ↓ 大模型提取新的长期事实 ↓ 生成独立记忆 ↓ 重复内容检测 ↓ 生成向量 ↓ 写入向量数据库 ↓ 提取实体信息 ↓ 写入实体索引基础 Python 示例：frommem0importMemory memory=Memory()messages=[{"role":"user","content":"我主要使用 Python 开发后端，我比较喜欢 FastAPI。"},{"role":"assistant","content":"好的。"}]result=memory.add(messages,user_id="user_001",metadata={"source":"chat"})print(result)Mem0 会分析消息内容，提取类似：用户主要使用 Python 开发后端。用户偏好 FastAPI。默认情况下，长期记忆保存的是提取后的事实，不是完整聊天原文。这一步决定了长期记忆库最终是高价值知识集合，还是另一个不断膨胀的聊天数据库。5 为何先查旧记忆写入新记忆前先查询已有记忆，是 Mem0 很重要的设计。假设数据库里已经存在：用户喜欢 Python。用户再次说：我一直都比较喜欢 Python。如果每一次都独立抽取，数据库可能不断产生：用户喜欢 Python。用户偏好 Python。用户经常使用 Python。用户很喜欢 Python。含义几乎相同，记忆库会出现大量语义重复内容。因此写入前可以先执行：当前对话 + 相关历史记忆 ↓ 大模