做 AI Agent 开发最绕不开的一个话题就是记忆。尤其是把 Agent 从 demo 推向真实业务场景的时候你会发现模型能力再强记不住上下文、记不住用户偏好、记不住历史决策一切等于白搭。最近我系统地梳理了一遍当前主流的几个 Agent 项目的记忆设计思路包括 LangChain/LangGraph、AutoGPT、MemGPTLetta、CrewAI、MetaGPT还有 Claude Agent SDK读下来有一个很深的感受每个项目的记忆方案都不是拍脑袋想出来的而是被各自的应用场景和使用方式逼出来的。这篇文章我想把这六个项目的记忆机制拆开揉碎讲讲它们各自的存储结构、读写时机、遗忘策略、以及背后真正解决的是什么问题。无论你是在做智能客服、知识库问答还是在调教自己的自动化助手这份对比应该能帮你在方案选型时省下不少弯路。1. 先把问题说清楚Agent 的“长期记忆”到底难在哪很多人在刚开始接触 Agent 开发时会天然地把“长期记忆”理解为“多轮对话中的上下文”但这两个概念完全是两码事。对话上下文是短时状态通常存在于一次会话的窗口内模型通过把历史消息拼进 prompt 就能感知。而长期记忆要解决的是跨会话、跨任务的持续信息沉淀比如用户上个月提过的偏好、项目里沉淀过的决策背景、某次任务执行后总结出来的经验——这些东西如果每次会话都从头开始Agent 就是个没有成长能力的工具人。我在实际开发中见过不少“伪长期记忆”的实现最常见的一种是把所有历史消息一股脑存进向量数据库每次用户提问就做一次相似度检索然后把检索结果拼进 prompt。这种方案看起来很简单但跑一段时间就会翻车一是向量检索召回的片段往往没有时间概念昨天刚改的结论和三个月前的旧结论同时命中模型分不清哪个优先二是长期记忆和短期上下文在 prompt 中混在一起token 消耗越来越大回答反而越来越飘。所以说长期记忆设计的核心不只是“存储”而是存储、检索、更新、遗忘四件事的联动设计。还有一个被很多人忽略的难点是记忆的粒度。到底该记会话中的每一句话还是只记提炼后的结论是记用户画像层面的抽象描述还是记事实层面的具体条目不同粒度决定了记忆系统的复杂度。一个靠谱的 Agent 记忆方案通常会同时存在短期工作记忆和长期持久记忆两类结构不同层级各司其职。理解了这层基本盘我们再去看各主流项目的设计就会有清晰的地图感。2. 六个主流项目的记忆设计思路逐一拆解2.1 LangChain/LangGraph外置存储 可插拔组件的实用派LangChain 作为 Agent 生态里覆盖面最广的框架它的记忆设计思路前后经历过一次重要转变。早期的ConversationBufferMemory、ConversationSummaryMemory、ConversationTokenBufferMemory这些类本质上是在 Chain 内部维护一个对话历史变量每个环节显式地往里写入或读取。这个时期的方案主要面向简短的会话场景缺点也非常明显所有记忆放在内存里进程一重启就什么都没了而且记忆无法跨 Chain 共享。后来 LangGraph 引入的持久化机制才是真正值得研究的设计。它把图的状态State作为一个可检查点checkpoint序列化存储跑完每一步都可以把整个 Agent 的状态快照写入后端存储默认支持 SQLite 或者类似 Postgres 的数据库。这里主要有两件事做得很到位用thread_id作为记忆的隔离维度。同一个 thread 内Agent 能恢复之前跑过的状态继续执行实现真正的长时任务接续。把状态检查点和消息列表分离开。历史消息存在 state 中但程序逻辑并不直接拼全部消息而是通过trim_messages、filter_messages这类工具先做裁剪再进模型。这套设计的好处是灵活所有组件都能替换存储层可以接任何你想接的库坏处是它把记忆方案的选择权完全交给了开发者。项目本身的记忆模块更像是一个工具箱而不是一个开箱即用的“大脑”。我自己的体会是如果你团队里有人能花时间做二次封装LangGraph 的底子很稳但如果想开箱即用、不想自己搭存储和检索它反而会让你陷入过多的选择焦虑。LangChain 生态里还有一类值得注意的组件VectorStoreRetrieverMemory。它的逻辑是把记忆片段写进向量库查询时用相关度召回。说实话这个组件单独用在生产级项目里是不够的因为它缺少记忆合并和冲突处理的机制。但如果你只是想快速给 Agent 加一个“记得之前说过什么”的能力它仍然是最省力的起步方案。2.2 AutoGPT向量库驱动的经典记忆范式AutoGPT 是 2023 年那波自主 Agent 热潮中人气最高的项目之一它的记忆系统设计在理念上很有代表性可以说是“向量库中心制”记忆的教科书级样本。整套记忆功能主要依赖一个外置的记忆管理器后端可以接 Redis 向量库、Pinecone、Weaviate 这类存储服务核心流程可以概括为三步事件发生时Agent 把当前任务相关的关键信息写成一段自然语言文本。这段文本通过 embedding 模型向量化后写入向量库。后续需要决策时Agent 把当前目标文本向量化在库里做相似度搜索取回 top-k 片段拼进 prompt。AutoGPT 还给召回结果设置了一个相关度分数阈值只有达到阈值的记忆片段才会被采用这个细节我非常喜欢。它避免了“有点相关但实际没用”的片段污染上下文。后来新版 AutoGPT 转向了基于规划与执行的架构记忆机制在保留向量库主体的情况下增加了对执行结果的持久化沉淀。这套设计思路的优点在于简单、直观、易实现。你不需要设计复杂的记忆层级只要有一个像样的向量库就能让 Agent 拥有“想起过往”的能力。但它的短板同样明显记忆写入是“事件型”的没有对已有记忆做合并、更新、纠正。如果 Agent 在执行任务的过程中形成了对同一问题的两次不同结论两条记录会同时存在库中。检索时两条新旧冲突的信息同时被召回模型很容易精神分裂。这个问题在 AutoGPT 的早期试用中非常常见也是后来我做记忆方案时坚决避免“只写不改”的关键原因。2.3 MemGPTLetta把操作系统虚拟内存搬进 Agent 的设计MemGPT 是这六个项目里在记忆机制设计上最有理论野心的一家。它的思路直接借鉴了操作系统里的内存层级管理主内存main context相当于模型有限的上下文窗口外部存储external storage相当于磁盘一个“内存管理器”负责在主存和外部存储之间搬运数据这个过程对应操作系统里的分页和换页。MemGPT 的记忆结构分两块一块是固定管理信息包括人物设定、记忆管理指令、工具函数定义另一块才是真正可读写的数据区包含对话历史、用户事实、业务信息等。当上下文快满时内嵌的管理器会自主启动“换出”操作把一些底层对话记录压缩成摘要存档同时腾出空间来载入当前任务更相关的长期记忆。整个过程对用户来说是无感的Agent 会以函数调用的方式触发这些记忆操作看起来就像在自主管理自己的大脑。这个设计最打动我的地方是它把“上下文压缩”和“记忆迁移”做成了有意识的自主动作而不是简单地拼接历史文本。传统的记忆方案是“用多少取多少”MemGPT 则是在“取的同时主动整理”。它对应的代价是实现复杂度明显更高因为需要设计一套专门的控制逻辑来调度自更新操作且必须保证这些控制指令不会干扰业务主流程。实际使用 Letta 时最明显的感受是它适合那些需要长期陪伴属性的场景比如个人助手、情感陪聊机器人——这种场景里有大量细碎但长期的用户信息要维护正是 MemGPT 的用武之地。2.4 CrewAI实体记忆与任务级记忆的分层智能CrewAI 是一个主打多角色协作的 Agent 框架它的记忆设计有一个非常鲜明的特点不是简单区分短期和长期而是把记忆分成了短期记忆、长期记忆、实体记忆三个层次。这种分层让 Agent 既能记住任务执行过程中的临时上下文又能沉淀跨任务的长期经验还能专门记录“关于某个对象的事实”。具体来说CrewAI 的短期记忆服务于当前任务执行过程保存最近的任务结果和状态保证 Agent 在同一任务的多个步骤之间能保持连贯。长期记忆则基于任务完成后的总结来沉淀每次跑完一个任务框架会生成任务的结果描述把有价值的部分写进长期存储。实体记忆Entity Memory是最特别的一层它专门抽取与业务相关的实体及属性信息比如人员、项目、组织、设备等存储并查询“这个实体是什么、有什么特征、跟我有什么关系”这类事实。执行下一个任务时CrewAI 会从三个记忆层中分别检索相关片段再注入上下文。CrewAI 的默认存储实现是基于 SQLite保存短期和实体记忆加 ChromaDB 向量库保存长期记忆文本开发者也可以把后端切换到 Postgres 等更成熟的存储。这套设计的思路是“为不同性质的记忆选择合适的保存格式”——结构化事实存表格数据库非结构化经验存向量库临时状态存轻量库。对应到真实项目如果你在做一个 CRM 智能助手实体记忆能高效地回答“这个客户上次反馈了什么问题”长期记忆能回答“我们对这类客户一贯的处理策略是什么”短期记忆负责当前轮到哪一步了。这种划分显然比单一向量库方式更细实现上也要多维护一套存储系统初期配置会绕一些但后期收益非常明显。2.5 MetaGPT共享消息池里的协作记忆MetaGPT 和前面几个项目走的路线差别很大。它是一个以“软件公司”为隐喻的多智能体协作框架把产品经理、架构师、工程师、项目经理这些角色抽象成不同的 Agent。在这个框架里长期记忆不再是某个 Agent 的私有记忆而是整个团队共享的“公司记忆”——一套基于消息池Message Pool的发布/订阅机制。所有 Agent 产出的内容比如需求文档、接口设计、代码文件、测试报告都会以消息的形式写入共享的消息池。每个 Agent 启动时订阅与自己职责相关的消息类型比如架构师只关注产品需求文档工程师关注接口设计文档。发布/订阅机制让每个角色都能在合适的时机获取它需要的上游信息而不是每次都要从头开始把所有消息都读一遍。这个机制背后是一套“角色-动作-消息”的循环每个 Agent 的产出都是结构化的消息整个流程天然具备可回溯性和可审计性。MetaGPT 的记忆设计本质上是在解决协作场景中最大的痛点信息同步成本。在真实的多 Agent 协作中如果每个 Agent 都维护一份私有记忆很容易出现信息不对齐和重复劳动。共享消息池的优势在于所有记忆对全团队可见但代价是消息池会膨胀得非常快项目稍微复杂一点消息数量就非常可观。MetaGPT 用的办法是让每个 Agent 通过 “订阅关注” 来过滤信息流只处理跟自己职责相关的消息从机制上限制了记忆检索的广播范围。这个思路非常值得学习尤其如果你在做一个多角色、多流程的企业级 Agent 系统建议认真参考它的消息池设计而不是别让每个 Agent 各自为战。2.6 Claude Agent SDKClaude Code以人和项目为中心的轻量级记忆Claude Agent SDK 是 Anthropic 推出的编程与任务代理框架它在记忆上的设计跟 LangChain、AutoGPT 这类“社区方案”有本质的不同Claude Agent SDK 选择把记忆的形态绑定在“文件”这种最朴素但最稳定的载体上。核心的记忆载体是 CLAUDE.md这是一个位于项目根目录的文本文件开发者可以在里面用 Markdown 写明项目背景、技术栈选择、编码规范、常用命令、注意事项等信息。Claude 在启动时会自动读取 CLAUDE.md 作为系统上下文的一部分。这个机制本质上就是“把项目知识固化到项目本身”新会话启动时无需检索历史的对话记录直接通过读取文件就获得项目级别的长期记忆。这里面的思路很值得玩味对于编程助手这个场景真正持久的记忆其实不是“和 AI 说过什么”而是“这个项目的客观约束和偏好”。所以它用文件承载记忆天然地具备跨会话、跨机器迁移、可版本控制、可人工审计的能力。后来 Anthropic 还引入了用户级的全局 CLAUDE.md放在用户配置目录用于保存跨项目的个人偏好这样在启动任何一个项目时Agent 都能保持统一的个人风格再叠加 Skills 机制把常做的复杂任务沉淀成可复用的技能包。这套设计的适用场景非常聚焦编程、运维、技术任务自动化或者说偏“项目型”的 Agent 工作流。它的最大优势是轻量、透明、易维护——任何用户都能一眼看到 Agent 的“记忆内容”不存在黑盒。但如果你把 Claude Agent SDK 用在一个需要连续多轮、自由对话的业务场景比如客服、销售助手它这套文件式记忆就不太够用了因为它本质上没有对话级的历史沉淀也不做相似度检索只靠静态文件承载所有长期上下文。3. 六个方案横向对比存储、检索、更新与遗忘把六个方案放在一张表里看能直接感受到不同设计哲学的差异。项目核心记忆模型存储介质写入时机检索方式遗忘/更新策略LangChain/LangGraph状态检查点 可插拔内存模块SQLite/Postgres/Redis/向量库每步状态变更或显式调用基于 thread 的状态恢复 相似度检索手动裁剪、消息过滤、可自定义AutoGPT事件型向量记忆Redis/Pinecone/Weaviate 等任务事件发生时写入向量相似度 top-k 相似度阈值基本无遗忘冲突记忆共存MemGPT(Letta)主内存 外部存档分层向量库/数据库 上下文窗口对话过程中自主调用来写入/迁移记忆管理器自主检索 上下文内载入主动换出、摘要压缩、永久存储归档CrewAI短期/长期/实体三层记忆SQLite ChromaDB 或 PG任务执行中存入短期、任务结束沉淀长期三类检索结果注入上下文短期待清理、长期可持续写入MetaGPT团队共享消息池消息队列/数据库各 Agent 完成产出后写入发布/订阅 职责订阅过滤消息池增量膨胀依赖过滤机制控制视野Claude Agent SDK文件式项目记忆项目/用户级 Markdown 文件用户手动编辑或会话中自动更新会话启动时静态载入人工编辑为主透明可追责这张表看完就会发现六个项目的思路其实分布在一个很宽的谱系上从最轻量的人工维护文件到最复杂的自主管理分层记忆各有各的取舍。LangChain 是“工具箱”把选择权交给你AutoGPT 是“最经典的向量库方案”起步快但要自己补冲突更新MemGPT 是“操作系统派”适合需要长期陪伴的任务CrewAI 是“实体中心派”适合业务实体驱动的应用MetaGPT 是“协作共享派”适合多角色协同Claude Agent SDK 则是“项目知识派”在编程这个特定场景里效率极高。没有哪个是“全能的终极答案”关键要看你的使用场景里记忆到底是“个人的”还是“协作的”是“自由对话型”还是“任务执行型”是“轻量可解释”重要还是“自主自动”重要。4. 实操选型与设计建议如何搭一套靠谱的长期记忆系统做完了六个项目的拆解回到一个更现实的问题如果现在让我从零设计一个带长期记忆能力的 Agent我会怎么搭先给一个筛选原则先明确记忆的“消费者”是谁。如果只有单个 Agent 自己消费记忆选 LangGraph 状态检查点加向量库就行如果是多角色协作共享消息池的设计可以参考 MetaGPT如果产品核心是“记住用户这个人”实体记忆和 MemGPT 的结构更值得借鉴如果是在编码场景里落地那 Claude Agent SDK 的思路反而是投入产出比最高的。在实际开发中我建议把记忆系统拆成四层来设计无论你选择哪个框架存储层结构化信息用户属性、任务状态用关系型数据库或 KV 存储非结构化信息对话记录、经验总结用向量库。写入层定义什么信息值得写入记忆。不是所有对话都要记只有涉及用户偏好、决策结论、事实变化的片段才需要提炼入库否则你的库会被噪音淹没。检索层设计分层召回策略。先查结构化信息再查短期上下文最后查向量记忆按需组合。更新/遗忘层这是最容易被忽略的一层。旧记忆必须支持更新和淘汰不然 Agent 越用越“糊涂”。一种方案是按时间衰减另一种方案是记录冲突时以后写入为准。我自己的一个经验是不要把记忆系统想成“模型只能用得上的信息”而要把它想成“业务状态的一部分”。做 Agent 记忆设计底层逻辑和做传统后端系统很接近——先定义数据模型再决定读写接口最后才考虑模型怎么消费数据。很多项目翻车都是因为一上来就直奔向量检索把“记忆”等同于“有多少条文本可以被搜索到”结果就是 Agent 表面上记得很多实际上没有一个信息是可依赖的。另外一个值得单独说的是 token 成本问题。把历史记忆全量塞进 prompt短期看似简单长期一定会让你承担巨大的 API 成本和时间延迟。我在实际项目里常用“三段式”来管理上下文核心指令 与当前任务强相关的记忆片段带时间戳 必要的历史摘要。在这三层里第三层通常承担了 70% 以上的“长上下文”负担所以要设计一个摘要更新机制——每当上下文超过预设长度就把最近的对话压缩成更精炼的摘要替换掉旧的详细记录。这种玩法本质上就是在手动复刻 MemGPT 的换页机制只是用业务逻辑来触发而已。5. 常见问题与避坑清单记忆系统上线后最容易踩的五个坑抛开理论层面的讨论最后把我在真实项目里反复遇到过的问题挑几个最常见的拿出来聊聊每一个都对应了一条真实的踩坑经历。第一个坑检索召回一堆“旧记忆”把新结论覆盖了。解决方案是在记忆条目上打时间戳和来源标识检索时把时间作为排序因子或加入一个“最近更新优先”的权重。如果框架不支持这个能力就自己在写库的时候加一个updated_at字段检索结果里按时间做二次过滤。第二个坑记忆体越跑越胖。不少人的 Agent 跑了一周之后向量库里攒了几万条记录每一次请求都要做一次全库搜索。我的做法是给记忆建立分层归档机制超过一定时间且没有被高频访问的条目转入冷存储不进常规检索范围。这就像整理办公室常用资料放桌面不常用的进档案柜。第三个坑多会话之间的记忆串线。如果你有多个用户或业务线共用一套存储而没有在每条记忆上绑定user_id/thread_id很快就会出现“A 用户的偏好被 B 用户看到”的尴尬场景。尤其要注意向量库里的元数据过滤一定要做好权限隔离这一步做不好长期记忆系统根本没法面对真实用户。第四个坑调试困难Agent 自己不知道为什么做出某个决策。记忆耦合进 prompt 后就成了“隐性上下文”一旦出错很难定位。我在开发中养成了“可观测性优先”的习惯每次模型调用前都会把本次注入的记忆片段打印成日志记录是哪几条记忆、来自哪个存储层、命中分数是多少。这样出了问题能直接定位是检索召回的问题还是模型理解的问题。第五个坑信息和模型能力不匹配。不是所有记忆都适合塞进 prompt 让模型自己理解。我踩过的比较深的一个坑是把详细的业务表格数据直接向量化存在库里结果检索回来一堆字段名模型根本不知道这些字段怎么关联。正确处理方式是先做一个结构化摘要比如把客户信息整理成 “客户名/行业/最近买过啥/上次投诉原因” 这类短句再向量化存储。记忆检索面向的是 LLM 的语义理解不是数据库查询这一点要想清楚。6. 写在最后的个人体会六个项目看下来我最直观的感受是记忆设计本质上是产品设计而不是单纯的技术方案。技术选型永远服务于你希望 Agent 成为一个什么样的角色。如果你希望它像一个得力的同事那就要让它能共享团队上下文参考 MetaGPT 的协作记忆如果你希望它像一个贴心助理那就要让它理解你的长期偏好参考 MemGPT 或 CrewAI 的实体记忆如果你只是想让一个编码助手别忘项目规范Claude Agent SDK 一个 Markdown 文件就足够了压根不值得为它搭一套向量库。从我个人实操的角度建议第一次做 Agent 记忆系统的朋友先别急着追求复杂的自更新记忆用一个最简单的方案结构化信息落库、非结构化信息落库加时间戳、上下文摘要定期压缩。跑通这三点再逐步引入实体抽取、冲突消解、主动遗忘这些高级机制。记忆系统的复杂度永远应该跟着业务复杂度的需求走而不是跟着新潮技术走。这样你的 Agent 才能越来越聪明而不是越来越臃肿。