1. 为什么 Agent 的“长期记忆”是个真问题做过 Agent 开发的人大概都有过这种体验你精心搭了一个助手能调工具、能写代码、能查资料但只要关掉会话窗口再打开它就像换了个人——昨天聊过的项目背景、用户偏好、踩过的坑全都不记得了。这不是模型不够聪明而是上下文窗口天生就是“短期记忆”它只负责当前这一轮推理不负责跨会话的信息沉淀。所谓 Agent 长期记忆要解决的核心就一句话让 Agent 在会话结束后仍然能把关键信息存下来并在未来需要时准确取回来。听起来像给数据库加个读写接口就完事了但真正做过就知道难点根本不在“存”而在“存什么、怎么存、什么时候取、取多少”。存多了检索噪声大、token 成本飙升存少了关键信息丢失Agent 又变回金鱼。这中间的取舍就是各个主流记忆项目设计思路分道扬镳的地方。这篇内容我打算把 Mem0、Zep、Graphiti 这几个常被提到的项目连同另外几个同类型方案放在一起对比。不是做产品评测而是从架构设计的第一性原理出发拆解它们在记忆抽取、存储结构、检索策略上的不同选择以及这些选择分别适合什么场景。如果你正在给自己的 Agent 加记忆模块或者纠结该选哪个方案这篇应该能帮你少走一些弯路。全文会涉及不少工程细节和参数取舍建议边看边对照自己的业务场景。2. 长期记忆的四个核心问题先想清楚再选型在对比具体项目之前有必要先把长期记忆这件事拆成几个必须回答的问题。很多人一上来就看项目文档结果选完发现跟自己场景不匹配返工成本很高。我习惯先把问题定义清楚再去匹配方案。2.1 记忆的写入时机什么时候该记最朴素的做法是每轮对话都存但这样会产生大量冗余和噪声。你想想用户说“你好”“谢谢”“帮我看看这个”这些内容存下来对未来的推理几乎没有价值反而会稀释真正重要的信息。所以第一个设计决策就是记忆写入是同步还是异步是每轮触发还是按事件触发。常见做法有两类。一类是对话结束后批量抽取把整段会话丢给一个抽取模型让它总结出值得记住的事实、偏好、结论。另一类是实时增量写入每轮对话后立即判断是否有新信息需要落库。前者成本低、噪声少但有时效性延迟后者实时性好但判断逻辑复杂容易误存。Mem0 早期版本偏向实时抽取后来也支持了批量模式Zep 则更强调会话级别的自动摘要。2.2 记忆的存储结构向量、图还是混合存储结构直接决定了检索能力。纯向量存储实现简单语义相似度检索够用但它有个硬伤无法表达关系。比如“张三负责项目A”“项目A依赖服务B”这种多跳关系用向量很难精确检索。图结构天然适合表达实体和关系但构建和维护成本高查询也需要专门的图查询语言。所以现在主流方案基本走向混合架构向量负责语义召回图负责关系推理两者配合。Graphiti 就是典型的图优先设计Mem0 则提供了向量加图的混合模式。选哪种取决于你的记忆里“关系”占多大比重。如果只是记用户偏好向量足够如果要记复杂的项目依赖、人物关系网图结构会省很多事。2.3 记忆的检索策略怎么取、取多少检索环节最容易被低估。很多人以为存好了、检索时算个相似度就完事实际上面临几个问题检索结果怎么排序、怎么去重、怎么控制注入上下文的数量。取太多token 爆炸且引入噪声取太少关键信息漏掉。一个实用的策略是多路召回加重排先用向量召回一批候选再用关键词或图查询补充最后用重排模型精排只取 top-k 注入。k 的取值需要根据模型上下文窗口和任务复杂度调一般 5 到 15 条比较常见。另外还要考虑时间衰减越久远的记忆权重越低除非它被反复引用。2.4 记忆的更新与遗忘怎么保持新鲜记忆不是只增不减的。用户偏好会变项目状态会更新旧记忆如果不处理就会误导 Agent。所以需要更新机制新信息与旧信息冲突时是覆盖、合并还是标记失效还需要遗忘机制长期不被引用的记忆是否降权或清理这几个问题没有标准答案但每个项目都有自己的取舍。下面进入具体对比。3. 六个主流项目的设计思路逐一拆解我选的项目覆盖了从轻量到重量、从向量优先到图优先的不同路线。需要说明的是这些项目的版本迭代很快以下分析基于我实际接触到的版本和公开设计文档具体实现以你用的版本为准。3.1 Mem0向量优先的轻量记忆层Mem0 的定位很清晰做一个开箱即用的记忆层让开发者几行代码就能给 Agent 加上长期记忆。它的核心流程是“抽取-存储-检索”三段式。写入时把对话内容交给 LLM 抽取成结构化的事实条目每条事实带元数据存储默认用向量库也支持接入图数据库做混合。它的优势在于接入成本极低API 设计友好适合快速验证。缺点是抽取质量高度依赖 prompt 和模型如果抽取规则没调好会存进很多无用信息。我在实际使用中的体会是抽取 prompt 里一定要明确“什么算值得记住的信息”比如用户偏好、明确结论、重要事实而寒暄和过程性讨论要过滤掉。另外它的检索默认是向量相似度如果业务涉及复杂关系需要自己补图查询逻辑。3.2 Zep会话摘要加事实抽取的双层结构Zep 的思路比 Mem0 更偏“服务化”。它把记忆分成两层会话级摘要和事实级抽取。摘要负责保留对话的整体脉络事实负责精确检索。这种双层设计的好处是检索时既能拿到宏观背景又能拿到具体细节。Zep 比较强调自动摘要的时效性会在会话过程中持续更新摘要而不是等会话结束。这对长对话场景很友好因为摘要能及时反映最新状态。但代价是计算开销更大每轮都要跑摘要模型。如果你的场景是短会话、高频次这个开销需要算进成本。另外 Zep 对记忆的时间维度处理得比较细支持按时间范围检索这对“最近发生了什么”这类查询很实用。3.3 Graphiti图结构优先为关系推理而生Graphiti 是我个人觉得设计上最有意思的一个。它以知识图谱为核心存储把对话中的实体、关系、事件都抽成图节点和边检索时用图查询加向量混合。这种设计特别适合多跳推理场景比如“找出所有跟项目A相关且最近两周有更新的人”。它的构建流程比向量方案重需要实体识别、关系抽取、图 schema 设计。但一旦建好查询能力是向量方案比不了的。Graphiti 还支持时序图每条边带时间戳能回答“某个关系在某个时间点是否成立”。这个特性在需要追溯历史状态的场景里非常关键。缺点是学习曲线陡图 schema 设计需要一定经验不适合想快速上手的项目。3.4 另外三个值得关注的项目思路除了上面三个还有几类方案值得了解。一类是基于文件系统的记忆把记忆写成 Markdown 或 JSON 文件用目录结构组织检索时靠文件遍历加关键词匹配。这种方案极其简单透明适合个人项目或对可解释性要求高的场景缺点是规模一大就难管理。另一类是基于数据库的记忆用关系型数据库存结构化记忆配合全文索引。它的优势是事务性和一致性有保障适合企业级应用但语义检索能力弱通常要额外接向量库。还有一类是框架内置记忆比如一些 Agent 框架自带的 memory 模块通常实现较简单胜在和框架无缝集成。选这类要看框架的迭代活跃度否则容易被锁死。3.5 六个项目的横向对比把关键维度拉成表格方便对照。项目存储核心抽取方式检索策略关系推理上手难度适合场景Mem0向量为主可选图LLM 抽取事实向量相似度弱低快速验证、偏好记忆Zep摘要加事实双层自动摘要加抽取混合检索加时间过滤中中长对话、客服场景Graphiti知识图谱实体关系抽取图查询加向量强高复杂关系、多跳推理文件型方案文件系统手动或半自动关键词加遍历无极低个人项目、小规模数据库型方案关系型数据库结构化写入全文索引中中企业级、强一致框架内置视框架而定视框架而定视框架而定弱到中低已用该框架的项目这张表不是绝对的很多项目都在演进边界在模糊。但大方向可以参考。4. 从零搭一个带长期记忆的 Agent实操路径光看对比不够得动手。下面我按一个通用流程把接入长期记忆的关键步骤和参数取舍讲清楚。你可以根据选的方案替换具体组件。4.1 记忆抽取的 prompt 设计要点抽取质量决定记忆质量。我的经验是prompt 里要明确三件事抽取范围、输出格式、过滤规则。抽取范围要列出你关心的事实类型比如用户偏好、项目状态、明确结论、待办事项。输出格式建议用 JSON每条记忆带content、type、timestamp、confidence字段。过滤规则要明确排除寒暄、重复内容、低置信度推测。一个常见的坑是抽取粒度太细把一句话拆成好几条导致检索时碎片化。建议按“一个完整事实”为单位比如“用户偏好用 Python 做数据分析”就是一条不要拆成“用户喜欢 Python”和“用户做数据分析”两条。4.2 存储 schema 的设计与索引选择如果走向量方案schema 相对简单id、content、embedding、metadata、created_at。索引选 HNSW 还是 IVF取决于数据规模和查询延迟要求。HNSW 查询快、召回高但内存占用大IVF 省内存但需要训练且召回略低。一般十万条以内用 HNSW 足够。如果走图方案schema 设计是重头。要先定义实体类型和关系类型比如Person、Project、Service关系有负责、依赖、参与。schema 不要一开始就设计得太复杂按业务需要逐步扩展。Graphiti 支持动态 schema这点比较友好。4.3 检索链路的组装与参数调优检索链路我建议做成多路召回加重排。第一路向量召回取 top-20第二路关键词召回取 top-10如果有图第三路图查询补充关系。然后合并去重用重排模型精排取 top-5 到 top-10 注入上下文。参数调优的关键是观察注入后的效果。如果 Agent 回答经常遗漏已知信息说明召回不够加大 top-k 或调整相似度阈值如果回答被无关信息干扰说明噪声太多收紧阈值或加强重排。这个调优过程需要反复迭代没有一劳永逸的参数。4.4 记忆更新与冲突处理的实际做法冲突处理我常用两种策略。时间优先新记忆覆盖旧记忆适合状态类信息比如“用户当前所在城市”。置信度优先保留高置信度记忆低置信度的标记为待确认适合偏好类信息。实现上可以给每条记忆加status字段active、superseded、pending检索时只取active。遗忘机制可以简单点给记忆加last_accessed字段超过一定时间没被检索到的降权或归档。归档不是删除只是不参与默认检索需要时还能查回来。5. 实操中踩过的坑与排查技巧这部分是我觉得最有价值的地方都是实际调试中积累的。5.1 记忆检索不准的常见原因检索不准通常不是单一原因。先查embedding 模型是否匹配中英文混用场景下有些模型对中文语义捕捉差会导致召回偏移。再查抽取质量如果存进去的就是模糊表述检索自然不准。最后查阈值设置相似度阈值太高会漏召回太低会引入噪声。我的排查顺序是先看召回结果人工判断是否相关如果不相关看 embedding如果相关但没排前面看重排。5.2 上下文被记忆挤爆怎么办这是很常见的问题。记忆注入太多把当前对话的上下文挤没了模型反而抓不住重点。解决办法有两个限制注入条数硬性控制在 top-5压缩记忆表述抽取时就要求简洁一条记忆不超过 50 字。另外可以把记忆放在系统提示里和当前对话分开让模型知道哪些是背景、哪些是当前任务。5.3 记忆写入延迟影响体验的优化如果写入是同步的每轮对话都要等抽取模型返回延迟会很明显。优化方向是异步写入对话响应先返回抽取任务丢到队列里后台跑。这样用户无感知代价是记忆有短暂延迟。对于实时性要求高的场景可以只对关键信息同步写其他异步。5.4 常见问题速查表问题现象可能原因排查方向解决建议检索不到已知信息召回不足查 embedding、阈值、top-k降低阈值、加大 top-k检索结果噪声大抽取质量差查抽取 prompt、过滤规则优化 prompt、加过滤上下文被挤爆注入过多查注入条数、记忆长度限制条数、压缩表述写入延迟高同步抽取查抽取耗时改异步、队列化旧记忆误导未更新查冲突处理逻辑加时间优先覆盖关系查询失败无图结构查存储方案补图或换方案5.5 几个容易被忽略的细节第一时区问题。记忆的时间戳如果时区不统一时间范围检索会出错。建议统一存 UTC。第二多用户隔离。记忆必须按用户或租户隔离否则会串数据。第三敏感信息过滤。抽取时要过滤掉不该存的内容这个在 prompt 里就要明确。第四备份与迁移。记忆是资产要有备份机制换方案时能迁移。6. 选型建议不同场景怎么选最后说说选型。没有最好的方案只有最合适的。如果你是个人开发者做原型建议从 Mem0 或文件型方案起步快速验证记忆有没有用。别一上来就上图数据库容易陷进 schema 设计里出不来。如果你是做客服或长对话产品Zep 的双层结构比较合适摘要加事实的组合能兼顾脉络和细节。注意算好摘要模型的开销。如果你面对的是复杂关系推理比如企业知识管理、项目依赖分析Graphiti 这类图优先方案值得投入。前期 schema 设计多花时间后期查询能力会回报你。如果你在企业环境对一致性和审计有要求数据库型方案更稳妥配合向量库做语义检索。如果你已经用了某个 Agent 框架先看框架内置记忆够不够用不够再外接。别为了记忆把整个架构推翻。我个人在实际项目里的做法是分层短期用上下文窗口中期用向量记忆长期用图记忆。不同时效和不同关系复杂度的信息走不同通道检索时按需组合。这样既控制了成本又保证了关键场景的召回。这个思路不一定适合所有人但供你参考。记忆这件事本质上是在信息完整性和检索效率之间找平衡。存得全不一定好取得准才是关键。多观察实际对话中的召回效果比看多少文档都管用。
