大模型 Agent 记忆系统深度调研：从范式之争到「Agent 原生记忆」
先把「Agent 记忆系统」讲清楚
大模型本身是没有记忆的。每次调用，它只能看到你这次塞进”上下文窗口”(context window)里的那点文字，聊完就忘。所谓”记忆系统”，就是在模型外面挂一个独立的数据管理系统：把历史对话、工具执行结果、环境观察这些东西存下来，在下一次需要时，再挑出相关的部分重新塞回模型的上下文里。
用一句大白话打比方：
大模型像一个失忆但很聪明的临时工，每天上班前你得把相关资料摊在他桌上他才知道怎么干活。记忆系统就是那个帮他归档资料、并在他需要时精准抽出正确那几页的助理。这个助理干得好不好，直接决定这个临时工能不能胜任”长期项目”。
论文给了个更准的定义：记忆系统是 agent 的数据管理系统(data management system)，负责在”单次推理”之外持久地存储、检索、更新、整合信息，并管理其整个生命周期，和模型的”参数权重”与”易失的上下文窗口”是解耦的。
为什么这事现在突然重要？ 因为 agent 要”长跑”。一个只聊三五轮的 chatbot，把全部历史直接塞进上下文就行（这叫 Long Context 基线）。但一个要连续工作几小时、跨几十个会话、边做边学的 agent，如果记忆层设计得烂，就会出现三种灾难：前后事实自相矛盾、灾难性遗忘、延迟和成本高到不可用。记忆层的可靠性和效率，基本决定了 agent 能力的上限。
把记忆系统拆成四个模块
市面上的记忆项目五花八门，论文最大的贡献，是提出一个统一的拆解框架，把任何一个记忆系统都拆成四个可以独立分析的模块。记住这四个模块，再看任何一个新项目，都能看清它在哪个环节做文章。
flowchart LR
subgraph W[写入路 Write Path]
E[② 抽取 Extract<br>从原始对话里挑该记的]
S[① 表示 & 存储<br>按什么结构存]
E --> S
end
subgraph R[读取路 Read Path]
Q[③ 检索 & 路由<br>来了问题去哪捞]
B[回灌给模型<br>塞回上下文]
Q --> B
end
S -.-> Q
M[④ 维护 Maintenance<br>后台整理:合并/去重/更新/遗忘]
M -.-> S| 模块 | 干的事（大白话） | 关键设计选择 |
|---|---|---|
| ① 表示与存储 | 记下来的东西长什么样、存哪 | 存纯文本？存成树？存成知识图谱？存向量库还是图数据库？ |
| ② 抽取 | 从一大段对话里，挑哪些内容值得记 | 全存原文？LLM 提炼成摘要？按主题切段？ |
| ③ 检索与路由 | 来了个新问题，去哪捞、怎么捞 | 语义相似度匹配？关键词？图上遍历？要不要先”规划”再捞？ |
| ④ 维护 | 后台悄悄整理记忆库 | 新事实来了怎么覆盖旧的？多久整理一次？整理范围多大？ |
术语小注
- 向量 / embedding 检索：把每句话压成一串数字坐标，意思相近的坐标也相近，靠”坐标距离”找相似内容。好处是懂语义（问”宠物”能捞到”我家猫”），坏处是捞不准确切的名字日期。
- 知识图谱(Knowledge Graph)：把信息拆成”实体—关系—实体”的三元组（如”老羊—养—猫”），连成一张网，擅长回答需要多跳推理、讲究前后关系的问题。
- BM25 / 稀疏检索：老派的关键词全文匹配，认字面不认语义。
按照”表示”这一维度，论文把现有系统归成四大流派(这也是 awesome-agent-memory 清单的分类主线)：
flowchart TD
ROOT[Agent 记忆系统四大流派]
ROOT --> A[① 流式+反思<br>Stream & Reflection<br>时间线流水账,定期总结成反思<br>代表:MemoryBank]
ROOT --> B[② 分层分级<br>Hierarchical Tiered<br>分核心内存/归档层,像OS换页<br>代表:MemGPT/Letta]
ROOT --> C[③ 知识图谱<br>Knowledge Graph<br>实体-关系-时间存成网<br>代表:Zep, Mem0^g]
ROOT --> D[④ 复合混合<br>Composite Hybrid<br>多存储后端并存,按类型路由<br>代表:A-MEM, MemOS]实证结论：论文跑出来的九条发现
论文在 5 个基准、11 个数据集上，对 12 个代表性记忆系统 + 2 个基线做了评测，并拆成五个研究问题(RQ)逐条分析，而不是只比谁总分高。下面是提炼后的核心结论，每一条都对应一个具体的选型判断。
一条贯穿全文的主结论：没有银弹
没有任何一种记忆架构能通吃所有场景。系统强不强，取决于它的记忆结构，是否对得上当前任务的瓶颈。
这是全篇反复出现的主结论。具体到三类任务：
- 跨会话、找散落的事实(信息分散在几十次对话里) → 知识图谱 / 时序结构赢(Zep、Cognee)。因为它能把”实体—事件—时间”的关系连起来。
- 长但连贯的对话里抠一个确切细节(某个日期、某个名字) → 由粗到细的过滤 / 摘要赢(MemOS、MemoryOS)。先定位到相关那一段，再抠细节。
- 有状态的流程执行(数据库操作、依赖前后步骤) → 保留完整原始轨迹最重要(Long Context、MemoChat)。这里字面精确匹配反而不如”把过程原样留着”。
RQ1–RQ5 与模块消融：九条发现
| # | 发现 | 一句话说人话 | 实操启示 |
|---|---|---|---|
| F1 | 记忆要对齐工作负载 | 别问”哪个记忆最强”，要问”我的任务卡在哪” | 先定位瓶颈类型，再选架构 |
| F2 | 检索是”凑齐证据”，不是”排第一” | 好检索不是把最相关那条排最前，而是能把散落各处、时间久远的证据都捞全 | “早定位”和”凑齐证据”是两个独立目标；证据分散时，带链接/层级的结构(A-MEM、MemTree)完胜扁平向量检索 |
| F3 | 更新可靠性是”管线问题”，不是”模型问题” | 事实被修正后能不能答对，靠的是记忆结构设计，而不是换个更强的大模型 | 可改写性要内建到表示层(让新事实绑到同一实体上，而非当成新文本追加)；换更强模型只能改善”表达”，救不了”记错” |
| F4 | 长程稳定靠”结构”，不靠”塞更多” | 上下文越长/证据越远，难点不是存不下，而是能不能把远处的事实和答题所需的抽象连着 | 纯长上下文 prompting 和扁平向量库，随 horizon 拉长会急剧下滑；图结构和层级摘要则稳得多 |
| F5 | 效率由”维护范围”决定，不由”用不用结构”决定 | 贵不贵，看每次写入要惊动多大范围的记忆库 | 局部维护(LightMem、MemTree)性价比最高；全局重组(Cognee、Zep 全图整合)效果好但代价惊人（单次查询延迟可达 100~150 秒） |
| F6 | 保真度 > 压缩度 | 留住原始内容，比”多做抽象/多加层级”更重要 | 存原文(User-Only Raw)在多数指标上最好；摘要化损失惨重；更深的树只改善”导航”，救不回被删掉的信息 |
| F7 | 写入时要”晚过滤” | 抽取阶段别急着精挑细选，先把上下文留住 | 粗粒度分段、轻度改写、同时存用户和助手的对话，都比激进过滤更稳 |
| F8 | 检索靠”有针对性的结构”，不靠”堆复杂度” | 加一步轻量规划有用，再加”反思”反而变差 | 适度的稀疏+稠密混合最佳；规划(Planning)有效，但规划之上再叠反思(Reflect)是负收益、纯增开销 |
| F9 | 维护要”保守整合” | 别拖着不整理，也别一刀切粗暴总结 | 保守合并（提高相似度阈值再合） > 延迟刷新 > 强制单主题摘要 |
把这九条拧成一句话：好的记忆系统，是在写入时尽量留全证据(F6/F7)、用匹配任务瓶颈的结构组织它(F1/F2/F4)、把更新能力内建进表示层(F3)，并用局部而非全局的方式低成本维护(F5/F9)，而不是指望一个更聪明的大模型或更花哨的检索流程来兜底(F3/F8)。
主流工程项目横评
论文和 MemoryData 偏学术评测视角，而 GitHub 上真正被生产环境用的，是下面这几个工程项目。它们和论文里的方法多有重叠，但关注点是”跑得起、接得上、省钱”。
| 项目 | 定位 | 记忆怎么组织 | 更新/维护策略 | Star | 差异化卖点 |
|---|---|---|---|---|---|
| mem0 | AI Agent 通用记忆层 | 以”事实条目”为单位存向量库，配实体抽取；User/Session/Agent 三级 | 新算法转为纯累加(ADD-only)，靠时序排序区分新旧，不做覆盖 | ~60k | 主打生产可用、低 token、单遍检索；库/自托管/云三档商业化 |
| Letta(原 MemGPT) | 有状态 Agent 平台 | 核心是常驻上下文的 memory blocks，配外部存储做分层（类 OS 换页） | Agent 自主编辑自己的记忆块(self-editing) | ~24k | “stateful agent”范式开创者；记忆由 agent 自己管 |
| Zep(引擎 Graphiti) | 时序知识图谱记忆平台 | 时序知识图谱，分 episodic/semantic/community 三层子图，存 Neo4j | 双时序(bi-temporal)：每条 fact 记”何时为真/何时失效”，靠边失效处理演化而非删除 | 引擎 ~20k+ | 唯一以”时序图+双时序”为核心，擅长时间推理与多会话一致性 |
| Cognee | 开源 AI 记忆平台 | 向量 + 图推理 + 认知科学 ontology；1.0 起可整层跑在单个 Postgres 上 | 提供 remember/recall/forget/improve 四原语，forget 显式删除 | ~26k | “单库跑完整记忆层”降运维；强调 ontology |
| MemOS | 面向 LLM 的记忆操作系统 | 图结构记忆(可读可编辑，非黑盒)，以 MemCube 做隔离与共享；支持多模态 | 自然语言反馈纠错；四层自进化(交互轨迹→策略→世界模型→结晶为 Skills) | ~10k | “记忆 OS”抽象 + 分层自进化 + 技能结晶；多模态与工具记忆 |
| A-MEM | Agentic 记忆（学术复现） | 基于 **Zettelkasten(卡片盒)**的互联笔记网，每条记忆带结构化属性 | LLM 自动生成 tags 并在记忆间建立链接，支持动态演化 | ~1k | 核心创新是”自组织 + 记忆间自动链接” |
一个有意思的错位：论文实证里，A-MEM 和 MemTree 这类「带链接/层级的结构」在凑齐分散证据上表现突出(F2)，而 mem0 这类偏扁平的方案在长程、分散场景会掉队，但 mem0 在 GitHub 上的 star 数远高于它们。这说明：工程上的流行度，和学术 benchmark 上的分数，是两套评价体系。
记忆冲突：同一件事说了两遍，记哪条
前面讲的检索、召回，都建立在一个前提上：记忆库里存的东西是干净的。可对话是会变的：第一轮用户说“我喜欢吃草莓”，Agent 把它抽成一条事实存下来；第二轮用户又说“我不喜欢吃草莓”。两条记忆都在库里，检索时该信哪条？这就是记忆冲突。写入侧怎么处理它，直接决定了后面能召回到什么。
常见有四种写入策略，各有取舍：
| 策略 | 怎么做 | 代价 |
|---|---|---|
| ADD-only | 直接追加“不喜欢草莓”，不检查它和旧记忆冲不冲突 | 新旧两条主题接近，多数 Embedding 模型对“喜欢/不喜欢”这种逻辑极性又不敏感，两条容易一起被召回，污染上下文 |
| 合并式更新 | 找到旧记忆，把新旧信息合并进同一条 | 缓解了同时召回，但把当前事实和历史变化压进一条；偏好继续变，这条会越来越长，召回和解析都变复杂 |
| 软删 + 新增 | 把旧记忆标记为失效、不参与召回，再新增一条当前偏好 | 保留了变更记录，也不让旧事实干扰当前召回；代价是库里的记忆只增不减 |
| 硬删 + 新增 | 物理删掉旧记忆，再写一条新的 | 当前召回最干净，但偏好变化的历史彻底丢了 |
写侧维护不好，读侧再怎么做向量召回、关键词召回或 rerank，也只是在一堆被污染的记忆里挑挑拣拣。这就是记忆系统的“读写联动”。
Mem0 的两版演化：从“写时定事实”到 ADD-only
Mem0 是这个领域被生产环境用得最多的开源项目之一。它盯的不是单次召回的技巧，而是长期事实怎么沉淀、更新和淘汰。它的新旧两版实现，正好把上面四种策略的取舍演了一遍。
旧版：写入时就把事实定下来
早期 Mem0 收到一条新消息，会先召回相关的旧记忆，再让模型判断触发哪种动作：
- ADD：新增一条独立记忆，比如用户第一次说“我常用 pnpm”，历史里没有对应事实，直接写入。
- UPDATE：覆盖同一个事实槽位，比如把“喜欢草莓”改成“现在不喜欢草莓”，改的是同一个偏好的状态。
- DELETE：删除或失效旧记忆，比如用户明确说“这条记错了，别再记”。
- NOOP：忽略当前信息，比如寒暄、一次性的任务细节，不值得进长期记忆。
回到草莓的例子，旧版倾向用 UPDATE 矫正原记忆。好处是候选集干净、后续召回判断成本低；代价是丢掉一部分演化过程，而且写入时就得判断这条信息有没有长期价值、和旧记忆冲不冲突、该新增还是覆盖，判断错了，要么覆盖了本该留的历史，要么留下了本该失效的事实。
这套做法适合更看重“当前态”的场景：客服里的当前收货地址、订单状态，个人助理里的最新偏好、饮食忌口。这些都只关心“现在按哪条执行”，旧事实继续参与召回只会添乱。
新版：先把事实留住，冲突后面再说
新版把默认写入链路改成 ADD-only。它并没有取消 UPDATE / DELETE，只是把默认动作从“写入时确定事实”挪成“先保留事实，冲突留到检索和显式维护里再处理”。这么改图三件事：
- 降低写入成本：旧流程要先抽事实、再拿新事实和旧记忆做 diff，判断该增、改还是删，两次 LLM 调用；新版压成一次 ADD-only，抽取延迟大约砍半。
- 减少误改误删：UPDATE 错了覆盖历史，DELETE 错了丢信息，NOOP 错了漏记。像“我不喜欢草莓，但草莓蛋糕可以接受”这种带例外的偏好，本就不该被急着裁成一句结论。
- 提升可控性：让模型少做状态机式的 diff，多负责事实抽取；冲突的事实先共存，再靠去重、实体链接、多信号排序、显式维护或周期整理来收拾。
要注意，新版不是裸的 ADD-only：写入时仍然去重（拿相关旧记忆当上下文减少重复抽取，再用 hash 过滤完全重复的条目），还会抽实体、建 memory_id 链接，检索时用语义、BM25、实体匹配、时间等多路信号融合排序，把更可能有用的记忆排进 Top-K。ADD-only 本身并不解决冲突，它只是把判断从写入阶段后移了。
两版对应两种目标：旧版优先维护干净的当前事实集，新版优先降低写入成本和误删风险、多留变化过程。这也再次印证了那条主结论：记忆系统没有跨场景通用的最优解，场景的主要矛盾一变，写入、存储、检索、维护的重心也跟着变。
另一条路：只靠文件系统的轻量记忆
mem0、Zep 这些方案设计精巧，但对个人开发者或小体量 Agent 常常太重，记忆层的复杂度甚至会超过 Agent 本身。有没有更轻的路子？有两个思路值得借鉴，它们都没有向量库，只靠文件系统就把记忆搭起来了。
LLM Wiki：把经验编译成知识
LLM Wiki 是 Karpathy 提出的、面向大模型读写的个人知识库模式，核心就四个字：知识编译。它分三层：raw sources（原始资料）、wiki（结构化的 Markdown 页面）、schema（写入规则）。得到一个结论、收到一条用户输入后，它不会自动去总结整段会话，而是先问三个问题：这条信息以后还会不会复用？该进哪个页面？要不要保留原始来源？只有过了这层筛选的信息，才被“编译”进 Wiki。
所以项目目录约定、常用排查命令、踩坑结论这类东西最适合进 Wiki：整理成 Markdown 页面后，人能看、Agent 也能读；结论错了直接改，过期了直接删。Agent 读的时候不会把整个 Wiki 一股脑塞进上下文，先看索引和页面结构，找到相关片段；碰上高风险的结论，再回查原始来源。
Claude Code Memory：把文件接进运行时
Claude Code Memory 走的是同一个方向：记忆直接维护成 Markdown 文件，简单，还方便人阅读、审计和修改。它更进一步，把这些文件接进了编码 Agent 的运行时。
- 文件化存储：为项目维护一个 memory 目录，MEMORY.md 当索引，记“哪个主题文件里有什么”；详细内容按主题拆成多个 Markdown 文件，存的是整理过的长期经验，不是原始聊天记录。任务来了（比如“本地启动失败”），Agent 先读 MEMORY.md 判断 debugging.md 相关，再去读正文，不用一次性把所有文件塞进上下文。所以写入时不能只写正文，还得写清什么时候该用它。
- Subagent 记忆：这是它有新意的地方，专业 Subagent 也能有自己的记忆目录。Reviewer 维护审查口径，Debugger 维护排障路径，Researcher 维护资料筛选经验，各管各的，不用都混进主 Agent 的通用记忆。
- Team Memory 与 Auto Dream：Team Memory 解决团队共享，放团队共识、项目约定、共同踩坑记录；Auto Dream 是后台巩固机制，负责清理重复、刷新索引、重组过时又散乱的记忆。（还有个 Session Memory 服务长会话的 compact，只管当前任务进展，不承担跨项目沉淀。）
这两个例子指向同一条轻量路线：编码 Agent 场景下，可以先从文件系统记忆起步，把经验写成可维护的文件，再靠索引、作用域和运行时读取控制送进上下文；等一致性、冲突处理或大规模召回成了主要矛盾，再引入数据库、向量检索或图谱。Claude Code Memory 的价值，是把这条路线产品化进了运行时，还补上了 Subagent、Team Memory 和 Auto Dream 这些工程机制。
工程实现 vs 学术评测：两套目标函数
这也是理解 awesome-agent-memory(论文清单)和 MemoryData(评测套件)这两个库定位的关键。
学术/评测侧(MemoryData, LoCoMo…) 目标：在标准题上答得准、说清为什么
- 提出新机制（自组织/时序图/分层进化）
- 固定协议下做消融、对比 SOTA
- 报准确率/召回/延迟 trace
- 强调可复现
- 不太管运维和成本 [!NOTE] 工程/生产侧(mem0, Letta, Zep…) 目标：在生产里跑得起、接得上、省钱
- 稳定的 add/search/update API
- 多语言 SDK、多存储后端选型
- 多租户隔离、可观测性
- token 与延迟成本、框架集成
- 商业化（云/自托管分层） 两者交汇于 LoCoMo / LongMemEval 等 benchmark，但工程侧跑它主要是营销与选型佐证。MemoryData 的价值正在于填平这道沟：它把 4 大 benchmark 家族、22 个方法预设、统一 runtime 收进一个 main.py 入口，让异构的记忆方案在同一套执行接口和产物格式下横向对比。过去每篇论文自带一套 loader、adapter、metric，复现两个方法的一个对比数字往往意味着两个都得重写，这正是它要终结的痛点。
未来方向：什么才叫「Agent 原生记忆」
论文标题是个反问——“我们准备好迎接 agent 原生的记忆系统了吗？“——答案是还没有。现有系统大多是”给 NLP 任务做的记忆”，而非”为 agent 长跑而生的记忆”。结合全文，真正 agent-native 的记忆系统应当具备：
- 按瓶颈自适应结构(F1)：不是押注单一表示，而是能根据任务瓶颈动态选择图/树/原文的组织方式。
- 把可改写性做进底层(F3)：事实更新要能精确绑定到实体/事件上，而不是无差别追加文本，这是当前多数系统的硬伤。
- 局部维护优先(F5)：放弃”定期全局重组”的思路，改用只惊动局部的增量维护，这是成本可控的关键。
- 写入留全、读取精选(F6/F7)：写入阶段克制过滤、保住证据；把”挑选”的压力后移到检索阶段。
- 超越 end-to-end 指标：不能再把记忆当黑盒只看 F1/BLEU，要能独立测量检索保真度、更新鲁棒性、长程稳定性和操作成本，这正是 MemoryData 这套评测框架的意义。
给选型者的一页速查
| 你的场景 | 优先考虑 | 理由 |
|---|---|---|
| 个性化助手、聊天记忆、要快速接入 | mem0 | 生态成熟、SDK 全、生产可用 |
| 需要 agent 自主管理记忆、长期自我改进 | Letta | self-editing 范式、有状态平台 |
| 强时间推理、多会话事实一致性（如客服/CRM） | Zep / Graphiti | 时序图 + 双时序，处理”事实随时间变化”最强 |
| 想自托管、降运维、数据要落自己库 | Cognee | 单 Postgres 可跑完整记忆层 |
| 多模态、工具轨迹记忆、想要”技能沉淀” | MemOS | 图结构 + 四层自进化 + 技能结晶 |
| 做研究、要横向复现对比 | MemoryData | 统一入口跑 22 个方法 × 4 大 benchmark |
最后一句忠告：选型前先做一件事，搞清楚你的任务到底卡在哪(是证据分散？是事实频繁更新？是流程状态依赖？还是纯长上下文？)。把这个瓶颈类型对上速查表，比纠结「哪个 star 多」靠谱得多。这也是这篇论文九条发现反复强调的一点。
落地前先答清楚五个问题
先说结论：相当一部分场景，基于文件系统的记忆就够用了。先跑通最小可用版本，遇到问题再升级，别一上来就套向量库、知识图谱和一堆可能根本用不上的“优化”，那样只会拉高复杂度和维护成本，在你的场景里甚至起反作用。
选型别从“某个数据库”或“某个框架”起步，先想清楚你到底要 Agent 记住什么、达成什么效果。落地前把下面五个问题答清楚：
| 问题 | 要判断什么 | 影响的技术选择 |
|---|---|---|
| 记给谁 | 单用户、团队、项目，还是某个专业 Agent 的私有记忆 | 决定 scope 设计：user_id、team_id、workspace_id、agent_id，以及权限隔离和共享边界 |
| 记什么 | 事实、偏好、行为模式，还是实体关系 | 事实和状态适合结构化存储；经验和规范适合文件化沉淀；关系复杂时才需要实体索引或图结构 |
| 记多久 | 只要当前有效的事实，还是要保留完整的变化过程 | 只要当前态，可学 Zep：旧事实标失效或被新版本覆盖，查询默认取最新；要历史，则得保留时间线和版本字段 |
| 记多少 | 记忆规模是几十条、几千条，还是持续增长的大规模文本 | 规模小用文件、KV 或 SQL；规模大了要索引、分片、归档、去重和清理 |
| 怎么取 | 精确查找、模糊联想，还是沿关系做多跳推理 | 精确查找用 KV / SQL；模糊联想用 BM25、向量检索或 hybrid；多跳推理靠实体关系或知识图谱 |
填这张表的过程，其实就是把落地场景拆开，弄清楚到底需要什么、每一项要做到什么程度。五问答完，再回头看前面那张速查表，选哪个方案基本就有谱了。
资料来源：Are We Ready For An Agent-Native Memory System? · awesome-agent-memory · MemoryData · 各项目 GitHub 主页(mem0 / Letta / Zep / Cognee / MemOS / A-MEM)