企业官网建设流程全解析

前言

今天抽空读了一篇 Agent 记忆相关的综述，记录一下论文内容。

这篇文章的核心问题是：Agent 记忆机制为什么会从简单的“存储”逐渐走向“反思”，再进一步走向“经验”？如果说早期记忆机制解决的是“Agent 如何记住过去”，那么 Experience 阶段更关注的是“Agent 如何从过去的轨迹中总结出可复用经验，并指导未来行动”。

零、论文基本信息

• 论文名称：From Storage to Experience: A Survey on the Evolution of LLM Agent Memory Mechanisms
• 论文链接：
  • arXiv 页面
  • PDF 原文
• 发表平台：ACL 2026 Findings
• 作者信息：
  • Jinghao Luo，South China Normal University
  • Yuchen Tian，Hong Kong Baptist University
  • Chuxue Cao，Hong Kong University of Science and Technology
  • Ziyang Luo，Hong Kong Baptist University
  • Hongzhan Lin，Hong Kong Baptist University
  • Kaixin Li，National University of Singapore
  • Chuyi Kong，Hong Kong Baptist University
  • Ruichao Yang，University of Science and Technology Beijing
  • Jing Ma，Hong Kong Baptist University

一、简介

记忆机制是 Agent 不可或缺的组成部分。由于 LLM-based Agent 本身缺乏显式状态维护机制，如果没有外部记忆，Agent 很难在复杂多轮任务中保持一致性，也很难从过去的交互中学习，容易反复犯同样的错误。

这篇综述认为，Agent 记忆机制的演化可以分为三个阶段：

• Storage：存储历史轨迹
• Reflection：对历史轨迹进行反思和修正
• Experience：从多条轨迹中抽象出可复用经验

也就是说，记忆机制并不是简单地“存得越多越好”，而是在不断从“记录过去”走向“优化过去”，再走向“利用过去指导未来”。

需要注意的是，这三个阶段并不是完全替代关系。Experience 阶段的记忆机制仍然可能包含 Storage 和 Reflection 的成分，只是核心能力从保存轨迹、修正轨迹，进一步转向了抽象经验。

举个简单例子：

• Storage 更像是把用户和 Agent 的历史对话保存下来。
• Reflection 更像是对这些历史对话做总结、纠错和更新。
• Experience 则更像是从很多次对话和任务中总结出一套以后还能复用的做事方法。

比如一个写作 Agent，刚开始可能只是记住“用户之前写过一篇 Agent 记忆机制的文章”；之后它会反思“用户不喜欢空泛总结，更喜欢结构清楚、有例子的解释”；最后它可能总结出一条更通用的经验：“给技术博客做修改时，应该先保留作者原有行文风格，再补充必要例子和过渡句，而不是直接重写成论文综述风格。”

这就是从 Storage 到 Reflection，再到 Experience 的区别。

二、记忆机制总览

下图可以作为理解全文的“地图”。它把 Agent 的工作流和记忆机制的三阶段演化放在了一起：Agent 在和环境交互的过程中产生历史轨迹，而这些轨迹可以被存储、反思，最后进一步抽象为经验。

图源：Luo et al., 2026，Figure 1。

结合这张图，文中提出了三个问题：

1. 记忆机制为什么要经历这三个演化阶段？
2. 记忆机制具体是如何演化的？
3. 演化的最后一个阶段，也就是 Experience，给 Agent 带来了怎样的改变？

后面的内容也基本按照这三个问题展开。

三、演化动力：为什么需要从 Storage 走向 Experience？

1. 长时一致性

目前大模型在多步互动中经常出现冗余探索、错误累积和推理不连续的问题。对于 Agent 来说，这会直接影响任务执行效果。

长时一致性主要包括两个方面：

• 状态一致性：Agent 需要维护内部推理状态，并让自身对外部世界的感知与真实环境保持同步；同时，对于长期交互型 Agent，还需要将用户偏好、人格特征等信息沉淀为稳定记忆，保证行为表现的一致性。
• 目标一致性：Agent 在长任务中不能只追求局部看起来合理的动作，而需要持续围绕全局目标进行规划，避免任务执行过程中出现目标漂移。

举个例子，假设一个 Agent 的目标是帮助用户完成一份求职简历。用户一开始说自己想投递“AI Agent 开发岗位”，后面又陆续补充了项目经历、技术栈、岗位要求和简历风格偏好。

如果 Agent 没有长时一致性，它可能每一轮都只根据当前输入修改一句话，结果导致前后重点不一致：前面突出 RAG，后面又突然改成产品经理，最后整份简历主线变得很乱。

而有记忆机制的 Agent 应该记住整个任务目标：这份简历是为了投递 AI Agent 开发相关岗位。因此，后续无论是修改项目描述、技术关键词，还是自我评价，都应该围绕这个全局目标展开。

因此，早期的 Storage 机制主要解决“记住过去”的问题，让 Agent 不至于每一轮都像从零开始。

2. 动态环境

Agent 并不是只在静态文本中工作，而是需要不断和外部环境交互。环境变化会带来两个问题：

• 知识会过时：过去保存的知识可能随着时间变化而失效。
• 因果关系有延迟：当前动作的影响可能不会立刻出现，而是在多轮交互之后才体现出来。

这就要求记忆机制不能只是机械保存，还需要能够判断哪些记忆仍然有效，哪些记忆需要被更新或修正。

举个例子，假设一个旅行规划 Agent 记住了“某个景点周一闭馆”。如果这个信息来自几年前的网页，那么今天可能已经不准确了。此时 Agent 不能简单召回旧记忆就直接回答，而应该意识到这类信息具有时间敏感性，需要重新确认。

再比如，一个投资分析 Agent 曾经记录过“某家公司增长很快”。但几个月后，公司财报、市场环境、监管政策都可能发生变化。旧记忆并不是不能用，而是需要判断它现在是否仍然有效。

下面这张图主要对应论文中“动态环境”这一部分。它说明了 Agent 记忆面临的不是一个静态数据库问题，而是一个随着时间、环境反馈和因果关系不断变化的问题。

图源：Luo et al., 2026，Figure 2。

从这张图可以看出，记忆机制如果只负责保存历史信息是不够的。对于真实环境中的 Agent 来说，更重要的是判断一条记忆是否仍然有效，以及过去某个动作是否会在未来产生延迟影响。

3. 持续学习

真实场景中的 Agent 不可避免会遇到新任务、新环境，或者训练分布之外的模式。如果每次都只依赖上下文临时推理，那么 Agent 很难真正变强。

因此，记忆机制最终需要走向 Experience：从历史任务轨迹中总结出更通用的策略、规则或技能，让 Agent 在未来任务中复用这些经验。

比如一个代码 Agent 第一次处理 Milvus 报错时，只是根据报错信息临时解决问题。第二次又遇到类似问题时，如果它还是从零开始搜索和推理，就说明它没有真正学习。

更理想的情况是，Agent 能从过去的解决轨迹中总结出经验：

如果 Milvus 搜索时报 Collection is in state ‘released’，通常需要在查询前显式调用 load()，并检查 collection 的加载状态。

这样下次遇到类似错误时，Agent 就不只是“记得之前出现过这个报错”，而是能够直接复用之前沉淀下来的排查经验。

四、演化路径：三个演化阶段具体是如何实现的？

论文中对 Agent 记忆机制做了比较完整的分类。为了先有一个整体印象，可以先看下面这张图。它把 Storage、Reflection 和 Experience 下面的具体方法都放在了一起。

图源：Luo et al., 2026，Figure 4。

这张图信息量比较大，可以先不用一次性看完，文中按照三个阶段拆开整理。

1. Storage

Storage 阶段解决的是“如何把过去保存下来”的问题。它强调对历史交互轨迹的保留，通常不会对原始信息做太多语义加工。

存储方式可以分为三类：

• 线性存储：互动轨迹被看作按时间顺序组织的 token 流，一般通过 FIFO 策略管理，主要有两种实现方式：

  • 通过修改注意力机制或编码位置，直接修改模型结构，以扩充上下文窗口。
  • 通过机械式压缩或稀疏化方法删除不重要的内容，例如裁剪、摘要、启发式过滤等。

• 向量存储：将记忆内容转化为向量后存入向量数据库，扩展了记忆容量，也让研究重点逐渐转向召回优化，例如如何召回更相关、更有用的记忆。

• 结构化存储：将记忆划分为更清晰的结构，兼顾存储能力和召回效率，同时缓解单纯向量召回中可能出现的语义歧义问题。主要有两种方式：

  • 用关系数据库、表格等结构化方式存储记忆。
  • 用类似知识图谱的方式，将互动历史建模为实体和关系网络。

举个例子，假设用户多次告诉 Agent：

• “我更喜欢简洁一点的回答。”
• “写代码时最好加注释。”
• “我正在做 Agent 记忆相关的项目。”
• “我的文章希望保留原来的行文风格，不要改得太学术。”

Storage 阶段要做的事情，就是把这些历史信息保存下来。后续用户再让 Agent 写文章、改代码或解释论文时，Agent 可以从记忆中召回这些信息，让回答更符合用户习惯。

不过，这里也会出现问题。Storage 只是保存，并不一定判断这些信息是否仍然有效。例如用户后来又说“这篇文章不用太简洁，可以稍微展开讲一下”，如果旧记忆没有被更新，就可能反而影响当前回答。

因此，Storage 阶段的核心目标是“存下来”。但问题在于，原始轨迹中可能包含错误、噪声和过时信息。如果 Agent 只是把这些内容全部保存下来，后续召回时反而可能干扰推理。

2. Reflection

Reflection 阶段解决的是“如何提升记忆质量，而不只是忠实保存原始轨迹”的问题。因为原始轨迹中可能包含错误推理、幻觉内容或无效探索，所以仅仅保存是不够的，还需要对记忆进行评估、修正和更新。

现有方法大致可以分为三类：

• Introspection：通过模型自我反思的方式优化记忆。也就是让 LLM 根据已有轨迹进行总结、纠错或提炼。
• Environment：依靠外部环境反馈优化记忆。例如根据任务执行结果、用户反馈或环境变化来判断某条记忆是否仍然有效。
• Coordination：多个 Agent 共同参与记忆的生成、评估、修正和更新，通过多 Agent 协作提升记忆质量。

举个例子，假设 Agent 在一次任务中得出了一条记忆：

用户喜欢所有回答都尽量简短。

但后续多次交互中发现，用户在写论文笔记、项目文档、简历描述时，其实更希望回答完整、有结构，只是不喜欢无意义的废话。

那么 Reflection 阶段就需要对这条记忆进行修正。更合适的记忆可能是：

用户喜欢结构清楚、信息密度高的回答；在文章和项目描述中，希望保留必要细节，但避免空泛和冗余表述。

这就比原来的“喜欢简短回答”更准确，也更有助于后续任务。

再比如，Agent 之前记住“某个接口不能使用”，但后来环境更新后这个接口已经恢复正常。如果 Agent 能根据新的运行结果修正旧记忆，就不会一直被过时信息误导。

Reflection 相比 Storage 更进一步，它不再只是“保存过去”，而是开始尝试判断过去的信息是否正确、是否有用、是否需要更新。

3. Experience

Experience 阶段解决的是“如何从记忆中总结出可复用经验”的问题。Reflection 之后的记忆虽然更可靠，但仍然偏片段化，很大程度上依赖具体上下文。Experience 则进一步从多条轨迹中抽象出更通用的策略、规则或技能。

论文中将 Experience 分为三种形式：

• Explicit Experience：显式经验，通常以人类可读的文本形式保存，例如规则、总结、提示词、操作建议等。
• Implicit Experience：隐式经验，通过微调、参数更新等方式，将经验内化到模型参数中。
• Hybrid Experience：混合经验，同时结合显式经验和隐式经验，既保留显式经验的可解释性和高容量，又通过周期性内化增强模型自身能力，形成经验积累和参数内化的循环。

如果说 Storage 是“记住发生了什么”，Reflection 是“判断记忆是否可靠”，那么 Experience 就是“从过去总结出以后还能用的东西”。

这里可以用一个写作 Agent 的例子来理解。

假设一个 Agent 帮用户修改了很多篇技术博客。刚开始，它只是保存每次修改记录，例如某一篇文章哪里改了标题，哪里删了冗余句子，哪里补了例子。这个阶段更接近 Storage。

后来，Agent 开始总结每篇文章中哪些地方容易出问题，例如：

• 开头没有说明论文价值；
• 概念之间缺少过渡；
• 方法分类只是罗列，没有解释区别；
• 读者可能不知道某个抽象概念对应什么实际场景。

这个阶段更接近 Reflection。

再往后，Agent 从多篇文章中抽象出一套更通用的写作经验：

技术博客最好先说明问题背景，再解释论文框架，最后结合自己的项目经验总结启发；每个抽象概念后面最好配一个简单例子。

这条经验不再依赖某一篇具体文章，而是可以迁移到后续很多论文笔记中，这就是 Experience 更关注的内容。

不过，论文也强调 Experience 并不是一种完全独立于微调、强化学习或元学习之外的新学习范式，而是从 Agent 记忆机制的角度，重新解释这些技术如何把交互轨迹转化为可复用经验。

五、Experience 带来了什么改变？

Storage 和 Reflection 两个阶段总体来说仍然比较依赖已有轨迹。更准确地说，Reflection 更偏向单条轨迹内的修正，而 Experience 则进一步转向跨轨迹归纳。它主要带来了两个变化：主动探索和跨轨迹抽象。

1. 主动探索

在 Experience 阶段，Agent 不再只是被动记录信息，而是开始主动探索经验。

从探索机制上看，可以分为三类：

• 奖励驱动的探索：根据任务奖励或反馈，引导 Agent 探索更有效的行为策略。
• 课程驱动的探索：从简单任务逐步过渡到复杂任务，让 Agent 在渐进式任务中积累经验。
• 复用驱动的探索：通过抽象和复用历史轨迹，提高后续任务中的探索效率。

从探索维度上看，又可以分为三类：

• 广度探索：尝试更多任务、环境或策略。
• 深度探索：在某一类任务中深入探索更优解法。
• 策略探索：关注不同策略之间的差异，以及哪些策略更适合迁移到未来任务中。

举个例子，假设一个代码 Agent 需要完成一个数据清洗任务。普通的记忆机制可能只会记录“这次使用 pandas 成功完成了任务”。但如果进入 Experience 阶段，Agent 可能会主动尝试不同方案：

• 方案一：直接用 pandas 规则清洗。
• 方案二：先用 LLM 判断异常字段，再用 pandas 处理。
• 方案三：先抽样检查数据分布，再生成清洗规则。

如果最后发现方案三在多个任务中更稳定，Agent 就可以把它总结成一条经验：

在处理未知结构的数据清洗任务时，先抽样分析字段分布，再生成清洗规则，通常比直接写规则更稳。

这类经验就可以在未来任务中复用。

再比如，在网页自动化任务中，Agent 可以主动尝试不同的页面理解策略：先看按钮、先看标题、先看表单字段，或者先读取页面整体结构。经过多次任务后，它可能发现“先理解页面语义，再执行点击动作”比“直接点击最显眼按钮”更可靠。

也就是说，Experience 阶段的 Agent 不只是“遇到什么记什么”，而是会主动寻找值得沉淀的经验。

2. 跨轨迹抽象

Experience 的另一个重要特点是跨轨迹抽象。Agent 不仅记忆某个具体任务的执行过程，还会从多个相似或对比性任务轨迹中抽象出更通用的经验。

这部分比较抽象，可以先看论文中的示意图。图中展示的重点是：Agent 并不是只保存单条轨迹，而是会把多条轨迹放在一起比较、归纳和压缩，最后形成不同粒度的经验。

图源：Luo et al., 2026，Figure 3。

结合这张图，可以更好地理解 Experience 和前两个阶段的区别：Storage 保存的是单条轨迹，Reflection 修正的是具体记忆，而 Experience 更关注从多条轨迹中总结出可迁移的模式。

例如，对于同一个网页自动化任务，Agent 可能有两条轨迹。

失败轨迹：

1. 直接点击页面上最显眼的按钮。
2. 没有检查按钮含义。
3. 进入错误页面。
4. 任务失败。

成功轨迹：

1. 先读取页面标题和按钮文本。
2. 判断每个按钮可能对应的功能。
3. 选择和目标最相关的按钮。
4. 进入正确页面。
5. 任务完成。

Storage 只会保存这两条轨迹；Reflection 可能会指出第一条轨迹的问题是“没有观察页面语义”；而 Experience 会进一步抽象出一条通用经验：

在网页操作任务中，不要直接点击视觉上最显眼的按钮，而应该先结合页面标题、按钮文本和任务目标判断动作含义。

这条经验就不再局限于某一个网页，而可以迁移到其他网页自动化任务中。

论文中提到的抽象机制主要包括以下几类：

• 对比归纳：对比同一任务中成功和失败的轨迹，总结哪些行为导致了成功，哪些行为导致了失败。
• 动作蒸馏：把细粒度动作蒸馏为高阶的思维模式，对多粒度的行为序列进行分块和聚合。
• 代码封装：把反复出现的行为模式封装为可复用的函数或程序。
• 参数内化：通过微调等方式，将经验固化到模型参数中。

其中，“代码封装”也比较好理解。比如一个 Agent 多次执行文件整理任务后，发现自己总是在做类似流程：

1. 扫描目录；
2. 根据后缀名分类文件；
3. 建立目标文件夹；
4. 移动文件；
5. 输出整理结果。

如果每次都重新规划这些动作，效率就比较低。Experience 阶段可以把这类重复行为封装成一个可复用函数。以后遇到类似任务时，Agent 不需要重新推理完整流程，而是直接调用这个封装好的程序。

从抽象粒度来看，可以分为三类：

• 浅层抽象：保留一部分原始语义逻辑，将自然语言规则作为经验。
• 中层抽象：去除自然语言冗余，只保留可执行的模块化骨架。
• 深层抽象：将轨迹分布压缩为模型权重。

这三种抽象粒度也可以用同一个例子理解。假设 Agent 总结“如何写一篇论文阅读笔记”：

• 浅层抽象可能是一条自然语言经验：先介绍论文背景，再整理核心方法，最后写自己的理解。
• 中层抽象可能变成一个固定模板：论文信息 → 问题背景 → 方法框架 → 样例解释 → 总结启发。
• 深层抽象则可能通过训练或参数更新，让模型在以后写类似文章时自然倾向于这种组织方式。

这部分我觉得是这篇综述比较有启发的地方。因为很多 Agent 项目中的“记忆”其实还停留在向量库召回层面，也就是把历史信息存起来，然后在需要时检索出来。但 Experience 更进一步，它关注的是如何从历史任务中沉淀出可迁移、可复用的经验。

六、总结和未来展望

整体来看，这篇综述的价值不只是整理了 Agent 记忆机制的分类，而是提出了一条比较清晰的演化线索：

从保存轨迹，到修正轨迹，再到抽象经验。

对于想做 Agent 项目的人来说，这个框架也很有启发。因为它提醒我们，记忆模块不能只停留在“向量库召回”层面，更重要的是让 Agent 能够判断哪些记忆有用、如何更新记忆，以及如何从历史任务中沉淀出可复用经验。

当然，目前 Agent 记忆机制仍然存在一些有待改进的地方，例如：

• 主动记忆感知：Agent 需要判断当前任务是否真的需要引入额外记忆，以及应该调用哪一类记忆，让记忆机制成为一种按需调用的资源。
• 工作记忆的组织模式：随着任务复杂度提高，Agent 需要更好地管理当前上下文中的关键信息。
• Experience 相关评测基准：目前针对经验抽象和复用能力的测试仍然不够充分。
• 分布式共享记忆：多个 Agent 之间如何共享、更新和协调记忆，仍然是一个重要问题。
• 多模态记忆：未来 Agent 不仅需要记住文本，还需要处理图像、语音、视频等多模态信息。

这里也可以用几个具体场景理解这些未来方向。

对于主动记忆感知，一个 Agent 不应该每次回答都盲目检索全部记忆。例如用户只是问“Python 里 list 和 tuple 有什么区别”，可能不需要调用长期记忆；但如果用户问“根据我之前的项目经历，帮我优化这段简历描述”，这时就明显需要调用用户历史信息。

对于工作记忆组织，可以理解为 Agent 在当前任务中如何管理临时信息。比如写一篇长文章时，Agent 需要同时记住文章主题、当前小节、已经写过的内容、尚未展开的部分，以及用户提出的风格要求。如果这些信息组织不好，就容易出现前后重复、遗漏重点或跑题。

对于分布式共享记忆，可以想象一个多 Agent 系统：一个 Agent 负责检索论文，一个 Agent 负责总结方法，一个 Agent 负责写博客。如果它们之间不能共享关键信息，就会出现重复工作或者结论不一致的问题。

对于多模态记忆，未来 Agent 可能不仅要记住文字信息，还要记住图片、表格、语音甚至视频中的内容。比如一个科研助手可能需要记住论文中的模型结构图，一个面试辅导 Agent 可能需要结合用户简历、项目截图和模拟面试语音来给出反馈。

简单来说，Storage 让 Agent 记住过去，Reflection 让 Agent 修正过去，而 Experience 则让 Agent 从过去中学习。真正有长期能力的 Agent，应该不只是会调用历史记录，而是能够从历史任务中不断积累经验。

参考资料

• Luo J, Tian Y, Cao C, et al. From Storage to Experience: A Survey on the Evolution of LLM Agent Memory Mechanisms. arXiv preprint arXiv:2605.06716, 2026. Accepted by ACL 2026 Findings.