给 AI Agent 装上长期记忆：Mem0 的记忆层设计

跟 AI 助手聊过几次的人都有类似的挫败感：你要重复告诉它同样的背景信息。上次说了项目用哪个技术栈，这次还得再说一遍；上次明确过输出格式偏好，这次它又忘了。

根本原因是每一轮对话都在一个空白的上下文里开始。模型的权重不会因为你用过就更新，会话结束后所有信息就丢了。

市面上解决这个问题的做法大致两类：一类是把历史对话全塞进上下文（很快就撞上窗口上限，而且 token 成本爆炸）；另一类是简单做个向量检索，把相似的历史片段捞回来（语义相似不等于信息有用）。

Mem0（读作"mem-zero"）走的是第三条路：做一个独立的记忆层，专门负责决定什么值得记、怎么存、什么时候取出来。

它的官方定位是：为 AI 助手和 Agent 提供智能记忆层，实现个性化交互——记住用户偏好、适应个体需求、随时间持续学习。

每次对话都从零开始

它记忆的层次

README 里把记忆分成用户、会话、Agent 三层状态，并支持自适应个性化。

这三层的划分其实很有讲究：

用户层存的是跨会话稳定的事实——这个人的技术背景、沟通偏好、所在团队。这类信息一次写入，长期有效。

会话层管的是当前对话内的上下文连贯性。这层不需要跨会话，但要保证多轮交互不跑题。

Agent 层记录的是 Agent 自身的行为状态——做过什么、处于哪个阶段、有哪些待办。做长流程任务时，这层决定它能不能接着上次的进度往下走。

把三类分开存的好处是检索时不会互相污染。你问一个需要用户偏好的问题时，不该把 Agent 的执行日志也捞回来。

新算法改了什么

README 里有一节专门讲 2026 年 4 月的新记忆算法。这里有五个改动，每个都说清了动机：

单次 ADD-only 抽取——一次 LLM 调用，不做 UPDATE/DELETE。记忆只累积，不覆盖。

这个改动挺反直觉的。通常的直觉是"信息更新了就该改掉旧的"，但那样会丢历史。只增不删的设计意味着你可以看到偏好是怎么演变的，而且避免了更新逻辑出错导致信息丢失。

Agent 生成的事实是一等公民——当 Agent 确认某个动作发生时，这条信息以同等权重存储。

很多记忆系统只记"用户说了什么"，忽略"Agent 做了什么"。但实际协作中，Agent 做过的事同样是重要上下文。

实体链接——实体被抽取、嵌入，并在记忆之间建立链接，用于检索增强。这是从"存文本"升级到"存关系"。

多信号检索——语义匹配、BM25 关键词匹配、实体匹配并行打分后融合。

这一点值得单独说：纯语义检索有个已知弱点——它对精确匹配不敏感。用户明确说过一个产品型号，语义检索可能给你返回一堆"相关但不对"的东西。把关键词匹配加进来，能兜住这类精确查询。

时间推理——时间感知检索，能针对"当前状态""过去事件""未来计划"这类查询排出正确的时间实例。

这是纯向量方案最缺的能力。用户问"我现在的配置是什么"，你需要的是最新的那条；问"我上次怎么解决的"，你要的是特定时间点的那条。没有时间维度，这两类问题都会答错。

记忆层的三种能力

关于基准数据，官方给了一个重要限定

README 里列了新算法在几个记忆基准上的成绩，同时明确标注了一句限定：

这些分数反映的是 Mem0 托管平台的成绩，其中包含开源 SDK 里没有的专有优化；开源用户应该预期有方向性相似的提升，但不是相同的数字。

这句话很重要。很多文章引用记忆类项目的跑分时，会直接拿托管服务的成绩当成开源版的成绩讲，这是误导。Mem0 官方主动把这条写出来，态度是对的。

同样标注清楚的是评测条件：单次检索（一次调用，不做 Agent 循环），检索预算 top_200。评测框架也是开源的，官方说明任何人都可以复现这些数字。

对做技术选型的人来说，能复现比数字本身更重要。

接入方式

README 里给了一个挺特别的细节：AI Agent 可以在五秒内自己申请到一个可用的 API key——不用邮箱、不用登录控制台、不用一次性验证码。官方给了四条命令走完全程。

这个设计明显是冲着"让 Agent 自己给自己配记忆"去的。传统 SaaS 的注册流程（注册邮箱→验证→建项目→生成 key）对自动化流程来说全是阻碍。

安装上，Python 和 Node.js 都有对应的包。核心能力是多级记忆（用户/会话/Agent 状态自适应个性化）、开发友好的 API、跨平台 SDK，以及完全托管的服务选项。

这里同样存在开源和托管的区分——托管服务省去自己维护向量库和 LLM 调用的麻烦，自托管则把数据和控制权拿在自己手里。

典型工作流

记忆层的典型工作流就三步：写入（对话结束后抽取值得保留的信息）、检索（新对话开始时按需召回）、注入（把召回结果拼进提示词）。

看起来简单，但难点全在"什么值得记"这个判断上。记得太多，检索时全是噪声；记得太少，等于没记。这也是为什么它的算法重点全在抽取策略和融合检索上。

适合谁用

做 AI 助手产品的团队。个性化体验的核心就是记忆——用户期待的是"越用越懂我"，不是每次都从零开始。

做客服系统的团队。README 里点名了这个场景：召回历史工单和用户记录，提供更贴合的帮助。这类场景的记忆需求很明确——必须有时间维度，因为"上次的问题解决了吗"是高频问法。

做长流程 Agent 的开发者。跨运行保留项目上下文、历史决策、踩过的坑，能让 Agent 在第二次接手同一项目时表现明显不同。

不太适合：

  • 单次、无状态的问答场景。没有跨会话需求，加记忆层是纯粹的开销。
  • 对数据位置极其敏感的场景。这时候要评估自托管方案的运维成本，而不是直接用托管服务。

项目地址： https://github.com/mem0ai/mem0

本文依据项目官方仓库 README 整理编写。文中基准数据为官方公布口径，且官方明确说明托管平台与开源 SDK 存在差异，选型与引用时请注意区分。