做过Agent项目的朋友应该都有同感：单轮对话里模型表现得像个专家，但一旦跨会话、跨任务，它瞬间失忆，昨天刚确认过的偏好今天又要重新交代一遍。这个问题几乎卡住了所有想把Agent推向真实生产的团队。我过去一年里在多个项目里反复纠结这个问题，从早期拿向量库硬塞历史消息，到后来研究专门的记忆中间件，最大的体会是——长期记忆不是给模型加个存储盘，而是一整套关于写什么、存哪里、怎么取、何时忘的工程决策。今天这篇文章，我把六个主流项目的记忆设计方案放在一起做了个系统对比：LangChain/LangMem、MemGPT（Letta）、Mem0、Zep、CrewAI，以及一度很火的AutoGPT。每个项目的定位差异很大，有的选择管理上下文窗口，有的选择沉淀语义知识，有的直接做成生产级服务。希望通过这组对比，能帮你弄清楚自己的Agent到底需要哪种记忆，以及怎么绕开我踩过的那些坑。

1. 先摆清楚一个问题：Agent的"长期记忆"到底是什么

聊记忆之前，得先定义记忆。很多项目踩坑，就是因为把记忆一概而论，结果要么什么都存，要么什么都丢。

1.1 记忆不是单一存储，而是有层级的

人脑的记忆分工作记忆和长期记忆，Agent的记忆也一样。我习惯把它拆成三层来看：

• 工作记忆：当前会话上下文，相当于模型正在处理的context window。大模型靠注意力机制读这段内容，所有推理都发生在这里。
• 长期记忆：跨会话持久化的信息，包括用户偏好、历史事实、任务结论、知识片段。这是Agent"越来越懂你"的关键。
• 场景记忆/程序记忆：某种特定流程怎么走、某个工具怎么用、某个任务的历史做法。这部分在编排层体现为流程模板或技能库。

不同项目对这三层的侧重点差别很大。MemGPT侧重把工作记忆管好，Mem0和Zep侧重点在长期记忆的提取和检索，CrewAI则把长期记忆和场景记忆做了角色分工。理解这个分层，后面看各家设计就顺了。

1.2 记忆系统躲不开的三个环节：写入、存储、检索

任何记忆系统，拆到最底层就是三个动作：

• 写入：决定哪些信息值得沉淀。这一步最难，因为它依赖模型对"重要性"的判断，而判断错了，后面全错。
• 存储：决定用什么形式把记忆落地。纯文本块、向量索引、知识图谱、关系型表，各有利弊。
• 检索：决定在什么时机、用什么信号把相关记忆捞回上下文。实时性、相关性、抗噪声，三个指标很难同时拉满。

六家项目的思路差异，本质就是在这三个环节上做的不同取舍。有的把写入交给大模型自主判断，有的用规则+模型混合；有的存储只用向量库，有的做了图结构；有的按相关性检索，有的额外叠加了时间衰减。没有绝对优劣，只有适不适合你的场景。

1.3 context window再大也救不了记忆缺失

有人会说：Claude和GPT的上下文窗口都到100K、200K了，直接把历史全塞进去不就行了？这事我专门测过，结论很直接：窗口大不等于记忆好。

第一，成本不是一个量级。每轮对话全量携带历史，token消耗线性增长，跑不了几轮就顶不住账单。第二，噪声会淹没信号。模型注意力是有限的，塞进去10万token，真正关键的那几条信息反而容易被稀释。第三，信息会过期。用户的偏好可能三个月后就变了，全量历史根本没法做遗忘和版本管理。所以长期记忆一定要有独立的存储和检索机制，不是硬塞窗口能解决的。

2. 六家方案全景图：先看分歧再谈优劣

2.1 一张表看懂项目定位

先把六个项目放在同一张表里，看各自的定位、记忆形式和核心思路：

定位不同，意味着它们解决的问题边界完全不一样。LangChain是"给你工具，自己拼"，Zep和Mem0是"别管实现，直接用服务"，MemGPT则是"把记忆控制权交给模型自己"。下面逐个展开讲。

2.2 两大流派：向内管理上下文，向外沉淀知识

仔细观察会发现这六个项目其实分成两大派。

一派是上下文管理派，代表是MemGPT和LangChain的记忆类。它们的主要精力花在"如何从历史会话中提炼出当前执行需要的状态"，关注点是context window内怎么装得下又装得对。通俗点说，这类方案关心的是"此时该给模型看什么"。

另一派是知识沉淀派，代表是Mem0和Zep。它们主要解决"如何从大量交互中抽取出稳定的、可复用的知识"，关注点是通过结构化和索引让记忆可以被长期检索。这类方案关心的是"Agent持续积累下来什么"。

CrewAI和AutoGPT是混合体，但层次比较浅。CrewAI做了分工尝试，AutoGPT则基本属于"先存下来再说"的早期形态。理解这两派，选择时会清晰很多：如果你的Agent是单会话复杂任务，上下文管理派更适合；如果你的Agent要做跨会话个性化助手，知识沉淀派是主线。

2.3 为什么拿这六个项目对比

市面上做记忆的项目远不止这些，比如Memori、LlamaIndex的memory模块、LangMem之外的Mem0衍生生态。我选这六个，是因为它们分别代表了一种典型思路的极致形态：框架内置、系统级换页、语义管线、图记忆服务、多角色分工、早期全量存储。把这六种思路放在一起，基本能覆盖当前Agent记忆设计的全部主流技术手段。后面每个项目，我都会讲清它的设计逻辑、适合的场景，以及实测中的问题。

3. LangChain / LangMem：开发者友好，但记忆是"拼接件"

LangChain是最早把"记忆"作为一等公民写进文档的框架。但现在回头看，它的记忆模块更像是一个工具箱，而不是一套解决方案。

3.1 短期记忆：从内存Buffer到摘要再到向量检索

LangChain早期的记忆类很好理解，就是围绕聊天的历史记录做包装。

• ConversationBufferMemory：把全部历史消息原样保存，需要时全量拼进prompt。最简单，但基本只能支撑短会话。
• ConversationSummaryMemory：用模型把历史对话总结成摘要，存摘要而不是原文。解决了一定程度上的长度问题，但摘要会丢失细节。
• ConversationSummaryBufferMemory：摘要和原文混合，近期保留原文、远期保留摘要，兼顾细节与长度。
• VectorStoreRetrieverMemory：把历史片段向量化存入向量库，查询时按相似度检索出最相关的片段。

这组演进对应了一个核心问题：历史信息在上下文里放不下时，怎么压缩和筛选？我记得早期测试时，用SummaryMemory接长对话，模型对具体数字和用户原话的记忆基本全面退化，只剩"聊过某个话题"这种级别。所以后来社区普遍转向向量检索式的记忆，至少能按相关性找回细节。

3.2 长期记忆：LangMem的四阶段操作

LangChain在长期记忆上的野心体现在LangMem这个项目里。LangMem把记忆操作抽象成四类：

• Extract：从当前对话中提取潜在记忆候选。通过提示词让大模型判断"这段对话有什么值得记住的"。
• Prepare：对候选记忆做清洗和规范化，比如去掉对话杂质、统一格式。
• Evolve：根据新信息更新或合并旧记忆。比如用户之前喜欢轻量级笔记本，后来买了游戏本，记忆需要改写而不是新增。
• Integrate：把整理好的记忆写入存储，并建立索引。

这套管线设计得很规整，但它高度依赖大模型在Extract阶段的判断质量。我在实际使用中遇到的现实是：模型常常把"随口一说"当成重要偏好记住，或者漏掉真正关键的信息。提取质量决定了整套记忆系统的天花板，这一点在LangMem里体现得最明显。

3.3 实操感受与翻车点

用LangChain/LangMem搭记忆系统，最大的优点是灵活：所有组件都能换，LLM、向量库、存储后端都可以自由组合。但缺点也正在于此——你得到的是零件，不是整机。你需要自己设计记忆提取的提示词、自己决定哪些记忆要合并、自己处理记忆冲突和过期。LangMem提供了框架，但决策逻辑基本都要自己写。

我印象最深的一个翻车案例：某个助手项目里，我把用户每条重要操作都提取成记忆，结果跑了半个月，记忆库里堆了几千条碎片，检索时随便一查就能搜出几十条相关记录，模型根本不知道该信哪条。后面不得不加了合并和衰减逻辑，才算把召回质量拉回来。用LangChain系方案，建议一开始就把记忆的"遗忘策略"想清楚，别只想着存。

4. MemGPT / Letta：把执行上下文当成虚拟内存来管理

MemGPT这个项目的核心洞察非常聪明：既然大模型的context window是有限的内存，为什么不用操作系统管理内存的那套办法来管理它？

4.1 虚拟上下文管理机制

MemGPT的设计逻辑是这样的：把模型能看到的上下文看作物理内存，把外部存储看作磁盘。系统维护一套分页机制——模型先把最关键的信息放在"内存"里，次要信息放在"磁盘"里，需要时把相关页面换入，不需要时换出。

具体到实现，MemGPT定义了几种记忆层级：

• Core Memory（核心内存）：始终驻留上下文的信息，通常是系统提示词中的结构化记忆块（比如用户画像、Agent自我设定）。
• Recall Memory（回忆存储）：历史消息的完整记录，存在外部数据库，需要时可以检索回上下文。
• Archival Memory（归档存储）：长期事实性知识，通过函数调用按需写入和检索。

这套设计的精妙之处在于，它引入了中断和心跳机制。模型在执行过程中如果觉得需要记住某件事，可以主动调用函数请求"把这个信息写入归档"，系统会中断当前执行流，处理写入后再恢复。这让记忆写入不再是脱离模型的外部过程，而变成了模型自主决策的一部分。

4.2 可自我编辑的Agent记忆

MemGPT还有一个非常有意思的设计：核心记忆不是系统外部写进去的，而是Agent自己可以编辑的。它通过function calling调用core_memory_append、core_memory_replace等接口，自己维护对自己人设的记忆。

这意味着Agent的行为可以随记忆演化。比如一个客服Agent，这轮对话发现用户更喜欢简洁回复，它会直接在核心记忆里把"回复风格：简洁"这条改写掉，下一轮自动生效。这个思路放到记忆系统里，算是最大胆的尝试——把记忆的写入权从开发者交给了Agent自己。

这个设计在Letta（MemGPT的延续项目）里被保留并强化了，记忆块可以组织成JSON结构，Agent可以精细操作某个字段。

4.3 实操感受与翻车点

MemGPT的系统级比喻非常优雅，但实际使用时会有几个问题。

第一是换页的不可控性。模型判断"此刻需要哪些信息"并不总是可靠。我有一次跑多轮任务型对话，模型在一个子任务里把用户的核心偏好换出了上下文，后面再也没想起来，整场对话的体验明显变差。系统换页逻辑需要有很强的守卫机制，但默认配置下通常不够稳。

第二是记忆碎片化。Agent自己编辑记忆块，久了会产生大量细碎、重复甚至互相矛盾的小字段，尤其是做append操作时。需要定期做记忆压缩和合并，这又是一个额外的工程负担。

第三是成本不透明。MemGPT为了换页会频繁调用函数，这些函数调用也要消耗token和时间。实测在复杂任务里，光记忆维护可能就占掉不少调用量，需要在实际业务里做预算。

客观说，MemGPT的思想对后续项目影响极大，我现在看任何记忆系统，都会下意识问一句："模型自己能主动写记忆吗？"但把它直接用到生产环境，得有心理准备去处理换页稳定性的问题。

5. Mem0：从"存了多少"转向"记得多准"

Mem0是这两年长期记忆赛道里跑得最快的项目之一。它的口号是"给AI一个可成长的记忆"，但真正让它区别于早期方案的是：它的重点不在存储，而在记忆的提取和维护质量。

5.1 记忆提取管线：ADD、UPDATE、DELETE、NOOP

Mem0最核心的设计是一条由大模型驱动的提取管线。系统拿到新的对话内容后，会交给模型做四类判断：

• ADD：提取出全新的值得记住的信息，写入记忆库。
• UPDATE：发现新信息与已有记忆存在关联或冲突，改写旧记忆。比如用户换了工作城市，旧记忆"住在北京"需要更新为"住在上海"。
• DELETE：判断某条记忆已经失效或错误，删除它。
• NOOP：判断当前内容没有任何值得记住的信息，什么都不做。

这四类操作让记忆系统具备了自我维护能力。尤其UPDATE这个动作，解决了我前面提到的一个大痛点——用户的偏好会变，记忆不能只增不改。在Mem0之前，很多方案的记忆库都是"只写不删"的垃圾场，Mem0第一次把记忆的更新和删除提升为核心机制。

5.2 向量+图谱混合检索

存储层面，Mem0采用混合架构。它以向量数据库作为主体承载记忆的语义索引，同时引入了知识图谱来组织实体之间的关系。

这是什么意思呢？纯向量检索擅长找"语义相似"，但不太擅长回答"某个实体和另一个实体是什么关系"这类问题。比如问"这个用户最常找我们买什么品类"，向量检索会返回一堆关于购买行为的片段，但知识图谱可以直接抽出用户和商品的关联关系。两者结合，召回的相关性和可解释性都会更好。

Mem0的另一个特点是，它可以在多个Agent之间共享记忆。比如一个Agent处理邮件、一个Agent处理日历，各自独立运行但共享同一套用户记忆，这对构建个人助理形态的产品非常关键。

5.3 实操感受与翻车点

Mem0我实际集成过两个项目，总体印象是"开箱即用程度最高"。它有API和Python库，配置好LLM和向量库就能跑，提取效果明显比LangChain里自己写提示词稳定。尤其是信息冲突的处理，比如用户先说了"我工作在深圳"，几天后又说"我搬到杭州了"，Mem0能正确把旧记忆更新掉，这在别的方案里很少见。

但要泼几盆冷水。

第一，它的提取质量强依赖底层LLM。我用GPT-4和用开源模型跑同一个对话流，提取出来的记忆质量差异非常大。开源模型经常把对话里的闲聊也当成事实存进去。如果要上生产，底层模型的钱不能省。

第二，记忆重写带来的历史一致性风险。UPDATE操作有时改得过头，把一些还有效的细节也抹掉了。比如用户从"喜欢性价比手机"更新成"买了高端机型"，但这个用户可能依然在意性价比。Mem0提供了重构的置信度选项，但调整这些参数需要大量实验。

第三，存储成本比看上去高。混合检索意味着要同时维护向量库和图数据库，数据一致性问题就出现了。我在项目里遇到过向量库里已经删掉的实体，图库里还残留关联的情况，最后得写对账脚本定时清理。

6. Zep：把记忆做成独立于模型的服务层

Zep的思路和前面的项目都不一样——它不绑定任何Agent框架，而是把记忆做成了一个独立服务。你的Agent只需要调用Zep的API，就能获得记忆的写入、读取、更新、搜索全套能力。

6.1 时间加权图记忆的核心设计

Zep最有辨识度的设计是时间加权图记忆。它会把对话中提取出的实体（人、事、物、概念）和关系存成知识图谱，同时给每条记忆加上时间属性。

这个"时间加权"是什么意思？Zep在检索记忆时，不只算语义相关性，还会把时间衰减因素算进去。一条两年前的记忆和一条昨天的记忆，即使语义上同样相关，后者的权重会明显更高。这套机制很好解决了长期运行Agent的一个棘手问题：老记忆和新事实打架时，该信谁。时间加权给了新信息合理优势，而且不需要开发者手动做过期标记。

Zep图记忆的另一个优势是召回可解释。因为它存的是一张图，你可以直接查"用户提到的项目、参与的人、关联的时间"，顺着边就能找到推理路径。这在排查Agent错误决策时特别有用——你能看到模型到底是根据哪条记忆做的判断。

6.2 会话历史速写与事实提取

除了图记忆，Zep还内置了对话历史速写功能。它对每段会话做两层处理：一层是把完整对话生成压缩摘要，另一层是从中提取出可结构化的"事实"。这样当新会话开始时，系统可以快速回放摘要让Agent"想起来"上次聊了什么，同时把关键事实同步进图记忆。

实际操作中，Zep的API设计比较务实：创建用户、添加会话、查询记忆，几个接口就能串起来。它还提供了一些预置的提示词模板，方便做事实提取。相比前面那些需要自己组装全套方案的项目，Zep更像是一个生产保障件——部署在Agent和模型之间，承担记忆的脏活累活。

6.3 生产环境部署的观察

Zep现在同时有云服务和自托管两种形态。自托管时它包含PostgreSQL、Neo4j等组件，整体部署起了一套微服务，但好处是记忆层可以和业务完全解耦，多个Agent服务可以共享同一套记忆后端。

我在一个内部知识型Agent上部署过Zep，最明显的感受是检索延迟需要监控。因为图查询和向量检索要同时跑，某些复杂查询的响应时间会到几百毫秒，这在一个实时对话链路里是能感知到的延迟。当时我们做了一层缓存，对高频记忆做热加载，才把体验拉回来。

另外，Zep的图模型默认把关系类型划得比较细，存多了以后图会变得很复杂，检索时容易查出一堆边。建议实际使用时限制图的深度，或者定期做图剪枝，不然迟早会遇到查询超时。

7. CrewAI与AutoGPT：早期风潮里的两种极端

这两个项目放在一起对比很有意思。CrewAI代表了"把记忆分给不同角色"的编排路线，AutoGPT则代表了"先把历史全存下来"的朴素路线。它们都算不上最佳实践，但教训价值很高。

7.1 CrewAI：三种记忆按角色分工

CrewAI是多Agent协作框架，它设计了三类记忆接口：

• 短期记忆：会话内的上下文共享，所有Agent在执行同一个任务时共享一段短时状态。
• 长期记忆：跨任务的持久存储，底层用SQLite和向量检索，保存Agent在历史任务中的结论和偏好。
• 实体记忆：专门存业务实体的信息，比如用户、项目、组织，结构化为层级实体存储。

CrewAI让我欣赏的一点是，它明确了记忆的"归属"——不同记忆服务不同的Agent流程角色，而不是一股脑全塞给主Agent。比如一个市场调研Crew，资料收集Agent的产出沉淀到长期记忆，客户画像Agent把结论写进实体记忆，最终汇总时各自按需读取。这种分工在多人协作式Agent里很有价值。

但它的缺点是，这套记忆系统做得比较浅。长期记忆本质上还是"任务结果向量化存储"，缺少Mem0那种提取、合并、更新的精细管线。存进去的信息质量取决于各Agent输出质量，输出很差时记忆库就是垃圾进垃圾出。

7.2 AutoGPT：什么都往里塞的向量库

说到AutoGPT，它是2023年那波自主Agent热潮的代表，而它的记忆方案其实简陋得惊人：每个Agent实例把所有历史操作和结果哈希化，塞进向量数据库，需要时按相似度取回。典型做法是用Pinecone存embedding，配上简单的"相关记忆"查询。

AutoGPT式的记忆有两个致命问题。

第一是没有信息筛选。它记住的不是"重要结论"，而是"发生过的所有事"。跑了一天的自主任务，记忆库里堆了几万条操作日志，检索时召回一堆无关噪音。模型本身没有能力区分哪些该记、哪些该忘。

第二是没有结构。所有记忆都是平铺的文本块，没有实体关系、没有时间维度、没有优先级。它的表现就像记了满满一本流水账，翻哪页都像在翻垃圾。

我见过不少早期项目拿AutoGPT的路子搭记忆，最后都死在这两个问题上。但AutoGPT给行业的启示也很大：它让所有人看到了，没有好的记忆，自主Agent跑得越久越糟糕。后来MemGPT、Mem0这些项目能拿到大量关注，很大程度是因为被AutoGPT的失败教育过市场。

7.3 从它们身上能学到的教训

把CrewAI和AutoGPT放在一起看，有两条很实在的教训。

一是记忆要有"归谁管"的意识。CrewAI的分工模型比AutoGPT的混装模型好太多，多Agent系统里记忆必须跟着职责走，而不是塞一个公共垃圾桶。

二是存储不等于记忆。AutoGPT不缺存储，缺的是对信息的筛选、结构化和遗忘。而这恰恰是后面Mem0、Zep重点解决的问题。如果今天要新做Agent，我建议直接绕过AutoGPT式全量存储，起步就设计好提取和更新管线。

8. 选型落地：六套方案对应什么场景，以及我踩过的坑

最后把这六套方案的选型逻辑和实战中容易踩的坑讲透。每次被问"该用哪个"，我都建议先想清楚自己的Agent要服务什么场景。

8.1 按场景选型

如果要我给出一个务实路径：个人助手类应用优先试Mem0，生产级系统优先评估Zep，想要深度掌控和快速试验选LangMem，想要模型自我管理上下文试Letta。别一上来就全量接入图记忆或复杂管线，先跑通一个最简记忆闭环，再逐步叠加复杂度。

8.2 三个容易踩的坑

第一个坑是记了一堆没用的信息。所有记忆系统都会过度提取，尤其用便宜模型时。我的解决方案是给提取加一层过滤规则：只有包含明确实体（用户名、产品名、时间、偏好词）的内容才允许入库，纯闲聊、纯寒暄一律丢弃。

第二个坑是检索到了旧信息且未处理时效性。如果方案没有Zep式的时间加权，建议自己在记忆条目上打时间戳，检索时对旧条目做降权。否则一个用户半年前吐槽过某功能，半年后问起该功能时，Agent会把吐槽当成当前态度。

第三个坑是把记忆库当成了万能缓存。有人为了省token，把业务中间状态也塞进Agent记忆。这是把记忆库和数据库混为一谈。Agent记忆应该只承载"影响模型行为的用户信息与事实"，业务数据该进业务库就进业务库。混用之后，检索准确率和系统可维护性都会快速劣化。

8.3 一个务实的落地路径

如果你还在初期，我建议按这个顺序推进：先用LangChain把短期记忆跑通，理解context window的边界；然后接一个Mem0或Zep做长期记忆，观察提取质量和检索效果；最后再根据业务需要引入图结构或记忆共享。每一步都先定量评估——提取准确率、检索命中率、对最终任务成功率的提升——再决定要不要继续加深复杂度。记忆这个事，做减法永远比做加法难，但也永远更有效。

我个人在实际项目里的体会是，长期记忆的价值不在"存了多少"，而在"该想起来时想得起来，不该当真时不当真"。一套好的记忆系统，最终应该像一个靠谱的助理：记得住关键事，拎得清轻重，也懂得忘掉过时的细节。希望这篇对比能帮你少走一些弯路，找到适合自己Agent的那套方案。