Agent长期记忆设计对比：六大开源项目选型指南

最近我在调一个客服Agent，对话轮次超过二十，它就把关键信息忘得干干净净——用户刚说完的收货地址，下一轮就开始“我这边暂时查不到”。这几乎是每个长期做Agent开发的人都绕不过的坎：模型上下文窗口再大，也包不住用户的全部历史。所谓“长期记忆”，拼的不是谁的窗口长，而是谁的工作台里多了一套能存、能找、能更新的记忆机制。

为了把这件事彻底搞明白，我把社区里讨论最多的六个项目翻了个底朝天：LangChain、Dify、CrewAI、Mem0、Letta（MemGPT）和Zep。这篇文章不聊纸上理论，只聊这六个项目各自的长期记忆设计思路，以及什么样的应用场景适合用哪一套。如果你也在做Agent开发、或者正在给自己项目的Agent加记忆，这篇文章应该能省不少弯路。

1. 为什么Agent的记忆问题这么难

1.1 模型本身是“金鱼”，记忆得靠外部系统补

先说一个最基础的认知：大语言模型本身没有任何持久状态。每次调用接口，模型看到的都是你这次传进去的提示词，上一次聊过什么它完全不知道。即便你用的是支持超长上下文的模型，那也只是把更长的对话历史“临时塞进”了这次请求，关掉窗口之后，一切归零。

所以Agent的长期记忆，本质上是一个外部系统问题。它要解决的不只是“把数据存下来”，而是在每一次对话开始时，从存下来的大量数据里找出对当前最有用的那部分，再拼进Prompt里，让模型表现得“像记得住一样”。这个思路很像人失忆之后的补救方案：你不是真的想起来，而是靠着日记、便签、数据库记录，把自己伪装成一个有记忆的人。

这也是为什么“记忆”这个问题这么容易翻车。它涉及三件相互矛盾的事：存储的容量要大，检索的准头要好，注入的开销要小。三者在真实项目里几乎永远在互相妥协。

1.2 长期记忆不是一种，而是三种

拆开看，Agent的长期记忆其实可以分三类，六个项目各自的侧重点完全不同。

第一类是工作记忆，也就是当前会话里正在发生的事情——用户刚才说了什么、现在进行到哪一步、待会要回什么。这类信息通常只对当前Thread有效，会话结束就可以丢。对应到人身上，就是“过脑就忘但当时一定得有”的状态。LangChain的对话缓冲、Dify的会话变量都在处理这类记忆。

第二类是场景记忆，也就是一个用户和Agent之间跨会话的历史经历。比如“上周张三咨询过退款流程”“他习惯用支付宝付款”。这类记忆需要持久化存储，还需要在下次聊天时被准确召回。CrewAI的长期记忆、Mem0的实体偏好都在干这件事。

第三类是长期知识，更像是文档、产品手册、用户档案这些静态信息，它不是对话过程中产生的，而是预先塞给Agent的。很多项目把它叫知识库或者检索增强生成。严格来说，这不算“记忆”，但在落地时经常和记忆一起做，容易混淆。

一个真正成熟的Agent，缺不了这三种记忆的配合。但六个项目在设计上多数只做好其中的一两层，剩下的靠开发者自己拼装。这就是为什么我们做选型之前，得先知道自己更缺哪一种记忆。

2. 六项目选型与记忆架构全景图

2.1 我为什么偏偏挑这六个

市面上的Agent框架远不止这些，但我刻意选了六种实现方式跨度足够大的项目，而不是清一色的“LangChain系”。

LangChain、Dify、CrewAI都是应用框架，但它们把记忆嵌入到业务逻辑里的角度完全不同。LangChain是给程序员用的积木库，Dify是给产品团队用的低代码平台，CrewAI则是围绕“多Agent协作”设计的框架。

Mem0、Zep、Letta是另一类。它们不把自己定位成让开发者快速搭Agent工作流的框架，而是专门解决“记忆怎么管”这个子问题。Mem0把记忆做成一个独立服务，Zep用图结构存关系记忆，Letta干脆用操作系统管理内存的思路来设计Agent的大脑。

六个项目刚好分成三条线：应用框架、记忆服务和系统级记忆。对比起来看，比单纯对比两个框架的API有信息量得多。

2.2 核心差异一表看

先放一张我整理了很久的对照表，后面再逐个拆：

这张表别只看热闹，重点看第三列和第五列。选手一套的“记忆实现方式”，基本就决定了你以后要怎么跟它相处。是用封装好的记忆组件，还是自己写存取逻辑，还是把记忆当成一个黑盒服务，这种差异比存储用什么数据库重要得多。

3. 逐个拆解：六个项目的记忆设计细节

3.1 LangChain：模块化记忆组件与链式抽象

LangChain是典型的“拼装派”。它把记忆拆成了好几个Memory类：ConversationBufferMemory直接把历史对话全部缓存，ConversationBufferWindowMemory只保留最近N轮，ConversationSummaryMemory用模型把旧对话压缩成摘要，VectorStoreRetrieverMemory把历史片段向量化之后按相似度召回，还有EntityMemory专门记录人名、地名、产品名这类实体信息。

实际用的时候，我通常把WindowMemory和SummaryMemory搭配着用。指令是：近期两三轮对话用原文，保持精准；更早的内容走摘要，节省Token。代码写出来大概是这样：

from langchain.memory import ConversationBufferWindowMemory, ConversationSummaryMemory from langchain.chains import LLMChain memory = ConversationBufferWindowMemory(k=2) summary_memory = ConversationSummaryMemory(llm=llm, memory_key="summary")

但这里有个很容易踩的大坑：LangChain的Memory只是“提示词拼接工具”，它本身不做任何自动清理，也不会判断哪些历史重要。如果你同时挂了好几个Memory类，模型Prompt里可能同时出现原文、摘要和实体列表，内容重复甚至矛盾——摘要说“用户喜欢微信支付”，原文里用户刚刚又改成了支付宝，模型就会精神分裂。

所以我会建议：所有模块化记忆组件，最后都要自己写一个统一的Memory管理器，至少控制好注入顺序和优先级，别把记忆组件直接裸放到复杂链路上。

3.2 Dify：产品经理也能玩转的会话级记忆

Dify跟LangChain不同，它是一个完整的应用开发平台，在界面上就能把Agent的长期记忆配置好。Dify的记忆机制有两套主要入口：会话内记忆和知识库检索。

会话内记忆就是普通的对话历史，它把每个应用下的会话Thread独立存起来，你可以在编排界面直接打开“记忆”开关，还能设置上下文长度上限。它更特别的地方是“会话变量”：你可以定义数组、字符串这类变量，让Agent在对话中自行写入和读取。用第一个问题粗暴理解，这就是“给状态一个持久化的坑位”。

知识库检索才是Dify真正处理长期记忆的武器。你可以把用户档案、产品手册、历史工单塞进知识库，再把记忆相关的对话也追加进去。每次对话时先做向量检索，把最相关的片段拼进提示词，以此实现“跨会话”的记忆召回。

这套设计的好处是上手极快，产品经理都能半小时内搭出一个带历史记忆的客服机器人。代价是定制能力有限。Dify的逻辑是：给你几种足够通用的方案，覆盖大多数场景就好。一旦你需要的记忆召回策略很特别，比如“用户三个月前的订单信息要优先于最近聊天内容”，就得自己写外部服务，再通过API往会话里塞上下文。

所以Dify适合先把业务跑起来的场景。先用它验证“Agent带长期记忆是不是真的能提升用户留存”，验证通过之后再考虑切到更底层的东西。

3.3 CrewAI：让多Agent共享“团队记忆”

CrewAI的核心心智模型是“团队”：一群Agent各自有分工，协作完成一个任务。它的记忆是围绕这个建模展开的，有三种。

短期记忆直接挂在任务执行过程中，记录这个Agent这轮任务刚做过什么、发现了什么。长期记忆存在SQLite里，跨任务保留“这类任务以前是怎么完成的”，相当于团队的项目复盘记录。实体记忆存的是对象之间的关系，比如“用户A和订单B的关联”。

在多Agent协作场景里，记忆不只是要给同一个Agent用的，还要被团队成员共享。CrewAI在这方面做得相当直白：每个Task允许开发者在内部写入特定的历史上下文，运行完之后可以提取关键信息存入长期记忆，下一个Task启动时又能把之前的经验拉出来参考。

我在做一个跨部门工单流转Agent的时候，深度用过CrewAI这套机制。客服组负责收集信息，技术组负责排查，两个角色之间需要的记忆完全不一样。客服组需要记住用户的语气和诉求，技术组需要记住排查到哪一步。CrewAI的实体记忆刚好能把“用户”“工单”“系统环境”这类实体关系理清楚，比把所有历史一股脑丢给每个Agent强太多。

但也要注意，CrewAI并不是一个低门槛的产品。它的多Agent编排和记忆存取逻辑，需要你其实理解任务依赖关系。如果你只是单Agent对话机器人，硬上CrewAI反而会让问题变复杂。

3.4 Mem0：把记忆当独立服务来管理

Mem0是我见过“记忆模块化”做得最彻底的一个。它不关心你用什么框架，而是提供一个REST API，让任何Agent都能往一个独立的记忆数据库里写、改、查。

Mem0的底层同时用了向量数据库和知识图谱。它能自动从对话里抽取出“这是一个事实”还是“这是一个偏好”：“用户住在上海”是事实，“用户喜欢言简风”是偏好，然后分别存到不同索引下。调用时，你只需要给一句查询，它能同时从向量相似和实体关系两个维度找回相关记忆。

最关键的是它的自动更新机制。如果用户在第二周改了需求，说“我搬家到北京了”，Mem0不是简单追加一条，而是会找到旧的那条“住在上海”，确认冲突后更新掉。这避免了一个长期记忆最典型的问题：旧记忆和新记忆打架。如果你要我推荐“谁家的记忆像个人样”，Mem0这套自动冲突处理机制是很接近的。

不过引入Mem0也意味着你要多运维一套有状态服务，而且它到底抽取了什么、更新了什么，中间过程对开发者来说是半黑盒的。我一般会在系统里增加一个可视化调试界面，定期去看它记住的东西是不是合理，防止它抽到某些带有偏见的表述。

3.5 Letta（MemGPT）：用操作系统内存管理思路管理Agent记忆

Letta的前身是MemGPT，背后的核心思想是“把LLM上下文当作内存，模型自己当操作系统”。它的设计是让LLM通过Function Call来管理自己的记忆，而不是我们手工拼Prompt。

它把记忆分成了两块：主上下文（in-context memory）和外部内存（external memory）。主上下文就是模型当前能直接看到的信息，外部内存则是大量归档在数据库中的历史数据。模型在对话过程中，如果判断某个旧信息很重要，会自己调用工具把相关内容从外部内存“翻”进主上下文；如果主上下文太挤，它会调用工具把不太重要的内容写回外部内存。

这套思路最惊艳的地方在于“记忆自管理”。使用者不需要预估“最近几轮对话应该放进去”，而是模型自己判断“这个话题现在需要哪段历史”。我用它做法律咨询顾问的时候效果非常明显：对话从十几个小时前的合同条款，自然过渡到今天的补充提问，不需要开发者手动拼接任何长文档。

但Letta的代价是：模型依赖Function Call的稳定性，如果函数调用失败，记忆翻页就可能卡住。另外这套架构跟LangChain这类偏程序员找辅助工具的思路有些不同，上手曲线陡峭，适合有精力做深度定制的团队。

3.6 Zep：用图结构保存“实体关系网”

Zep是这六个里最偏“企业系统”的项目。它不把记忆当文本片，而是当一张图来处理。

它会把每轮对话保存成时间线（timeline），同时从对话中提取实体（用户、商品、地区、情绪）和实体之间的关系，比如“用户张三投诉了订单A”，其中“张三”和“订单A”之间就有一条“投诉”的关系边。检索的时候，既可以按时间线查“上一个会话说了什么”，也可以按实体查“这个用户所有相关历史”。后者在客服场景尤其发挥优势：同样问一句“上次出问题是什么情况”，我不用把整个聊天记录交给模型，只要把张三关联的节点和边抽取出来喂进去，模型就能精准回答。

Zep还有个细节设计做得很踏实：它支持对记忆做临时性的“延迟决策”。本地提问一个事实时，它可以把相关联但还没有被“确认”的关系一并返回，让LLM自行判断是不是相关。这减少了误召回概率。

它的硬伤是重。图数据库一旦做起来，运维成本和数据建模就都是事。适合业务本身实体关系很紧密的场景，比如CRM、供应链调度，而不是那种“随便聊聊天”的轻量Agent。

4. 设计思路对比：两种根本路线的博弈

4.1 路线A：上下文拼装派（LangChain、Dify、CrewAI）

把三个框架放在一起看，它们的共同点是：把记忆当成“给Prompt额外塞进去的上下文包”。每次用户提问，系统从某个存储里把相关历史、摘要或实体信息捞出来，拼接到系统提示词后面，最后再交给LLM。

这套路最直接的优点是透明、可控、容易调试。临时某一步出了问题，你可以把真正的Prompt打出来，看到底是哪一段历史在捣乱。同时它跟现有模型推理流程最匹配，毕竟对LLM来说，输入文字越长权重越大，其他机制都得“转译”。

缺点也很直观：它把记忆质量寄托在“检索策略”上。检索策略不好，召回的不是用户这次真正需要的旧信息，模型就会被弱相关的内容干扰甚至产生幻觉。而且随着记忆越攒越多，拼装出的上下文开销也越来越大，成本随Token线性增长。

几乎所有新手项目都会先选这条路线，因为试错成本低。但当业务复杂到“Agent自己不知道需要哪段记忆”时，拼装派就开始力不从心了。

4.2 路线B：记忆基础设施派（Mem0、Zep、Letta）

另一派的共同点，是尝试把记忆抽象成一个自主运行的系统，而不是每次请求前由开发者手工决定“把哪几段文本塞进去”。

Mem0像记忆管家，自动抽取事实、维护冲突更新；Zep像人际关系图谱，把记忆变成实体和关系，让LLM按图索骥；Letta像操作系统，让LLM自己决定把哪一页从磁盘搬进内存。三者都不需要你每次对话都去写“召回哪段历史”的调参逻辑，而是设计了某种自动机制来管理。

代价是系统复杂度大幅上升。你需要维护额外服务、理解内部抽取逻辑、处理黑盒更新带来的意外。模型对记忆的“自管理”行为并不稳定，有时它会把重要的事写回外部内存，留下不重要的在上下文里。这类问题一旦出现，比拼装派那种可预期的“检索漏了”难排查得多。

选这类方案的本质，是信任“自动记忆机制”比“手工拼装”更能应对复杂场景。我个人的判断标准是：如果你的Agent真的需要处理几万条协议级的历史记忆，并且你愿意花时间调试蒸馏机制，基础设施派是值得的；如果你只是想让一个客服机器人别把昨天的订单号忘了，那么次先拼装好也够了。

4.3 四维对比：持久化、检索、演化、更新策略

这张表最值得关注的是最后一行：更新策略。拼装派通常把“写入记忆”当成业务代码的一部分，比如对话结束后把摘要存储到MySQL。基础设施派则更倾向于异步、自动的管道，对话过程中就开始抽关系、写图谱。

异步更新的好处是不阻断对话，坏的方面是实时性差。如果你要做一个实时性要求特别高的Agent——比如用户上一秒刚修改了关键信息，下一秒必须立刻生效——拼装派的同步写入更可靠。如果只是追忆历史状态，异步自动抽取完全够用。

5. 实战中的坑与判断：什么情况选哪套方案

5.1 我在落地时踩过的坑

第一个坑是上下文污染。刚开始用LangChain组合记忆时，我一股脑把VectorStore召回的前20条历史全塞进Prompt，结果模型被大量无关内容干扰，回复质量直线下降。后来我把召回条数压到5条，再按时间倒序重排，效果立刻好了很多。长期记忆不是越多越好，是要刚好够用。

第二个坑是记忆覆盖的冲突。用自建摘要记忆时，如果用户中途更正了某个事实，旧摘要在很长一段时间里仍然留在向量库里，会被反复检索出来。我后来做了一层“记忆修正标记”处理：检测到新矛盾信息时，直接标记旧摘要失效，而不是简单追加。这比让模型自己判断容易调试得多。

第三个坑是成本爆炸。多Agent场景下，每个Agent都塞一份长期记忆，Token消耗按Agent数量倍增。CrewAI看起来每个Agent只塞自己的部分，但团队协作时共享上下文依然会膨胀。后来我限制共享记忆只在Task边界传递，流程内部的细节不跨Agent扩散，成本才降下来。

5.2 什么场景选什么方案

如果你只有一个产品化的Agent，想让电商客服、个人助理这种人机对话拥有基础记忆，从Dify起手最稳。界面点几下就完成，会话变量+知识库已经覆盖80%的需求。

如果你是开发者，想动手搭一套可定制的多步链路，LangChain仍然是首选。它的记忆组件虽然要自己拼装，但胜在透明可控，你完全知道自己喂了什么给模型。

如果你的需求是多角色分工、需要多个Agent站在不同视角读取记忆，CrewAI的团队级记忆设计是匹配的。它能让你把客服Agent和财务Agent的信息隔离得很干净。

如果你希望“记忆”变成可复用的公司基础设施，不绑定某个Agent，Mem0值得认真看。它自带API，别的系统随时存取用户画像，不用重头搭建。

如果你要做一个角色很稳定、对话动辄上百轮的产品，Letta的自我编辑机制是革命性的省心方案。它会主动管理上下文，你基本上不需要手工调参。

最后，如果你做的是客服、CRM、客户成功这类实体关系密集的业务，Zep的图记忆会让你比所有拼装派方案都省力。它能找到“用户、订单、售后工单”之间的内在联系，调用历史时准确率明显高于纯文本向量检索。

最后再分享一点实际体会：不要一开始就追求完美记忆，先跑出一版能“记住最近几轮”的，然后逐步加摘要、加实体、加独立服务。记忆功能做得越“聪明”，它带来的调试复杂度也越高。踩过几次坑之后，我现在反而会刻意保留一套最朴素的“最近N轮原始对话+长期外部摘要”的组合，很多项目就这么简单的一套，就已经够顺滑了。