Agent长期记忆方案对比：六大主流框架的记忆机制与选型指南-北京尧图网络

1. 先聊清楚Agent 的“记忆”到底难在哪如果你上手写过几个 Agent一定会碰到这个场景对话刚开始Agent 表现得像个聪明的助手上下文里塞了多少信息都能记住。但聊着聊着它就开始“失忆”——用户五分钟前告诉它的偏好、半个钟头前让它记住的任务状态统统丢得一干二净。这不是模型笨而是 Agent 的对话上下文本质上是一次性的每次调用大模型接口传进去的只有当前这段窗口里的内容窗口之外的东西模型一概不知。更麻烦的是很多 Agent 应用不是“聊完就走”而是需要长期陪伴比如个人助理要记住用户的工作习惯客服机器人要沉淀用户的历史工单代码助手要记住项目里那些“约定俗成”的命名规范。这些场景下短期上下文窗口根本扛不住模型输入长度有限塞进去太多历史消息既费钱又容易把关键信息挤掉。于是“长期记忆”就成了 Agent 工程化绕不开的一环。我最早踩这个坑是在做一个内部文档问答机器人。一开始天真地以为把全部历史记录都拼到 prompt 里模型就能“记得住”。结果不到两百轮对话token 费用直接爆炸而且回复质量肉眼可见地下降——大量无关历史把有效信息稀释了。后来才意识到长期记忆不是“把东西都塞进上下文”而是“在需要的时候把对的东西取回来”。这一下就把问题从“模型能力”变成了“工程架构”。这篇文章就把我研究过的六个主流 Agent 项目的记忆方案拉出来做个横向对比LangChain / LangGraph、MemGPTLetta、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 的代价也很直接你需要额外部署和维护一个服务有学习成本而且知识图谱的构建需要消耗模型调用。对于大团队、高复杂度场景这是划算的对于一个小脚本或者原型 DemoZep 属于杀鸡用牛刀。4. 横向对比六种思路放在一张表里谁更适合什么场景先把六个项目的核心特性整理成一张表方便你对照着看。项目核心记忆思路记忆类型覆盖存储介质自定义程度适用场景LangChain / LangGraph显式 Memory 模块状态 Checkpoint短期、工作记忆为主SQLite / Postgres / Redis高需自行设计状态驱动的复杂多步 Agent 流程MemGPT / LettaOS 式虚拟内存换入换出模型自主管理短期、长期、核心记忆全覆盖内存向量库中高但模型决策有不确定性长期陪伴型 Agent、研究原型CrewAI四类记忆拆分围绕多 Agent 协作短期、长期、实体、情景记忆向量库内存中框架封装较多多角色协作团队型 AgentAutoGPT任务关键信息提取向量库语义检索长期任务记忆为主向量库中依赖提取质量自主任务执行链较长的 Agent 实验SuperAGI可插拔存储元数据管理定期压缩短期、长期Redis 向量库中高需要灵活搭配存储后端的 AgentZep独立服务知识图谱语义检索长期记忆、实体记忆最突出自建服务 / 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 这个飞速变化的领域这种底层判断力比任何具体工具都值钱。

Agent长期记忆方案对比：六大主流框架的记忆机制与选型指南

相关推荐

从SEO到GEO：生成式AI时代的内容优化转型

ERP-MES文件型接口设计：制造指图抽出与实绩计上落地要点

如何正确理解与使用项目标题生成技术博文

更多资讯

游戏安全攻防技术：从内存修改到AI防御实战

OpenClaw容器化部署与Docker生产环境实践指南

MySQL 8.0 JDBC驱动使用指南与优化实践

SQLite下载安装与连接实战：从环境配置到报错排查

游戏安全攻防：从原理到实践的全面防护策略

Web性能检测与优化：核心指标与实战技巧

今日更新

猫狗目标检测数据集：VOC/COCO/YOLO三格式一体化实战包

HDU2017多校标程复现：算法竞赛工程化真题沙盒

Codex Sandbox 隔离环境拆解：AI Agent 的临时实验室如何运作

本周精选

防幻觉智能体架构：电源硬件设计中的大模型编排与工具化实践

OpenGL面试核心考点：渲染管线、矩阵变换与性能排查全解析

全国计算机二级C语言真题PDF高效刷题指南

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？