MemEvolve：当 Agent 不只积累记忆，还开始进化自己的记忆系统

谢白羽

276人浏览 · 2026-06-05 22:10:57

谢白羽 · 2026-06-05 22:10:57 发布

MemEvolve：当 Agent 不只积累记忆，还开始进化自己的记忆系统

一句话定位：MemEvolve 把 Agent Memory 从“固定架构里的经验积累”推进到“记忆架构本身也能被搜索、诊断和进化”的层次。

论文 / 代码：arXiv / GitHub: bingreeky/MemEvolve
会议状态：仓库标注已被 ICML 2026 接收
关键词：Agent Memory、Self-Evolving Agent、Meta-Evolution、EvolveLab、Encode-Store-Retrieve-Manage
适合读者：关注自进化 Agent、长期经验复用、Agent 架构搜索、工具调用 Agent、Deep Research Agent 的研究者和工程实践者。

1. 大多数 Agent Memory 只是在固定盒子里装更多东西

今天的 Agent Memory 系统，大多遵循一个固定流程。

Agent 做完一次任务，系统把任务轨迹、成功经验、失败原因、用户偏好、工具调用方式写进记忆。下次遇到类似任务时，再从记忆里检索相关内容，作为提示注入给 Agent。

这个方向本身没问题。它确实能让 Agent 不用每次都从零开始。

但这里有一个很大的隐含前提：记忆系统的架构是人类提前设计好的。

例如，一个系统可能固定采用这样的流程：

把轨迹总结成自然语言经验；
存进向量库；
查询时按 embedding 相似度取 top-k；
把召回文本拼进 prompt；
定期用 LLM 合并重复记忆。

另一个系统可能采用知识图、工具库、技能库、错误案例库，或者把这些混在一起。无论哪种方式，一旦架构确定，Agent 后续通常只能增加记忆内容，很少能改变“应该怎样记忆”。

MemEvolve 关注的正是这个问题：如果 Agent 想真正自我改进，它不应该只改进 memory content，也应该能改进 memory architecture。

换句话说，Agent 不只要学会记笔记，还要学会改变自己的记笔记方法。

2. MemEvolve 的核心问题

MemEvolve 问的是一个更高层的问题：

能不能让 Agent 根据任务表现，自动进化自己的记忆系统？

这和普通 memory update 不一样。

普通 memory update 改的是内容。例如“这次任务中，某个网站搜索框需要先点开”“这个 API 的参数名是 user_id”“这个项目测试命令是 npm test”。

MemEvolve 想改的是机制。例如：

这类任务应该存完整轨迹，还是只存失败节点？
经验应该保存成事实、步骤、工具调用模板，还是层级摘要？
查询时应该只按语义检索，还是先判断任务意图再取不同记忆？
旧记忆应该按时间衰减，还是按成功率重新加权？
工具使用经验是否应该被蒸馏成可复用 skill？

这些问题不是“记住了什么”，而是“系统应该如何记忆”。这就是 MemEvolve 的 meta-evolution。

3. 四模块设计：把记忆系统拆成可进化组件

为了让记忆架构可进化，MemEvolve 需要先定义什么是“一个记忆系统”。

它把 memory architecture 拆成四个核心模块：

Encode：经历如何变成记忆

Encode 决定原始任务轨迹如何被加工。

同样一次任务经历，可以有很多编码方式：

保存完整轨迹；
提取关键事实；
总结失败原因；
抽象成可复用步骤；
生成工具调用模板；
把任务拆成子目标和状态转移；
提取“什么时候该用某个工具”的触发条件。

Encode 的质量决定了记忆系统能不能把一次经历变成未来有用的经验。

Store：记忆如何组织

Store 决定记忆被放进什么结构。

可以是简单文本列表，可以是向量库，可以是分层知识库，可以是图，也可以是多个 memory bank：事实一类、技能一类、工具经验一类、错误案例一类。

不同任务对 Store 的要求不同。长对话问答可能更需要事实和时间线；Web Agent 可能更需要页面操作流程；Deep Research Agent 可能更需要搜索路径、引用证据和中间结论。

Retrieve：新任务如何找记忆

Retrieve 决定任务开始时如何召回历史经验。

最简单的方式是 embedding top-k，但这不一定够。很多 Agent 任务需要先判断任务类型，再选择不同检索路径。

例如：

用户问事实，优先检索 factual memory；
Agent 要执行网页任务，优先检索 workflow memory；
任务失败后重试，优先检索 failure memory；
需要调用工具，优先检索 tool-use memory。

Retrieve 是记忆系统真正参与决策的入口。

Manage：记忆如何维护

Manage 决定记忆如何更新、合并、删除和降权。

长期 Agent 最怕 memory base 越长越脏。重复经验、过期经验、错误经验、低价值经验如果不处理，系统会越来越慢，也越来越不可靠。

Manage 要解决的问题包括：

新旧记忆是否重复；
某条记忆是否已经过期；
失败经验是否应该保留；
多条记忆冲突时信谁；
哪些经验应该被提升为通用 skill；
哪些记忆应该被删除或降权。

这四个模块组合起来，就是一个可执行的 memory architecture。

MemEvolve 的关键一步，是把这个架构当成可以被修改、评估和选择的对象。

4. 双循环：内容进化和架构进化同时发生

MemEvolve 的方法可以理解成双循环。

第一层是内循环：Agent 在当前记忆架构下做任务。

在这一层里，系统流程和传统 memory agent 很像。Agent 使用固定的 Encode、Store、Retrieve、Manage 模块完成一批任务。任务过程中产生经验，经验进入 memory base，后续任务再从 memory base 中检索和复用。

也就是说，内循环负责让 memory content 变多、变好。

第二层是外循环：系统评估当前记忆架构是否适合这类任务。

外循环会看任务表现，诊断瓶颈，再生成新的候选 memory architecture。候选架构会在同一批或相关任务上竞争，表现更好的被选为下一轮基础。

这就形成了两种进化：

记忆内容的进化：Agent 积累越来越多经验。
记忆架构的进化：系统逐渐改变积累和使用经验的方式。

这也是 MemEvolve 和普通 memory system 的根本区别。普通系统最多让 Agent 在一个固定盒子里积累内容；MemEvolve 让盒子本身也参与进化。

5. 把记忆架构看成 genotype

MemEvolve 里一个很重要的抽象是：memory architecture 可以被看成一种 genotype，也就是可变的结构编码。

如果用更工程化的话说，一个记忆系统不是一个模糊概念，而是一组可替换模块：

Memory Architecture Ω = (Encode, Store, Retrieve, Manage)

其中每个模块都可以有不同实现。

Encode 可以是“保存完整轨迹”，也可以是“抽取 task insight”，还可以是“生成工具使用规则”。

Store 可以是“单一向量库”，也可以是“事实库 + 技能库 + 失败案例库”，还可以是“图结构 + 文本库”。

Retrieve 可以是“embedding top-k”，也可以是“按任务类型路由到不同 memory bank”，还可以是“先用 LLM 判断需要事实、流程还是工具经验”。

Manage 可以是“只追加不清理”，也可以是“定期合并重复记忆”，还可以是“按成功率给经验加权、按时间衰减、淘汰低价值记忆”。

MemEvolve 的进化不是随便让 LLM 改 prompt，而是在这个模块化空间里修改模块实现或模块组合。这样做的好处是每次变化都有边界：可以只改 Encode，不动 Store；也可以只换 Retrieve 策略，不重写整个 Agent。

这也是 EvolveLab 的意义。它把多种已有 self-improving memory 系统放进统一接口里，让这些系统可以被比较、复用、组合和进化。

6. 内循环具体做什么

内循环可以理解为“固定记忆架构下的任务学习”。

假设当前第 k 轮有一个候选记忆系统 Ω_j^(k)。这个系统内部已经规定好了 Encode、Store、Retrieve、Manage 怎么实现。Agent 用它去跑一批任务。

每个任务大概经历这样的流程：

Agent 接收任务目标和环境观察。
Retrieve 模块从 memory base 里取回相关经验。
Agent 根据当前观察和取回经验做决策。
任务过程中产生轨迹，包括观察、动作、工具调用、错误、成功结果。
Encode 模块把轨迹转成新的经验条目。
Store 模块把经验写进 memory base。
Manage 模块合并、清理或重排记忆。
系统记录这次任务表现，比如成功率、token 成本、API 成本、执行延迟。

这个阶段会得到两类东西。

第一类是新的 memory content，也就是任务经验本身。它可能是事实、流程、工具调用模式、失败原因、搜索策略等。

第二类是 performance feedback，也就是这个记忆架构在任务上的表现。比如任务成功了没有，花了多少 token，调用了多少工具，耗时多长，失败时卡在哪一步。

内循环本质上回答的是：在当前记忆架构下，Agent 能不能靠积累经验变好？

7. 外循环具体做什么

外循环才是 MemEvolve 的核心。

外循环拿到内循环的任务日志和表现指标后，不只问“这次任务为什么失败”，还会问“当前记忆架构哪里不适合这类任务”。

它会把每个候选系统的表现整理成一个反馈向量。公开解读里常见的形式是：

F_j^(k) = (Perf_j^(k), -Cost_j^(k), -Delay_j^(k))

这里 Perf 表示任务表现，比如成功率或 pass@1；Cost 表示 API / token 成本；Delay 表示执行延迟。因为系统既想效果好，也想成本低、延迟低，所以通常会用 Pareto ranking 或 non-dominated sorting 来比较候选。

这点很关键。MemEvolve 不是只选分数最高的系统。如果一个记忆架构只提升一点效果，却让 token 成本和延迟暴涨，它未必是好选择。Pareto selection 的意义是同时考虑任务成功、成本和速度。

外循环可以拆成三件事。

第一，Architectural Selection。系统根据表现、成本和延迟选择一批 top parent architectures。

第二，Diagnosis。系统回放任务轨迹和错误案例，判断瓶颈属于哪个模块。比如：

Encode 问题：经验抽得太粗，没保留关键失败原因。
Store 问题：所有经验混在一个库里，事实、流程、工具模板没有分层。
Retrieve 问题：召回内容相似但不实用，真正相关的流程经验没取到。
Manage 问题：旧经验过期，重复记忆太多，错误经验没有被降权。

第三，Design。系统根据诊断结果修改 Encode、Store、Retrieve、Manage 的实现，生成下一代候选架构。

外循环本质上回答的是：当前记忆架构哪里限制了 Agent 学习？下一轮应该怎样改这个架构？

8. 进化过程具体怎么跑

从公开材料看，MemEvolve 的外循环大致包含几个步骤。

第一步，使用当前 base system 跑一批任务，收集任务日志和表现指标。

这一步的目的不是单纯刷分，而是获得诊断材料。系统需要知道当前 memory architecture 在哪里失败：是编码没抓住关键经验，还是存储结构太粗糙，还是检索取错内容，还是管理模块让记忆库变脏。

第二步，生成多个候选系统。

候选系统不是随便改 prompt，而是围绕 Encode、Store、Retrieve、Manage 这些模块做结构调整。比如加强工具经验抽取、增加层级摘要、改变检索路由、给失败案例单独建库、让旧记忆按成功率重新排序。

第三步，让候选系统和原系统比赛。

系统会把新候选和原始 base 放在同一任务集上比较。这样可以避免只凭直觉决定哪个架构更好。

第四步，进入 finals 或选择阶段。

表现最好的系统会在更多任务或新任务上继续验证，最终 winner 成为下一轮的 base system。然后下一轮继续从它出发，重复诊断、生成、竞争和选择。

这个过程有点像架构搜索，也有点像演化算法。不同的是，它搜索的不是神经网络结构，而是 Agent 的 memory system design。

9. README 里的自动进化流程

官方 README 给了一个自动多轮进化命令，大致长这样：

python evolve_cli.py auto-evolve gaia \
    --num-rounds 3 \
    --provider agent_kb \
    --num-systems 3 \
    --task-batch-x 40 \
    --top-t 2 \
    --extra-sample-y 20 \
    --creativity 0.5

这个命令里的参数能很好地解释 MemEvolve 的具体步骤。

--num-rounds 3 表示跑 3 轮进化。每一轮都会从当前 base system 出发，生成候选、比赛、选择 winner。

--provider agent_kb 表示初始 baseline memory system。也就是说，第一轮不是凭空开始，而是从某个已有记忆系统出发。

--num-systems 3 表示每轮生成 3 个候选系统。如果加上原来的 base system，tournament 阶段就是 N+1 个系统一起比较。

--task-batch-x 40 表示初始评估用 40 个任务。这批任务用于收集 base logs，也用于 tournament 阶段比较候选。

--top-t 2 表示 tournament 后选前 2 个系统进入 finals。

--extra-sample-y 20 表示 finals 会额外加入 20 个任务，避免候选只是在前一批任务上碰巧表现好。

--creativity 0.5 控制候选生成时的创新程度。这个值太低，候选可能只是小修小补；太高，则可能生成不稳定或跑不通的架构。

官方 README 也把每轮流程写得很明确：

Collect base logs：用当前 base system 跑 x 个任务，收集日志。
Generate candidates：生成 N 个候选系统，每个候选都经历分析、生成、创建和验证。
Tournament：把 N 个新系统和 1 个 base system 放在同一批任务上评估。
Finals：选 top t 系统，在额外任务和抽样任务上继续比较。
Selection：winner 成为下一轮 base system。

这个设计避免了两个问题。

第一，避免只靠 LLM 主观判断哪个架构更好。候选必须跑任务。

第二，避免在单一任务批次上过拟合。finals 里会加入额外任务重新验证。

10. 候选架构具体可能怎么变

为了更直观，可以想象一个 Web Agent 初始使用很普通的向量记忆：

Encode：把任务轨迹总结成一段自然语言。
Store：所有总结放进同一个向量库。
Retrieve：按当前任务描述做 top-k 相似检索。
Manage：定期删除太旧的记录。

跑任务后，系统发现几个问题：成功案例里真正有用的是页面操作流程，但 Encode 只保存了泛泛总结；失败案例和成功案例混在一起；Retrieve 经常召回看似相似但不可操作的记录。

MemEvolve 可能生成一个候选架构：

Encode：把轨迹拆成 goal、state、action、observation、result，并抽取可复用 workflow。
Store：分成 workflow memory、failure memory、tool-use memory 三个库。
Retrieve：先判断任务类型，再检索对应 memory bank。
Manage：重复 workflow 合并，失败案例只保留根因和避免策略。

另一个候选可能更保守：

Encode：仍然保存摘要，但额外抽取关键工具调用参数。
Store：保持单一向量库，但给工具经验加 metadata。
Retrieve：向量召回后用 LLM rerank，优先选择有成功结果的经验。
Manage：按成功率给记忆加权。

这两个候选都不是简单“多存点历史”，而是在改变记忆系统如何处理经验。Tournament 会用任务表现、成本、延迟来决定哪个更适合当前任务族。

11. Diagnose-and-Design 是怎么工作的

MemEvolve 的外循环可以概括为 diagnose-and-design。

Diagnose 不是只看最终分数，而是尽量定位失败属于哪个记忆环节。

如果 Agent 没有写入关键经验，问题在 Encode。比如它完成了一次复杂搜索，但只记了“成功找到答案”，没有记搜索策略和关键查询词。

如果 Agent 写入了很多经验，但下次找不到，问题在 Store 或 Retrieve。比如事实、流程、工具经验都混在一个库里，embedding 检索只找到文字相似的记录，却没有找到可复用流程。

如果 Agent 找到了经验但用错了，问题可能在 Retrieve 的排序、prompt 注入方式，或者 Manage 没有处理冲突记忆。

如果 memory base 越来越大，召回越来越乱，问题在 Manage。系统可能需要合并重复经验、删除低质量经验、按任务成功率重排经验。

Design 阶段会针对诊断结果生成修改方案。它不是泛泛地说“提高检索质量”，而是具体改模块：

改 Encode：增加失败根因抽取、工具参数抽取、子目标分解。
改 Store：增加分层 memory bank，区分事实、流程、工具、失败。
改 Retrieve：增加任务分类、metadata filter、LLM reranker、hybrid retrieval。
改 Manage：增加合并、去重、遗忘、成功率加权和冲突处理。

这样每次进化都有明确靶点。

12. EvolveLab：为什么统一接口重要

MemEvolve 另一个重要贡献是 EvolveLab。

Agent Memory 领域有一个现实问题：大家的方法很多，但接口、任务、评估方式不统一。一个系统可能叫 memory，另一个叫 skill library，第三个叫 experience replay，第四个叫 tool-use cache。它们解决的问题相似，却很难公平比较和组合。

EvolveLab 试图把已有代表性 memory systems 统一到同一个模块化设计空间里，也就是 Encode、Store、Retrieve、Manage。

这件事看起来像工程整理，但对研究很重要。

第一，它让不同记忆系统可以在同一协议下比较。否则每篇论文都在自己的框架里跑，结论很难横向对齐。

第二，它让 memory module 可以组合。一个系统的编码方式，也许可以配另一个系统的检索方式；一个系统的管理策略，也许可以迁移到另一个 Agent 框架。

第三，它为 meta-evolution 提供搜索空间。如果没有统一接口，系统很难自动生成和验证新架构。

所以 EvolveLab 的意义不只是“开源代码”，而是把 Agent Memory 从一堆孤立技巧，整理成可以系统搜索的模块空间。

13. 实验结果怎么看

MemEvolve 的公开摘要里强调，它在多个 agentic benchmark 上能提升不同 Agent 框架表现，例如 SmolAgent、Flash-Searcher 等，并报告最高约 17% 的改进。同时，进化出来的记忆架构可以跨任务、跨框架、跨 LLM backbone 迁移。

这个结果如果成立，意义很大。

因为 MemEvolve 最容易被质疑的一点是：进化出来的 memory architecture 会不会只是过拟合某个任务集？如果它只能在一个 benchmark 上有效，那它更像自动调参；如果能迁移到不同任务和模型，那说明它确实发现了一些更通用的记忆设计原则。

从论文叙事看，这些原则可能包括：

更强的 agentic involvement：让 Agent 更主动地参与经验抽取和使用。
更层级化的组织：不是平铺所有记忆，而是区分事实、流程、工具、失败。
更多抽象层次：既保存具体经验，也沉淀可复用模式。
更任务感知的检索：不同任务类型走不同 memory route。

这些结论和近年的 Agent Memory 趋势是一致的：有用的记忆不只是“相似文本”，而是能指导行动的经验结构。

14. 和 ProcMEM、PlugMem、SimpleMem 的关系

MemEvolve 和 ProcMEM 有相似之处。ProcMEM 关注从 episodic narratives 中学 procedural memory，也就是把过去经历变成可复用 skill。MemEvolve 则更上层，它可以把“是否需要 procedural memory、如何抽 skill、如何检索 skill”也纳入可进化架构。

MemEvolve 和 PlugMem 也有关联。PlugMem 把记忆组织成事实、处方和证据链，强调任务无关的插件式记忆模块。MemEvolve 会问：这种组织方式是否适合当前任务族？是否应该增加别的模块？是否应该改变检索策略？

MemEvolve 和 SimpleMem 的区别更明显。SimpleMem 关心长期记忆的信息密度，重点是压缩、合并、检索成本。MemEvolve 关心记忆系统设计本身是否可进化。一个偏工程效率，一个偏 meta-level architecture。

如果用一句话区分：