Agent 记忆长文总结：精选 23 篇记忆典型论文，帮你构建 Agent Memory 全局观

3 月 26 号我写过一篇文章，把 150+ 位研究者联合写的 Agent 记忆综述分析了一下。那篇侧重的是综述本身的分类框架和全局视角。

但读完之后我一直觉得不够。框架看懂了，具体每篇论文到底在解决什么问题、方法细节是什么、效果怎么样，光看综述里的一两句引用是看不清楚的。

所以这篇是续集。我从综述的四个维度里选了 23 篇代表性论文，逐篇精读了原文，把每篇的动机、方法和结论整理在这里。

目标是让你不用翻原论文，也能搞清楚每篇到底做了什么。从而构建一个 Agent 记忆的全局观。

从人脑到 Agent：五种记忆各有各的用处

这篇综述把 Agent 记忆按认知心理学的 Atkinson-Shiffrin 模型来分。感知记忆和工作记忆属于短期系统，情景记忆、语义记忆、程序性记忆属于长期系统。

每一类对应的都是 Agent 系统里非常具体的工程问题。下面逐篇来聊。

感知记忆：原始输入的第一道缓冲

感知记忆是最底层的记忆类型。你可以把它理解成一个「快速暂存区」——信息涌进来的时候先接住，给系统一个筛选的机会，再决定哪些值得进一步处理。人类看到一个画面、听到一个声音，在你还没「想」之前，感知记忆就已经在工作了。对 Agent 来说，这对应的是视频流、传感器数据、长对话原始输入这类需要快速缓冲的场景。

这个方向挑了一篇：LightMem 把感知缓冲的思路搬到了 LLM 长对话场景，设计了三阶段记忆流水线。

LightMem：三阶段轻量记忆系统

论文链接：https://arxiv.org/abs/2510.18866
发表时间：2025年10月
机构：浙江大学、新加坡国立大学

动机

大模型很强，但它有个硬伤：没记性。每次对话都是"失忆重来"。现有的记忆系统（比如 Mem0、LangMem、MemoryOS）试图解决这个问题，但代价不小。

第一个痛点是冗余。用户和模型的对话里有大量废话——寒暄、重复、跑题的内容。现有系统不做过滤，直接把原始内容扔给 LLM 做摘要，token 消耗巨大但收益不成比例。

第二个痛点是粒度不对。要么按"每轮对话"切分（太细，API 调用爆炸），要么按"每个 session"切分（太粗，不同话题混在一起，摘要质量差）。缺少一种按语义主题自适应分段的机制。

第三个痛点是更新太贵。记忆需要去重、合并、修正矛盾。现有方法在推理时实时做这些操作，严重拖慢响应速度。而且更新是串行的（必须先读后写），没法并行。

LightMem 的思路很清楚：借鉴人类记忆的 Atkinson-Shiffrin 模型，设计一个感知-短期-长期三阶段系统，把记忆维护的开销降下来。

主要方法

LightMem 其实是一个跨越三种记忆类型的完整系统，包含感知、短期和长期三个模块。之所以放在感知记忆这一节，是因为它的第一阶段做的事情正好是感知记忆的核心功能：在原始输入进入后续处理之前，先做一层快速过滤，把冗余信息筛掉。不过后面两个阶段也值得一起看，这样才能理解整个系统的设计逻辑。

第一阶段：感知记忆（Light1）。这是一个预压缩+主题分段模块。预压缩用的是 LLMLingua-2，把每个 token 当做二分类任务：“保留"还是"丢弃”。

保留概率低于阈值的 token 直接砍掉。阈值怎么定？取所有 token 保留概率的第 r 百分位数（r 就是压缩率）。这个操作很快，只需要一个小模型（不到 2GB 显存），不用调 LLM。

压缩后的文本进入感知记忆缓冲区。当缓冲区满了，就要把这段对话切成一个个独立话题。

怎么切？用两个信号交叉验证。第一个信号是注意力矩阵：模型在处理对话时，相邻两轮如果聊的是同一个话题，注意力权重会比较高。如果突然变低了，说明话题可能换了，这里就是一个候选切分点。

第二个信号是语义相似度：直接算相邻轮次之间的文本相似度。相似度骤降的地方，同样可能是话题切换点。

最后取两个信号都认为「这里该切」的位置作为最终分段点。两个信号互相印证，比单用一个更靠谱。

第二阶段：短期记忆（Light2）。分段后，每个主题片段形成一个索引结构：{主题, 用户消息, 模型回复}。这些片段先进入短期记忆缓冲区。

当缓冲区 token 数达到阈值时，调用 LLM 对每个片段做摘要，生成精简的记忆条目存入长期记忆。关键点在于：因为输入已经按主题聚好了，摘要质量远高于把多个话题混在一起摘要的做法。而且批量处理减少了 API 调用次数。

第三阶段：长期记忆（Light3）。这里的创新是"睡眠时更新"机制。新记忆到达时，不做复杂的去重合并，而是直接带时间戳插入——这就是"软更新"。推理时的延迟几乎为零。

真正的去重和整合在"离线睡眠"阶段完成。系统为每条记忆计算一个更新队列：找出语义最相似且时间戳更晚的 top-k 条目。注意这里有个时间约束——只允许后来的信息更新先前的信息，符合因果逻辑。

然后各条目的更新队列独立执行，可以完全并行。这比现有系统的串行在线更新快得多。

从复杂度角度看，传统系统每轮对话都要调 LLM 做摘要和更新，总调用次数是 O(N)。LightMem 只在缓冲区满时才调用，总调用次数降到 O(N * r^x * T / th)，其中 r 是压缩率、x 是压缩轮数、T 是平均 token 数、th 是缓冲区容量。这几个因子叠在一起，削减效果非常可观。

主要结论

在 LongMemEval 上，LightMem 用 GPT 骨干比最强基线 A-MEM 高出 2.09%~6.40% 准确率，用 Qwen 骨干最高提升 7.67%。总 token 消耗减少 6.9~38 倍，API 调用减少 3.3~30 倍，运行时间加速 1.6~12.4 倍。

如果只算在线推理开销（不算离线睡眠阶段），效率提升更夸张：token 消耗最高减少 117 倍，API 调用最高减少 310 倍。

在 LoCoMo 上，LightMem 准确率高出 4.41%~29.29%，token 效率提升最高 20.9 倍，API 调用减少最高 55.5 倍。两个数据集、两个骨干模型（GPT 和 Qwen），全面领先。

不足之处是话题分割准确率虽然超过 80%，但仍有近 20% 的错误会导致记忆条目话题混杂。另外睡眠时更新的触发时机和频率需要人工调参，缺乏自适应机制。

工作记忆：上下文窗口是 Agent 的命门

工作记忆就是你「手头正在用」的信息。人类做心算的时候，脑子里同时记着几个中间结果，这就是工作记忆在干活。对 LLM Agent 来说，工作记忆约等于上下文窗口——当前 prompt 里能放多少信息，Agent 就能「同时想着」多少东西。问题是这个窗口有上限，任务越长越容易爆。

这个方向挑了两篇，思路不同但目标一致。ACON 走的是「智能压缩」路线，通过失败驱动的自动优化来学会压缩什么、保留什么。Context-Folding 走的是「结构化管理」路线，让 Agent 像写代码调函数一样分支处理子任务再折叠回来。

ACON：长时域 Agent 上下文压缩优化

论文链接：https://arxiv.org/abs/2510.00615
发表时间：2025年10月
机构：KAIST、微软、剑桥大学

动机

大模型 Agent 越来越能干了——帮你发邮件、管文件、操作各种 App。但有个越跑越严重的问题：上下文会无限膨胀。

想象一下：Agent 在 AppWorld 里帮你完成一个任务，需要先查邮件、再改日历、再发 Venmo 转账，每步都产生大量 API 返回值。做了几十步之后，上下文动辄几万 token。成本飙升不说，太长的上下文还会"稀释"关键信息，模型被一堆旧数据干扰，反而做错。

现有的压缩方法要么是为对话场景设计的，做个摘要就行。要么是为单步问答设计的，把无关文档删掉就完事。这些方法对 Agent 不够用。

Agent 的上下文比对话和文档复杂得多。里面有因果关系、有状态变化、有前提条件、还有影响未来决策的线索。粗暴截断或通用摘要很容易丢掉这些关键信号。

ACON 的定位很明确：为长时域 Agent 任务设计一个通用的上下文压缩框架。

主要方法

ACON（Agent Context Optimization）的核心思想是：用自然语言描述的"压缩指南"来指导 LLM 做上下文压缩，然后通过"失败驱动"的方式自动优化这个指南。

先说压缩机制。ACON 把 Agent 上下文分成两部分来压缩。第一部分是交互历史——Agent 过去所有的动作和观测。

当历史长度超过阈值时，调用压缩器 LLM 对历史做摘要。第二部分是最新观测——环境返回的当前信息（比如一大段 API 返回值）。当观测长度超过阈值时，同样做压缩。两种压缩都遵循一个自然语言"压缩指南"，告诉 LLM 该保留什么、该丢弃什么。

关键创新在于怎么自动优化这个压缩指南。ACON 的方法叫"对比任务反馈"。在训练集上，让 Agent 分别用完整上下文和压缩上下文跑同样的任务。

找出那些"完整上下文成功、压缩上下文失败"的案例——这些就是压缩出了问题的样本。然后让一个优化器 LLM 分析这些失败案例：比较压缩前后的上下文，找出"丢了什么关键信息导致的失败"。这些分析结果就是"自然语言梯度"。

收集多个任务的反馈后，批量更新压缩指南。同时生成多个候选指南，在对比子集上评估，选最好的。这一步叫"效用最大化"（ut），确保压缩后任务还能成功。

但只优化"不丢信息"可能导致压缩不够激进。所以 ACON 还有第二步——“压缩最大化”（co）。这一步只看压缩后仍然成功的案例，让 LLM 分析"哪些信息其实没被用到"，进一步精简压缩指南。两步交替，兼顾任务成功和压缩效率。

整个过程是无梯度的——不需要修改模型参数，只优化自然语言 prompt。这意味着 ACON 可以直接用于闭源 API 模型。

还有一步是蒸馏。优化好的大模型压缩器可以蒸馏成小模型。做法很直接：大模型按优化后的指南生成压缩输出，作为小模型的监督训练数据。蒸馏后的小模型替换大模型做压缩，推理开销大幅降低。

主要结论

在三个长时域 Agent 基准上用 GPT-4.1 评估。AppWorld 上，ACON 减少 25% 以上的 peak token，任务成功率和不压缩的上界持平，而其他基线（FIFO、检索、LLMLingua、通用 prompting）在中等和困难任务上严重退化。

OfficeBench 上，ACON 将 peak 上下文缩减近 30%，准确率保持在 74% 以上。8-objective QA 上，ACON 甚至超过了不压缩的基线（EM/F1 都更高），同时 peak token 减少 54.5%，依赖度减少 61.5%。

蒸馏效果也不错：小模型压缩器保留了大模型 95% 以上的准确率。更有意思的是，ACON 能显著提升小模型做 Agent 的能力——AppWorld 上提升 32%，OfficeBench 上提升 20%，8-objective QA 上提升 46%。压缩掉干扰信息后，小模型反而不容易被长上下文搞晕了。

ACON 的局限在于压缩指南优化需要在训练集上收集成对轨迹，对新环境需要重新优化。另外双重压缩（历史+观察）的阈值需要人工设定，不同任务的最优值差异较大。

Context-Folding：分支-折叠机制管理工作记忆

论文链接：https://arxiv.org/abs/2510.11967
发表时间：2025年10月
机构：字节、CMU、Stanford

动机

LLM Agent 做复杂任务时，有一个结构性瓶颈：上下文是线性增长的。Agent 每执行一步，交互历史就长一截。标准的 ReAct 框架把所有历史堆在一个不断膨胀的上下文里，最终要么撞上窗口上限，要么被冗余信息淹没。

你可能会想：做个摘要不就行了？实践中摘要方法有两个问题。第一，摘要本身不完美，总会丢信息。第二，摘要是"事后补救"，不是"主动管理"——Agent 没有选择权，不知道哪些该留、哪些该折叠。

Context-Folding 提出的思路完全不同：让 Agent 自己学会管理上下文。不是被动地压缩，而是主动地"分支"和"折叠"。

主要方法

Context-Folding 给 Agent 增加了两个特殊动作：branch（分支）和 return（返回）。

当 Agent 遇到一个子任务，比如搜索某个信息，它可以发出 branch 指令，进入一个全新的 32K 子上下文窗口。这个子窗口不会继承主线程的全部历史，只带上主线程传过来的任务描述和必要上下文。Agent 在子窗口里独立工作——调用工具、做推理、收集信息——这些中间步骤不会污染主线程。子任务完成后，Agent 发出 return，系统把子上下文"折叠"成一段简短摘要，插回主线程。

这个机制其实很像把任务分配给一个 subagent。主线程只给子轨迹一个任务描述和必要上下文，子轨迹不知道所有过往细节。做完了只汇报结论，中间过程主线程不关心。

这正是 peak context 能控制在 32K 的原因——如果子轨迹继承全部历史，上下文还是会膨胀，分支就没意义了。那怎么保证子轨迹拿到的信息够用？这就是后面要说的 FoldGRPO 训练要解决的问题之一。

这也像人类工作时的"另开一个标签页"。你在主任务里遇到一个需要深入查资料的子问题，就开个新标签页去查。查完了，记下结论，关掉标签页，回到主任务继续。你的主任务思路不会被查资料的过程打断。

关键参数：主线程和每个子线程的上下文窗口都是 32K token，最多允许 10 次分支。理论上等效于 327K token 的上下文容量，但任何时刻活跃的上下文始终只有 32K。

怎么让 Agent 学会有效地使用 branch/return？论文提出了 FoldGRPO——一个专门为折叠行为设计的强化学习框架。FoldGRPO 在标准 GRPO（Group Relative Policy Optimization）基础上加了两个针对性的过程奖励。

第一个是"未折叠 Token 惩罚"（Unfolded Token Penalty）。如果 Agent 在主线程上堆了太多 token 而不分支，会受到惩罚。这鼓励 Agent 主动把重活儿分到子线程去做。

第二个是"越界惩罚"（Out-of-Scope Penalty）。如果 Agent 在某个子线程里做了和该子任务无关的事情，也会受到惩罚。这确保每次分支有明确目标，而不是无目的地分叉。

FoldGRPO 的训练过程是端到端的。它在 rollout 时动态管理折叠后的上下文——主线程看到的是折叠过的精简版，子线程看到的是自己的完整内容。过程奖励在每个 token 级别给出反馈，比只看最终任务成功/失败的稀疏奖励密集得多，训练更稳定。

和 ACON 那种"优化压缩指南"的思路相比，Context-Folding 更激进：它不是在同一个上下文里做压缩，而是在结构层面改变了上下文的组织方式。Agent 真正拥有了"工作记忆管理"的能力。

主要结论

在 BrowseComp-Plus（150 个深度研究任务）上，Folding Agent + FoldGRPO 达到 62.0% pass@1。对比之下，同模型（Seed-OSS-36B）的 32K ReAct 只有 28.6%，327K ReAct 也只有 47.8%。甚至超过了 GPT-4.1 的 327K ReAct（64.0% vs 62.0%，但 GPT-4.1 是百亿级参数模型）。

在 SWE-Bench Verified（500 个软件工程任务）上，Folding Agent 达到 58.0%，超过 327K ReAct 的 55.2%。活跃上下文只有 32K——比基线的 327K 小了 10 倍。

消融实验证明 FoldGRPO 的必要性：用标准 GRPO 训练的 Folding Agent 在 BrowseComp-Plus 上只有 56.7%，换成 FoldGRPO 后跳到 62.0%。这说明专门针对折叠行为的过程奖励是关键。

Summary Agent（用传统摘要做上下文管理）在同样条件下只有 52.7%，明显不如 Folding Agent 的 62.0%。结构化的分支-折叠比笼统的摘要有效得多。

Context-Folding 的局限是分支-折叠决策依赖 RL 训练，对未见过的任务类型可能不知道何时该分支。另外子轨迹折叠后信息不可逆丢失，如果摘要质量不好，后续决策可能受影响。

情景记忆：过去的经历不能白费

情景记忆记的是「什么时候、在哪里、发生了什么」。不是泛化的知识，而是你亲身经历过的具体事件。比如「昨天下午三点在会议室 B，老板说了下个月要上线」，这就是一条情景记忆。对 Agent 来说，情景记忆意味着能回忆起过去的交互细节——上次用户问了什么、哪步操作失败了、当时的环境状态是怎样的。

这个方向挑了两篇。AriGraph 把情景记忆和语义知识统一在一张知识图谱里，在文本游戏环境中验证。Memoria 面向个性化对话场景，用带时间衰减的知识图谱来解决用户偏好变化的问题。

AriGraph：用知识图谱统一语义记忆和情景记忆的 LLM Agent

论文链接：https://arxiv.org/abs/2407.04363
发表时间：2024 年 7 月
机构：AIRI、莫斯科国立大学等

动机

AriGraph 的验证场景是文本游戏。Agent 在一个虚拟房子里走来走去完成任务，比如找到钥匙开门、收集食材做饭。每走一步，游戏返回一段文字描述当前场景——「你在厨房里，桌上有菜谱，抽屉是关着的」——这就是一条「观测」。Agent 需要根据历史观测来决定下一步做什么。

问题是怎么记住这些观测。目前主流做法有三种：全部塞进 prompt、做摘要压缩、或用 RAG 检索。但它们有一个共同硬伤——记忆是非结构化的。

非结构化记忆为什么不好用？假设你已经走了 30 步，积累了大量观测文本。现在任务需要一把刀，你得回忆刀在哪个房间。

全文检索可能找到好几条提到「刀」的观测，但分不清哪条是最新的、刀现在还在不在那里。RAG 按语义相似度检索，但「厨房里有红辣椒」和「菜谱需要红辣椒」之间的关系，向量检索未必能捕捉到。

认知科学告诉我们，人脑有两种长期记忆：语义记忆（世界知识，比如"火会烧伤"）和情景记忆（亲身经历，比如"昨天我在厨房被烫了"）。传统上认为它们是分离的，但新研究表明它们紧密相连。AriGraph 的核心思路就是：用一张图把语义记忆和情景记忆统一起来。

主要方法

AriGraph 的核心数据结构是一张混合图 G = (Vs, Es, Ve, Ee)，包含四类元素：语义节点 Vs、语义边 Es、情景节点 Ve、情景边 Ee。这张图就是 Agent 的"世界模型"，随着交互不断生长。

第一步是构建语义记忆。每当 Agent 收到一条环境观测（比如"你在厨房里，桌上有一本菜谱"），LLM 会从中抽取三元组，比如（菜谱, 在, 桌子上）、（桌子, 在, 厨房）。这些三元组作为语义边加入图中，对应的实体作为语义节点。这一步本质上是用 LLM 做开放域信息抽取（OpenIE），不需要预定义 schema。

第二步是构建情景记忆。每条原始观测文本被保存为一个情景节点。然后，第一步从这条观测中抽取的那些语义三元组，通过情景边连接到这个情景节点上。

情景边的含义很简单：这些知识是"同一时刻获得的"。这样设计的好处是：你通过语义三元组检索到某条知识后，可以顺着情景边找回当时的完整观测——不只拿到结构化的事实，还能看到当时的原始细节和上下文。

你可能会问：每次观测不是各自建一个子图吗，不同观测之间怎么关联？答案是靠共享的语义节点。比如第 5 步在厨房看到了刀，第 15 步拿着刀到了卧室，两次观测都涉及「刀」这个实体，就会连到同一个语义节点上。

观测越多，共享节点越多，整张图越稠密。不过情景节点之间没有直接的边，也没有时间顺序或因果关系。这是 AriGraph 的一个设计取舍：图结构更简洁，但丢失了事件之间的时序信息。

第三步是图的动态更新。Agent 不是只做加法。当新观测和已有知识矛盾时（比如"玩家不在房间 A 了"），系统会找出过时的语义边并删除。

这是通过 LLM 比较新三元组和已有三元组来实现的。这让图始终反映环境的当前状态，而不是越来越臃肿。

第四步是检索。当 Agent 需要做决策时，检索分两步走。首先是语义搜索：用 Contriever 模型按语义相似度找到最相关的三元组，然后沿着图的边做广度优先展开，把邻居关系也带出来。

接着是情景搜索：根据已找到的三元组，通过情景边找到所有关联的历史观测。Agent 的上下文窗口放不下所有观测，所以需要排序，选出最值得看的 top-k 条。排序公式是 ni/Ni × log(Ni)。

Ni 是一条观测总共抽取出的语义三元组数量，ni 是其中和当前查询匹配上的数量。ni/Ni 这个比例项是关键：同样命中 3 个三元组，一条观测总共才 4 个（高度聚焦），另一条有 50 个（只是顺带提了一嘴），前者的排名会远高于后者。log(Ni) 做了一点修正，避免特别小的观测因为比例高就被过度抬升。整体思路类似 TF-IDF：既要相关，又要聚焦。

第五步是 Agent 架构。AriGraph 被嵌入一个叫 Ariadne 的认知架构中。Ariadne 有规划模块和决策模块。

规划模块根据工作记忆（当前观测+检索到的语义和情景记忆+目标描述）生成子目标序列。决策模块用 ReAct 框架，先推理再行动。Agent 还能利用图中的空间关系做导航——比如根据"厨房 西边是 客厅"的语义边规划路线。

主要结论

在 TextWorld 文本游戏上，Ariadne 在寻宝、打扫、烹饪三类任务中全面超越了 Full History、Summarization、RAG、Simulacra、Reflexion 等基线。特别是在最难的寻宝任务（36 个房间、7 把钥匙）中，基线方法基本无法完成，而 Ariadne 能稳定通关。与 RL 基线（GATA、LTL-GATA、EXPLORER）对比，Ariadne 在烹饪任务的 4 个难度级别上都取得了更高分数。

在 NetHack 经典地牢游戏中，只能看到当前房间的 Ariadne 取得了 593 分，接近能看到整层地图的 NetPlay（675 分），远超同样只能看当前房间的 NetPlay（342 分）。这说明 AriGraph 可以有效补偿视野的不足。

在多跳问答任务上，AriGraph(GPT-4) 在 MuSiQue 上取得 EM=45.0/F1=57.0，在 HotpotQA 上取得 EM=68.0/F1=74.7，与专门为 QA 设计的 HOLMES 相当，且成本不到 GraphRAG 的十分之一。

在多跳问答任务上，AriGraph(GPT-4) 在 MuSiQue 上取得 EM=45.0/F1=57.0，在 HotpotQA 上取得 EM=68.0/F1=74.7，与专门为 QA 设计的 HOLMES 相当，且成本不到 GraphRAG 的十分之一。

不足的是，AriGraph 仅在文本游戏（TextWorld、NetHack）和多跳问答上进行了验证，尚未在真实世界的复杂任务中测试泛化能力。此外，随着交互历史增长，知识图谱的规模会持续膨胀，图的维护成本（包括冲突检测、过时边删除）在大规模场景下是否可控尚不清楚。

Memoria：给对话 AI 加上个性化的情景记忆

论文链接：https://arxiv.org/abs/2512.12686
发表时间：2025 年 12 月
机构：BlackRock

动机

大多数 LLM 聊天系统都是"无状态"的。每次对话从头开始，上一次聊了什么全忘了。用户得反复介绍自己、重复偏好，体验很差。

现有的记忆解决方案要么用向量库存检索结果，要么用图数据库做结构化存储，但它们各有问题。

向量库缺乏可解释性，也没法处理信息冲突——如果用户先说"我喜欢咖啡"后说"我现在改喝茶了"，向量检索可能两条都返回。图数据库虽然结构清楚，但在处理时效性（哪条信息更新）和规模化方面有困难。很少有框架把短期对话记忆和长期用户画像两件事整合在一起。

Memoria 要解决的就是这个问题：在一个统一框架里，同时搞定会话内的连贯性和跨会话的个性化。

主要方法

Memoria 是一个模块化的 Python 库，可以插到任何 LLM 聊天系统上。它的核心由四个模块组成，我们逐一拆解。

第一个模块是结构化对话日志。每条消息都带时间戳、会话 ID、原始内容、从中抽取的知识三元组、摘要、Token 用量等字段存入 SQLite 数据库。这是一切的基础——你不能记住你没存下来的东西。三元组同时以原始形式存入 SQL，以向量嵌入形式存入 ChromaDB，方便后续语义检索。

第二个模块是动态用户画像。Memoria 只从用户消息中抽取知识三元组，不从 AI 回复中抽。比如用户说「我是做股票交易的，习惯看早间新闻」，就会抽出「用户-是-股票交易员」「用户-偏好-早间新闻」这样的三元组。

这些三元组逐步构建成一张知识图谱，代表系统对这个用户的理解。图只会增长和修正，不会重建，成本可控。

第三个模块是会话级摘要。这个模块管的是「同一次对话里不要丢上下文」。比如你跟 AI 聊了 50 轮，前面说过的偏好和需求不能忘。

Memoria 的做法是每轮对话后都用 LLM 更新一次摘要。不过不是每次从头总结整个对话，而是增量更新：LLM 拿到「上一版摘要 + 最新几轮」，输出更新后的摘要。后续对话都是用这份最新版摘要作为上下文，不会回头看原始对话历史。

这意味着早期对话的细节会随着多次压缩逐渐模糊。这和前面 LightMem 的思路不同——LightMem 选择先原样存下来、离线再整合，保真度更高但延迟也更大。Memoria 选择在线实时压缩，响应快但信息有损。是延迟和信息保真度之间的取舍。

到这里，前面三个模块其实构建了两种记忆：会话摘要是短期记忆，记的是当前这次对话的上下文；用户画像知识图谱是长期记忆，记的是跨会话积累的用户偏好和事实。

第四个模块是上下文感知检索，负责在回答时把这两种记忆融合起来。当用户发来一条新消息时，系统先按语义相似度从向量库中检索一批相关三元组。但检索出来的可能有很多条，不能全塞进 prompt，所以还要做一轮筛选。筛选的依据就是时间衰减权重：语义相似度决定「检索哪些三元组」，时间衰减权重决定「这些三元组里哪些优先给 LLM 看」。

加权用的是指数衰减函数。每个三元组的权重为 ，其中 是当前时间与三元组创建时间的差值，归一化到 [0,1] 区间。归一化很关键——如果不做，很久以前的三元组权重会趋近于零，即使没有更新的信息替代它们。

最终权重再做一次 softmax 归一化，确保所有权重之和为 1。这样，最近的信息权重最高，但很久以前的信息不会被完全遗忘。

衰减率 控制遗忘速度。 越大，越偏向最近的信息。论文中使用 。

Memoria 区分三种场景。新用户第一次来，什么记忆都没有，直接开始积累。老用户开启新会话，有用户画像图谱但没有当前会话摘要。

老用户继续上次的对话，图谱和摘要都能用。每种场景下，系统自动选择可用的记忆源来增强 prompt。

说实话，Memoria 的每个单独组件都不算新——会话摘要、知识图谱、向量检索都是现有技术。它的贡献更多是工程整合。但这个时间衰减加权确实解决了一个实际问题：用户偏好会变。

传统知识图谱里「用户喜欢咖啡」和后来的「用户改喝茶」会并存，检索时不知道该信哪个。时间衰减自动让新信息权重更高，不需要显式做冲突检测和删除。这是整套系统里我觉得最有意思的设计。

主要结论

在 LongMemEval 数据集上（每段对话约 11.5 万 token），Memoria 在 single-session-user 和 knowledge-update 两类问题上都取得了最高准确率，超过了 A-Mem 的两个版本（默认 SentenceTransformers 嵌入和 OpenAI 嵌入）。

延迟方面，全文拼接法平均需要 522 秒处理超过 11.5 万 token。Memoria 将 prompt 压缩到不到 400 token，延迟降低了 38.7%。A-Mem 虽然也减少了延迟，但检索的是原始用户消息（平均 900+ token），比 Memoria 的加权三元组方式更臃肿。

不足的是，Memoria 的评估仅在 LongMemEval 一个数据集上进行，缺乏跨数据集的泛化性验证。此外，知识图谱中的三元组提取完全依赖 LLM 的质量，如果 LLM 在抽取时犯错（如遗漏关键实体或生成错误关系），这些错误会直接传导到用户画像和检索结果中。

语义记忆：把知识组织成网络

语义记忆存的是事实和概念。比如你知道「巴黎是法国首都」「水的化学式是 H2O」，但你不会记得自己具体是哪天、在哪本书上学到的。这就是语义记忆和情景记忆的区别：情景记忆带着时间和场景，语义记忆只剩下纯粹的知识。

对 Agent 来说，语义记忆就是它的知识库，从文档、对话、工具返回中积累的结构化知识。RAG 系统本质上就是在做语义记忆的检索。

这个方向挑了两篇。HippoRAG 受海马体神经科学启发，用知识图谱加 PageRank 做多跳检索，解决跨文档知识整合的难题。A-Mem 借鉴了 Zettelkasten 卡片笔记法，让 Agent 自主构建、链接和进化记忆笔记。

HippoRAG：受海马体启发的长期记忆 RAG 框架

论文链接：https://arxiv.org/abs/2405.14831
发表时间：2024 年 5 月
机构：俄亥俄州立大学等

动机

哺乳动物的大脑经过几百万年进化，能存储大量世界知识，还能不断整合新信息而不丢失旧知识。但 LLM 做不到。即使加上 RAG，现有方法仍然有一个致命弱点：每篇文档是孤立编码的，无法跨文档整合知识。

什么意思呢？假设一篇文档写了"Thomas Sudhof 是斯坦福大学教授"，另一篇写了"Thomas Sudhof 研究阿尔茨海默症的神经科学"。如果有人问"哪位斯坦福教授研究阿尔茨海默症"，标准 RAG 需要先检索到其中一篇，再迭代检索第二篇。

但更难的情况是"路径发现"型问题：斯坦福有很多教授，研究阿尔茨海默的也有很多人，你需要找到交叉点。迭代检索在这种情况下要探索的路径太多，基本无能为力。

人脑是怎么做到的？海马体记忆索引理论给了一个解释。新皮层负责处理感知输入，海马旁回区域做中转，海马体维护一个索引——不存储完整记忆，但存储记忆之间的关联。

当你收到部分线索时，海马体通过关联网络"补全"完整记忆。HippoRAG 就是要用计算系统模拟这个过程。

主要方法

HippoRAG 有三个组件，分别对应人脑的新皮层、海马旁回和海马体。整个系统分为离线索引和在线检索两个阶段。

离线索引阶段，模拟的是记忆编码过程。首先，用一个指令微调的 LLM 充当「人工新皮层」，对语料中的每篇文档做 OpenIE，也就是开放域信息抽取——不预定义关系类型，让 LLM 自由地从文本中抽取「主语-关系-宾语」三元组。这个过程分两步：先提取命名实体，再以命名实体为锚点提取完整三元组。

抽取出来的所有名词短语作为节点，关系作为边，构成一张无 schema 的知识图谱。这就是「人工海马体索引」。

接着，用检索编码器充当「人工海马旁回」，给所有节点生成向量表示。如果两个节点的余弦相似度超过阈值 0.8，就加一条同义边。这些同义边弥补了信息抽取不一致的问题。

比如 “Stanford University” 和 “Stanford” 本来是两个节点，加了同义边之后就被关联起来了。同义边让图更稠密，有利于后续的图搜索。

在线检索阶段，模拟的是记忆提取过程。给定一个查询，LLM 先从中提取出命名实体（比如"Stanford"和"Alzheimer’s"）。然后用检索编码器把这些实体链接到知识图谱中最相似的节点上，得到"查询节点"。

关键一步来了：在这些查询节点上运行 Personalized PageRank（PPR）算法。PPR 是 PageRank 的变体，它只从指定的源节点开始传播概率，而不是从所有节点均匀开始。概率沿着边扩散到邻居节点，再到邻居的邻居。

这样，与查询节点在图上有路径连接的节点会获得较高的概率值。PPR 的阻尼因子设为 0.5，意味着每一步有 50% 的概率回到查询节点重新出发。

PPR 运行完后，每个节点有一个概率值。最后一步是把节点概率映射回文档。系统维护了一个"节点-文档"矩阵 P，记录每个节点出现在哪些文档中。用 PPR 输出的概率向量乘以 P，就得到每篇文档的检索得分。

论文还引入了"节点特异性"的概念。如果一个节点只出现在少数几篇文档中，它的区分度更高。节点特异性定义为 si = 1/|Pi|，即出现文档数的倒数。

在 PPR 之前，用它调节查询节点的初始概率。这类似于 IDF 的思想，但只需要本地信息，不需要全局统计。

回头看整个设计，知识图谱在 HippoRAG 里扮演的角色其实是一个索引层。它不直接回答问题，而是帮你找到该读哪些文档。就像图书馆的目录卡片帮你定位到具体的书架，但你最终读的还是书本身。

PPR 找到的节点会追溯回原始文档段落，送给 LLM 的是文档原文而不是三元组。这和论文名字里「海马体索引」的类比是一致的：人脑的海马体也不直接存记忆内容，而是维护一套索引指向新皮层中实际存储的位置。

主要结论

在单步检索上，HippoRAG 在 2WikiMultiHopQA 上的 R@2 和 R@5 分别比最佳基线高出 11% 和 20%，在 MuSiQue 上高约 3%。这里 R@K 是 Recall@K，意思是「返回的前 K 个结果里是否包含了正确答案所需的文档」。R@2 就是只看前 2 个结果，R@5 看前 5 个。

K 越小越难，因为留给系统犯错的余地越少。它把 ColBERTv2、Contriever、BM25、Propositionizer、RAPTOR 都甩在后面。

效率方面惊人：单步 HippoRAG 的在线检索成本只有 IRCoT（迭代检索）的 1/10 到 1/30，速度快 6-13 倍，但检索效果相当甚至更好。把 HippoRAG 作为 IRCoT 的检索器，还能在 MuSiQue 上再提 4%，在 2WikiMultiHopQA 上再提 18%。

在端到端 QA 上，HippoRAG 带来了最高 17% 的 F1 提升（2WikiMultiHopQA）。用 Llama-3.1-70B 替换 GPT-3.5 做 OpenIE，性能基本不降，但成本大幅下降，使大规模部署成为可能。

不足的是，HippoRAG 的效果高度依赖 OpenIE 的抽取质量，如果 LLM 在信息抽取时犯错（如遗漏实体或提取错误关系），这些错误会传播到整个知识图谱和检索结果中。同义词检测依靠固定阈值的余弦相似度来判断，不够鲁棒，容易漏掉表述差异较大的同义实体或误合并不相关的实体。

A-Mem：用 Zettelkasten 方法让 Agent 自主管理记忆

论文链接：https://arxiv.org/abs/2502.12110
发表时间：2025 年 2 月
机构：罗格斯大学等

动机

LLM Agent 的记忆系统目前有两个层面的问题。

第一，存储方式僵硬。MemGPT 用类似操作系统的缓存层级，MemoryBank 用遗忘曲线调权重，但它们都依赖开发者预定义好的存储结构和检索时机。当 Agent 在全新的任务场景中遇到意外信息，这些固定结构就不够灵活了。

第二，缺乏自组织能力。即使用了图数据库（比如 Mem0），也需要预定义 schema 和关系类型。如果 Agent 学到了一种全新的数学解法，系统只能按现有分类塞进去，无法主动建立跨领域的创新连接。真正的知识管理不应该是被动存储，而应该是记忆之间能自发建立关联、随着新知识的加入不断演化。

A-Mem 的灵感来源是 Zettelkasten 卡片笔记法。这是社会学家 Niklas Luhmann 发明的知识管理方法：每张卡片记录一个原子化的知识点，卡片之间通过手动标注的链接形成网络。Luhmann 用这套方法写了 70 多本书。

A-Mem 把这个思想搬到了 LLM Agent 的记忆系统里，让"建立链接"和"演化记忆"变成自主行为。

主要方法

A-Mem 的整套流程可以分为四个阶段：笔记构建、链接生成、记忆演化、记忆检索。

笔记构建是起点。当 Agent 产生一次新的交互，系统不是简单地把原文存下来就完事。它会让 LLM 对这条交互做一次深度加工，生成三样东西：关键词 Ki（捕捉核心概念）、标签 Gi（用于分类）、上下文描述 Xi（提供丰富的语义理解）。

这三样东西加上原始内容 ci 和时间戳 ti，拼接在一起后通过文本编码器（all-minilm-l6-v2）生成一个嵌入向量 ei。每条记忆就是这样一个多属性的笔记。

链接生成是关键一步。新笔记创建后，系统先用嵌入向量做余弦相似度搜索，找出 Top-K 个最近的历史笔记。然后，把新笔记和这些候选笔记一起交给 LLM，让它判断哪些笔记之间存在有意义的关联。

这里的判断依据不只是语义相似——LLM 可以识别因果关系、概念层级、甚至跨领域的类比，这些是纯向量相似度捕捉不到的。确认有关联的笔记之间建立双向链接。

记忆演化是最有特色的部分。当新笔记与历史笔记建立链接后，系统会反过来审视那些历史笔记：在新信息的光照下，它们的上下文描述、关键词、标签是否需要更新？比如，Agent 之前存了一条关于"二次方程"的记忆，现在遇到了"复数根"的概念。

系统可能会更新旧笔记的上下文描述，加入"可以用来解含复数根的方程"。这就是记忆演化——不只是新记忆在增长，旧记忆也在变得更丰富、更精确。

记忆检索在 Agent 需要做决策时触发。查询文本先编码成向量，然后按余弦相似度找到 Top-K 条最相关的笔记。由于笔记的嵌入包含了原始内容、关键词、标签、上下文描述的综合信息，而且经过了演化更新，检索质量比只存原文要高很多。

整套流程的精妙之处在于：它不需要开发者预定义任何记忆操作。链接的建立和记忆的演化都由 LLM 自主决定。这就是论文标题中"Agentic"的含义——记忆系统本身就是一个 Agent。

总结一下 A-Mem 的整体结构。虽然笔记之间有链接，但检索时走的不是链接遍历，而是向量相似度直接匹配所有笔记。链接的作用主要在写入阶段，帮助判断哪些旧笔记需要和新信息关联、需要更新。所以 A-Mem 更像是一个「带关联关系的向量笔记库」，每条笔记是一张富信息卡片，检索靠向量，关联靠 LLM 判断。

主要结论

在 LoCoMo 数据集（平均 9K token、最多 35 个会话的长对话）上，A-Mem 在非 GPT 模型上全面超越了 LoCoMo、ReadAgent、MemoryBank 和 MemGPT 四个基线。特别是在多跳推理任务上，A-Mem 的 F1 至少是基线的两倍。在 DialSim 数据集上，A-Mem 的 F1 为 3.45，比 LoCoMo (2.55) 高 35%，比 MemGPT (1.18) 高 192%。

效率方面，A-Mem 每次记忆操作只需约 1200 个 token，比基线方法（约 16900 token）减少了 85-93%。每次操作成本不到 $0.0003。处理时间方面，用 GPT-4o-mini 平均 5.4 秒，用本地部署的 Llama 3.2 1B 只需 1.1 秒。

消融实验表明链接生成和记忆演化缺一不可。去掉记忆演化后性能明显下降，同时去掉两者时性能降幅更大。

t-SNE 可视化也直观显示，A-Mem 的记忆嵌入呈现出更清晰的聚类模式，而基线方法的记忆分布杂乱。原因在于 A-Mem 的每条笔记不只存原始内容，还有 LLM 生成的关键词、标签和上下文描述，这些额外信息让语义相近的笔记在向量空间里自然聚拢。再加上记忆进化会持续更新旧笔记的描述，同一话题的笔记会越来越靠近。基线方法只存原文，没有这层语义增强，向量分布自然更散。

不足的是，链接生成依赖嵌入检索加 LLM 判断两步操作，当记忆量极大时，这两步叠加的延迟可能成为瓶颈。此外，A-Mem 缺乏显式的遗忘机制，记忆只增不删，长期运行后过时信息会持续积累，可能干扰检索质量。

程序性记忆：学会了就不会忘

程序性记忆是「怎么做」的记忆。骑自行车、打字、炒菜——你不需要每次都从头学，身体记住了步骤。对 Agent 来说，程序性记忆就是学会的技能和工作流。做过一次「在电商网站搜索产品→加购物车→结算」的流程，下次遇到类似任务直接复用，不用重新摸索。

这个方向挑了两篇，代表了程序性记忆的两种载体。Voyager 用可执行的 JavaScript 代码来表示技能，在 Minecraft 里做终身学习。AWM 用自然语言描述的抽象工作流来表示流程，在网页导航任务上验证。

Voyager：在 Minecraft 里用代码做程序性记忆

论文链接：https://arxiv.org/abs/2305.16291
发表时间：2023 年 5 月
机构：NVIDIA、Caltech等

动机

之前的 LLM Agent 有一个根本性的局限：它们不是终身学习者。能规划、能推理，但学到的东西没有积累机制。每次遇到相似的任务，都得从头来过。

拿 Minecraft 来说。这个游戏没有固定终点，玩家需要在随机生成的 3D 世界里持续探索、收集资源、解锁科技树。一个好的玩家会先砍木头、做工具，再挖矿、冶炼，最终制造钻石装备。关键是：高级技能建立在低级技能之上，而且技能可以跨场景复用——用剑打僵尸和打蜘蛛的逻辑差不多。

当时的 LLM Agent（ReAct、Reflexion、AutoGPT）都缺少这种渐进式的技能积累。它们可以做一次性的规划，但没有一个"技能库"来存储已经学会的能力。而传统 RL 方法虽然能积累，但依赖大量训练数据，且学到的策略不可解释、难以迁移。

Voyager 的核心观点是：用代码作为技能的载体。代码天然可解释，你能看懂它在干什么。代码天然可组合，复杂函数直接调用简单函数。

代码天然可复用，同一个函数在不同场景都能用。这比向量化的记忆或自然语言描述好得多。代码就是可执行的程序性记忆。

主要方法

先交代一下 Minecraft 的背景。这个游戏有一棵技术树：木工具→石工具→铁工具→钻石工具，每一级都需要先掌握上一级的技能才能解锁。Agent 出生在一个随机生成的世界里，没有固定任务线，需要自己决定干什么。

Voyager 的目标是让 Agent 在这个开放世界里尽可能多地发现新物品、解锁新技能。没有固定终点，衡量的是探索广度和技能积累速度。

Voyager 由三个模块组成：自动课程、技能库、迭代式提示机制。

自动课程模块本质上是一个动态任务生成器，负责决定「接下来做什么」。论文叫它 curriculum 是因为它像老师出题一样从易到难。

做法是把 Agent 当前的状态，比如背包里有什么、在什么地形、已经完成了哪些任务，交给 GPT-4，让它提出下一个难度合适的任务。Agent 刚出生什么都没有，它就出「砍一棵树」。有了木头就出「做一个工作台」。

有了工作台就出「做一把木镐」。一路沿着技术树往上升。

关键约束是「发现尽可能多的不同事物」，这驱动 Agent 不断探索新东西而不是反复做已经会的。而且它能根据环境动态调整，Agent 出生在沙漠就先采仙人掌，不会硬按森林的路线走。

技能库模块是 Voyager 的核心记忆系统。每个技能就是一段 JavaScript 函数代码，可以调用 Mineflayer API 来操控游戏角色。比如 craftStoneShovel() 是一个技能，combatZombieWithSword() 是另一个。

每个技能附带一段自然语言描述，通过描述的嵌入向量索引。当 Agent 面临新任务时，系统用任务描述和当前状态做检索，找出最相关的已有技能放进 prompt，作为参考代码。复杂技能可以组合简单技能，比如 buildHouse() 可以调用 mineBlock()、craftItem()、placeItem() 等基础技能。这种组合性让 Agent 的能力呈指数级增长，而不是线性增长。

三个模块的执行顺序是：自动课程出题，技能库检索相关代码放进 prompt，GPT-4 生成新代码去执行。如果执行失败，就进入迭代式提示的内层循环反复修正。成功了就存入技能库，回到自动课程出下一道题。自动课程管「做什么」，迭代式提示管「怎么做到」。

迭代式提示机制解决的是"一次生成的代码往往有 bug"的问题。GPT-4 生成一段代码，在 Minecraft 中执行，然后收集三种反馈。第一种是环境反馈，来自游戏的 chat log，比如"我没法制作铁胸甲，因为还缺 7 块铁锭"。

第二种是执行错误，来自 JavaScript 解释器的报错信息。第三种是自我验证：让另一个 GPT-4 实例充当"评审官"，根据 Agent 当前状态判断任务是否完成，如果没完成就给出改进建议。这三种反馈被塞回 prompt，让 GPT-4 在下一轮修正代码。

这个循环最多重复 4 轮。如果任务成功，代码被存入技能库；如果卡住了，自动课程会换一个任务。

自我验证模块值得特别说明。它不只是判断"成功/失败"，还会分析失败原因并给出具体建议。这比 Reflexion 的自我反思更全面——既检查结果，也诊断问题。

整个系统不需要任何梯度更新或模型微调。Voyager 通过纯黑盒的 API 调用和 in-context learning 实现了终身学习。技能库就是 Agent 的长期记忆，而且是程序性记忆——不是"记住了什么"，而是"学会了怎么做"。

主要结论

在 160 轮 prompt 迭代中，Voyager 发现了 63 种不同物品，是 AutoGPT 的 3.3 倍。ReAct 和 Reflexion 因为缺少课程系统，几乎停滞不前。

科技树解锁速度方面，Voyager 解锁木质工具比基线快 15.3 倍，石质工具快 8.5 倍，铁质工具快 6.4 倍。Voyager 是唯一一个解锁了钻石级别的方法。

地图覆盖方面，Voyager 行进距离是基线的 2.3 倍，探索了沙漠、丛林、雪原等多种地形。

最惊艳的是零样本迁移：把 Voyager 的技能库搬到一个全新的 Minecraft 世界，在库存清零的情况下，它能用已有技能解决全新任务。其他方法在 50 轮迭代内无法完成任何任务。更有趣的是，把 Voyager 的技能库给 AutoGPT 用，AutoGPT 的表现也大幅提升——技能库是一个通用的"即插即用"资产。

消融实验显示：去掉自动课程后物品发现量下降 93%；去掉技能库后后期增长停滞；自我验证是最关键的反馈类型，去掉后物品发现量下降 73%；用 GPT-3.5 替代 GPT-4 做代码生成，物品发现量降为 1/5.7。

不足的是，Voyager 完全依赖 GPT-4 的代码生成能力，换用能力较弱的模型（如 GPT-3.5）效果会大幅下降至原来的 1/5.7。此外，Minecraft 是一个沙盒游戏环境，技能以游戏 API 调用为基础，向真实物理世界的泛化能力尚未得到验证。

AWM：从过去的轨迹里提炼可复用工作流，让 Agent 越做越熟练

论文链接：https://arxiv.org/abs/2409.07429
发表时间：2024 年 9 月
机构：CMU、MIT

动机

当前的 LLM Agent 在网页导航这类"长链路"任务上表现很不稳定。一个订机票的流程可能要点十几步，步骤之间还有依赖关系，稍有差错就前功尽弃。

更关键的问题是：每个任务都是从零开始做。Agent 昨天刚在 Amazon 下过单，今天遇到类似的下单任务，它还是一步一步重新摸索。它不会像人那样——做过几次之后，把"搜索商品 -> 加购物车 -> 填地址 -> 下单"这套流程总结成一个可复用的套路。

已有方法要么把完整的 few-shot 示例塞进 prompt，太长太具体不好迁移。要么手工编写特定网站的操作指南，费人力不通用。核心痛点就是：Agent 不会归纳，缺乏从过往经验中提炼可复用知识的能力。

主要方法

AWM（Agent Workflow Memory）的思路很直接：让 Agent 自己从做过的任务轨迹中归纳出"工作流"（workflow），存到记忆里，下次遇到类似任务就拿出来用。

每个工作流由两部分组成。一段自然语言描述说明它是干嘛的，比如「在地图上按名字找到一个地方」。加上一系列具体步骤，每步包括页面状态描述、推理过程和要执行的动作。关键在于具体值会被替换成变量占位符，“dry cat food” 变成 {product-name}，这样同一个工作流就能适配不同的商品和地址。

归纳过程由 LLM 完成。给它看一批完成任务的动作轨迹，提示它「从这些轨迹中提取重复出现的子程序」。LLM 会找出跨任务反复出现的操作片段，抽象成子任务级的工作流。比如从「订机票到纽约」「订机票到东京」两条轨迹中，归纳出一个通用的「输入出发地和目的地」工作流。

AWM 支持两种模式。离线模式先从训练集的标注轨迹中提炼工作流，测试时直接用。在线模式不需要训练数据，Agent 边做任务边学。

触发条件很简单：任务成功了就触发。每做完一个任务，评估模块判断成功还是失败。成功了就把这条轨迹交给 LLM 归纳工作流，加到记忆里。

失败了就跳过，不从错误中学。越做越多，会的套路越多，后面的任务就越容易做对。

在线模式下还有一个组合生长的能力。Agent 先学会了「按名字找地点」，后来遇到「查某个地点的邮编」，就会复用前面的找地点工作流，再加上「获取邮编」的新步骤，组合出一个更高级的工作流。

归纳出的工作流作为辅助信息加到 Agent 的 prompt 中。Agent 生成动作时既能参考基础操作如 CLICK 和 TYPE，也能参考这些高层工作流来指导决策。论文还试过把工作流封装成可调用的高级动作，类似快捷指令，但发现使用率不高，只有 18.5% 的任务调用了工作流动作，说明当前模型还不太习惯用新工具。

主要结论

在 WebArena 基准上，AWM 在线模式的整体成功率比最强的无人工监督基线 BrowserGym 高出 12 个绝对百分点（51.1% 相对提升），甚至超过了使用 14 条人工编写工作流的 SteP 方法（高 7.9%）。同时，AWM 每个任务平均少走 2 步，效率也更高。

在 Mind2Web 上，AWM 离线模式在 cross-task 测试中步级成功率相对提升 24.6%。在更难的跨网站和跨领域测试中，AWM 在线模式比基线高出 8.9-14.0 个绝对百分点，而且训练/测试分布差距越大，AWM 的优势越明显。

消融实验显示：LLM 归纳出的抽象子程序比规则去重的完整轨迹好用（Mind2Web 上高 2.8 分）；工作流用代码格式还是文本格式差异不大；自然语言描述状态比 HTML 更有效。

不足的是，工作流的粒度固定在子任务级别，面对需要更灵活分解粒度的任务（比如跨多个网站的复杂操作流程）可能不适用。在线模式下，工作流是否该被保留依赖 Agent 的自评估结果，而这种自评估并不总是可靠，可能导致错误的工作流被存入记忆。

给谁记？为谁记？

以用户为中心：记住你是谁

用户中心记忆关注的是：Agent 能不能记住「你是谁」。你的名字、偏好、历史对话、行为模式——这些信息让 Agent 从一个通用工具变成一个懂你的助手。没有用户记忆的 Agent，每次对话都像跟一个陌生人说话。

这个方向挑了三篇。Generative Agents 是斯坦福小镇实验，25 个 AI 居民用记忆流+反思机制过日子，是 Agent 记忆领域的开创性工作。MemGPT 把 LLM 类比成操作系统，用虚拟内存分页的思路管理上下文。Mem0 是目前工业界采用最广的生产级记忆方案，GitHub 25K star。

Generative Agents：斯坦福小镇，25 个 AI 居民靠记忆流+反思+规划过日子

论文链接：https://arxiv.org/abs/2304.03442
发表时间：2023 年 4 月
机构：斯坦福大学

动机

人们一直想造出行为像真人的虚拟角色。但"像真人"这件事太难了。以前的方法要么靠手写规则（有限状态机、行为树），写死了就没法应对开放世界的复杂交互；要么靠强化学习，但只适合有明确奖励信号的对抗游戏，没法处理日常社交这种模糊场景。

大语言模型的出现带来了新可能——它们训练数据中编码了大量人类行为模式，给一个角色设定，就能生成看似合理的回应。但问题是：LLM 是"无状态"的。它不记得昨天发生了什么，不会从经历中总结教训，也没法做出跨越时间的连贯规划。你问它"现在该干嘛"，它可能连续三次回答"吃午饭"。

核心痛点是：如何让 LLM 驱动的角色拥有持续生长的记忆，以及基于记忆的反思和规划能力。

主要方法

这篇论文构建了一个叫 Smallville 的虚拟小镇，灵感来自《模拟人生》，里面住着 25 个 AI 居民。每个居民用一段自然语言描述来初始化，包括职业、性格和人际关系。

整个系统的核心是三大模块：记忆流、反思、规划。

第一个模块是记忆流，一个只增不删的数据库，完整记录 Agent 的所有经历。每条记忆包含三个信息：自然语言描述、创建时间戳、最近访问时间戳。存储方式很朴素，就是一条条自然语言文本按时间顺序追加，每条同时生成一个 embedding 向量用于后续检索。

没有知识图谱，没有复杂的数据库结构。Agent 看到的一切都会存进去。

光有记忆还不够，关键是怎么检索。论文设计了一个三维打分机制。时效性用指数衰减函数，最近的记忆得分高。

重要性让 LLM 直接打 1-10 分，"刷牙"可能只有 1 分，"被告白"能拿 8 分。相关性用 embedding 余弦相似度算当前情境与记忆的匹配度。三个分数归一化后加权求和，取 top-k 塞进 prompt。这样 Agent 每次只取最相关、最重要、最新鲜的那几条，不会被海量记忆淹没。

第二个模块是反思，解决的是「只有原始记忆，没有高层理解」的问题。举个例子：Klaus 经常去图书馆查资料、写论文。如果问他"想跟谁共度一小时"，纯靠观察记忆他会选见面最多的室友 Wolfgang，其实只是路上打个招呼。但如果他能反思出"我对城市化研究充满热情"，再联想到 Maria 也在做研究，就会选择跟 Maria 聊天。

反思机制这样工作：当近期记忆的重要性总分超过阈值 150，就触发反思。先让 LLM 基于最近 100 条记忆提出 3 个高层问题，比如"Klaus 对什么有热情"。然后针对每个问题检索相关记忆，让 LLM 生成带引用的洞察。

这些洞察本身也存回记忆流。反思可以嵌套，Agent 能对之前的反思再做反思，形成一棵从具体观察到抽象理解的记忆树。

第三个模块是规划，让 Agent 的行为在时间维度上保持连贯。每天开始时，Agent 基于自身描述和前一天的经历，生成一个粗粒度的日程。然后递归细化：先分成小时级，再分成 5-15 分钟级。

这些计划也存进记忆流。计划不是死的，当 Agent 感知到新事件，比如看到有人走过来，系统会判断是否需要打断当前计划做出反应。

主要结论

论文展示了令人印象深刻的涌现行为（emergent behavior）。只需要给一个 Agent 设定"想举办情人节派对"这个种子意图，25 个 Agent 就能自主完成：传播消息 -> 互相邀请 -> 有人趁机表白 -> 布置场地 -> 准时到场。这一切没有任何人工编排。

在受控评估中，100 名人类评估者对比了完整架构和各种消融版本生成的回答。完整架构的 TrueSkill 评分显著高于所有消融版本。

具体来说：去掉反思后，Agent 无法做出深层推断（比如基于研究兴趣选朋友）；去掉规划后，行为在时间上不连贯（重复吃午饭）；去掉记忆流后，回答变得泛泛而谈，丢失个性化细节。完整架构的表现甚至略优于人类众包工人撰写的回答，说明这套记忆-反思-规划的组合确实有效。

主要的失败模式包括：检索到不相关的记忆、编造不存在的细节、以及从底层语言模型继承了过于正式的说话风格。

不足的是，实验只涉及 25 个 Agent 的小规模模拟，扩展到几百个 Agent 时的计算成本和可能出现的涌现行为均未知。反思机制的质量完全依赖 LLM 的自我评估能力，如果底层模型的推理不准确，生成的高层洞察也会出错，进而影响后续决策。

MemGPT：把 LLM 当操作系统来用，用虚拟内存管理撑起无限上下文

论文链接：https://arxiv.org/abs/2310.08560
发表时间：2023 年 10 月
机构：UC Berkeley

动机

LLM 的上下文窗口是有限的。当时最主流的开源模型只支持几千到几万 token，即使 GPT-4 Turbo 也只有 128K。这在两个场景下是硬伤：

第一是长文档分析。一份 SEC 年报动辄上百万 token，远超任何模型的上下文。你没法把整篇文档塞进去让模型回答问题。

第二是多轮长对话。一个陪伴型 Agent 可能要和用户聊几个月。对话历史越积越多，早期的重要信息会被挤出上下文窗口，Agent 就"失忆"了。

直接扩大上下文？代价太高，Transformer 的自注意力机制让计算量随上下文长度二次增长。而且即使上下文变长了，模型对中间位置信息的关注度也会下降，这就是 Lost in the Middle 问题。所以需要一种更聪明的方案：不改模型，但让模型"以为"自己有无限上下文。

主要方法

MemGPT 的核心灵感来自操作系统的虚拟内存机制。在传统 OS 里，物理内存有限，但操作系统通过在内存和磁盘之间来回搬运数据（paging），给应用程序造成了"内存很大"的幻觉。MemGPT 对 LLM 做了同样的事情。

MemGPT 把存储分为两大层。主上下文对应操作系统的物理内存，就是 LLM 的 prompt token，模型能直接看到。外部上下文对应磁盘，包括存在数据库里的历史对话和文档，模型看不到，必须主动"调入"才能用。

主上下文进一步分成三个区域。系统指令是只读的，告诉 LLM 自己是 MemGPT，该怎么管理记忆、有哪些函数可以调用。工作上下文是一块固定大小的读写区域，存放用户的关键事实和偏好，类似 Agent 的"置顶笔记"。FIFO 队列滚动存储最近的对话消息和函数调用记录，队列头部维护一个递归摘要，概括已经被挤出去的内容。

外部上下文也分两个存储。回忆存储自动记录所有进出主上下文的消息，相当于完整的对话日志。归档存储用来放 Agent 主动存下来的长期知识，比如用户的偏好总结或者重要文档片段，容量不限。

队列管理器负责"换页"。当 prompt token 接近上下文窗口上限的 70% 时，系统插入一条"内存压力警告"，提醒 LLM 赶紧把重要信息转存到工作上下文或归档存储。如果到了 100%，就强制刷新队列：把最旧的 50% 消息踢出去，更新递归摘要。被踢出的消息不会丢失，它们自动进入回忆存储，随时可以通过搜索函数调回来。

不同存储层的写入方式不一样。回忆存储是全自动的，所有进出主上下文的消息自动存一份，不需要 LLM 决策。FIFO 队列的刷新也是自动的，token 数到阈值就触发。

但工作上下文和归档存储的写入完全靠 LLM 自主决策，这是 MemGPT 的关键创新。系统给 LLM 提供了一组函数，比如 core_memory_append 往工作上下文写信息、archival_memory_insert 存到归档、archival_memory_search 从归档搜索、conversation_search 搜索历史对话。LLM 在对话过程中自己判断什么时候该调哪个。

比如用户提到"我是素食主义者"，LLM 判断这是重要偏好，就主动调 core_memory_append 写入工作上下文。后来聊到吃饭话题时，它就能直接看到这条信息。工作上下文满了或者遇到不需要常驻但将来可能有用的信息，LLM 就调 archival_memory_insert 存到归档里。

记忆的检索和使用也分层。工作上下文是始终可见的，不需要检索，LLM 每次推理都能直接看到里面的内容。这就是为什么要把最重要的用户偏好放在这里。

归档存储和回忆存储就需要主动检索了。LLM 觉得当前问题需要查阅历史信息时，会调 archival_memory_search 或 conversation_search，传入一个查询关键词，系统返回最匹配的条目插入当前上下文。检索结果临时占用主上下文的空间，用完了可能在后续的队列刷新中被挤出去。

LLM 还可以连续执行多个检索函数再回复用户。比如回答一个需要查阅多篇文档的问题时，先搜文档 A、再搜文档 B、把结果拼到上下文里，最后统一回答。这种链式调用让 Agent 能处理需要多步检索的复杂问题。

主要结论

在多轮对话任务中，MemGPT 在 Deep Memory Retrieval 测试中显著优于固定上下文基线。基线只能看到过去对话的有损摘要，而 MemGPT 能通过搜索回忆存储找到原始对话细节。在 Conversation Opener 任务中，MemGPT 生成的开场白在个性化程度上接近甚至超过人类撰写的开场白。

在文档分析任务中，固定上下文基线的表现受限于检索器返回的文档数量（因为上下文装不下更多）。MemGPT 则可以通过多次调用归档存储搜索，翻页浏览检索结果，有效利用远超上下文窗口大小的文档库。在嵌套 Key-Value 检索任务中（需要多跳查找），GPT-4 在嵌套 3 层时准确率降到 0%，而 MemGPT + GPT-4 不受嵌套层数影响，始终保持高准确率。

总的来说，MemGPT 证明了一个重要观点：不需要等更长上下文的模型出来，用 OS 式的内存管理就能在固定窗口内做到"类似无限上下文"的效果。

不足的是，记忆的换入换出完全依赖 LLM 自主决策，决策质量不稳定，模型可能在关键时刻忘记保存重要信息或检索错误的记忆。整个系统没有学习信号，纯靠系统提示词控制 LLM 的记忆管理行为，无法从错误中改进策略。

从现在的视角回看，MemGPT 提出的分层存储、LLM 自主管理记忆、函数调用读写这套框架，已经成了 Agent 记忆系统的标配思路。后面的 Mem0、Letta 乃至 Claude 和 ChatGPT 的记忆功能，多多少少都能看到这套设计的影子。

它的真正价值不在于某个具体技术多先进，而是第一个把操作系统的内存管理范式完整地搬到了 LLM 上来，给后续所有工作定义了问题框架。

Mem0：面向生产的长期记忆系统，增量处理 + 四操作更新

论文链接：https://arxiv.org/abs/2504.19413
发表时间：2025 年 4 月
机构：Mem0.ai

动机

即使上下文窗口越来越大，GPT-4 有 128K、Claude 有 200K、Gemini 有 10M，"把所有对话历史塞进上下文"这条路走不通。原因有两个：

第一，实际对话很少是连续的。用户上午聊饮食偏好，下午聊了三个小时编程，晚上又回来问晚饭吃什么。那条"我是素食主义者"的信息被埋在几万 token 的代码讨论之下，模型很可能找不到它。

第二，成本和延迟不可接受。每次回答问题都要把 2.6 万 token 的完整对话送进模型，p95 延迟高达 17 秒，token 开销巨大。在医疗、教育、客服这类生产环境中，这种方案根本没法用。

已有的记忆方案也各有缺陷。RAG 把对话切成块来检索，但块的粒度难以把控，太粗了噪音多，太细了语义不完整。MemGPT 的内存管理机制很优雅但偏学术，缺少工程层面的落地打磨。

OpenAI 内置的记忆功能在时间推理上表现很差，生成的记忆经常丢失时间戳。核心诉求：一个工程上能落地、延迟低、成本省、又能跨会话保持一致性的记忆系统。

主要方法

Mem0 的设计哲学是"增量处理"——不是一口气处理整段对话，而是每来一对消息就实时提取和更新记忆。系统分为提取（Extraction）和更新（Update）两个阶段。

先说提取阶段。每当收到一对新消息，系统需要判断这轮对话里有没有值得记住的信息。怎么判断？

把当前消息连同两种背景信息一起交给 LLM。第一种背景是对话摘要，概括了整段对话到目前为止的主旨。第二种是最近 m 条消息原文，提供细粒度的上下文。

LLM 综合这三样输入，提取出若干「候选事实」。比如用户这轮说了「我最近开始吃素了，下周要去东京出差」，LLM 就会提取出「用户是素食主义者」和「用户下周去东京出差」两条候选事实。对话摘要通过一个异步模块定期刷新，不阻塞主流程。

更新阶段是 Mem0 最核心的设计。对于每条候选事实，系统先用向量 embedding 从数据库中检索 top-s 条语义相似的已有记忆。然后把候选事实和这些已有记忆一起交给 LLM，让它通过 function calling 选择四种操作之一：ADD（新增——数据库中没有语义等价的记忆时）、UPDATE（更新——已有记忆需要补充新信息时）、DELETE（删除——新信息与旧记忆矛盾时，比如"用户搬家了"就要删掉旧地址）、NOOP（不操作——候选事实不需要改变知识库时）。

这四种操作确保了记忆库的一致性和时效性。注意，这不是用一个单独的分类器来判断操作类型，而是直接利用 LLM 的推理能力来决策。

在基础版之上，论文还提出了图记忆增强版 Mem0^g。它和基础版的文本事实记忆是并行互补的关系，不是替代。基础版把记忆存成一条条独立的文本事实，事实之间没有显式关联。

图记忆额外维护一张知识图谱，把同样的信息组织成节点和边：节点是实体，比如人、地点、概念。边是关系，比如住在、喜欢、拥有。这样实体之间的关系就显式地建模了。

提取时先用 LLM 识别实体，再推断实体间的关系，生成三元组，比如 Alice-lives_in-San_Francisco。存储时用向量相似度判断是否要合并到已有节点。

检索时两套系统同时工作。基础版的文本记忆走向量相似度检索，和前面更新阶段用的是同一套 embedding。图记忆走双通道：一条路从查询中识别实体在图上展开邻居，另一条路把整个查询和所有三元组做向量匹配。

两边的结果合并后一起拼进 prompt 交给 LLM 生成回答。因为记忆是精炼的事实而非大段原始对话，token 消耗极低。图记忆在需要时间推理和关系推理的任务上比纯文本记忆更强，两者互补。

主要结论

在 LOCOMO 长对话记忆基准上测试，每段对话约 600 轮、26000 token。Mem0 在"LLM-as-a-Judge"指标上比 OpenAI 内置记忆高出 26% 相对提升。单跳问题 J=67.13，多跳问题 J=51.15，时间推理 Mem0^g 达 J=58.13，三项均为最高。

效率方面的数字更亮眼。Mem0 的 p95 延迟仅 1.44 秒，全上下文方案是 17.1 秒，降了 91%。token 消耗平均 7K，全上下文是 26K，省了 90% 以上。对比商业记忆平台 Zep，Zep 的图记忆消耗超过 600K token，Mem0^g 只需 14K，而且 Zep 的后台图构建可能需要几小时才能生效，Mem0 的记忆构建在一分钟内完成。

不过 Mem0 也不是全面碾压。在开放域问题上，Zep 的 J 分 76.60 略高于 Mem0^g 的 75.71。全上下文方案的 J 分约 73% 仍然高于 Mem0 的 67%，因为完整上下文本身就包含了所有信息。但考虑到 Mem0 的延迟和成本优势，这个精度差距在生产环境中是完全可以接受的。

不足的是，ADD/UPDATE/DELETE/NOOP 四种操作的决策完全依赖 LLM 的推理能力，在复杂场景下可能误判，比如把新增信息误认为是对旧信息的更新而覆盖。图记忆版本的关系抽取在通用对话场景下表现不错，但迁移到医疗、法律等专业领域时准确率还没有验证。

以 Agent 为中心：从错误中学习

Agent 中心记忆关注的是 Agent 自己的成长。它记的不是用户信息，而是自己的经验——哪些方法有效、哪些操作失败过、学到了什么技能。这类记忆让 Agent 能从试错中进步，而不是每次都犯同样的错。

这个方向挑了一篇最具代表性的：Reflexion，开创了「语言强化学习」范式，让 Agent 通过自然语言反思而不是梯度更新来从失败中学习。前面的 Voyager 也属于 Agent 中心记忆，不过它的载体是代码技能库，已在程序性记忆里介绍过了。

Reflexion：不更新权重的强化学习，用自然语言反思代替梯度下降

论文链接：https://arxiv.org/abs/2303.11366
发表时间：2023 年 3 月
机构：Northeastern University、Princeton等

动机

用 LLM 做 Agent 去完成任务（玩游戏、写代码、查资料），核心的学习方式本应是"试错"——做错了就改，下次做得更好。但传统强化学习（RL）的试错要靠梯度更新模型权重，这对 LLM 来说代价太高：需要海量训练样本，需要昂贵的微调，而且很慢。

更根本的问题是，传统 RL 的奖励信号太粗糙了。一个标量奖励（成功=1，失败=0）告诉你"做错了"，但不告诉你"错在哪"、“下次怎么改”。这就是经典的信用分配问题（credit assignment problem）——在一条包含几十步的决策轨迹中，到底是哪一步导致了失败？

已有的一些改进方案也有局限。Self-Refine 这类方法能在单步生成任务上自我纠错，但没有跨 episode 的记忆——它不记得上一轮犯过什么错。那些纯重试的方法（不做反思，只是重新运行一遍），在简单任务上靠随机性能碰对，但在复杂任务上就失灵了。

核心问题：能不能不改权重，用自然语言的"反思"来代替梯度，让 Agent 从失败中学习？

主要方法

Reflexion 的架构由三个角色组成：Actor（执行者）、Evaluator（评估者）、Self-Reflection（反思者），再加上一个存放反思结果的记忆缓冲区。

Actor 就是实际干活的 LLM Agent。它可以用不同的推理框架——Chain-of-Thought（适合推理任务）或 ReAct（适合需要与环境交互的决策任务）。Actor 根据当前环境状态和记忆中的过往反思来生成动作。

Evaluator 负责给 Actor 的表现打分。这个打分可以有多种形式：精确匹配（答案对不对）、启发式规则（比如在 AlfWorld 里检测是否陷入了循环——同一个动作重复 3 次以上说明卡住了）、或者用另一个 LLM 来判断。在编程任务中，Evaluator 更有意思——它用 Agent 自己生成的单元测试来评估代码是否正确。

Self-Reflection 是整个框架的核心。当 Evaluator 判定任务失败后，反思模块接收三样输入：失败的轨迹、奖励信号、以及之前的反思记忆。然后它生成一段自然语言的反思总结，分析失败的原因并给出改进建议。

比如在 AlfWorld 中，Agent 可能反思道："我以为自己拿了锅铲，但其实忘了从抽屉里拿出来，就直接去了灶台。下次应该先确认物品在手里再移动。"这段反思被存入记忆缓冲区（通常限制最多存 1-3 条最近的反思，以控制 prompt 长度）。

完整的学习循环是这样的： 第 1 轮，Actor 尝试完成任务，生成轨迹 tau_0。Evaluator 打分 r_0。如果失败，Self-Reflection 分析 {tau_0, r_0}，生成反思 sr_0，存入记忆。

第 2 轮，Actor 在生成动作时除了看环境状态，还会看到记忆里的 sr_0，从而避免重蹈覆辙。如此循环，直到成功或达到最大轮次。

在编程任务中的特殊设计。Reflexion 用了一个巧妙的自我评估手段：让 Agent 先生成一组单元测试，然后运行自己写的代码跑这些测试。测试通过就提交，测试失败就把错误信息交给反思模块。

这让反思的质量远比单纯的"成功/失败"信号高得多——"第 3 个测试用例报了 IndexError，说明边界条件没处理好"比"你错了"有用多了。论文指出，这里有一个微妙的取舍：假阳性（测试全过但代码有 bug）会导致过早提交错误答案；假阴性（测试报错但代码其实是对的）反而还好处理——Agent 可以通过反思发现是测试写错了。

短期记忆和长期记忆的配合。在 RL 的框架下，当前 episode 的轨迹历史是短期记忆（提供精细的近期细节），而反思模块的输出存入长期记忆，提供跨重试轮次的经验教训。不过要注意，这里的「长期」只是同一个任务内多次重试之间的记忆，不跨任务。

做完一个任务换下一个，记忆会清空。两者结合让 Agent 既能记住刚才做了什么，也能回忆起上一轮的失败教训。

主要结论

在 AlfWorld（文本世界里的家务决策任务）上，ReAct + Reflexion 在 134 个环境中成功完成 130 个，比纯 ReAct 基线高出 22 个百分点。学习曲线显示，前 2 轮提升最快（Agent 快速纠正了"以为自己拿了东西但其实没拿"这类常见错误），随后稳步提升到近乎完美。相比之下，纯 ReAct 基线到第 6-7 轮就不再进步，卡在 22% 的幻觉率上。

在 HotPotQA（多跳问答）上，Reflexion 比基线提升 20 个百分点。即使给了 ground truth 上下文的 CoT (GT) 基线，也有 39% 的问题答不对，加上 Reflexion 后又额外提升了 14%。消融实验证明，纯粹的 episodic memory（只是把上一轮轨迹放进 prompt）只带来一部分提升，而自然语言的反思在此基础上再加 8 个百分点。

在编程任务上，Reflexion 在 HumanEval 上达到 91% pass@1，超过当时 GPT-4 的 80%。消融实验显示：去掉单元测试生成（只靠反思不靠测试反馈），准确率从 91% 掉到 52%——说明具体的错误信息对反思质量至关重要；去掉反思（只靠测试反馈重试），准确率也比完整方案差——说明"知道错在哪"和"知道怎么改"是两件事，后者需要反思来完成。

Reflexion 的局限也很明确：它在需要大量探索多样性的任务（如 WebShop 电商搜索）上效果不好，因为 Agent 的搜索查询变不出太多花样。但在大多数可以通过定向纠错来逐步逼近正确答案的任务上，Reflexion 是一种极其轻量且高效的学习方式。

不足的是，反思的质量完全取决于 LLM 的自我评估能力，对于推理能力较弱的模型，生成的反思可能不准确甚至误导后续尝试，效果有限。此外，记忆缓冲区最多只保留 3 条最近的反思，长期积累的策略和经验受限，无法支撑需要大量历史教训的复杂任务。

记忆的工程学：怎么存、怎么找、怎么忘

存储与检索

知道该记什么之后，下一个问题是怎么存、怎么找。目前主流的存储方式大致有这么几种。最常见的是向量数据库，把文本编码成 embedding 向量，检索时按余弦相似度匹配，前面的 A-Mem 和 Memoria 都用了这种方式。

第二种是知识图谱，把信息组织成实体和关系，前面的 AriGraph 和 HippoRAG 是代表。第三种是 KV Cache 级别的操作，直接在 Transformer 的键值缓存上做文章，比如压缩、淘汰、分页管理，MemGPT 的 FIFO 队列就属于这个范畴。第四种是纯文本列表，Generative Agents 的记忆流就是这种最朴素的方式。

每种方式各有取舍。向量数据库灵活但缺乏结构，知识图谱有结构但构建成本高，KV Cache 操作快但容量受限，纯文本简单但检索效率低。

这个方向挑了两篇，关注的不是底层用什么数据库，而是存储结构的设计和检索策略。RAPTOR 用递归聚类+摘要构建多层抽象树，让检索能同时看到细节和全局。SCM 给 LLM 装了一个「自控记忆器」，让模型自己决定什么时候需要回忆、回忆什么。

RAPTOR：用递归摘要树让检索"看得更远"

论文链接：https://arxiv.org/abs/2401.18059
发表时间：2024 年 1 月
机构：斯坦福大学

动机

RAG（检索增强生成）已经是 LLM 落地的标配了。但现有 RAG 方案有一个很本质的问题：它只检索短的、连续的文本块。

你想想灰姑娘的故事。如果问"灰姑娘是怎么获得幸福结局的？"，答案散落在全文的各个地方——水晶鞋、午夜逃跑、王子寻人、最后相认。传统 RAG 用 top-k 检索出的短片段，根本覆盖不了这些跨越全文的信息。

这个问题在需要全局理解的任务上尤其严重：读一本书、理解一篇长论文、回答需要多步推理的问题。DPR 和 BM25 这些检索器只能看到局部，看不到全局主题。

另一条路是把上下文窗口拉长。但研究已经表明，模型对长上下文的利用率其实在递减——越往中间塞的信息越容易被忽略（“Lost in the Middle”）。而且长上下文又贵又慢。

RAPTOR 的出发点很直接：既然单一粒度的检索不够用，那就构建一个多粒度的索引结构，让检索本身就能提供从细节到全局的不同层次信息。

主要方法

RAPTOR 的核心思路是：自底向上地构建一棵"摘要树"。最底层是原始文本块，往上每一层都是对下层节点的聚类摘要，越往上信息越抽象、越全局。

第一步是分块和嵌入。语料被切成 100 token 左右的短文本块，跟传统 RAG 一样。但如果一个句子超了 100 token 的限制，整个句子会被推到下一个块里，避免把句子切断。

每个块用 SBERT 编码成向量。这些块就是树的叶子节点。

第二步是聚类。这里用的不是简单的 K-Means，而是高斯混合模型（GMM）做软聚类。所谓"软聚类"，就是一个节点可以同时属于多个簇。

为什么要这样？因为一段文本可能同时涉及多个主题，硬性分到一个簇里会丢信息。具体实现上，先用 UMAP 把高维向量降维（高维空间里距离度量会失效），然后用 BIC（贝叶斯信息准则）自动确定最优簇数，最后用 EM 算法估计 GMM 参数。聚类还分两层：先全局聚类找大主题，再在每个大簇内做局部聚类找子主题，形成层级结构。

第三步是摘要。每个簇里的节点文本被送给语言模型生成摘要，压缩比大约 72%。这些摘要就是簇内叶子节点的父节点，是对它们的语义概括。摘要再被编码成向量，作为新的节点进入下一轮。

然后递归。这些摘要节点继续聚类、继续生成更高层的摘要，一层层往上堆。每一层的节点都是下面那些子节点的概括，粒度越往上越粗。

最终因为聚类不一定把所有节点聚成一个大簇，形成的是一片森林而不是一棵树，可能有多棵树各自覆盖不同主题。叶子层是原文，中间层是局部摘要，顶层是最粗粒度的全局概括。整个过程的计算复杂度是线性的——无论是 token 消耗还是构建时间都和文档长度成正比，在普通 M1 Mac 上就能跑。

查询阶段有两种策略。第一种叫"树遍历"：从根节点开始，每一层选 top-k 最相关的节点，逐层向下搜索。第二种叫"折叠树"：把所有层的节点拍扁成一层，直接在全部节点上做 top-k 检索。

实验表明折叠树效果更好，因为它更灵活——面对不同粒度的问题，它能自动选择合适层级的节点，而树遍历每层固定取 k 个，比例是写死的。最终论文用的是折叠树 + 2000 token 上限（约 top-20 节点）。

值得注意的一个细节：论文对摘要做了幻觉分析。在 150 个随机节点中，约 4% 包含轻微幻觉（比如添加了原文没有的小细节）。但这些幻觉不会向上传播到父节点，对下游 QA 也没有可观测的影响。

主要结论

在三个 QA 数据集上，RAPTOR 全面超过传统检索方法：

• QuALITY（中等长度多选题）：RAPTOR + GPT-4 达到 82.6% 准确率，比之前最好的 CoLISA 高出 20.3%，在困难子集上更是高出 21.5%。
• QASPER（NLP 论文问答）：RAPTOR + GPT-4 的 F1 为 55.7%，超过 CoLT5 XL 的 53.9%，刷新 SOTA。
• NarrativeQA（书籍/电影全文问答）：RAPTOR + UnifiedQA 在 METEOR 指标上刷新 SOTA，超过同样用递归摘要的 Wu et al. (2021) 的方法——因为后者只用了树顶的摘要，而 RAPTOR 利用了所有层。

消融实验发现，18.5%–57% 的检索结果来自非叶子节点，说明高层摘要节点确实在发挥作用。

不足之处：树构建依赖 LLM 摘要质量，约 4% 摘要有轻微幻觉；查询时无法动态更新树结构，新文档加入需要重建整棵树。

SCM：给 LLM 装一个自主控制的记忆系统

论文链接：https://arxiv.org/abs/2304.13343
发表时间：2023 年 4 月
机构：北航、字节跳动

动机

LLM 有一个非常现实的问题：上下文窗口有限，历史信息会丢。

论文举了一个例子：在一段很长的对话里，用户在第 5 轮说了自己的爱好，到了第 105 轮再问"你还记得我的爱好吗？"，即使是 ChatGPT 也会被中间大量无关对话干扰，回答错误。

更要命的是，不是所有用户输入都需要调用记忆。"给我讲个笑话"不需要历史信息，"你还记得上周我们讨论的健身饮食结论吗？"才需要。如果一股脑把所有历史都塞进去，不但浪费 token，还会引入噪声。

2023 年中的方案要么是改注意力结构，需要重新训练。要么是做位置编码扩展，泛化能力存疑。要么是简单的分段摘要，会丢掉段落间的依赖关系。

SCM 想做的是：不改模型、不训练，用一个即插即用的记忆框架让任何 LLM 都能处理无限长输入，而且自己决定什么时候用记忆、怎么用记忆。

主要方法

SCM 由三个核心组件构成：LLM Agent（骨干模型）、Memory Stream（记忆流）、Memory Controller（记忆控制器）。

Memory Stream 是一个结构化的存储系统。每当一轮对话完成，系统自动生成一条记忆存进去。每条记忆包含五个字段：

1. 交互索引：第几轮对话，自动编号
2. 观察：用户说的话，直接存原文
3. 系统响应：LLM 回复的内容，也存原文
4. 记忆摘要：用 LLM 对这轮「观察+响应」做一次压缩总结，保留关键信息
5. 嵌入向量：对摘要文本做 embedding 编码，用于后续的语义检索

前三个字段是直接记录的原始数据，后两个是系统自动加工生成的。摘要和向量是为了检索方便，原文是为了在需要时能回溯完整细节。

使用记忆时分两种取法。闪存只取上一轮的那条记忆，提供最近的对话上下文。激活记忆从整个记忆流里按相关性和时近性检索 top-k 条，提供跨轮次的历史信息。

两者格式一样，区别在于取的范围不同。闪存保证当前连贯性，激活记忆负责长距离回忆。

Memory Controller 是整个框架的大脑，它通过"自问自答"两个问题来控制记忆的使用。

第一个问题：“当前用户输入是否需要激活记忆？“论文设计了一个 prompt，让控制器自己判断。如果判断"不需要”，就直接回答，省掉检索开销。如果判断"需要”，就进入记忆检索流程。

检索时，用当前输入作为 query，对每条记忆计算 rank_score = recency_score + relevance_score。时近性（recency）偏向最近交互过的记忆，相关性（relevance）用 cosine 相似度衡量。按分数取 top-k（k 在 3 到 10 之间）。

第二个问题："能否只用记忆摘要来回答当前问题？"这是为了应对单条记忆太长的情况。如果某条激活记忆超过 800 token，且所有激活记忆总长超过 2000 token，控制器会判断摘要是否足够回答问题。如果够用，就用摘要代替原文，省下上下文空间。

记忆摘要的生成也有讲究。论文发现直接用原始对话文本做嵌入效果不好，因为用户输入和系统回复长度差异大，语义信息不平衡。所以是把观察摘要和响应摘要拼起来作为语义表示，再生成嵌入向量。

最终送给 LLM 的 prompt 由三部分拼成：系统指令告诉 LLM 它的角色和当前任务，闪存提供上一轮对话的即时上下文，激活记忆提供检索出来的历史信息。三部分加上当前用户输入，一起送进 LLM 生成回复。

注意这里没有完整的多轮对话历史。常规聊天系统会把最近 N 轮对话原文都放进 prompt，SCM 不这么做。除了上一轮，更早的历史全部靠记忆检索来获取。

这是一个很激进的设计，好处是 prompt 长度始终可控，不随对话轮数增长。代价是如果检索没找到正确的历史记忆，LLM 就真的不知道之前说了什么。

整个工作流串起来就是：接收用户输入，判断是否激活记忆，检索 top-k 记忆，决定用原文还是摘要，拼装 prompt，生成响应，存入记忆流。六个步骤循环往复。

主要结论

论文标注了一个涵盖三个任务的评测集：长期对话（token 数从 2 万到 200 万）、书籍摘要、会议摘要。

长期对话实验表明：

• SCM + text-davinci-003（注意，这不是对话优化模型）在记忆检索召回和多轮问题准确率上都超过了 ChatGPT。
• 消融实验里，去掉激活记忆后准确率暴跌约 60%，记忆检索召回和多轮准确率直接归零——说明长距离依赖全靠激活记忆。
• 去掉闪存只有轻微影响，去掉记忆控制器在多轮问题上影响更大（因为没有控制器就只能暴力拼接+截断，信息丢失严重）。

摘要任务中，SCM 在覆盖度和连贯性上都优于递归摘要基线，人类评估也更偏好 SCM 的结果。

不足之处：记忆控制器的自问自答机制增加了推理轮次，每次交互都要多走两步判断，延迟开销不可忽略。记忆检索只用了时近性和相关性两个维度，没有重要性维度，可能导致频繁但琐碎的记忆排在前面。

压缩与摘要

记忆不能无限膨胀，需要压缩。压缩的核心问题是：怎么用更少的空间保留最有价值的信息？简单截断会丢关键细节，通用摘要会抹平差异。好的压缩应该是有选择性的——知道什么重要、什么可以丢。

这个方向挑了一篇 Dynamic Cheatsheet，思路很有意思：不是压缩历史对话，而是从解题经验中提炼可复用的策略存成「速查表」，让模型边做题边积累解题技巧。

Dynamic Cheatsheet：让模型在考试中"越做越会"

论文链接：https://arxiv.org/abs/2504.07952
发表时间：2025 年 4 月
机构：斯坦福大学

动机

LLM 有一个反常识的问题：它不会从做题中学习。

你让 GPT-4o 做 100 道 Game of 24（给四个数字，用加减乘除凑出 24），它在第 1 题和第 100 题上犯的是同样的错误。它不会因为前面做对了某道题，就在后面的类似题上表现更好。每道题都是从零开始推导。

这跟人类完全不同。人类做第 5 道题的时候已经总结出一些套路了，到第 20 道题可能已经发现写个小程序暴力枚举更靠谱。

现有方案也有局限。微调成本太高，而且黑盒 API 根本改不了参数。RAG 能提供外部知识，但那些知识是静态的、事先准备好的，不是从做题过程中动态积累的。

把完整对话历史塞进 prompt？上下文爆炸不说，噪声还特别多——实验表明这种做法（Full-History Appending）甚至会让 GPT-4o 的表现从 20% 降到 6.7%。

DC 要做的事情很简单：给黑盒 LLM 加一个持久的、自演化的外部记忆，让它在推理时就能积累经验、复用策略，本质上是一种 test-time learning。

主要方法

DC 的核心循环只有两个模块：Generator（生成器）和 Curator（策展器）。两者可以是同一个模型的不同 prompt，也可以是不同模型。

Generator 的工作是：给定新问题 x_i 和当前记忆状态 M_i，生成答案 y_i。记忆的内容会被注入 prompt，让模型在推理时就能复用之前积累的策略、代码片段、解题技巧。

Curator 的工作是在生成答案之后更新记忆。这里的「记忆」存的不是对话历史，而是可迁移的解题策略。比如数学任务里存的是代数技巧，算法任务里存的是 Python 暴力搜索模板，知识问答里存的是公式的简洁参考。本质上就是一张不断更新的「考试小抄」。

Curator 具体做三件事。第一，判断新答案是否有用且可迁移，有用就提炼成可复用的形式存入记忆。第二，评估现有记忆条目是否需要修正或淘汰，如果某条策略被更好的取代了就更新。

第三，保持整个记忆简洁紧凑，防止上下文膨胀。关键的一点是 Curator 没有 ground-truth 标签，它必须自己判断答案是否正确。

论文提出了两个变体。DC-Cu（Cumulative）是"先做题再更新记忆"：做完第 i 题后更新记忆，第 i+1 题使用更新后的记忆。它没有检索模块，记忆是累积式增长的。

DC-RS（Retrieval & Synthesis）改进了两个问题。首先，它在做题之前就更新记忆——先用 embedding 检索出与当前问题最相似的 top-3 历史问答对，传给 Curator 做记忆更新，然后再用更新后的记忆去做题。其次，它引入了显式的检索机制，让模型可以直接参考过去的具体案例。步骤是：检索 -> 策展更新记忆 -> 生成答案。

记忆的内容非常关键。DC 存的不是完整的对话记录，而是被提炼过的策略片段。比如在 Game of 24 里，记忆可能只存"使用 Python itertools.permutations 暴力枚举所有四则运算组合"这样一条通用策略。

在 AIME 数学竞赛里，可能存的是"处理几何题时先建坐标系"这种启发式规则。这种精炼的记忆既省 token 又可迁移。

DC 的一个精妙之处在于它催化了工具使用。GPT-4o 在 Game of 24 里，早期几道题还在手动算术，后来自己"发现"了写 Python 暴力搜索更靠谱，就把这个代码存进记忆。之后的 90 多道题全是直接调用这段代码，命中率飙到 99%。DC 没有强制模型使用工具，是模型自己在记忆系统的辅助下学会了这一点。

不过 DC 不是万能的。小模型（GPT-4o-mini、Claude 3.5 Haiku）效果有限，因为它们基础能力不够——做对的题太少，记忆里积累的是错误策略，越记越差。DeepSeek R1 这种推理模型的输出又太长太啰嗦，也不适合存入紧凑记忆。DC 本质上是放大器，放大的是模型已有的能力。

主要结论

DC 的效果在强模型上非常惊人：

• Game of 24：GPT-4o 从 10% 飙到 99%（DC-RS），本质上是学会了写代码暴力搜索。
• AIME 2024：Claude 3.5 Sonnet 从 23.3% 翻倍到 50.0%（DC-Cu），比 Full-History Appending 的 26.7% 强得多。
• GPQA-Diamond（研究生级别科学题）：Claude 3.5 Sonnet 提升 9.1%（59.6% -> 68.7%）。
• Math Equation Balancer：Claude 从 44.8% 升到 98-100%，GPT-4o 从 50% 升到 99-100%。
• DC 还显著优于多数投票（Majority Voting），后者在 AIME 上完全没有提升。

不足之处：小模型获益有限（基础能力太弱，记忆里充斥错误策略，越记越差）；策展器（Curator）没有真实标签，自评估可能不准确，尤其在困难任务上容易把错误答案当成正确策略存入记忆。

遗忘与保留

遗忘听起来是坏事，但其实是记忆系统的必要能力。人脑每天接收海量信息，绝大部分会被遗忘，这是一种高效的资源管理策略。Agent 也一样——不是所有信息都值得存，主动丢弃低价值内容才能把有限的记忆预算花在刀刃上。

这个方向挑了一篇 BudgetMem，做的是在文档摄入阶段就用简单特征做块级筛选，只保留 30% 的高价值内容。整个过程不需要任何神经网络，在 10 美元/月的 Colab 上就能跑。

BudgetMem：给长文档"瘦身"的极简方案

论文链接：https://arxiv.org/abs/2511.04919
发表时间：2025 年 11 月
机构：UT Arlington

动机

长上下文处理太贵了。一次 100K token 的查询成本超过一美元。一家律所分析几千份合同，一个研究生调研几百篇论文，很快就把计算预算花光了。

现有方案分两派。一派是从架构层面扩展上下文窗口——稀疏注意力、线性注意力、RoPE 位置编码——但推理时还是要处理全部输入，内存和延迟都没省下来。另一派是上下文压缩，比如 LLMLingua 用小模型给每个 token 打困惑度分数，丢掉不重要的 token。这类方法确实有效，但需要额外的神经网络来做压缩，还可能需要针对不同任务微调。

BudgetMem 走了一条完全不同的路：在块级别（chunk-level）做取舍，而不是 token 级别。它用几个简单的、可解释的统计特征给每个段落打分，低于预算阈值的直接丢弃，永远不进入检索索引。全程不需要任何训练和 GPU 压缩。

为什么粒度很重要？论文做了一个令人印象深刻的对比：在 5 万到 10 万 token 的 NarrativeQA 文档上，token 级别的 TF-IDF 剪枝把 F1 压到了 0.0007——几乎为零。因为散落各处的高分 token 拼起来是 “John traveled…Paris saw…historical museums” 这种不知所云的碎片，连 BM25 检索都没法用。块级别选择保留的是完整段落，语义完整、检索友好。

主要方法

BudgetMem 的流程分为两个阶段：离线写入和在线查询。

离线阶段有四步。第一步是分块：把文档切成 150 token 的段落，30 token 重叠。第二步是打分：用五个可解释特征给每个块打一个加权分数。

第三步是选择：按分数排名，保留前 30% 的块（默认预算比率）。第四步是索引：对保留的块建 BM25 索引。

五个打分特征是 BudgetMem 的核心。实体密度（权重 0.2）：用 spaCy NER 统计每个 token 对应的命名实体密度，实体多的块通常包含事实性内容。TF-IDF 重要性（权重 0.2）：块内 token 的平均 TF-IDF 分数，词汇越独特说明内容越重要。

位置偏置（权重 0.15）：一个 U 型打分，开头和结尾的块得分更高——因为引言和结论通常包含关键信息。数值密度（权重 0.15）：数字 token 的比例，统计数据、日期、数量往往是查询相关的。话语标记（权重 0.1）和问句存在（权重 0.1）：像 “however”、“in conclusion” 这样的话语标记和嵌入式问句，标志着结构性和主题性内容。

五个权重是在一个小开发集上调一次，之后在所有基准测试上固定不动。完全不需要 per-task 调参。

查询阶段也很简单：用 BM25 在保留的块集合中检索 top-3，拼接后作为上下文送给 Llama-3.2-3B-Instruct 生成答案。全程不用任何神经检索器，保持 training-free 的特性。

BudgetMem 在什么情况下好用？三种场景效果最好。第一种是答案集中在特定段落的问题，比如问论文的方法、问某个人名、问核心结论。

这些答案通常出现在实体密度高或关键词突出的段落里，正好是打分器会保留的块。第二种是结构清晰的文档，比如有引言、方法、结论等章节的论文。章节边界让打分器容易区分重要段落和背景填充。第三种是长文档，因为同一个知识点可能在多个段落里被提到，即使丢了一个块，类似信息在别的块里还能找到。

什么情况下不行？分布式信息。"A 和 B 的关系如何影响了 C 的决定？

"这种多跳问题需要拼接多个段落，有些段落可能被剪掉了。短文档也不行——SQuAD 的维基百科段落里每个块得分都差不多，强制丢弃 70% 会误伤。

主要结论

在三个基准上的表现：

• 中等长度文档（合成论文，5K-10K token）：72.4% 内存节省，F1 仅下降 1.0%。这是 BudgetMem 最理想的使用场景。
• 超长文档（NarrativeQA，50K-100K token）：达到 LLMLingua 87% 的 F1 水平（0.0351 vs 0.0402），但完全不需要 GPU 压缩。
• 短文档（SQuAD，237 token）：15.5% 内存节省，但 F1 下降 9.7%——压缩空间太小。
• 预算敏感性分析显示 30-40% 是最佳区间：60-72% 的内存节省，仅 1-3% 的 F1 损失。
• 整个流水线在 $10/月的 Google Colab 上就能跑。

不足之处：对多跳问题效果差（需要拼接多个段落的信息，有些关键段落可能被预算机制丢弃）；短文档上几乎没有优势，SQuAD 上 F1 下降 9.7%，说明压缩空间太小时强制丢弃反而有害。

多 Agent 记忆

单个 Agent 的记忆已经够复杂了，多个 Agent 协作时问题更多。团队怎么共享信息？谁能看到谁的记忆？

信息在 Agent 之间传递时怎么不失真？这些问题在多 Agent 系统里都要解决。

这个方向挑了两篇。MetaGPT 用共享消息池和标准操作流程来解决多 Agent 信息传递失真的问题，是 ICLR 2024 的 Oral 论文。G-Memory 设计了三层图记忆架构，让多 Agent 团队能跨任务积累经验并持续进化。

MetaGPT：给多 Agent 系统装上"标准操作流程"

论文链接：https://arxiv.org/abs/2308.00352
发表时间：2023 年 8 月
机构：DeepWisdom等

动机

多个 LLM Agent 协作听起来很美好，但实际效果很糟糕。

主要问题是"级联幻觉"（cascading hallucinations）。你让 Agent A 做需求分析，A 的输出有一点偏差，传给 Agent B 做系统设计，B 在偏差上继续偏，传给 Agent C 写代码，到最后生成的代码跟原始需求可能已经差了十万八千里。幻觉在多轮传递中不断放大。

另一个问题是"闲聊式协作"。当时的多 Agent 框架（比如 CAMEL）让 Agent 之间自由对话。结果经常出现这种场景：产品经理说"嗨你好"，架构师回"不错！

你吃午饭了吗？"一来一回浪费大量 token 但没有实质推进。

现有框架还有一个效率问题：信息传递是一对一的。架构师需要看产品需求文档，工程师也需要看，但每次都要单独询问产品经理。通信拓扑一复杂，效率就崩了。

MetaGPT 的核心洞察来自人类工作实践：在真实的软件公司里，人们不是靠自由聊天来协作的，而是遵循标准操作流程（SOP）。产品经理输出 PRD 文档，架构师输出系统设计文档，每个角色的交付物都有明确的结构和标准。MetaGPT 要做的就是把这套 SOP 搬到 LLM 多 Agent 系统里。

主要方法

MetaGPT 模拟的是一个软件公司，定义了五个角色：产品经理、架构师、项目经理、工程师、QA 工程师。每个角色有明确的 profile（名称、目标、约束）、初始化的领域技能（产品经理可以用搜索工具，工程师可以执行代码），以及标准化的输出格式。

工作流是严格的流水线制。用户提出需求后，产品经理做竞品分析和用户需求分析，输出一份结构化的 PRD 文档（包含用户故事、需求池、竞品四象限图）。架构师基于 PRD 输出系统设计（文件列表、数据结构、接口定义、时序图）。

项目经理做任务拆分。工程师按照文件结构和函数定义写代码。QA 工程师写测试用例验证代码质量。每一步的输出都是结构化文档，不是自然语言对话。

这里的关键设计是"结构化通信接口"。跟 ChatDev 那种 Agent 之间用自然语言对话不同，MetaGPT 要求每个角色用文档和图表来交流。为什么？

论文用了一个很生动的类比——“电话游戏”（传话游戏）。自然语言经过几轮传递后，原始信息会严重失真。结构化文档避免了这个问题，因为每个字段的含义是明确的。

共享消息池是 MetaGPT 的另一个核心设计。所有 Agent 把结构化输出发布到一个全局消息池中，任何 Agent 都可以直接从池中获取需要的信息，不用逐个询问。获取的时机和方式由发布-订阅机制决定：每个 Agent 根据角色配置预先声明自己关注什么类型的消息。

架构师订阅产品经理的 PRD，QA 订阅工程师的代码。当订阅的内容发布到池中，Agent 自动被激活开始工作。前置依赖没到齐之前，Agent 不动。这样既避免了信息过载，也保证了工作流的顺序性。

可执行反馈机制是最后一个关键组件。早期版本的 MetaGPT 在代码审查阶段由于 LLM 幻觉会漏掉错误。于是论文引入了一个闭环：工程师写完代码后执行单元测试，如果测试失败就调试修复，循环最多 3 次。这不是让 LLM “看” 代码找 bug，而是真的跑代码、看报错、改 bug，用执行结果作为反馈。

自我改进机制虽然放在了附录里，但也值得一提。每开始一个新项目，每个 Agent 会回顾之前项目的反馈，调整自己的 constraint prompt。总结信息存入长期记忆，供未来的 prompt 更新继承。这本质上是让整个"公司"从项目经验中学习。

主要结论

在代码生成基准上：

• HumanEval：85.9% Pass@1，MBPP：87.7% Pass@1，均为当时的 SOTA。
• 可执行反馈机制贡献了 HumanEval 上 4.2%、MBPP 上 5.4% 的提升。

在更复杂的 SoftwareDev 基准（70 个软件开发任务）上：

• MetaGPT 的可执行性评分 3.75（满分 4），远超 ChatDev 的约 2.1 分和 AutoGPT 的 1.0 分。
• 代码生产率更高：每行代码消耗 126.5 token，而 ChatDev 需要 248.9 token。
• 100% 的任务完成率。
• 人工修正次数从 ChatDev 的较多降至仅 0.83 次。

消融实验表明，每增加一个角色（从只有工程师到加入产品经理、架构师等），代码质量和可执行性都会提升，虽然 token 成本略增但效果明显改善。

不足之处：SOP 流程是硬编码的，面对非软件开发任务（如科研、法律文书、创意写作）需要重新设计整套角色和流水线。角色间没有动态协商机制，一旦上游输出有误，下游只能被动接受，缺乏回溯和纠错的反馈通道。

G-Memory：用三层图记忆让多Agent团队越做越聪明

论文链接：https://arxiv.org/abs/2506.07398
发表时间：2025 年 6 月
机构：NUS、同济大学、UCLA等

动机

多Agent系统（MAS）干活比单Agent强得多，但有一个要命的短板：不会从过去的经验里学东西。

问题出在记忆上。现有MAS的记忆设计存在两个致命缺陷。第一，太粗糙。

多个Agent之间的协作过程很复杂，谁说了什么、谁启发了谁、哪个决策导致了成功或失败，这些细腻的协作轨迹全被丢掉了。现有系统顶多传一个"最终答案"给下一次任务，完全不记录过程。第二，缺乏个性化。单Agent领域已经有了很多精巧的记忆设计，但MAS领域还停留在"所有Agent共用一个扁平记忆"的阶段，既没有跨任务的知识积累，也没有针对不同Agent角色的定制。

能不能把单Agent的记忆方案直接搬过来？不行。MAS的交互轨迹极其冗长，可以是单Agent的10倍以上。把这么长的原始对话直接塞进上下文窗口，既低效又没收益，因为缺乏从协作视角进行的抽象和提炼。

所以核心诉求是：怎么把MAS那些又长又复杂的协作历史，组织成结构化的、可检索的、分层的记忆，让Agent团队真正能从经验中"进化"？

主要方法

G-Memory借鉴了组织记忆理论（Organizational Memory Theory），用一个三层图结构来管理MAS的全部交互历史。三层从底到顶分别是：交互图、查询图、洞察图。

最底层是交互图（Interaction Graph）。它记录的是某一次任务中，所有Agent之间最细粒度的对话过程。每个节点是一条"话语"（utterance），包含谁说的和说了什么。

节点之间的边表示时序和因果关系——A的发言启发了B的回复。可以把它理解成一份详尽的会议纪要，完整记录了一场头脑风暴的全过程。

中间层是查询图（Query Graph）。它存储的是系统处理过的所有历史任务的元信息。每个节点代表一个历史任务，包含三样东西：原始问题、任务状态（成功还是失败）、以及指向对应交互图的引用。

节点之间的边编码了任务之间的语义关联。这一层就像一个项目档案库，记录了公司做过的所有项目的摘要和状态。

最顶层是洞察图（Insight Graph）。它是从大量具体经验中提炼出的抽象知识和策略。每个节点是一条洞察（比如"执行动作前后要验证对象状态"），同时记录了支撑这条洞察的具体任务集合，提供溯源依据。

节点之间的边带有超图语义——洞察A通过某个具体任务为洞察B提供了上下文。这一层就像公司的"最佳实践指南"。

当新任务来了，G-Memory执行双向记忆遍历。首先在查询图上做语义相似度检索，找到最相关的历史任务，再通过图上的1跳邻居扩展搜索范围。然后分两个方向走：向上遍历到洞察图，拿到与当前任务相关的高层策略和通用知识；向下遍历到交互图，用LLM作为"图稀疏器"，从冗长的原始对话中只抽取最关键的协作子图。这样一上一下，既拿到了宏观指导，也拿到了微观经验。

拿到的记忆不是一股脑塞给所有Agent。G-Memory会根据每个Agent的角色和职责，进行个性化过滤。给项目经理的记忆侧重协调策略，给技术专家的记忆侧重技术细节。每个Agent只看到对自己有用的部分。

任务完成后，整个三层结构同步更新。交互图记录本次完整对话；查询图新增一个节点，与相关历史任务和洞察建立连接；洞察图根据本次成败总结新的经验，并和已有洞察关联。这就形成了一个持续进化的闭环。

G-Memory设计成即插即用的模块，不需要修改原始MAS框架的任何代码，可以直接嵌入AutoGen、DyLAN、MacNet等主流框架。

主要结论

在5个基准测试（ALFWorld、ScienceWorld、PDDL、HotpotQA、FEVER）、3个LLM后端（GPT-4o-mini、Qwen-2.5-7B、Qwen-2.5-14B）和3个MAS框架（AutoGen、DyLAN、MacNet）上做了实验。G-Memory在具身行动任务中成功率最高提升20.89%，在知识问答任务中准确率最高提升10.12%。消融实验显示高层洞察和细粒度交互两个模块都有贡献，其中交互信息的影响略大于洞察信息。

实验还表明1跳扩展通常是最优选择，过度扩展反而引入噪声。在token消耗方面，G-Memory与主流记忆设计持平甚至更低。

不足之处：洞察图的质量依赖 LLM 提炼能力，噪声洞察可能误导后续任务；交互图的压缩（用 LLM 做图稀疏）可能丢失关键协作细节，尤其是在多轮复杂讨论中。

学习策略：让 Agent 自己学会管理记忆

前面所有论文的记忆管理策略，要么靠人写规则，要么靠 LLM 的 in-context 指令。能不能让 Agent 自己学会怎么管理记忆？这就是学习策略维度要回答的问题。

这个方向挑了四篇。EvoMem 是纯 Prompt 路线，用双演化记忆改进多 Agent 规划，不需要训练。Memory-R1 用 RL 训练了一对双 Agent（管理器+回答器），只需 152 个训练样本。

MemAgent 用固定长度记忆加覆写策略，从 8K 训练外推到 350 万 token，拿了 ICLR 2026 Oral。Mem-alpha 证明了复杂的三组件记忆架构也能用 RL 端到端训练，4B 小模型训完后超过了 GPT-4.1-mini。

EvoMem：用双演化记忆让多Agent规划一步步变好

论文链接：https://arxiv.org/abs/2511.01912
发表时间：2025 年 11 月
机构：伊利诺伊大学、华为

动机

规划是AI的一个核心能力，但LLM在涉及多步推理和长程依赖的规划任务上表现不佳。比如安排一趟旅行，需要同时满足总天数限制、固定日期活动、城市停留时间、航班可用性等一堆约束，任何一条漏掉都会导致方案无效。

虽然多Agent框架已经开始在规划领域发力，但有一块几乎没人认真研究：记忆在规划中的角色。认知心理学早就告诉我们，人类做规划时严重依赖工作记忆（working memory）来维持约束、追踪错误、迭代修正。但现有的多Agent规划框架基本没有显式的记忆机制。

一个典型的痛点是：Agent生成了一个方案，发现有错，想改。但它不记得上一轮犯了什么错、为什么犯错，于是同样的错误反复出现。没有记忆辅助的自我纠正，就像一个人不做笔记地重考一份考卷——大概率在同一个地方再次翻车。

主要方法

EvoMem受Baddeley在1974年提出的工作记忆多成分模型启发，设计了一个由三个Agent和两个记忆模块组成的框架。

先说三个Agent的分工。约束提取器（Constraint Extractor）负责从任务描述中识别出所有需要满足的约束条件。比如一个旅行规划任务，它会提取出"总共5天"、“第3天必须参加婚礼”、“从纽约出发”、"每个城市至少待2天"等等。

验证器（Verifier）负责检查方案是否违反了这些约束，它会输出两样东西：一个0-100的质量分数，以及具体违反了哪些约束。只有满分100才算通过。执行者（Actor）负责根据约束和反馈，生成或修改方案。

核心创新在两个记忆模块。约束记忆（CMem, Constraint Memory）存储提取出的约束条件，在整个任务处理过程中保持不变。它被附加到Actor的每一轮prompt中，确保Actor始终"记得"任务的核心要求，不会跑偏。

CMem在不同任务之间会更新（因为不同任务有不同约束），但在同一个任务的多轮迭代中是固定的。认知心理学里，这类似于工作记忆中的"语音环路"（phonological loop），维持稳定的语言信息。

查询反馈记忆（QMem, Query-feedback Memory）则在同一个任务的迭代过程中不断演化。每当Actor生成的方案被Verifier否决，这次失败的方案、得分和具体错误都会被记录到QMem中。下一轮生成时，Actor同时参考CMem中的约束和QMem中的历史错误，避免重蹈覆辙。QMem类似于工作记忆中的"视空间画板"（visuospatial sketchpad），把多轮中间结果和反馈整合成连贯的表征。

两个记忆模块的"双演化"体现在不同的时间尺度上：CMem跨任务演化（任务变了约束就变），QMem在任务内演化（每轮迭代后追加新反馈）。两者都在任务结束后重置，防止不同任务之间的信息串扰。

整体工作流程是：先提取约束写入CMem，Actor根据CMem生成初始方案，Verifier检查并给出反馈，如果不通过就把反馈存入QMem，Actor在下一轮同时参考CMem和QMem重新生成，如此迭代最多T轮。实验中T设为5。

主要结论

在NaturalPlan基准的三个任务上测试：旅行规划（1600例）、日历调度（1000例）、会议规划（1000例）。以Gemini-1.5-Pro为骨干模型，EvoMem达到最高的精确匹配分数：日历63.26%、会议47.56%、旅行52.08%。相比最强基线PlanGen，旅行规划平均提升11.17%，日历调度提升2.56%，会议规划提升3.76%。

在DeepSeek V3和GPT-4.1-mini上也观察到一致的提升，说明方法与模型无关。消融实验确认CMem和QMem各自都有独立贡献。成本效益分析显示前3轮迭代解决了93.7%的可解任务，但只用了67.88%的总查询量，T=5是性能和成本的最佳平衡点。

不足之处：两个记忆模块在每个查询结束后清空，没有跨查询的长期学习能力——做完 100 个旅行规划任务，系统不会比第 1 个任务时更聪明。验证器打分完全靠 LLM 自行评估约束违反情况，一致性可能不足，尤其在约束间存在隐式冲突时。

Memory-R1：用强化学习训练两个Agent学会管理和使用记忆

论文链接：https://arxiv.org/abs/2508.19828
发表时间：2025 年 8 月
机构：慕尼黑大学、剑桥大学等

动机

LLM本质上是无状态的。上下文窗口一满，之前的信息就丢了。最近很多工作给LLM加了外部记忆库，但大多采用RAG范式：把检索到的记忆条目拼接到prompt里。这带来两个没解决好的问题。

第一个是检索问题。启发式检索要么太少——遗漏关键上下文，要么太多——塞进一堆无关信息让模型分心。而且检索到的记忆是原封不动丢给模型的，没有经过任何过滤或优先级排序。人类其实不是这样的：我们检索到一堆相关记忆后，会先过滤，只整合最有用的。

第二个是管理问题。什么时候该存新信息、什么时候该更新旧信息、什么时候该删除过时信息？现有系统（如Mem0、MemGPT）靠手写规则或原生LLM能力来做这些决策，经常出错。

论文举了一个生动的例子：用户先说"我领养了一只叫Buddy的狗"，后来又说"我又领养了一只叫Scout的狗"。原生系统以为后一句是"纠正"前一句，直接删掉Buddy的记录再新建Scout的记录。正确做法应该是更新为"用户领养了两只狗，Buddy和Scout"。

这些决策很难用监督学习来训练，因为标注每一步记忆操作的ground truth几乎不可能。而强化学习只需要最终的答案正确性作为奖励信号，不需要标注中间步骤。

主要方法

Memory-R1包含两个专门的Agent，分别负责记忆管理和记忆使用，都用RL来训练。

记忆管理器（Memory Manager）负责维护外部记忆库。每当对话中出现新信息，管理器需要决定执行四种操作之一：ADD（新增条目）、UPDATE（更新已有条目）、DELETE（删除条目）、NOOP（不操作）。它被建模为一个策略网络，输入是新信息和当前记忆库中检索到的相关条目，输出是操作类型和更新后的内容。

关键在于奖励信号的设计。管理器的操作好不好，不是靠人来标注，而是看下游回答的正确性。原文的流程是：每轮对话中，管理器对新信息做一次操作，更新记忆库。

然后把更新后的记忆库交给冻结的回答 Agent 去回答问题。这些问题不是系统实时生成的，而是数据集在构建时就预先配好的 QA 对，比如「用户的宠物叫什么名字」「用户提到的旅行目的地是哪」。回答的精确匹配分数就是这一步操作的奖励，通过 PPO 或 GRPO 优化管理器的策略。

这个设计很巧：不需要人工标注什么是好的记忆操作，只要下游任务答对了，说明记忆管理做对了。

回答Agent（Answer Agent）负责利用记忆来回答问题。它引入了一个记忆蒸馏（Memory Distillation）机制。问题来了之后，先通过RAG检索60条候选记忆。

但60条太多，里面大量是噪声。回答Agent学会了从中筛选出真正相关的少数条目，然后只基于这些条目来推理和生成答案。筛选策略同样由RL训练，奖励信号也是最终答案的正确性。

两个Agent分开训练。先训练记忆管理器，让记忆库质量变好。再训练回答Agent，让它学会利用好的记忆。

论文发现这两个组件有叠加效应：回答Agent在更好的记忆库上获得的提升更大。具体数字是，换上更强的GPT-4o-mini管理器后，回答Agent的F1提升从10.10跃升到19.72。

训练数据量很少。只用了152个QA对来训练，来自LoCoMo数据集的训练集。这是整个数据集的1/10都不到。GRPO相比PPO在早期收敛更快，但两者最终达到相近的奖励水平。

论文还对比了记忆蒸馏和传统重排序（reranker）的效果。重排序虽然也能提升准确率，但带来了显著的延迟开销。Memory-R1在准确率更高的同时，推理延迟更低。

主要结论

在LoCoMo基准上，以LLaMA-3.1-8B-Instruct为骨干，Memory-R1-GRPO相比最强基线MemoryOS，F1提升28.5%、BLEU-1提升34.0%、LLM-as-Judge提升30.2%。在Qwen-2.5-7B上提升类似（F1提升24.5%、B1提升24.1%、J提升20.0%）。消融实验证实管理器、回答Agent、记忆蒸馏三个组件各自都有贡献。

用RL训练的Memory-R1甚至超过了用GPT-5轨迹做监督微调的Memory-SFT。零样本迁移到MSC和LongMemEval两个从未见过的数据集上，仍然保持一致提升。在3B到14B不同规模的模型上都有效。

不足之处：只在对话记忆场景（LoCoMo、MSC 等）验证，Agent 任务场景（工具调用、代码执行等）未测试，泛化能力存疑。双 Agent 架构（管理器 + 回答器分开训练）增加了系统复杂度，部署时需要维护两个独立模型。

MemAgent：固定长度记忆+覆写策略，8K窗口外推到350万token

论文链接：https://arxiv.org/abs/2507.02259
发表时间：2025 年 7 月
机构：字节跳动、清华大学等

动机

处理超长文本是LLM的终极挑战。理想的长上下文方案需要同时满足三个条件：能处理无限长度、性能不随长度下降、推理开销线性增长。目前没有一种方法能同时做到。

位置编码外推（NTK、YaRN等）修改位置编码来扩展窗口，但在超长文本上性能衰减严重，而且注意力的O(n^2)复杂度让推理变得极慢。稀疏注意力和线性注意力改变了计算复杂度，但通常需要从头训练，或者依赖人工设计的固定模式，缺乏灵活性。上下文压缩方法试图在token级别或外部模块中压缩信息，但在外推时表现不稳，且破坏了标准生成流程。

根本矛盾在于：现有方法要么扩大窗口（治标不治本，还是有限的），要么修改架构（代价太大）。有没有一种方式，不改模型架构，用一个有限窗口就能处理无限长文本？

人类就是这么做的。读一本书的时候，我们不会试图记住每个字。我们边读边做笔记，笔记本的大小是固定的，但可以不断擦除和更新。读完整本书后，靠笔记来回答问题。

主要方法

MemAgent的核心思想简洁到令人意外：给LLM一块固定长度的"记忆板"，让它把长文本分段读入，每读完一段就更新记忆板，最后靠记忆板来回答问题。整个过程用RL来训练模型学会"什么该记、什么该丢"。

具体来说，推理时分为两个模块。上下文处理模块：把长文本切成等长的chunk（每个约5000 token），模型逐个chunk读入。每次读完一个chunk，模型看到的是"当前chunk + 上一轮的记忆"，然后输出一份新的记忆，完全覆写掉旧记忆。

记忆长度固定为1024 token。答案生成模块：所有chunk处理完毕后，模型只看"问题 + 最终记忆"来生成答案。

这里有一个很精巧的设计：记忆就是普通的token序列，写在上下文窗口里。不需要任何特殊的注意力机制、不需要外部数据库、不需要改模型架构。整个过程就是标准的自回归生成。

因为记忆长度固定，每处理一个chunk的计算量是O(C+M)——C是chunk长度，M是记忆长度，都是常数。所以处理N个token的总复杂度严格为O(N)，线性的。

训练是关键难点。MemAgent在一次推理中会生成多个独立的上下文片段（每读一个chunk就生成一次记忆更新），这些片段之间的上下文是断开的。传统RL训练假设所有生成在同一个上下文中，这里不适用。

为此论文提出了Multi-Conv DAPO算法。DAPO是一种改进的GRPO算法。Multi-Conv DAPO的关键创新是：把每段独立的记忆更新视为一个独立的优化目标，而不是把它们强行拼接成一个长序列。

奖励信号来自最终答案的正确性，但advantage值被均匀分配到所有中间记忆更新步骤上。这样，即使某一步的记忆更新和最终答案之间隔了好几步，RL信号仍然能有效传播。

从自回归建模的视角看，MemAgent本质上是把标准Transformer变成了一个"循环网络"——每一步的"隐状态"就是那1024 token的记忆。但和传统RNN不同的是，这个隐状态是人类可读的token序列，可以检查甚至手动编辑。

训练设置很极端：只用8K上下文窗口，在32K长度的文档上训练。1024 token给记忆，5000 token给chunk，其余给问题和chat模板。模型一般需要5-7轮对话来处理完一篇32K的文档。

主要结论

MemAgent-7B（基于Qwen2.5-7B-Instruct）在8K窗口、32K文档上训练后，可以直接外推到350万token的QA任务，性能下降不到5%。MemAgent-14B在RULER测试的8K-512K范围内平均准确率超过95%，超过了1M窗口的Qwen2.5-Instruct-1M系列（后者在896K时性能降为零）。对比模型中，DeepSeek-R1-Distill-Qwen系列在超过128K后快速崩塌，QwenLong-L1在60K之后开始衰减。

消融实验证实RL训练是关键：没有RL训练的记忆机制虽然比裸模型好，但随长度增加仍会性能衰减；有了RL之后，性能曲线几乎是平的。在RULER的各种OOD任务（大海捞针、变量追踪、高频词提取、SQuAD问答）上，MemAgent都保持了一致的高性能。

不足之处：固定长度记忆（1024 token）是硬约束，极度细节敏感的任务（如精确数字提取、逐字引用）可能丢失关键信息。训练需要 Multi-Conv DAPO 特殊算法来处理多段独立上下文的 RL 优化，不能直接用标准 RL 库，增加了工程复现难度。

Mem-alpha：三组件记忆架构 + 四维RL奖励，4B模型打败GPT-4.1-mini

论文链接：https://arxiv.org/abs/2509.25911
发表时间：2025 年 9 月
机构：Anuttacon、UCSD、斯坦福

动机

现有的记忆增强Agent面临一个根本性的鸡生蛋问题：你给模型提供了一套复杂的记忆工具（插入、更新、删除、多种记忆类型），但模型天生不知道怎么用它们。

什么时候该存？存到哪个类型的记忆里？存多少？

什么时候该更新而不是新建？这些决策对人来说需要经验积累，对模型来说同样如此。但现有系统（如Mem0、MemGPT、MIRIX）全靠预定义的指令和提示来指导模型做这些决策，本质上是在赌模型的"instruction following"能力。

问题是：就连GPT-4o这种顶级模型，在复杂记忆操作上也经常犯错。小模型就更不用说了，复杂的系统提示反而会把它搞晕。更别提现有用RL训练记忆的工作（MEM1、MemAgent、Memory-R1）只用了很简单的记忆结构——要么是一段纯文本的记忆覆写，要么是一个事实列表。面对长叙事、程序性规则、不断变化的知识，这种简单结构远远不够。

所以Mem-alpha要解决的问题是：能不能用RL训练模型，让它学会操作一套真正复杂的、多组件的记忆系统？

主要方法

Mem-alpha把记忆构建建模为一个序列决策问题，用GRPO算法训练。但它和前面几篇工作的关键区别在于：记忆架构复杂得多，奖励函数也精细得多。

先说三组件记忆架构。

第一个是核心记忆（Core Memory），类似MemGPT的设计，是一段持续保留在上下文中的文本摘要，最长512 token。它始终存在于Agent的视野中，不需要检索。存放的是最关键的、全局性的信息。

更新方式只有一种：整体重写。因为它是高度浓缩的摘要，局部修改会破坏连贯性。

第二个是语义记忆（Semantic Memory），存储事实性知识和声明性信息。实现为一系列离散的事实条目，每条代表一个原子知识单元，可以独立检索和更新。支持三种操作：memory_insert（新增）、memory_update（修改）、memory_delete（删除）。

第三个是情景记忆（Episodic Memory），存储带时间戳的事件和经历。实现为按时间排列的事件集合。同样支持三种操作。它和语义记忆的区别是：语义记忆存"什么是什么"（事实），情景记忆存"什么时候发生了什么"（经历）。

Mem-α 的输入是一段长对话，按固定长度切成若干个 chunk，模型按顺序一个个处理。记忆是增量构建的。最开始三个组件都是空的。

第一个 chunk 进来，模型看完内容后通过 insert 写入第一批条目。第二个 chunk 进来时，模型就能看到之前写入的那些条目了，可以继续新增、修改或删除。随着 chunk 逐个处理，记忆逐步积累。

每个 chunk 的输入包含两样东西：当前 chunk 的内容和当前记忆的完整状态。核心记忆始终在上下文里，语义和情景记忆的所有条目也展示出来，每条带着自己的 ID。模型能看到记忆里现在有什么，知道该操作哪条。

语义和情景记忆的条目数会不会随着对话变长而爆炸？原文没有设硬上限，而是通过 RL 的压缩奖励来间接控制：，记忆总长度占 chunk 总长度的比例越小，奖励越高。这逼着模型学会精简，该合并的合并，该删的删，不能什么都往里塞。实验结果显示训练后的模型确实学会了主动合并冗余条目。

在此基础上，模型可以发出任意数量的记忆操作调用。根据原文，每个调用都是结构化的 function call，统一带三个参数：record id 指定操作哪条记忆、memory type 指定操作哪个记忆组件、string content 是具体内容。比如 memory_insert(type="semantic", content="用户养了两只猫") 新增一条语义记忆，memory_update(id="sem_003", type="semantic", content="用户养了两只猫，一只叫 Mimi") 更新已有记忆，memory_delete(id="epi_012", type="episodic") 删除过时信息。

不过三个记忆组件支持的操作不完全一样。语义记忆和情景记忆支持 insert、update、delete 三种操作。核心记忆只支持 update，因为它是一段 512 token 的完整摘要，必须整体重写，没法局部插入或删除。RL 训练的就是让模型学会在什么时候、对哪个组件发出什么操作。

然后是四维奖励函数，这是Mem-alpha的另一个核心贡献。

r1是正确性奖励。处理完所有chunk后，用RAG管线（BM25检索 + 冻结的生成器）基于最终记忆来回答评估问题。答对的比例就是r1。这是全局奖励，评估记忆的整体完备性。

r2是工具调用格式奖励。检查每次function call的格式是否正确、能否成功执行。这是局部奖励，每步独立计算。格式正确率对训练稳定性至关重要，因为如果模型连调用格式都搞不对，后面的记忆操作全是空谈。

r3是压缩奖励。定义为1减去记忆总长度与原文总长度的比值。鼓励模型用更少的空间存储同样多的有用信息。这也是全局奖励。

r4是记忆内容质量奖励。用Qwen3-32B来判断每次记忆操作是否符合其语义定义（比如"更新"操作是不是真的在更新，而不是在做其他事）。这是局部奖励，每步独立评估。

最终奖励为 r = r1 + r2 + beta * r3 + gamma * r4，其中beta=0.05，gamma=0.1。r1和r2的权重固定为1。

训练数据来自MemoryAgentBench，包含对话、文档共享、模式识别、叙事等多种场景。总共4139个实例，采样后562个用于训练。每个实例包含多个chunk，每个chunk触发若干记忆操作。以Qwen3-4B为骨干模型，32张H100训练3天，共205步。

总结一下 Mem-α 到底在优化什么。记忆架构是固定的，检索方式是固定的，生成器也是冻结的。RL 训练改变的只有一样东西：模型面对每个 chunk 时决定发出什么记忆操作的能力。

也就是写策略。该不该存、存到哪个组件、怎么措辞、要不要合并旧条目、要不要删过时的。同一个 Qwen3-4B，同一套记忆架构，训练前 0.389，训练后 0.642。差距全在写策略上。

主要结论

在验证集上，Mem-alpha平均性能0.642，远超Long-Context基线（0.588）、RAG-Top2（0.567）、MEM1和MemAgent。在OOD测试集MemoryAgentBench上，在精确检索和长程理解任务上提升尤为显著。最令人印象深刻的是长度泛化能力：虽然只在最长30K token的数据上训练，但成功泛化到超过400K token（Multi-Doc数据集中最长474K），超过训练长度13倍以上。

消融实验显示：去掉r4（记忆内容质量奖励）会导致灾难性性能下降，模型完全学不会有意义的记忆策略；压缩奖励r3在不同任务上效果不同，在BookSum上能大幅减少记忆长度（从4.5K降到2.2K）同时保持性能。Case study显示Qwen3-4B裸模型完全不会用核心记忆（留空），只维护一条语义记忆；GPT-4.1-mini的情景记忆有冗余（相同时间戳的事件不合并）；Mem-alpha则三种记忆都用得合理。

不足之处：训练数据需要精心构造（含对话、文档共享、模式识别、叙事等多种交互模式），泛化到全新领域（如医疗、法律等专业场景）的迁移成本未知。三组件架构（核心记忆 + 语义记忆 + 情景记忆）增加了系统设计复杂度，小团队可能难以调通整条训练管线。

我的感受

记忆应该放在哪里

读完这 20 多篇论文，我发现记忆存放的位置大致有三条路线。

第一条是放在上下文窗口里。MemAgent 就是这种思路：固定长度的记忆就是普通 token 序列，直接在上下文中参与注意力计算。优点是不需要额外的存储和检索机制，缺点是容量受限。

第二条是放在外部数据库里。MemGPT、Mem0、RAPTOR、G-Memory 都走这条路。用向量数据库或图数据库存记忆，需要时检索进来。容量无限，但检索质量是瓶颈。

第三条是放在模型参数里。MemoryLLM（本文未介绍但在综述中有）把记忆嵌入 Transformer 的潜在空间，通过前向传播更新。容量大、延迟低，但灵活性差。

我觉得这三条路最终会收敛到混合方案。Mem-alpha 已经在尝试了：核心记忆在上下文里（即时访问），语义和情景记忆在外部数据库里（大容量），RL 统一优化写策略。把不同重要程度的信息放在不同层级，正好对应操作系统里 L1 缓存、内存、磁盘的分层思路。

RL 方向的爆发

2025 年下半年到 2026 年初，RL 训练记忆策略的论文集中爆发。Memory-R1、MemAgent、Mem-alpha 三篇分别被 NeurIPS 和 ICLR 接收。

我觉得这个方向最关键的问题是：RL 训练和记忆架构能不能解耦？MemAgent 把记忆简化为纯文本覆写，RL 训练很简洁但表达能力受限。Mem-alpha 在尝试解耦——记忆架构是模块化的，RL 框架可以适配不同的记忆设计。

如果这条路走通了，未来可能会出现像 Transformer 一样的通用记忆训练框架：你设计自己的记忆架构，框架帮你用 RL 训练出最佳读写策略。

但挑战也很明显。RL 的奖励设计依赖下游任务（通常是 QA），能不能泛化到开放域的记忆管理？训练成本目前还不低。

多 Agent 场景下的 RL 记忆训练还几乎没有人做。

安全问题

记忆让 Agent 变得更强，但也打开了新的攻击面。

上周有研究者用对抗性图片成功注入了 Claude 的记忆系统。Agent 把图片中的隐藏指令当作正常信息存入记忆，后续对话中持续被这条恶意记忆影响。这就是记忆投毒。

还有隐私问题。Mem0 这样的系统会提取和存储用户偏好、个人事实。用户有没有权利要求 Agent「忘记」某些信息？

GDPR 的「被遗忘权」在记忆系统中怎么实现？简单删除一条记忆不够——如果它已经被反思机制提炼成了高层洞察，或者被 RL 训练进了策略参数里，删除就变得非常困难。

这个领域目前几乎没有系统性的安全研究。但随着记忆系统进入生产，这些问题迟早要面对。

基础设施标准化

Cloudflare 发布了 Agent Memory 托管服务。LinkedIn 推出了认知记忆基础设施。Databricks 在做记忆相关的数据管理。

三家完全不同的公司在同一时期做同一件事。

这让我想起数据库之于 Web 应用的关系。2000 年代初，每个 Web 应用都在自己实现数据存储逻辑。后来 MySQL、PostgreSQL 成为标准基础设施，开发者不再需要关心底层存储细节。

Agent 记忆正处于同样的早期阶段。每个 Agent 框架都在自己实现记忆管理——Voyager 用向量数据库存代码，Generative Agents 用记忆流加三维检索，MemGPT 用分层上下文管理。没有统一的接口、没有标准的查询语言、没有通用的存储后端。

我猜未来两三年内会出现 Agent Memory 的「数据库时刻」：一个标准化的记忆基础设施层，提供统一的写入、检索、更新、过期接口，让 Agent 开发者不需要从零实现记忆管理。谁先定义这个标准，谁就占据了 Agent 基础设施的关键位置。

学AI大模型的正确顺序，千万不要搞错了

🤔2026年AI风口已来！各行各业的AI渗透肉眼可见，超多公司要么转型做AI相关产品，要么高薪挖AI技术人才，机遇直接摆在眼前！

有往AI方向发展，或者本身有后端编程基础的朋友，直接冲AI大模型应用开发转岗超合适！

就算暂时不打算转岗，了解大模型、RAG、Prompt、Agent这些热门概念，能上手做简单项目，也绝对是求职加分王🔋

📝给大家整理了超全最新的AI大模型应用开发学习清单和资料，手把手帮你快速入门！👇👇

学习路线:

✅大模型基础认知—大模型核心原理、发展历程、主流模型（GPT、文心一言等）特点解析
✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑
✅开发基础能力—Python进阶、API接口调用、大模型开发框架（LangChain等）实操
✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用
✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代
✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经

以上6大模块，看似清晰好上手，实则每个部分都有扎实的核心内容需要吃透！

我把大模型的学习全流程已经整理📚好了！抓住AI时代风口，轻松解锁职业新可能，希望大家都能把握机遇，实现薪资/职业跃迁～

这份完整版的大模型 AI 学习资料已经上传CSDN，朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】