Agent长期记忆方案深度拆解：六个主流框架横向对比与选型建议

先交代一下背景：最近团队里好几个项目都卡在了同一个地方——Agent 一聊长就“失忆”，要么把前几轮说过的话当耳旁风，要么把旧信息和新指令搅在一起，输出质量肉眼可见地滑坡。我花了两周时间，把市面上叫得上名字的六个主流 Agent 项目翻了个底朝天，专门对比它们在“长期记忆”这件事上的设计思路。这篇文章就把我的拆解笔记整理出来，希望能给正在选型或者准备自己搭记忆模块的朋友一点参考。

先把结论放在前面：长期记忆不是“存得越多越好”，而是“在正确的时间，把正确的信息，以正确的形式，喂给正确的模型调用”。六个项目没有绝对的好坏，它们的设计差异本质上是“记忆的获取方式”“记忆的存储形态”“记忆的召回策略”三个维度的不同排列组合。

1. 长期记忆到底难在哪

先别急着看方案，得先把问题定义清楚。很多开发者把长期记忆简单理解成“历史消息存起来，下次拼进 System Prompt”，这个思路在 demo 里够用，一上真实业务就崩。

1.1 “记不住”的三个技术成因

第一个原因是上下文窗口的物理限制。哪怕当前最强的模型支持百万级 token 的上下文，实际使用中也没人敢真的把全部历史都塞进去。成本先不谈，模型对超长上下文的注意力会稀释，中后段的信息召回率肉眼可见地下降。这不是模型“笨”，而是 Transformer 架构在超长序列上的固有能力边界。

第二个原因是信息噪声问题。真实对话里大量内容是寒暄、确认、重复表达，真正对后续任务有指导意义的“关键事实”可能只占 5%。如果把全部历史丢给模型，等于让模型在垃圾堆里找钻石，找得到是运气，找不到是常态。

第三个原因是时效性问题。用户昨天说“我喜欢喝美式”，今天可能就改口“现在只喝手冲”。记忆如果不做时效管理和更新机制，过时信息就会变成误导信息，比没有记忆还要糟糕。

1.2 一个合格的记忆系统该有什么

把问题拆开之后，我梳理出一个记忆系统至少要解决的四件事：

• 写入：什么信息值得记？怎么从对话流里抽取关键事实？
• 存储：以什么结构存？纯文本、键值对、向量、还是结构化数据库？
• 召回：每次对话时怎么把相关记忆捞出来？全量塞还是按相关性筛？
• 更新：旧记忆怎么淘汰？新信息和旧记忆冲突时听谁的？

六个项目看了下来，你会发现每个团队在这四个问题上的取舍都不一样，这就是它们设计思路的分水岭。下面一个个拆。

2. 六个主流项目的记忆方案逐一点评

2.1 LangChain / LangGraph：框架派的模块化集成

LangChain 的思路非常典型——我不自己发明记忆，我把记忆变成插件。它提供了ConversationBufferMemory、ConversationSummaryMemory、ConversationBufferWindowMemory等一堆内置类，开发者自己选，选完往里一插就能用。

早期的 LangChain 记忆模块我用过，说实话比较“玩具”。ConversationBufferMemory就是把历史消息原封不动拼进 Prompt，token 一多就爆，基本只适合教学场景。ConversationSummaryMemory好一点，会用 LLM 把旧对话压成摘要，但摘要能力取决于调用的模型，摘要太粗会丢细节，太细又起不到压缩作用。

真正让我觉得 LangChain 想明白了的，是后来 LangGraph 里的持久化检查点（Checkpointer）机制。它的思路是把对话状态存进数据库（默认 SQLite，可以换 Postgres、Redis），每次 Agent 运行到这个节点就把完整状态快照存下来。这个设计比“拼 Prompt”高明在哪？它把记忆从“输入组装”变成了“状态管理”——Agent 的每一步都能从检查点恢复，无论是崩溃恢复还是多轮对话续聊，都只要读取状态、继续执行流程图就行。

LangGraph 的MemoryStore则在更上层做了一个基于命名空间的记忆池，支持语义检索和自定义存储后端。我用下来的感受是：LangChain 系的记忆方案胜在灵活、生态全，但代价是你得自己决策用哪种记忆、怎么配存储、怎么设检索阈值，框架给的是积木，不是成品。

2.2 MemGPT / Letta：理论派的虚拟上下文管理

MemGPT（后改名 Letta）是我个人最欣赏的一个项目，因为它把“记忆”从工程问题提升到了系统设计层面。它的核心灵感来自操作系统的虚拟内存：物理内存不够用，就把不活跃的页换到磁盘，要用时再换回来。对应到 Agent 上就是——上下文窗口是“物理内存”，外部存储是“磁盘”，模型自己决定哪些信息要换入换出。

MemGPT 的自定义记忆结构特别值得细看。它把记忆分成三个层次：核心记忆（比如用户的名字、偏好这种永远该在上下文里的信息）、工作记忆（当前任务进行中的临时信息）、外部存储（归档的历史对话，按需检索）。

这个设计妙在引入了“记忆管理事件”。模型不是每次对话都盲目把所有历史捞出来，而是在适当时机触发heartbeat（主动思考是否需要管理记忆）、function call（调用检索或归档工具）、context window warning（上下文快满了，需要压缩）。也就是说，记忆的管理时机是模型自己判断的，而不是开发者写死“每次对话都拼最近 N 轮”。

我拿 MemGPT 做过一个长篇小说辅助创作 Agent。写到第 30 章时，它能自动把前面 20 章的人物设定压进核心记忆，把具体情节归档到外部存储，需要调用时再精准检索回上下文。这种体验是传统“拼历史”方案给不了的。代价也很明显——这套机制设计复杂，触发逻辑对模型能力有要求，用小参数模型跑容易频繁误触发，反而浪费 token。

2.3 AutoGPT：先驱派的记忆进化史

AutoGPT 作为 2023 年那个现象级开源项目，它的记忆方案演进其实很有代表性。最早版本根本没有长期记忆，全靠把所有历史塞进 Prompt，上下文窗口一满就崩。后来项目组意识到这不行，先后尝试了两个方向。

第一个方向是Pinecone 向量记忆插件，思路很直白：对话过程中的重要信息切片 → 转成 embedding → 存进 Pinecone 向量库。每次执行任务先去向量库检索 top-K 相关片段，再拼进 Prompt。这是当时最标准的“向量数据库+RAG”路线，跟今天大多数人做的记忆方案是一个套路。第二个方向是集成 MemGPT 作为记忆后端，借助 MemGPT 的虚拟上下文管理来解决遗忘问题。

AutoGPT 这段历史给我的启发是：先驱项目踩过的坑，后来者一个都躲不掉。今天你在生产环境里遇到的上下文爆炸、记忆召回不准、embedding 切分粒度难定，AutoGPT 在 2023 年就全踩过一遍了。它现在在普通 Agent 业务里用得不多，但作为“记忆方案进化史”的样本，参考价值极大。

2.4 CrewAI：多 Agent 协作中的记忆编排

CrewAI 走的是另一条路——记忆不是给单个 Agent 用的，而是给一群分工明确的 Agent 共享的。它把记忆分成了三类：短期记忆（存在 Crew 内部，任务结束就清）、长期记忆（存到 SQLite，跨 Crew 持久保留）、实体记忆（提取关键实体及属性，类似知识图谱的雏形）。

我上手 CrewAI 第一感觉是“它是真干了活的”。短期记忆解决多 Agent 协作时上下文同步的问题——研究员 Agent 发现的线索要传给写作者 Agent，不是靠两个 Agent 互相“猜”，而是通过 Crew 级的记忆池中转。长期记忆保存的是“这类任务我们以前是怎么解决的”，下次跑同类型任务时可以参考历史最优方案。实体记忆则能把“客户 A 的偏好是 X”这种结构化信息单独维护。

一个值得借鉴的小细节是 CrewAI 的实体记忆设计。它用 LLM 做实体抽取，把非结构化文本转成实体-属性-值的三元组形式存储，规避了向量检索“语义相近但事实不同”的问题。打个比方：向量检索可能把“用户喜欢美式咖啡”和“用户讨厌美式咖啡”都召回进来，但实体记忆的结构化查询只会精确返回“偏好=美式”。在处理高确定性事实时，结构化存储比向量检索靠谱一个量级。

CrewAI 记忆方案的局限在于它默认绑定自家的 SQLite 存储，大规模并发场景下写入性能会成瓶颈。不过它对单机多 Agent 协作的中小型项目来说，性价比非常高。

2.5 Dify / Coze：平台派的黑盒便捷

Dify 和 Coze 这类平台级产品，把长期记忆从“代码”变成了“配置”。你不用写一行记忆管理代码，在可视化编排界面里勾选“对话记忆”“知识库”，平台自动帮你完成历史消息存储、向量化、相似度召回。对业务方来说，确实是零门槛。

但黑盒也有黑盒的代价。我在 Dify 上做过一个客户支持 Agent，发现它的会话记忆默认策略是“把最近 N 轮对话全额保留 + 超长自动截断”，没有摘要压缩和关键信息抽取的中间层。这意味着对话一超过截断阈值，前面的信息就硬断掉了，用户 10 分钟前说过的关键需求可能就丢了。

平台派目前的记忆能力大概是“可用但不够聪明”的水平。它能帮你撑住常规客服、知识问答这类场景，但别指望它在“需要连续多轮获取信息并精确永记”的复杂任务上有出色表现。平台派的隐藏优势是服务端存储——用户关掉浏览器、换个设备回来，记忆还在，这对 C 端产品是刚需。

2.6 OpenAI Agents SDK / Claude Agent SDK：官方派的极简主义

这半年观察下来，两家官方 SDK 在记忆上的设计思路惊人地一致——都不做自带长期记忆方案，而是把记忆的主动权交还给开发者。

OpenAI Agents SDK 里有一个Session概念，它管的是单次会话的状态隔离，不是跨会话的长期记忆。你要做长期记忆，官方推荐的做法是通过instructions动态组装：每次对话前，你自己去外部数据库查一下用户相关的历史信息，拼进新的指令里。Claude Agent SDK 也类似，它的记忆模式就是将对话历史作为上下文传入，超过上下文窗口就得自己想办法切分和压缩。

我最初觉得这是“偷懒”，做过几个项目后发现这恰恰是最清醒的设计。长期记忆是个高度业务相关的需求——客服场景要记订单号，写作场景要记人物设定，编程场景要记项目架构。这些记忆的抽取规则、存储结构、更新策略全都不同，官方与其给一个通用但不顶用的方案，不如把这块完全开放，让开发者在应用层自己掌控。

代价就是要多做很多底层工作。你起码得自己实现“抽取摘要 → 向量化 → 存储 → 召回”这条链路，好在用 LangChain 或者自己维护一个记忆服务都行。

3. 六个项目横向对比速查表

这节直接给硬货，六个项目的记忆能力我拉了一张对比表，从存储介质、记忆类型、召回机制、上下文管理策略、时效性支持、适合场景六个维度打分。看完可以直接对着自己的业务场景找答案。

从这张表能读出一个趋势：记忆方案正在从“全量塞”走向“按需取”，从“通用方案”走向“业务定制”。六年前大家还在纠结上下文窗口不够用怎么办，现在比拼的是谁能在窗口之外构建更聪明的记忆调度系统。

4. 实操中的选型建议与避坑经验

看完对比，最现实的问题肯定来了：我到底该选哪个？这里结合我自己的项目经验，按典型场景给一套选型参考。

4.1 三种场景下的方案推荐

如果你做的是多轮对话客服、电商导购这类 C 端产品，我建议优先考虑 Dify / Coze 这类平台，或者直接自建“向量库 + 摘要压缩”的轻量方案。这类场景用户信息密度低，核心记忆就是订单状态、退换货偏好、沟通历史，用最朴素的“会话 ID 拉历史 + 向量检索关键事实”就够了。我在实际项目中用的是“最近 5 轮全量 + 历史摘要 + 关键实体表”三层结构，效果稳定，成本可控。

如果你做的是多 Agent 协作的复杂工作流（比如研究分析、报告生成、跨模块任务拆解），CrewAI 的三层记忆结构是目前最省心的方案。它的实体记忆对“谁负责什么、结论是什么、进度到哪了”这类协作信息管理得非常到位，省掉了自己设计共享记忆协议的麻烦。

如果你做的是长周期、高个性化阈值的深度 Agent（比如虚拟角色、写作助手、私人教练），建议认真研究 MemGPT / Letta 的层次化记忆思路。这类场景的痛点不是“记不住”，而是“记不准”——既要保留长期性格设定，又要吸收短期交互细节，还要在信息冲突时知道该听谁的。MemGPT 的核心记忆+工作记忆+外部存储三层模型，加上模型自触发换入换出，是目前最贴合这个需求的公开方案。

4.2 自己动手做记忆时最容易踩的四个坑

如果决定自建记忆模块，我先帮你把几个高频坑提前标出来。

第一个坑是切分粒度拍脑袋。做向量检索时，文本块切多大直接决定召回效果。切太大，单个块里噪声多；切太小，语义不完整。我自己的经验是中文场景以 200~300 字为基准块，按语义边界（段落、子标题）切，同时在块与块之间保留 10%~15% 的重叠，避免语义被切断。

第二个坑是只存不更新。很多人的记忆模块是只写的，用户说完就存，存了就不管，时间一长库里全是过时信息。我现在的做法是给记忆打两层时间戳——写入时间和最后访问时间，系统定期扫描，超过 N 天未访问的弱相关记忆自动降权或者归档。记忆贵在质量，不在数量。

第三个坑是召回策略一刀切。默认 top-k 检索在简单场景能用，一旦业务复杂就露馅。比如用户问“我刚说的那个项目报价是多少”，你其实只需要最近一轮对话的信息，根本不用去向量库捞。我现在的策略是先按“对话轮次新鲜度”筛一遍，再对筛出的候选做向量相关性排序，双路召回比纯向量检索稳得多。

第四个坑是忽略指令权限设计。用户应该是可以主动管理记忆的，但实际做的时候往往默认用户无权删除纠错，一旦记错就成“永久性脑损伤”。我的建议是在记忆写入接口上默认开放一个“用户可纠错”的入口，用户说“不是这样”的时候，Agent 要能把旧记忆标记为废弃，而不是傻乎乎地又存一条冲突记录进去。

5. 日常运行中的典型故障与排查思路

5.1 上下文明明还很短，Agent 却“失忆”了

症状：对话才维持了七八轮，Agent 就把前面说过的关键信息忘了。排查思路：先查看每次请求实际拼进 Prompt 的内容。我遇到过好几次这类问题，最后发现是会话 ID 传递链断了——前端每次请求生成了新的 session ID，后端查不到原会话的记忆，Agent 当然就“失忆”了。解决方式：对会话 ID 做全链路 log 追踪，确认从客户端到记忆服务都是同一个 ID。

5.2 向量检索召回了大量无关内容

症状：语义检索出来的记忆片段看着相关，实际跟当前问题一点关系都没有。排查思路：大概率是 embedding 模型选得不对或者文本切分粒度太大。中文领域我建议优先用中文语料预训练的 embedding 模型，而不是通用多语言模型。其次检查切分块是否混入了多个主题——一个记忆块里只能有一个主题，这是底线。解决方式：主题聚类逻辑加上，每个块独立校验主题纯度。

5.3 记忆库越攒越大，召回越来越慢

症状：项目跑了两三个月，记忆库体积暴涨，向量检索延迟肉眼可见地增加。排查思路：先看是不是写入了大量低价值的重复记忆。我在项目中见过最离谱的情况是同一用户把“今天心情不错”类似的情绪记录存了 200 多条，完全没意义。解决方式：部署一个轻量级的记忆去重和摘要合并 Pipeline，定期对相似记忆做合并压缩，同时给记忆库设置 TTL，超过生命周期的直接归档到冷存储。

5.4 多 Agent 之间记忆互不可见

症状：用 CrewAI 或者自研多 Agent 架构时，A Agent 记录的信息 B Agent 完全看不到，协作链路断掉。排查思路：检查记忆的读写权限是否绑定到了特定 Agent。很多多 Agent 框架默认记忆是以 Agent 维度隔离的，需要主动打开跨 Agent 共享。解决方式：在设计初始就确定记忆的可见范围——是全局共享池、按任务组共享、还是完全隔离，别等项目跑起来再改，改造成本极大。

6. 关于记忆方案选型的一个私人结论

六个项目拆完，我自己最大的感悟是：别迷信任何一个框架的记忆能力，也别指望“加个向量库就等于拥有长期记忆”。长期记忆的本质是信息生命周期管理——从产生、写入、存储、更新、召回、到淘汰，每个环节都要能感知业务语义。框架给你的是基础设施，真正决定记忆质量的，是你对自己业务场景中“哪些信息值得跨轮次存留”的理解深度。

如果你现在刚起步，我的建议是先别上重框架，用最笨的“全量历史 + 简单摘要”跑通业务，等你真的感受到遗忘带来的产品问题，再去研究 MemGPT 的层次化设计、CrewAI 的实体抽取、LangGraph 的状态持久化。到那个阶段，你看这些框架的眼光会完全不同——它们不再是“别人的方案”，而是你手里的工具箱。

最后再分享一个小技巧：不管最后选哪个方案，一定在项目初期就做好记忆模块的日志和可视化调试面板。记忆这东西是出了名的难调试，模型不会主动告诉你“我刚才没找到那条记忆”。有了完整的记忆读写日志，你就有了排查一切的抓手。这一点，我在好几个项目里都被反复验证过，值回票价。