五大开源Agent记忆系统横评：Mem0、Letta、Zep、Cognee实测对比

今年我给自己的一个硬性目标就是把市面上叫得出名字的开源 Agent 记忆系统全部拉下来跑一遍真实业务场景。起因很直接我做的几个 Agent 项目单轮对话能力都不差但一遇到跨天、跨会话的连续任务就露怯用户两小时前说的偏好换个 session 就忘得干干净净。这类问题不是调 prompt 能解决的必须有专门的记忆层。所谓记忆系统说白了就是一套让 Agent 在对话之外还能持续保存、检索、更新它知道的事情的基础设施。现在开源社区里挂着记忆名头的项目不少从 Mem0、Letta 到 Zep、Cognee各家技术路线差得非常大有走向量库的有走知识图谱的有把 LLM 当操作系统来管理的。但它们解决的问题是同一个怎么让 Agent 既不超出上下文窗口限制又能把该记住的东西记住。这篇文章是我个人实测的完整记录不是从 README 里抄参数而是用一个统一的测试脚本在相同的场景集上跑出来的结果对比。如果你正准备给自己的 Agent 引入记忆能力或者在几个开源方案之间犹豫这篇文章可以帮你省掉大量试错时间。我会从架构差异、检索能力、更新策略、工程成熟度几个维度分别拆最后给出我的选型建议和踩坑清单。1. 为什么 Agent 需要一套记忆系统1.1 没有记忆的 Agent 是什么体验很多人觉得 Agent 已经有了上下文窗口为什么还需要单独的记忆系统我的理解是上下文窗口只是短期工作台不是长期存储。窗口大小就是模型一次能看到的 token 上限。哪怕你用的是几十万 token 的模型对话一长或者任务跨了多个会话早期信息照样会被截断或稀释。更关键的是用户不会每次都把背景信息重复一遍他们默认你应该记得上次聊了什么。我遇到过一个真实案例一个客服 Agent用户前一天投诉了订单延迟第二天再来问我的包裹怎么样了Agent 完全不知道之前的投诉背景重新问了一堆已经回答过的问题。用户当时的原话是你们系统是不是有健忘症这就是没有记忆系统的典型症状——每次对话都是第一次见面。1.2 记忆问题到底难在哪记忆系统的设计远比存一段话到数据库里复杂拆开看有四个核心难点第一写入什么。对话里哪些信息值得记用户的姓名、公司、偏好、承诺过的事情显然值得记但寒暄、追问过程中的中间状态不该记。区分事实性信息和临时上下文本身就需要模型参与判断。第二存在哪里。这是一个存储选型问题。存在关系型数据库向量数据库图数据库还是直接存原始文本不同方案决定了后续检索的上限。第三怎么检索。用户提了一个新问题系统怎么知道该调取哪段历史信息关键词匹配显然不够语义相关性是一个层面时间相关性、实体关联性又是另一个层面。第四什么时候忘。记忆不是越全越好。信息会过期用户的偏好会变存了一堆过时信息反而会污染后续决策。怎么更新、怎么覆盖、怎么衰减这些都是记忆系统的清理逻辑。我见过不少团队一开始觉得记忆功能好做不就是把聊天记录存下来吗结果做深了才发现真正的工程难点全在检索和更新上。这也是为什么现在独立的开源记忆项目越来越多——大家都意识到这不是顺手能做的事。2. 参评项目全景2.1 我实测的五个开源方案这次对比我从知名度、社区活跃度、技术路线代表性三个角度选了五个项目项目开发语言存储后端核心思路开源协议Mem0Python向量库图数据库双通道记忆支持事实抽取与冲突检测Apache-2.0Letta原 MemGPTPython关系库向量库把 LLM 上下文当作内存用系统管理外存Apache-2.0ZepPython / GoNeo4j 图数据库时序知识图谱强调关系与时间维度Apache-2.0CogneePython组合存储图向量关系从文本到知识图谱的 ECL 管道偏推理链记忆Apache-2.0LangChain MemoryPython可插拔默认内存框架内的记忆模块适合轻量场景MITLangChain Memory 严格说不是一个独立的记忆系统它是框架内置的一组记忆抽象。我把它放进来当对照组因为很多人的第一个记忆方案就是它正好可以看看它和专用记忆系统的差距在哪里。2.2 这几个项目的定位差异五个项目表面都在做记忆实际上解决的场景不同Mem0 的定位是记忆即服务它提供一串 API你往里面塞对话文本它负责提取、存储、检索。它不关心你的 Agent 怎么调度只把记忆层做好。优点是上手快对已有 Agent 改动小适合想快速给应用加记忆能力的团队。Letta 走的是另一条路。它把记忆当成 Agent 本身的核心组件引入了虚拟上下文管理的概念——LLM 看到的是一个被压缩过的上下文完整历史放在外部存储里由 Agent 自主决定什么时候把哪段记忆加载回上下文。这个设计很接近操作系统换页的模型适合需要长期自主运行的 Agent。Zep 的核心亮点在时态知识图谱。每条记忆不只是文本而是被解析成实体-关系-属性的图结构并且带上时间戳。比如张三在 1 月 15 日说他不喜欢喝咖啡在 Zep 里会变成张三这个节点上带时间属性的一条事实。这种结构在处理谁在什么时候说了什么、后来变了没有这类问题上非常有优势。Cognee 更像一个面向知识工程的记忆系统它强调把非结构化文本转化成可供推理的结构化知识。如果团队对知识图谱和语义网络比较熟Cognee 会很顺手它适合需要严格推理链条的场景。LangChain Memory 提供的是一组标准化的记忆接口包括会话缓冲、对话摘要、实体记忆等。优点是和 LangChain 生态无缝集成缺点也很明显它默认把整段历史存下来或者做摘要没有真正意义上的实体级、事实级管理能力上下文一长检索精度和存储效率都会出问题。3. 核心维度横向测评3.1 记忆写入机制对比记忆写入是第一个分水岭。我测试时重点关注两件事项目是被动接收对话文本还是主动提炼结构化记忆。Mem0 采用的是双通道方案。两个纯函数调用分别处理不同性质的信息from mem0 import Memory m Memory.from_config(config) # 基于配置初始化默认连向量库和图库 # 显式写入由 Agent 决策哪些信息值得记 m.add(用户当前使用的是企业版套餐, user_idu_001) # 隐式写入从对话历史里自动提炼要点 m.add( 用户表示周五下午一般不安排会议喜欢邮件沟通对延迟很敏感。, user_idu_001, metadata{source: chat_20250115} )实测下来Mem0 对隐式写入的文本会做一次事实抽取把一句话拆成多条独立记忆保存并且自带去重逻辑。重复输入相似内容时它不会在库里堆垃圾。Letta 的做法完全不同它的记忆更新由 Agent 自己控制。Letta 的记忆结构里预设了若干记忆块Agent 通过工具调用来修改这些块的内容。相当于把记忆的增删改查权限直接交给了大模型本身from letta import create_client client create_client() # 连接 Letta server agent client.create_agent( namedemo_agent, memory_blocks[ {label: human, value: Unknown}, {label: persona, value: 我是一个耐心细致的助手} ] ) # 对话过程中模型自行决定是否更新记忆块 response agent.send_message(我叫李昂是一名后端工程师。) # Letta 会在内部调用 memory_replace 之类的工具更新 human 块这个设计的优势是记忆状态永远是最精炼的——模型每次只会修改真正变化的字段不会把整段对话都倒进去。但代价是记忆的好与坏完全取决于模型的判断能力模型判断错了记忆就脏了。Zep 的写入是异步且自动化的。只要在对话流里注册了 Webhook 或回调Zep 会持续从消息流里抽取实体、关系、事实进图数据库。写入过程是流水线化的不同 NLP 任务各自独立执行from zep_cloud import ZepClient client ZepClient(api_keyyour_key) # 告知 Zep 有一条新消息到达它会自动完成抽取、建图、时序更新 client.add_message( graph_search_depth3, session_idsession_test, roleuser, content我下周二去上海出差需要订一间带书桌的酒店 )Cognee 的写入是批处理式的它把原始文档切成块逐块走 ECL 管道Extract-Cognize-Load即抽取、认知建模、装载最终沉淀成知识图谱节点。适合事后归档不适合需要实时记忆的对话场景。LangChain Memory 的写入最简单粗暴就是把对话存进列表或者做一轮摘要总结。回到代码层面看它没有真正的实体管理概念from langchain.memory import ConversationSummaryMemory memory ConversationSummaryMemory.from_messages(llmllm) # 需要传 LLM 实例 memory.chat_memory.add_user_message(我叫李昂) memory.chat_memory.add_ai_message(你好李昂) # 本质上只是把文本追加进列表不识别任何实体3.2 检索方式的取舍写入决定记忆怎么进库检索决定记忆怎么出来。这五位选手的检索策略差异非常明显。Mem0 默认配置下做的是语义加实体混合检索。查询先做向量化从向量库取 Top-K 候选同时把查询里的实体抽出来在知识图谱里定位相关节点和相邻事实。两部分结果合并排序后返回results m.search( query用户对会议时间有什么偏好, user_idu_001, limit5 ) # results 按综合相关性排序既有向量相似也有图谱关联我实测时故意问了一个和原文用词完全不同的问题存入的是周五下午一般不安排会议查询用的是这周哪天不方便开会。Mem0 返回了正确的记忆片段说明向量语义本身起到了作用。但如果查询里包含明确实体比如张三喜欢什么饮料图通道的精确匹配往往比向量通道更准。Zep 的检索具备天然的图遍历能力。它支持子图搜索给定一个起始实体和搜索深度它会沿着关系边把相关记忆全部拉出来search_result client.search( session_ids[session_test], query出差时的酒店要求, search_typegraph # 图搜索模式 )这项检索能力在涉及多人、多组织、多事件交错的问题上有碾压性优势。比如张三上次见李四是在哪家餐厅当时聊了什么普通向量库很难把张三见李四这个关系精确关联起来图数据库却可以沿着实体边直接找到答案。Cognee 的检索同样走图结构但它的路径更重。整个查询会经过一系列管道化处理先识别查询里的实体再在图谱里做子图匹配。精度高但延迟也高。我测试时单次检索在百毫秒到秒级浮动这还是本地单机环境。Letta 的检索不是一个显式 API而是内建于 Agent 的注意力管理。系统在每次对话前决定把哪些记忆块内容注入上下文# Letta Agent 响应时会自动决定加载哪些 memory block response agent.send_message(你还记得我叫什么吗)这个机制的好处是检索不需要开发者设计查询逻辑模型自己判断坏处是记忆块的规模一旦变大Agent 的调度决策变多token 消耗相应上涨。我实测下来Letta 是五个项目里单轮查询 token 消耗偏高的。LangChain Memory 的检索就简单了要么把全部历史拼进上下文要么只取摘要。没有过滤、没有相关性排序。在会话很短的时候能用一旦对话历史超过几千 token这种全量塞入的检索方式会迅速吃满上下文窗口。3.3 存储层设计与扩展性存储层决定了记忆系统能撑多大、检索能有多快。Mem0 是有状态存储支持多种后端切换。默认配置用向量库做语义索引、图数据库做实体关系。我测试时用 Qdrant Neo4j 的组合单机环境下 10 万条记忆记录检索在数百毫秒级。不过 Mem0 的代码里向量库和图库的同步是应用层做的数据量大之后两库的强一致性维护需要自己考虑。Zep 的存储设计是它最看重的一部分。它深度绑定 Neo4j利用图数据库原生的时间属性管理时态数据。每条关系边上可以挂时间区间查询时天然支持某时间点之后发生了什么这类问题。这种时态能力在其他项目里基本没有。Cognee 的设计更重一点。它不是单库存储而是分级存储原始文本放对象存储向量放向量库图谱节点放图数据库三者通过一个中间层做关联。好处是抗单点故障能力更强适合企业级知识库场景坏处是部署复杂度直线上升单机玩不转。Letta 在后端存储上相对务实。它用 Postgres 存结构化数据包括记忆块和状态向量部分依赖 PG 扩展或者其他向量库。对于大多数中小规模项目这套组合足够稳。它的亮点在于状态管理所有记忆块都能追溯版本、来源和更新时间这在调试 Agent 行为时极其有用。3.4 遗忘与更新策略遗忘是记忆系统最容易被忽略、实则是及格线的能力。我拿了一个经典场景做测试用户先说喜欢喝美式两周后说现在只喝燕麦拿铁。正确行为是旧记忆被覆盖而不是并存。Mem0 对更新做了显式接口和隐式冲突检测。调用 add 传入新事实后它会先检索已有相同实体的记忆按时间戳和置信度决定是新增、覆盖还是保留。实测中当我输入用户目前只喝燕麦拿铁后再搜索用户喜欢什么咖啡返回的是新记忆旧的喜欢美式不再出现在 Top 结果里表现符合预期。Zep 的时效策略靠时间戳保证新事实胜出。图数据库中同一条关系如果存在多条时间版本查询时默认只返回最新时间片内的信息。这套机制的优点是不做物理删除历史状态仍在库中想做用户行为变化分析有据可查。Letta 的更新是模型驱动的记忆块覆盖。模型会在合适时机调用记忆替换工具过程是黑盒的调试时需要通过日志查看模型修改的完整轨迹。实测中模型能够准确执行替换记忆块指令但偶尔会把一些陈述性内容误当成事实存进记忆块需要人工过滤。Cognee 在更新上最弱它本质上是知识图谱构建工具对单条事实变更没有特别设计。要修改一条旧结论通常需要重新跑一遍包含新文档的数据管道整体周期长。LangChain Memory 几乎没有遗忘和更新能力历史记录只增不减。3.5 综合表现评分我根据几个维度的实测结果给这五个项目打了一个主观分维度Mem0LettaZepCogneeLangChain Memory上手难度5分制分数越高越省事53325检索精度长对话场景43541记忆更新能力44520中文支持44434部署成本43325适合场景广度54432需要说明LangChain Memory 分数低不是因为它差而是因为它本来就不承担深度记忆职责如果只做 Demo 或者轻量会话回忆它足够用。4. 实操过程与核心环节实现4.1 测试环境与方法统一测试环境说明一下方便你自己复现时对齐操作系统 Ubuntu 22.04Python 3.10Docker 用于跑中间件Qdrant、Neo4j、Postgres模型统一用 GPT-4o 和本地部署的 Qwen2.5-7B 各跑一遍看模型依赖度每个项目用相同场景集身份偏好记忆、叙事连续性、时间敏感事件、记忆更正测试逻辑不复杂就是模拟一个用户连续多条消息间隔一段时间后再来提问看系统能否给出正确的历史关联信息。下面是场景一个脚本化的完整过程。4.2 场景实测跨会话身份与偏好记忆场景设计为第一次会话告诉 Agent 自己的名字和偏好第二次会话直接用代词提问看能不能回忆起来。这类场景是所有 Agent 产品的基础能力。Mem0 的表现最直接写入和检索各一个 APIDebug 很透明from mem0 import Memory m Memory.from_config() # 会话1写入用户信息 m.add(用户叫林夏是产品经理偏好简洁风格, user_idu_10086, metadata{conv: 1}) # 模拟漫长中间对话隔了半天 # 会话2检索用户身份 results m.search(他是做什么工作的, user_idu_10086) print(results)返回结果里能清晰看到林夏、产品经理、偏好简洁这几条独立记忆。中文分词和实体识别对这种短句场景没有出问题命中相当准。Letta 的跨会话记忆依赖 Agent 自己的记忆块管理。首次对话时模型会把林夏、产品经理这类信息写入记忆块第二次会话时模型调用读取工具把相关块注入上下文。全程不需要开发者定义检索逻辑适合对话驱动型产品但如果你需要精确控制什么该记什么不该记它的自由度反而是一种负担。Zep 在身份记忆上表现也不错不过它的抽取结果是埋在图里的返回的形式是实体属性适合程序化消费直接给 LLM 用反而需要再做一层组装。4.3 场景实测多人叙事记忆这个场景模拟客服场景一个会话里连续多个话题穿插后期提问时要能定位到特定的一件事。消息序号内容1我的订单 20250113 延迟了客服让我等 3 天2同时我另一个充电器订单已经到货了3我周五要出远门必须在周四前收到4查询我的充电器订单状态在这个场景里Mem0 的向量检索能召回订单相关的语义记忆但如果提问变成我之前提到的出行日期是哪天它针对日期类信息的召回就不太稳定偶尔会因为语义偏差漏掉关键实体。Zep 在这个场景几乎是无敌的。订单、充电器、出行日期三个实体在图里天然分开每条边带着谁提到的、什么时候提到的属性查询用户的出行计划能直接沿着用户节点把相关事实全部拉出来。这种在复杂关系场景下的精确性是图结构对比纯向量方案的降维打击。Cognee 在这个场景的表现在我预期之上。它构建出来的知识图谱能支持比较复杂的多跳查询比如所有涉及订单延期的消息中用户表达过哪些时间约束。不过响应时间偏长需要接受它的处理周期。4.4 场景实测记忆更正把遗忘和更新单独拎出来测试是我这次评测里收获最大的一环。前面说过喜欢美式咖啡后来改成燕麦拿铁五个项目中只有 Zep 和 Mem0 做对了。Zep 的时序图谱里新旧两条记录同时存在但时间权重不同检索时返回最新状态。它的记忆更新不需要额外调用 API只要把新消息投喂进去解析管道自己会完成版本切换。这在实际应用里非常省心。Mem0 需要你保证新事实的表述足够清晰。我测试时输入用户目前只喝燕麦拿铁它能正确建立覆盖关系但输入用户觉得燕麦拿铁也不错这种模糊语气它就只新增了一条关联记忆不触发旧记忆的覆盖。所以用 Mem0 时开发者在写入侧要给模型明确的新旧冲突处理指令。Letta 的更新完全靠模型自己。模型在对话中接受到新信息后会调用更新工具改写记忆块。我跑了三轮测试模型每次都成功做了覆盖但有一轮额外保留了一条冗余信息增加了少许 token 消耗。整体可控但在生产环境需要对模型行为设置更严格的槽位和约束。4.5 场景实测中文检索与语义边界中文场景是国产 Agent 团队最关心的问题之一。我补充测试了几个容易出问题的点口语化表达周五下午一般不安排会议 vs 查询哪天开会不太合适上下文省略这个功能我们团队内部先放着不用对外说 之后查询客户能不能看到这个功能中英混合术语用户提到需要 SLA 保障但周末不接告警Mem0 在中文上的表现取决于底层 Embedding 模型。换成 text2vec 或者 bge-m3 之后整体召回率在 85% 以上日常场景够用。Zep 的抽取管道对中文实体识别依赖 Spacy 和自定义 NLP 组件默认配置对中文的支持需要额外加载模型。Cognee 的中文支持相对弱一些它在处理中文专名和长难句时偶尔会把关系边抽得比较稀碎。5. 场景化选型建议5.1 不同团队怎么选我根据项目定位、团队规模和业务场景把选型逻辑整理成了表格如果你的场景是推荐方案核心原因个人开发者快速 MVP、DemoMem0上手快、API 清爽、不绑架 Agent 框架客服系统、用户画像类产品Zep时序图谱天然适配用户行为追踪和关系梳理长期自主运行的 Agent无人值守Letta自主记忆编辑机制更像一个活体长期运行单元企业知识库、合规审计强需求Cognee处理管道完整、知识链路可追溯适合重交付简单会话总结、低并发内测LangChain Memory 向量库架构简单不做过度设计快速跑通5.2 集成成本和注意事项选型不只是看功能还得看团队规模。Mem0 的部署依赖不大一个向量库一个图库就能跑适合三个人以内的小团队。Zep 自带服务端如果你需要自托管就要多运维一个 Go 服务和一个 Neo4j 实例这部分成本需要提前算进去。Letta 的服务端支持 Docker ComposePostgres 和向量库都是熟面孔卡点主要在理解它的记忆管理哲学团队需要有人能把 Agent 调度逻辑捋顺。我的一个经验是别盯着哪个最强做决定要看哪个最容易在你的架构里活下来。记忆系统不是一个独立产品它要跟你的 Agent 框架深度融合。Mem0 之所以成为很多团队的首选不是因为它各方面分数最高而是因为它的接入成本低、方案通用后续想换也不至于伤筋动骨。6. 常见问题与排查技巧实录6.1 记忆污染检索出来的东西不相关这是所有记忆系统最常见的故障。症状是问 A 的时候带出了一堆 B、C、D 的旧记忆导致 Agent 回答张冠李戴。排查路径三件套第一步检查向量检索的召回阈值把相似度阈值调高一些宁可漏掉也别乱带第二步检查图路径检索的搜索深度Mem0、Zep 都支持配置图遍历层数默认深度过深会捞出一大堆间接关联的节点第三步检查是否缺少时间过滤条件很多场景只需要最近 7 天的记忆Zep 支持精确时间窗口查询Mem0 需要在元数据里手动维护时间戳再过滤。调参建议先严格召回再逐步放宽。对话类场景中召回精度比召回率重要得多一条错误记忆对用户体验的伤害远超十条正确记忆带来的增益。6.2 明明存了信息检索时却找不到这个问题的隐蔽性很高通常不是程序 bug而是写入和检索的表述口径不一致。比如存的是用户联系方式的邮箱是 ab.com查的时候问怎么联系用户向量检索找不到精确取值图检索又没有把 Email 属性建好索引结果就漏了。解决思路有两个写入侧要给关键实体打统一标签比如 user.contact.email检索侧按标签精确过滤或者养成双向检索的习惯——既做语义检索也做实体检索再把结果合并。6.3 并发写入时数据错乱记忆系统的数据有一个特点同一个用户的信息会频繁更新。多线程或多服务同时写入时很容易出现最后一次写入覆盖了更早的新数据的问题。Zep 因为使用图数据库并发冲突概率相对较低Mem0 则需要关注应用层的写锁。我遇到过一个真实事故两个服务同时为同一用户写偏好一个写喜欢邮件沟通另一个写偶尔用 Slack因为没有版本控制后写入的覆盖了先写入的最终用户偏好只剩一条。解决方案是引入更新时间戳核对写入前先取当前记忆的最新时间只有新数据的时间戳更晚才允许覆盖。部分项目支持条件更新也可以在应用层自行实现。6.4 记忆系统有没有评测集很多人问过我这个问题。目前开源社区没有一个公认的 Agent 记忆评测基准各家 README 里贴的指标基本都是自定义测试集的结果可比性有限。我的做法是自建一个记忆回归测试集包含 5 大类场景身份信息、偏好变更、多人叙事、时间敏感事件、模糊查询。每次改动代码后跑一遍用正确率、召回率、错误调用率三个指标做回归对比。这个测试集规模不大但能覆盖 80% 的常见故障。民间也有一些 Agent 评测框架开始支持记忆专项但成熟度还不高建议自建为主。6.5 部署与运维上的避坑最后再说几个运维层面的坑。如果你在生产环境引入开源记忆系统至少要注意这四点第一中间件版本锁定。Qdrant、Neo4j、Postgres 各自的大版本升级经常引起客户端驱动不兼容锁定版本是省事省心的第一步。第二向量库的索引参数要按数据规模设置默认配置在万级数据上没问题到百万级数据时 recall 会急剧下降需要在写入前做好分片规划。第三图数据库的 schema 设计要提前定图谱数据的 schema 变更比关系库难得多一旦跑起来再改结构会非常痛苦。第四考虑数据隔离。多租户场景下每条记忆记录至少带上 user_id / tenant_id 标记Mem0 原生支持这个字段Zep 需要在 metadata 里自行管理。我在实际项目中踩过的另一个细节是中文语义检索的 Embedding 和英文用的是不同模型切换模型后向量索引需要重建否则新旧向量分布不一致召回结果会出现越查越错的现象。换模型一定记得重建索引。最后分享一个体会。记忆系统的选型本质上是在控制力和自动化之间做权衡。Zep 的自动化程度很高图结构帮你把记忆整理得井井有条但对开发者的图谱建模能力有要求Letta 把记忆的决策权交给模型灵活但不可控Mem0 走中间路线值得大多数团队作为起步选择。真正上线之后你会发现记忆能力不是一个装上就能用的功能持续的数据治理、检索调参、脏数据清理才是日常工作。这个领域的开源生态还在快速演进现在把基础架构选对后面更换成本就低很多。