1. 先聊清楚：Agent 的“记忆”到底难在哪
如果你上手写过几个 Agent，一定会碰到这个场景：对话刚开始，Agent 表现得像个聪明的助手，上下文里塞了多少信息都能记住。但聊着聊着，它就开始“失忆”——用户五分钟前告诉它的偏好、半个钟头前让它记住的任务状态，统统丢得一干二净。这不是模型笨，而是 Agent 的对话上下文本质上是一次性的：每次调用大模型接口，传进去的只有当前这段窗口里的内容，窗口之外的东西，模型一概不知。
更麻烦的是，很多 Agent 应用不是“聊完就走”，而是需要长期陪伴：比如个人助理要记住用户的工作习惯，客服机器人要沉淀用户的历史工单，代码助手要记住项目里那些“约定俗成”的命名规范。这些场景下，短期上下文窗口根本扛不住，模型输入长度有限，塞进去太多历史消息，既费钱又容易把关键信息挤掉。于是“长期记忆”就成了 Agent 工程化绕不开的一环。
我最早踩这个坑是在做一个内部文档问答机器人。一开始天真地以为把全部历史记录都拼到 prompt 里，模型就能“记得住”。结果不到两百轮对话，token 费用直接爆炸，而且回复质量肉眼可见地下降——大量无关历史把有效信息稀释了。后来才意识到，长期记忆不是“把东西都塞进上下文”，而是“在需要的时候把对的东西取回来”。这一下就把问题从“模型能力”变成了“工程架构”。
这篇文章就把我研究过的六个主流 Agent 项目的记忆方案拉出来做个横向对比：LangChain / LangGraph、MemGPT（Letta）、CrewAI、AutoGPT、SuperAGI、Zep。每个项目的记忆设计思路侧重点都不一样，有的走“管理上下文窗口”的路线，有的走“外部向量库持久化”的路线，有的干脆把记忆做成一个独立服务。我会把它们的核心机制、适用场景、典型实现方式摆在一起拆开讲，最后再说说我实际使用中会怎么选。
2. 先建立坐标系：理解记忆方案之前，必须懂的几个基础概念
在逐个拆项目之前，有几个底层的概念你最好先心里有数。不然看哪个项目都觉得“好像差不多”，其实差异藏在这些细节里。
2.1 短期记忆、长期记忆、工作记忆，到底在说什么
记忆这个概念被各家项目用得比较随意，但本质上可以分成三层。
短期记忆（Short-term Memory）就是当前对话上下文窗口里正在处理的信息，比如用户刚刚说的话、模型上一次的回复、当前这一步的工具调用结果。它活在 prompt 里，窗口一关就没了。长期记忆（Long-term Memory）是跨会话持久化的信息，比如用户画像、历史偏好、过去完成过的任务结论，通常存到外部存储里，需要时再捞回来。工作记忆（Working Memory）则比较特殊，它指的是“当前任务执行过程中需要临时记住的中间状态”，比如一个多步骤任务执行到第几步了、已经拿到了哪些中间结果。工作记忆不一定跨会话，但它比短期记忆更结构化，通常要显式地建模和维护。
这三个概念会贯穿整篇文章。你会发现：LangChain 的 Memory 模块早期主要解决的是短期到长期的“搬运”问题；MemGPT 的核心创新在于像操作系统一样管理短期记忆的“换入换出”；CrewAI 更强调任务执行中的工作记忆；而 Zep 干脆把长期记忆做成了一个可以直接查的历史数据库。
2.2 上下文窗口是 Agent 记忆的物理天花板
所有记忆方案都绕不开一个问题：模型上下文窗口是有限的。GPT-4 级别的模型窗口能做到几十万 token，但你不能真的把它当无限用。一是成本问题，每多一个 token 都是钱；二是效果问题，上下文太长之后，模型对中段信息的注意力会衰减，这在业界被称为“迷失在中间”问题（Lost in the Middle），实测下来窗口前部和尾部的信息模型记得牢，中间部分经常被忽略。
所以，任何长期记忆方案的本质，都是在“有限的窗口”和“无限的历史”之间做一个折中。核心思路无非两种：压缩和检索。
压缩思路，就是把历史信息提炼成更精炼的摘要、结构化条目或 embeddings 向量，节省空间。检索思路，就是平时不占窗口，等需要的时候通过语义相似度把相关片段捞回来。这两个思路不是互斥的，实际项目里往往是混合使用。看一个记忆架构好不好，关键就看它在“压缩到什么程度”和“检索的准确率”之间怎么取舍。
2.3 记忆生命周期：写入、存储、检索、遗忘
一个完整的记忆系统，是有生命周期的，不是单纯“存进去取出来”那么粗暴。
写入（Write）阶段解决的是“什么信息值得记”。不是所有对话内容都值得入库，要有筛选机制，比如基于重要性判断、情绪强度判断、还是用户显式指令。存储（Storage）阶段解决的是“记到哪里、什么格式”。可以是结构化数据库、键值存储、向量数据库，也可以是一份 Markdown 文件。检索（Retrieval）阶段解决的是“怎么把相关记忆找回来”。关键词匹配太生硬，语义检索会把问题转成向量再比对相似度，但怎么决定“捞多少条、按什么权重排序”也是个讲究。遗忘（Forgetting）阶段虽然很多项目不提，但非常重要。记忆不清理会越积越多，检索噪声变大，存储成本升高，而且可能涉及用户隐私——该忘的得忘。
理解了这套生命周期，再回头看那些项目，你会发现每个项目其实只在其中某个环节上做得好，没有谁是全能的。
3. 逐个拆解六个主流项目的记忆设计
3.1 LangChain / LangGraph：用 Memory 模块和 Checkpointer 做“显式管理”
LangChain 可能是绝大多数人接触 Agent 的入口，它的记忆方案也最“中规中矩”——把记忆当成一块可以显式定义、显式操作的数据。
LangChain 早期版本里有一套 Memory 抽象，最常用的是 ConversationBufferMemory、ConversationSummaryMemory、ConversationBufferWindowMemory 这几类。Buffer 就是把对话原样缓存，Window 是只保留最近 N 轮，Summary 则是用模型把已有对话浓缩成摘要再接续。这些方案解决的是单会话内的“短期对话保持”，说白了一点都不“长期”，会话一重启，记忆全丢。
到了 LangGraph 阶段，情况好转不少。LangGraph 引入了 Checkpointer 机制，可以把图执行的完整状态（包括消息列表、Agent 的状态字段）持久化到存储后端——SQLite、Postgres、Redis 都行。每次节点执行完，自动存一个 checkpoint；下次恢复执行或者开启新会话时，可以从 checkpoint 恢复现场。这个机制能实现“断点续跑”和“跨会话恢复”，本质上是一种状态持久化，比单纯记对话消息更偏“工作记忆”。
但 LangGraph 默认的检查点机制，其实是“全量快照”式的。如果你一个会话里积累了上万条消息，checkpoint 一次成本不小。所以生产落地时，仍然需要你自己设计“哪些状态该存”“哪些消息该清掉”。LangGraph 给你的是“能存”的能力，但“存什么、怎么存得聪明”还是得自己拿主意。
我自己的体会是：LangGraph 适合那些把 Agent 执行流当“状态机”来设计的团队。你本来就要用图去编排复杂的多步任务，checkpoint 是顺手就有的技能。但如果你只想做一个“带记忆的聊天机器人”，LangGraph 这套东西有点重，杀鸡用牛刀了。
3.2 MemGPT / Letta：用“虚拟内存分页”思路管理上下文
MemGPT 是我觉得最有想象力的方案，后来改名成 Letta。它把一个操作系统里的虚拟内存机制整个搬到了 Agent 上：大模型上下文窗口是“物理内存”，外部存储是“磁盘”，Agent 自己会判断哪些信息该留在窗口里、哪些该“换出”到外存、什么时候该“换入”回来。
具体实现上，MemGPT 把记忆分成几个层级：核心内存（Core Memory）始终留在上下文里，像是系统提示词一样常驻，记录 Agent 的身份、关键用户信息；工作上下文（Working Context）是当前的对话与工具调用信息；外部存储（External Storage）则是向量数据库里的历史对话和归档记忆。
最妙的是它的“自我编辑”机制。MemGPT 定义了函数，让 Agent 可以自己调用工具去操作记忆，比如memory_insert、memory_replace、memory_delete、archive_memory这些。当上下文快满的时候，Agent 会主动把一些不那么重要的对话归档到外存；当新对话涉及旧话题时，Agent 又会主动去检索并加载相关记忆。整个过程不需要开发者硬编码，而是模型自主决策。
这种方案的前瞻性很强，但代价是复杂度和不确定性。模型自主判断“要归档什么、要加载什么”，判断错了就会出问题——比如把关键信息误归档，或者反复加载不相关记忆。而且模型每做一次记忆操作都要额外消耗 token，跑久了成本也不低。官方后来改名 Letta，并推出了托管服务，底层也引入了更可控的记忆块（Memory Blocks）管理。
一句话总结：MemGPT 适合那些追求“长期陪伴型 Agent”的团队，也适合爱折腾的研究者，但生产环境落地需要做好护栏，不能完全放任模型自己玩记忆。
3.3 CrewAI：把记忆拆成四种类型，服务于“多角色协作”
CrewAI 是这两年多 Agent 框架里火得很快的一个，它的核心卖点是让多个 Agent 像一支团队一样分工协作。因为 Agent 之间要频繁交接任务、共享状态，所以 CrewAI 对记忆的设计也更偏“团队协作”这个场景。
CrewAI 的记忆拆成四块：短期记忆（Short-term Memory）保存当前任务执行过程中的上下文，支持跨任务共享；长期记忆（Long-term Memory）从过往执行中提取偏好和结论，用向量存储持久化；实体记忆（Entity Memory）专门存“关于某个人/事/物的知识”，比如用户偏好某个颜色、团队习惯用某种代码风格；还有最近新增的情景记忆（Contextual Memory）之类，本质上是稍复杂一点的长期记忆增强版。
这套设计的优点是“分类清晰”，开发者可以针对性地决定哪类记忆对当前业务有价值。比如做客服 Agent，实体记忆就很重要——用户提到的产品型号、个人偏好都要重点记；做自动化任务执行器，短期记忆和工作流程记忆更关键。
但 CrewAI 的问题也很典型：为了易用性，很多记忆逻辑被封装在框架内部，意味着你自定义控制的粒度不如 LangGraph 那么细。它很适合快速搭一个带记忆的多 Agent 协作应用，但真要深度调优记忆策略时，反而没有 LangChain 或者 MemGPT 那么直接。
3.4 AutoGPT：从“直接忘光”到“向量库辅助回忆”
AutoGPT 是 2023 年那波“自主 Agent”浪潮的引爆点，当年它让 Agent 自己设定目标、自己拆解任务、自己调用工具，一副要取代人类的样子。但早期版本里，AutoGPT 的记忆策略约等于没有：所有上下文全靠一个巨大的 prompt 往下传，跑个几十步就开始暴走，经常出现“说着说着忘了自己在干嘛”的状况。这直接催生了后来对记忆方案的批评和重做。
后续 AutoGPT 引入了长期记忆模块，思路很标准：把 Agent 在任务执行过程中产生的关键信息（目标、子任务列表、执行结果摘要）提取出来，转成向量存进向量数据库（早期支持 Pinecone、Milvus 等）。每次任务循环开始之前，Agent 会先从向量库里语义检索与当前子任务相关的历史记忆，作为上下文补充。
这个设计解决了一个核心痛点：Agent 在长任务链执行过程中不会“走两步忘三步”。但代价也很真实：检索结果的质量直接决定 Agent 的稳定性。如果你提取“关键信息”的规则太粗，检索引擎会捞回一堆低质量的片段，反而干扰模型判断。AutoGPT 的定位更像一个“实验性质的全能 Agent”，它的记忆方案能证明“向量库自检”这条路走得通，但要生产化，还有很多细节要打磨。
3.5 SuperAGI：把记忆做成了可插拔的“记忆工具箱”
SuperAGI 是另一个开源 Agent 开发框架，也自带了一套专门设计的记忆模块。它的思路比 AutoGPT 更有“产品意识”：既然不同场景对记忆的需求不一样，那就把记忆做成可插拔的组件，开发者自己选。
SuperAGI 提供了不同类型的记忆存储后端，早期以 Redis 作为默认短期存储，向量数据库（如 Weaviate）作为长期存储。它还搞了一套记忆组织方式，就是为每条记忆打上时间戳、来源标签、重要性评分之类的元数据，这样检索的时候可以按时间衰减、按来源过滤、按重要性加权。
印象最深的是 SuperAGI 对“记忆清理”的处理。它引入了“对话压缩 + 摘要生成 + 定期归档”的机制，避免向量库无限膨胀。每次对话结束后，它会把新产生的对话内容融入已有摘要，并清理掉已经“过期”的细节信息。
不过 SuperAGI 后来的维护活跃度不如前几个项目，社区热度也有所下降。但它的记忆设计思路很值得参考，尤其是“可插拔存储后端 + 元数据管理 + 定期压缩”这套组合拳，放到今天依然是主流做法。
3.6 Zep：把“记忆”做成一个独立服务，走专业路线
Zep 的思路跟前面几个都不一样，它不满足于“给 Agent 框架加个记忆模块”，而是直接把长期记忆做成了一个独立服务。官方定位是“Memory for AI Agents”——你不管用 LangChain 还是自研框架，都可以把 Zep 当成一个外部记忆系统来调用。
Zep 核心的特性是 Graphiti（知识图谱记忆）。它不是简单地把对话片段存进向量库，而是会把对话中涉及到的实体（人、事、物、时间）抽取出来，构建成知识图谱，同时记录实体之间的关系。比如用户说“我儿子今年十岁，喜欢乐高”，Zep 不只是存下这句话，它会建立一个“用户 → 儿子 → 10岁 → 喜欢乐高”这样的关系网络。后续用户问“给我儿子挑个生日礼物”，Zep 可以从图谱里关联到“乐高”这个偏好。
Zep 还支持时间衰减、自动摘要、语义检索、实体链接等一整套记忆功能。它的 API 设计得很干净：服务端负责处理对话历史的摄取、记忆提取、索引构建，客户端只需要发送新消息和读取返回的记忆结果。这种“服务化”思路，让 Zep 特别适合已有稳定 Agent 架构、想“外挂”强大记忆能力的团队。
但 Zep 的代价也很直接：你需要额外部署和维护一个服务，有学习成本，而且知识图谱的构建需要消耗模型调用。对于大团队、高复杂度场景，这是划算的；对于一个小脚本或者原型 Demo，Zep 属于杀鸡用牛刀。
4. 横向对比：六种思路放在一张表里，谁更适合什么场景
先把六个项目的核心特性整理成一张表，方便你对照着看。
| 项目 | 核心记忆思路 | 记忆类型覆盖 | 存储介质 | 自定义程度 | 适用场景 |
|---|---|---|---|---|---|
| LangChain / LangGraph | 显式 Memory 模块 + 状态 Checkpoint | 短期、工作记忆为主 | SQLite / Postgres / Redis | 高，需自行设计 | 状态驱动的复杂多步 Agent 流程 |
| MemGPT / Letta | OS 式虚拟内存换入换出，模型自主管理 | 短期、长期、核心记忆全覆盖 | 内存 + 向量库 | 中高，但模型决策有不确定性 | 长期陪伴型 Agent、研究原型 |
| CrewAI | 四类记忆拆分，围绕多 Agent 协作 | 短期、长期、实体、情景记忆 | 向量库 + 内存 | 中，框架封装较多 | 多角色协作团队型 Agent |
| AutoGPT | 任务关键信息提取 + 向量库语义检索 | 长期任务记忆为主 | 向量库 | 中，依赖提取质量 | 自主任务执行链较长的 Agent 实验 |
| SuperAGI | 可插拔存储 + 元数据管理 + 定期压缩 | 短期、长期 | Redis + 向量库 | 中高 | 需要灵活搭配存储后端的 Agent |
| Zep | 独立服务 + 知识图谱 + 语义检索 | 长期记忆、实体记忆最突出 | 自建服务 / Graphiti 图谱 | 高中，服务化后集成方便 | 已有生产 Agent 需要外挂记忆能力 |
仅仅看表格还是不够的，六个项目的设计哲学差异很大，选型时不能只看功能清单。
4.1 从上到下：谁在解决“记什么”，谁在解决“怎么取”
仔细看会发现，LangChain 和 LangGraph 解决的其实是“开发者主动决定记什么”的问题，它把所有记忆逻辑的选择权交给你。MemGPT 则反过来，把“记什么”的决策权交给模型自己。这两种取向没有绝对优劣，但会直接影响你的开发模式。LangChain 模式下，你得更懂业务，因为记忆质量取决于你的显式设计；MemGPT 模式下，你可以省掉不少设计工作，但要接受模型偶尔抽风的风险。
CrewAI 介于两者之间：它预设好了记忆的“分类框架”，你只需要按框架填充内容。
AutoGPT 和 SuperAGI 则更偏向“任务执行历史”的记忆，因为它们诞生的场景是让 Agent 自主跑长任务，记忆的核心价值在于“让 Agent 不要半途忘目标”。
Zep 是最特殊的一个，它不关心你用什么框架，它只负责提供“记忆能力本身”，而且是质量最高的一档——知识图谱加持下的记忆，不仅能“想起来”，还能“关联起来”。
4.2 横着看：共识与分歧
六个项目有一个共识：长期记忆必须外部化，不能依赖模型上下文窗口。这是个很重要的一致性信号——就算大家路线不同，底层判断是相同的：内存靠不住，得用外存。
分歧点主要在两个维度。第一个维度是记忆如何写入：LangChain 靠开发者写逻辑，MemGPT 靠模型自主决策，CrewAI 靠框架自动提取，AgentGPT 靠规则提取关键信息，Zep 靠服务端模型构建知识图谱。第二个维度是记忆如何检索：简单的做向量相似度，进阶的加元数据过滤和时间衰减，再进阶的像 Zep 一样走知识图谱的图遍历。
所以：如果你只想要一个关键词“长期记忆”的答案，那就是“存入外部存储 + 按需语义检索”。但如果你想真的做好记忆，你需要进一步决定“谁来决定存什么”和“用什么结构来存”。这两件事决定了你这个 Agent 的记忆上限。
5. 实操视角：我在什么场景下用哪套方案，以及落地时的坑
5.1 “我现在就想做一个带记忆的 Agent，该怎么选”
根据我自己的实战项目经验，给你一个快速选型建议。
如果你用 LangChain 或 LangGraph 做流程编排，团队习惯自己掌控一切：直接用 LangGraph 的 Checkpointer 作为工作记忆底座，再搭配一个你自己设计的“长期记忆服务”（比如每次对话结束后用 LLM 提取要点入库向量库，需要时检索回来）。这是目前最稳妥、最可控的方案。别迷信现成框架的 Memory 插件，生产环境里往往不够用。
如果你做的是“私人助理类”Agent，守护进程式的长期陪伴是核心卖点：优先考虑 MemGPT / Letta，它会自己整理核心记忆和档案信息，非常贴近“越用越懂你”的体验。但生产部署时务必给它的记忆操作加上“人审”或“规则护栏”，避免模型乱删重要记忆。
如果团队风格是“既要多 Agent 协作，又要快速迭代”：CrewAI 的预设记忆类型能省你不少事，尤其是 Entity Memory 在客服类、CRM 场景下非常好使。
如果你已经有一套生产 Agent，只是感觉“记性太差”想补强：不用换框架，直接接 Zep 服务，它的知识图谱记忆能补上语义关联这块短板，尤其适合用户画像沉淀和推荐类 Agent。
5.2 落地记忆系统时会踩的五个坑
坑一：把所有对话都存起来。这是我见过最多的错误。很多开发者的第一反应是“先把历史都存了，以后用得上再说”。结果就是向量库里塞满了一堆无关紧要的寒暄和噪音，检索时召回结果被大量无用信息污染，Agent 的回复质量反而下降。正确做法是“写入前筛选”，只存那些有长期价值的信息：用户显式表达的偏好、任务完成的关键结论、涉及具体实体的事实型信息。
坑二：把检索结果全部填进上下文。即使做了筛选，长期运行后相关记忆还是可能很多。如果你把 Top 10 条记忆全塞进 prompt，每一条都有几百 token，上下文还是会被撑爆。我建议的做法是：先做一个两级过滤——第一级用向量相似度拉出 Top 20，第二级用 LLM 或规则过滤，按“与当前问题的相关度+信息的新鲜度”各占一定权重排序，只保留 Top 5 左右进上下文。
坑三：忽视时间衰减。用户三个月前的偏好很可能已经变了。如果不做时间衰减，Agent 很可能把一个旧偏好当成当前事实来回答。SuperAGI 和 Zep 都有时间相关的设计，但如果你自研，一定要在检索结果里给更近的记忆更高的权重。
坑四：记忆是很隐私的东西。有时候用户跟你说“我最近在考虑跳槽，但还没跟老板提”，这种记忆存下来，下次另一个人登录账号问问题，Agent 要是“全知全能”地把这事儿抖出来，后果很严重。建议至少做两层处理：记忆分级（普通级、敏感级），敏感级默认不带入上下文；记忆归属隔离，不同用户的数据物理隔离。
坑五：忘了记忆系统本身也是要维护的。向量库要磁盘空间，知识图谱要定期重建索引，记忆存储要备份。最尴尬的是因为摘要压缩逻辑写得太激进，把重要信息在压缩中弄丢了——这种 bug 极难排查，因为你不知道它“忘了什么”。建议对记忆压缩操作做版本日志，关键信息压缩前后都要留痕。
5.3 一个最小可落地的长期记忆实现方案
如果你不想直接上某个重型框架，我可以分享一个我最近项目里用的最小方案，成本低、见效快。
配置一个向量数据库（我用的是 Qdrant，本机跑很轻量）。每个用户单独 collection。每次对话结束，用一个小模型（任何便宜的 LLM 都行）从对话中抽取“事实型记忆”和“用户偏好型记忆”，转成一行文本。给这条文本加一个元数据：用户 ID、时间戳、记忆类型、重要性评分。对文本做 embedding，存入向量库。embedding 模型我用的 bge-m3，中文效果不错，本地能跑。
每次新的对话消息进来，拿用户当前的 query 做 embedding，到向量库检索 Top 20 条记忆，然后用一个排序小模型（或者干脆用规则）按相关度和新鲜度挑出 Top 5，塞进 system prompt 里的“用户长期记忆”区块。这里的核心思想就是“该遗忘的自然遗忘”——时间一久，旧记忆在排序中自然沉底，不必显式删除。
这个方案我跑了一个月，稳定性和成本都可控。它的最大优势是“你完全知道每一条记忆是为什么进来的”，好调试、好解释。
6. 关于 Agent 长期记忆，我最后想说的几句话
做了这么多对比，我的感受是：长期记忆是 Agent 从“能聊天”进化到“能办事、能陪伴”的分水岭。没有记忆的 Agent，再强的模型也只是个聪明的应答机器——每次对话都从零开始，永远不会在往事的积累上给出更有深度的回应。而有了长期记忆的 Agent，才真正具备“越来越懂你”的可能。
人脑的遗忘并不是缺陷，而是让注意力聚焦在重要事物上的机制。
所以，设计 Agent 记忆的时候，别总是想着“记得越多越好”，而要想着“记得聪明”。该忘的要忘，该淡化的要淡化，该检索的要能精准捞出来。知识图谱、向量检索、摘要压缩，这些只是工具；真正决定你 Agent 记忆质量的，是你对“什么值得记”的判断力。多看几个项目的设计，不是为了照搬，而是为了形成自己的判断。在 Agent 这个飞速变化的领域，这种底层判断力比任何具体工具都值钱。
