MemEvolve：智能体记忆系统的元演化

Status: completed

Original Title: MemEvolve: Meta-Evolution of Agent Memory Systems

Authors (ICML camera-ready): Guibin Zhang, Haotian Ren, Chong Zhan, Junhao Wang, He Zhu, Wangchunshu Zhou, Shuicheng Yan

Venue / Year: ICML 2026 regular paper；PMLR 306；Seoul, South Korea

Affiliations: National University of Singapore, Beijing University of Posts and Telecommunications, Chinese University of Hong Kong, OPPO, ByteDance

Links: arXiv v1 · OpenReview / camera-ready / reviews · Official Code · ICML 2026 Proceedings

Tags: [[LLM agent]], [[agent memory]], [[self-evolving agent]], [[meta-evolution]], [[bilevel optimization]], [[program synthesis]], [[Pareto optimization]], [[test-time learning]]

一句话总结

MemEvolve 把智能体从经验中学习的过程拆成“给定记忆架构时积累内容”的内循环，以及“根据成功率、token 成本和延迟改写记忆程序”的外循环；论文最有价值的贡献是 EvolveLab 的统一实验底座和“记忆架构也应被优化”的问题定义，而不是一个具有新理论保证的优化算法。

0. 先给结论

0.1 这篇论文真正做了什么

论文包含两个相关但应分开评价的贡献：

EvolveLab：把自改进记忆系统抽象成 Encode、Store、Retrieve、Manage 四类功能，并在同一套智能体接口中重新实现一批现有系统。
MemEvolve：让 LLM 读取当前记忆程序、任务轨迹和性能日志，诊断瓶颈，生成新的 Python 记忆实现；然后在实际 agent benchmark 上执行候选程序，用多目标选择保留下一轮父代。

概念上，它把普通的经验积累

M_t \longrightarrow M_{t+1}

提升为同时搜索记忆机制

\left( M_t,\Omega^{(k)} \right) \longrightarrow \left( M_{t+1},\Omega^{(k+1)} \right),

其中 $M_t$ 是记忆内容， $\Omega^{(k)}$ 是第 $k$ 轮的记忆程序。

但公开实现默认会在每一轮开始前清空父代存储。因此更精确的描述是：

\Omega^{(k)} \longrightarrow \Omega^{(k+1)}

会跨轮继承，而

M^{(k)}_0=\varnothing

通常会在每轮重新开始。论文所说的“内容与架构共同持续演化”在一次轮内成立，在跨轮意义上则主要是架构演化、内容重建。

0.2 主要实验证据

在 Flash-Searcher + GPT-5-mini 上，MemEvolve 的 pass@1 相比无记忆版本提高：
- WebWalkerQA： $71.18 \to 74.71$ ，增加 $3.53$ 个百分点；
- xBench-DS： $69.00 \to 74.00$ ，增加 $5.00$ 个百分点；
- TaskCraft： $69.67 \to 72.00$ ，增加 $2.33$ 个百分点；
- GAIA： $69.09 \to 73.33$ ，增加 $4.24$ 个百分点。
TaskCraft 上演化出的记忆直接迁移到 Kimi K2 时，WebWalkerQA 从 $52.35$ 提高到 $69.41$ ，绝对增加 $17.06$ 个百分点。
camera-ready 新增的模块消融显示：只演化 Retrieve 的增益最大，为 $10.00$ 个百分点；四模块联合演化为 $16.66$ 个百分点。
camera-ready 新增的搜索基线显示：TaskCraft 三轮增益分别为 MemEvolve $+16.66$ 、Greedy Search $+8.33$ 、Random Search $+3.33$ 。
OpenReview rebuttal 给出的估算是每轮约 $\$20.42$ ，三轮不足 $\$65$ ；这不是正文主表中的每任务推理成本，而是作者对一次架构搜索成本的补充估计。

0.3 证据应如何降温

这些结果足以支持“记忆架构会显著影响 agent 表现”和“诊断驱动的程序搜索比两个简单搜索基线更好”，但不足以支持一个强版本的“自动发现了普适的学习机制”：

外循环只有一个父代、三个后代，默认三轮，搜索规模很小；
没有理论收敛、遗憾界、泛化界或架构搜索复杂度分析；
所谓“statistical significance testing”只报告 $3$ 次运行的均值和标准差，没有假设检验、置信区间或 $p$ 值；
TaskCraft 与 GAIA 的演化任务、选择任务和最终汇报集之间没有给出足够清晰的严格隔离；
pass@1、pass@2、pass@3 的统计定义没有在论文或发布代码中完整说明；
公开仓库缺少论文使用的完整数据、运行日志、候选架构谱系和结果复算脚本；
论文的四模块接口在代码中被压缩为两个主要方法，且论文列出的 G-Memory 和 Riva 在当前仓库中没有对应 provider。

0.4 我的总体判断

维度	判断
问题重要性	强：固定记忆管线确实是 self-evolving agent 的结构性瓶颈
概念新颖性	中强：把记忆程序作为演化对象很自然，但与 prompt evolution、agent code evolution 有明显亲缘关系
算法新颖性	中等：LLM 诊断、程序生成、黑盒评估、精英选择的组合较直接
工程贡献	强：统一接口、基线实现和可执行程序搜索具有实际价值
数学严谨性	中弱：形式化主要是记号整理，没有定理或优化保证，并存在跨轮状态语义不一致
实验严谨性	中等：camera-ready 补了关键消融，但统计、数据隔离和成本报告仍不充分
可复现性	中弱：代码可读且能静态编译，但不是最终发布，关键结果资产不完整
长期影响	中强：很可能推动“agent harness / memory architecture optimization”成为独立问题

独立审稿结论：Weak Accept。接收理由主要是问题定义、EvolveLab 的社区价值和答辩后补齐的实验证据；不应把它评价成一个理论上成熟或搜索算法上高度原创的工作。

1. 版本、作者与公开评审状态

1.1 arXiv v1 与 camera-ready 不完全相同

用户给出的链接对应 arXiv v1，提交于 2025-12-21。到 2026 年，论文已被 ICML 2026 以 regular paper 接收。本文分析以以下顺序为准：

数学公式和初始主实验：arXiv v1 TeX 源码；
发表状态、作者和答辩后实验：OpenReview camera-ready；
代码事实：官方仓库提交 6035d5659d7a092dbfa6a87b1a32a3cee652ba54；
评审意见：OpenReview 的 3 份 Official Review、rebuttal、acknowledgement 与 Decision。

作者列表也发生变化：

arXiv v1 有 8 位作者，包含 Zhenhong Zhou；
ICML camera-ready 有 7 位作者，不再包含 Zhenhong Zhou；
camera-ready 给出更具体的五家机构，而 arXiv v1 只写 OPPO AI Agent Team 与 LV-NUS lab。

因此引用时应优先使用 ICML 版本：

bibtex

@inproceedings{zhang2026memevolve,
  title     = {MemEvolve: Meta-Evolution of Agent Memory Systems},
  author    = {Guibin Zhang and Haotian Ren and Chong Zhan and
               Junhao Wang and He Zhu and Wangchunshu Zhou and
               Shuicheng Yan},
  booktitle = {Forty-third International Conference on Machine Learning},
  year      = {2026},
  url       = {https://openreview.net/forum?id=qpkG0eKx4v}
}

1.2 公开评审概况

共有 3 份正式评审。最终决定将初审概括为“两份 Weak Accept、一份 Weak Reject”，并给出 Accept (regular)。Area Chair 的判断很克制：

评审认可问题的重要性与 EvolveLab 的代码价值；
初稿的主要不足是搜索规模小、消融不足、缺少统计验证；
rebuttal 补充了随机/贪心搜索、模块消融、小模型、长轮次和重复实验；
但简单搜索基线也表明，论文的核心价值更偏工程框架，算法概念增量有限。

这与本文的独立判断基本一致。

2. 问题定义与核心主张

2.1 普通自改进记忆只改变“记住了什么”

固定记忆架构可以在任务流中积累：

原始轨迹；
成功/失败经验；
反思与规则；
工作流；
API 或可执行工具；
知识图和多层摘要。

但其 Encode、Store、Retrieve、Manage 规则通常由人预先写死。于是智能体能改变

M_t,

却不能改变生成和使用 $M_t$ 的机制

\Omega.

论文把这种差异类比为：

无记忆 agent：不会从经验中学习；
固定记忆 agent：会按固定策略学习；
MemEvolve：会根据任务反馈改变“如何学习”。

2.2 为什么不存在单一最优记忆

这个动机是可信的。不同任务对记忆的需求确实不同：

任务	更有价值的记忆
Web / tool use	API、操作序列、站点模式、失败恢复
数学推理	解题模板、关键变换、错误类型
深度研究	查询规划、证据链、来源可靠性、上下文压缩
多智能体协作	角色轨迹、交接信息、协作图
个性化对话	用户偏好、事实一致性、时间衰减

因此，论文的核心问题可以写成：

\Omega^\star_{\mathcal{D}} = \operatorname*{arg\,max}_{\Omega\in\mathfrak{A}} \; \mathbb{E}_{\mathcal{Q}\sim\mathcal{D}} \left[ R\!\left( \tau(\mathcal{Q};\Omega) \right) \right],

其中：

$\mathcal{D}$ 是任务分布；
$\mathfrak{A}$ 是可执行记忆程序的搜索空间；
$\tau(\mathcal{Q};\Omega)$ 是使用记忆架构 $\Omega$ 执行任务 $\mathcal{Q}$ 的轨迹；
$R$ 是任务成功、成本和延迟共同决定的效用。

这条式子是对论文目标的等价归纳。论文自身没有把最终目标明确写成单一标量期望，而是使用三目标 Pareto 选择。

2.3 论文的四项核心主张

Encode–Store–Retrieve–Manage 能统一描述代表性的自改进记忆系统。
基于轨迹诊断并改写记忆程序，能优于固定的人类设计记忆。
演化出的架构可以跨任务、跨 LLM、跨 agent framework 迁移。
EvolveLab 能提供公平、统一、可扩展的实验底座。

第 2、3 条主要是经验主张；第 1、4 条更接近系统设计主张。论文没有定理证明“任何记忆系统都能被四模块无损表示”，也没有证明搜索会收敛到最优架构。

3. 完整数学形式化

3.1 智能体系统

论文把一个 LLM agent system 写为

\mathcal{M} = \left\langle \mathcal{I}, \mathcal{S}, \mathcal{A}, \Psi, \Omega \right\rangle.

符号含义如下：

符号	含义	类型或维度
$\mathcal{I}=\{1,\ldots,N\}$	智能体索引集合	有限集合
$\mathcal{S}$	共享环境状态空间	任意状态空间
$\mathcal{A}_i$	第 $i$ 个 agent 的动作空间	集合
$\mathcal{A}=\bigcup_{i\in\mathcal{I}}\mathcal{A}_i$	联合动作空间	集合
$\mu(t)\in\mathcal{I}$	时刻 $t$ 的活动 agent	离散索引
$\Psi(s_{t+1}\mid s_t,a_t,\mu(t))$	环境转移	条件分布
$\Omega$	记忆架构	程序或操作族
$M_t$	时刻 $t$ 的持久记忆状态	异构数据结构
$\mathcal{H}_t$	截至 $t$ 的交互历史	轨迹前缀
$\mathcal{Q}$	当前任务 query	文本或多模态输入
$c_t$	检索到的记忆上下文	文本、工具或结构化对象
$\pi_{\mu(t)}$	活动 agent 的策略	条件动作分布或解码器

每一步先从记忆中取得上下文，再产生动作：

\begin{aligned} c_t &\sim \Omega \left( M_t,s_t,\mathcal{H}_t,\mathcal{Q} \right), \\ a_t &= \pi_{\mu(t)} \left( s_t,\mathcal{H}_t,\mathcal{Q},c_t \right). \end{aligned} \tag{1}

执行任务后得到轨迹

\tau = \left( s_0,a_0,\ldots,s_T \right),

并用终局回报

R(\tau)

评价任务。新经验单元记为 $\epsilon$ ，记忆更新写成

M_{t+1} = \Omega \left( M_t,\epsilon \right).

这里的 $\Omega$ 同时表示“随机检索器”和“状态更新器”，是一个明显的符号重载；后面的四模块分解才把这些职责分开。

3.2 四模块记忆架构

论文将记忆架构写成

\Omega = \left( \mathcal{E}, \mathcal{U}, \mathcal{R}, \mathcal{G} \right),

分别表示 Encode、Store、Retrieve、Manage。

Encode

原始经验 $\epsilon_t$ 被编码为结构化表示：

e_t = \mathcal{E}(\epsilon_t).

$e_t$ 可以是：

压缩轨迹；
文本 insight；
成功/失败规则；
工作流；
API 或代码；
图节点、边和层级摘要。

Store

编码结果被并入持久记忆：

M_{t+1} = \mathcal{U} \left( M_t,e_t \right).

存储可以是 JSON、向量数据库、代码仓库、图数据库或混合存储。

Retrieve

当前状态和 query 决定检索上下文：

c_t = \mathcal{R} \left( M_t,s_t,\mathcal{Q} \right).

实际实现可能是：

top- $k$ 向量相似度；
BM25 与向量混合检索；
对比成功/失败轨迹；
图遍历；
LLM relevance gate；
工具签名匹配；
多阶段 retrieve–filter–synthesize。

Manage

异步管理操作写为

M'_t = \mathcal{G}(M_t),

包括合并、抽象、去重、遗忘、剪枝、重建索引和周期性维护。

四元组

\left( \mathcal{E}, \mathcal{U}, \mathcal{R}, \mathcal{G} \right)

被视作可演化的“genotype”。但它不是固定长度的离散向量；在公开代码中，每个分量最终体现在任意 Python 控制流、prompt、数据结构和模型调用里。因此真实搜索空间远大于简单的四模块笛卡尔积。

3.3 固定架构下的一阶经验演化

传统系统固定 $\Omega$ ，对 query $\mathcal{Q}$ 产生轨迹 $\tau$ ，并更新记忆：

M_{t+1} = \Omega \left( M_t,\epsilon_\tau \right), \qquad \epsilon_\tau \in \mathcal{E}(\tau). \tag{2}

论文文字说 $\mathcal{E}(\tau)$ 返回一个经验集合，并从中采样 $\epsilon_\tau$ 。严格说，如果一条轨迹产生多个经验单元

\mathcal{E}(\tau) = \left\{ \epsilon_{\tau,1}, \ldots, \epsilon_{\tau,L_\tau} \right\},

则更新应写为迭代或批量操作：

M_{t+1} = \mathcal{U} \left( M_t, \mathcal{E}(\tau) \right),

或者

M_{t,\ell+1} = \mathcal{U} \left( M_{t,\ell}, \epsilon_{\tau,\ell} \right).

原文式 (2) 把集合编码和单元素更新压成了一步。

3.4 内循环：经验演化

第 $k$ 轮有候选架构集合

\left\{ \Omega_j^{(k)} \right\}_{j\in\mathcal{J}^{(k)}}.

每个候选被实例化为

\Omega_j^{(k)} \triangleq \left( \mathcal{E}_j^{(k)}, \mathcal{U}_j^{(k)}, \mathcal{R}_j^{(k)}, \mathcal{G}_j^{(k)} \right).

初始种群只有一个人类设计基线：

\left| \mathcal{J}^{(0)} \right| = 1.

每轮开始时，每个候选的记忆状态初始化为空：

M_{0,j}^{(k)} = \varnothing.

沿候选 $j$ 产生的轨迹批

\mathcal{T}_j^{(k)}

更新记忆：

M_{t+1,j}^{(k)} = \Omega_j^{(k)} \left( M_{t,j}^{(k)}, \epsilon_\tau \right), \qquad \epsilon_\tau \in \mathcal{E}_j^{(k)}(\tau). \tag{3}

每条轨迹产生三维反馈：

\mathbf{f}_j(\tau) \in \mathbb{R}^{3},

对应：

task success；
token consumption；
latency。

聚合算子 $\mathcal{S}$ 给出候选级摘要：

\mathbf{F}_j^{(k)} = \mathcal{S} \left( \left\{ \mathbf{f}_j(\tau) \right\}_{\tau\in\mathcal{T}_j^{(k)}} \right), \qquad j\in\mathcal{J}^{(k)}. \tag{4}

论文没有正式定义 $\mathcal{S}$ 。公开代码使用 accuracy、总 token 和从日志计算的平均执行时间，但不同 runner 的计量一致性没有单独验证。

3.5 外循环：架构演化

元演化算子 $\mathcal{F}$ 接收当前架构与性能摘要，产生下一轮架构：

\left\{ \Omega_{j'}^{(k+1)} \right\}_{j'\in\mathcal{J}^{(k+1)}} = \mathcal{F} \left( \left\{ \Omega_j^{(k)} \right\}_{j\in\mathcal{J}^{(k)}}, \left\{ \mathbf{F}_j^{(k)} \right\}_{j\in\mathcal{J}^{(k)}} \right). \tag{5}

论文用如下统一视图描述一轮过程：

\begin{aligned} & \left( \left\{ \varnothing \right\}_{j\in\mathcal{J}^{(k)}}, \left\{ \Omega_j^{(k)} \right\}_{j\in\mathcal{J}^{(k)}} \right) \\ &\xrightarrow{\mathrm{inner}} \left( \left\{ M_{t+1,j}^{(k)} \right\}_{j\in\mathcal{J}^{(k)}}, \left\{ \Omega_j^{(k)} \right\}_{j\in\mathcal{J}^{(k)}} \right) \\ &\xrightarrow{\mathrm{outer}} \left( \left\{ M_{t+1,j}^{(k)} \right\}_{j\in\mathcal{J}^{(k)}}, \left\{ \Omega_{j'}^{(k+1)} \right\}_{j'\in\mathcal{J}^{(k+1)}} \right). \end{aligned} \tag{6}

式 (6) 容易让读者以为 $M^{(k)}$ 会与 $\Omega^{(k+1)}$ 一起进入下一轮。实际上：

正文明确说每轮从空记忆开始；
公开代码默认 clear_storage_per_round=True；
新架构可能改变存储 schema，旧 $M^{(k)}$ 未必与 $\Omega^{(k+1)}$ 类型兼容。

因此更准确的跨轮状态转移应写成

\left( M_{\mathrm{end}}^{(k)}, \Omega^{(k)} \right) \longrightarrow \left( \varnothing, \Omega^{(k+1)} \right),

除非显式关闭清空选项并额外实现 memory migration。

3.6 三目标选择

论文把候选摘要重新写为

\mathbf{F}_j^{(k)} \triangleq \left( \mathrm{Perf}_j^{(k)}, {}-\mathrm{Cost}_j^{(k)}, {}-\mathrm{Delay}_j^{(k)} \right). \tag{7}

三个坐标均是越大越好。候选 $a$ 支配候选 $b$ 当且仅当

\begin{aligned} & \mathrm{Perf}_a \geq \mathrm{Perf}_b, \\ & \mathrm{Cost}_a \leq \mathrm{Cost}_b, \\ & \mathrm{Delay}_a \leq \mathrm{Delay}_b, \end{aligned}

且至少一个不等式严格成立。

非支配排序产生 Pareto rank

\rho_j^{(k)}.

论文称同一 rank 内按任务性能排序，并取 top- $K$ ：

\mathcal{P}^{(k)} = \operatorname*{Top-K}_{j\in\mathcal{J}^{(k)}} \left( \rho_j^{(k)}, \mathrm{Perf}_j^{(k)} \right). \tag{8}

这里应理解为：

$\rho$ 升序；
$\mathrm{Perf}$ 降序。

公开代码存在两处重要差异：

Pareto selection 默认关闭；默认逻辑是 accuracy 降序、token 升序。
开启 Pareto 后，同一 rank 不只看性能，而使用

\mathrm{Score} = 0.6\, \mathrm{Accuracy} {}+ 0.25\, \mathrm{TokenEfficiency} {}+ 0.15\, \mathrm{TimeEfficiency}.

其中后两项在当前候选集合内做 min–max 归一化。这个 tie-breaker 会随着同轮其他候选变化，不是正文式 (8) 所写的纯性能破平。

3.7 Diagnose-and-Design

对每个父代

\Omega_p^{(k)} \in \mathcal{P}^{(k)},

LLM 分两步工作。

Diagnosis

它读取：

成功/失败；
token 和延迟；
query 描述；
任务轨迹；
当前 provider 代码；
当前记忆数据库样本。

输出缺陷报告

\mathcal{D} \left( \Omega_p^{(k)} \right),

定位：

无关或缺失检索；
抽象粒度错误；
存储冗余；
schema 不匹配；
缺少遗忘或维护；
工具记忆没有被正确暴露给 agent。

Design

设计器根据缺陷报告生成第 $s$ 个变体：

\Omega_{p,s}^{(k+1)} = \operatorname{Design} \left( \Omega_p^{(k)}, \mathcal{D} \left( \Omega_p^{(k)} \right), s \right), \qquad s\in\{1,\ldots,S\}. \tag{9}

所有后代的并集为

\left\{ \Omega_{j'}^{(k+1)} \right\}_{j'\in\mathcal{J}^{(k+1)}} = \bigcup_{\Omega_p^{(k)}\in\mathcal{P}^{(k)}} \left\{ \Omega_{p,s}^{(k+1)} \right\}_{s=1}^{S}. \tag{10}

camera-ready 将默认设置解释成经典 $(1+\lambda)$ 策略，其中一个父代与 $\lambda=3$ 个后代共同竞争。但式 (10) 只包含后代，不包含父代。公开代码实际会把

\left\{ \Omega_p^{(k)} \right\} \cup \left\{ \Omega_{p,s}^{(k+1)} \right\}_{s=1}^{S}

一起评估，代码语义才是真正的 $(1+\lambda)$ 。

3.8 它不是梯度型双层优化

论文多次使用 bilevel optimization 的语言，但没有定义连续参数、可微内外目标或隐式梯度。典型可微双层优化是

\begin{aligned} \theta^\star(\phi) &= \operatorname*{arg\,min}_{\theta} \mathcal{L}_{\mathrm{inner}}(\theta,\phi), \\ \phi^\star &= \operatorname*{arg\,min}_{\phi} \mathcal{L}_{\mathrm{outer}} \left( \theta^\star(\phi),\phi \right). \end{aligned}

MemEvolve 中：

内层不是求解 $\theta^\star$ ，而是执行任务并填充记忆；
外层不是计算 $\nabla_\phi$ ，而是让 LLM 生成新程序；
选择信号来自黑盒 benchmark；
优化对象是离散、可执行、结构可变的 Python 程序。

所以它更准确地属于：

trajectory-conditioned program evolution with expensive black-box fitness

而不是传统意义上的可微元学习。

4. 系统架构与完整算法流程

4.1 EvolveLab 的抽象层

论文设计空间有四个概念模块，但公开基类只强制实现三个方法：

python

initialize() -> bool
provide_memory(request: MemoryRequest) -> MemoryResponse
take_in_memory(trajectory_data: TrajectoryData) -> tuple[bool, str]

映射关系是：

论文模块	代码入口	说明
Encode	`take_in_memory` 内部	从 trajectory 抽取 insight、workflow、tool 或图结构
Store	`take_in_memory` 内部	把抽取结果写入 JSON、向量库、代码或图
Retrieve	`provide_memory`	根据 query、context、BEGIN/IN 阶段返回 `MemoryItem`
Manage	provider 辅助方法或生命周期逻辑	没有独立抽象方法，常与 ingest 或定期维护耦合

因此，“四模块统一接口”在论文层面成立，但代码层面更准确地说是两个主要行为接口承载四类职责。

4.2 一轮自动演化的真实执行

公开 auto-evolve 工作流不是正文中最简化的“60 条轨迹直接选一个 winner”，而是一个 tournament：

清空或备份当前父代存储；
当前父代在 $x$ 个任务上执行，产生诊断日志；
对同一批日志进行多次独立分析与生成，得到 $m$ 个新 provider；
对生成代码做创建、导入、接口和模拟调用验证；
父代与 $m$ 个候选在同一批 $x$ 个任务上比较；
选择 top- $t$ ；
top- $t$ 在 $y$ 个旧任务和 $x$ 个新任务上进入 finals；
finals winner 成为下一轮父代；
数据游标前移 $2x$ 。

若用集合表示：

\mathcal{B}_r = \left\{ q_{2rx}, \ldots, q_{2rx+x-1} \right\},

第一阶段使用 $\mathcal{B}_r$ ，决赛使用

\mathcal{F}_r = \operatorname{Sample}_y(\mathcal{B}_r) \cup \left\{ q_{2rx+x}, \ldots, q_{2rx+2x-1} \right\}.

这种两阶段选择比论文主文公式更具体，也有利于减少候选只记住首批任务的风险。

4.3 默认超参数

论文实验写的是：

记号	论文设置
最大轮数 $K_{\max}$	$3$
survivor budget $K$	$1$
每父代后代数 $S$	$3$
每候选轨迹数	$60$
新任务	$40$
上一轮复用任务	$20$

当前代码默认与 README 示例并不完全一致：

参数	代码默认	README 示例	论文
`task_batch_x`	$20$	$40$	新任务 $40$
`top_t`	$2$	$2$	survivor $K=1$
`extra_sample_y`	$5$	$20$	复用任务 $20$
`num_systems`	$3$	$3$	$S=3$
Pareto	关闭	命令中未开启	正文按 Pareto 描述
每轮清空存储	开启	开启	正文说每轮空初始化

这些差异不证明论文实验没有使用所述参数，但说明 README 命令不是论文配置的一键复现脚本。

4.4 训练与推理的区别

MemEvolve 不训练 LLM 权重。可以把所有调用模型参数记为冻结的 $\theta$ ：

\theta_{k+1} = \theta_k.

变化的是：

记忆状态 $M$ ；
provider Python 程序 $\Omega$ ；
provider 的 prompt、检索逻辑、数据结构和阈值。

没有论文级的

\nabla_\theta\mathcal{L},

也没有

\theta \leftarrow \theta {}-\eta\nabla_\theta\mathcal{L}.

所谓“训练阶段”更接近离线架构搜索；部署阶段则固定演化出的 provider，继续在线积累记忆：

\Omega^\star \;\mathrm{fixed}, \qquad M_t \longrightarrow M_{t+1}.

4.5 三个代表性演化结果

Lightweight

从最简单的 few-shot trajectory memory 出发：

基线：整条轨迹原样保存；
检索：向量相似度 top- $k$ ；
演化后：区分 planning、tool use、working context 等阶段；
在任务不同阶段提供不同粒度的建议。

它说明简单基线也能被重构为 stage-aware memory。

Riva

从不带大型离线知识库的 Agent-KB 风格初始化出发：

对 query 做 domain classification；
使用多信号混合检索；
用 LLM relevance scorer 或 gate 决定是否注入记忆；
把策略与操作指南结构化保存；
支持 tool memory；
重点解决静态 top- $k$ 容易注入无关上下文的问题。

Cerebra

Cerebra 进一步加入：

图式文本记忆；
TF-IDF、semantic 和 graph expansion 的混合检索；
phase-adaptive threshold；
对是否需要文本指导进行门控；
从成功轨迹中抽取工具函数；
单独的 tool retrieval；
每隔一定任务数执行 consolidate、merge、prune、edge optimization。

这确实比多数固定基线更“agentic”，但也带来更多 LLM 调用、阈值和维护逻辑。论文没有做足够细的成本归因来说明每个复杂部件的边际收益。

5. 数据集、模型与评测设置

5.1 数据集

Benchmark	规模	用途与风险
GAIA	$165$ ；Level 1/2/3 为 $53/86/26$	通用工具使用；部分实验用 Level-1 + 67 个 TaskCraft query 做演化，最终 GAIA 汇报是否完全排除演化题不够清楚
WebWalkerQA	原集 $680$ ；抽样 $170$	多跳网页导航；TaskCraft 上演化后直接迁移
xBench-DeepSearch	$100$	planning、tool use、deep research；TaskCraft 上演化后直接迁移
TaskCraft	工作子集 $300$ ；演化使用 $120$	合成 agent task；论文没有给出足够清晰的 train/selection/test ID 隔离

论文每轮使用 $40$ 个新任务与 $20$ 个复用任务。复用有助于稳定跨轮比较，但也会提高对固定 selection tasks 的适配风险。

5.2 Agent framework 与 backbone

Framework	类型	主要 backbone
SmolAgent	轻量两 agent	GPT-5-mini
Flash-Searcher	单 agent deep research	GPT-5-mini、Kimi K2、DeepSeek V3.2
CK-Pro	三 agent	Claude 3.7
OWL	层级多 agent	GPT-4o + o3-mini

用于 diagnose-and-design 的 meta-evolution LLM 在主实验中也是 GPT-5-mini。camera-ready 额外测试把由 GPT-5-mini 演化的记忆迁移到 Claude-3.7-Sonnet。

5.3 评价指标

主性能：accuracy / success rate；
多次采样：pass@1、pass@2、pass@3；
成本：每 query 平均 API cost；
延迟：每 query 平均秒数；
agent steps：平均交互步数。

论文没有给出 pass@ $k$ 的精确定义，例如它是

\operatorname{pass@}k = \frac{1}{n} \sum_{i=1}^{n} \mathbf{1} \left[ \max_{r\in\{1,\ldots,k\}} Y_{i,r}=1 \right]

这样的“ $k$ 次至少一次成功”，还是其他聚合。公开仓库也没有发现从运行结果计算 pass@ $k$ 的脚本。这个缺口会影响与其他框架数字的严格比较。

6. 主实验结果

6.1 与无记忆 agent 的直接比较

Framework / LLM	Dataset	No Memory pass@1	MemEvolve pass@1	绝对增益
SmolAgent / GPT-5-mini	WebWalkerQA	58.82	61.18	$+2.36$
SmolAgent / GPT-5-mini	xBench-DS	51.00	57.00	$+6.00$
SmolAgent / GPT-5-mini	TaskCraft	64.00	67.67	$+3.67$
SmolAgent / GPT-5-mini	GAIA	55.75	64.24	$+8.49$
Flash-Searcher / GPT-5-mini	WebWalkerQA	71.18	74.71	$+3.53$
Flash-Searcher / GPT-5-mini	xBench-DS	69.00	74.00	$+5.00$
Flash-Searcher / GPT-5-mini	TaskCraft	69.67	72.00	$+2.33$
Flash-Searcher / GPT-5-mini	GAIA	69.09	73.33	$+4.24$

结论是：记忆对较弱框架 SmolAgent 的收益通常更大，说明架构上限仍由 agent scaffold 决定。

6.2 跨 LLM 迁移

LLM	Dataset	Flash baseline	固定演化记忆	绝对增益
Kimi K2	WebWalkerQA	52.35	69.41	$+17.06$
Kimi K2	xBench-DS	66.00	68.00	$+2.00$
Kimi K2	TaskCraft	58.00	68.00	$+10.00$
Kimi K2	GAIA	52.12	61.21	$+9.09$
DeepSeek V3.2	WebWalkerQA	69.41	72.35	$+2.94$
DeepSeek V3.2	xBench-DS	68.00	70.00	$+2.00$
DeepSeek V3.2	TaskCraft	69.33	72.67	$+3.34$
DeepSeek V3.2	GAIA	60.61	67.88	$+7.27$

“up to $17.06\%$ ”在这里实际是 $17.06$ 个百分点。以 Kimi K2 的 WebWalkerQA 为例，相对提升是

\frac{69.41-52.35}{52.35} \times 100\% \approx 32.59\%.

所以论文把 percentage-point gain 写成百分比，表达不够精确。

6.3 与七种固定记忆的统一比较

以下均使用 Flash-Searcher + GPT-5-mini：

Memory	GAIA Perf.	xBench Perf.	WebWalkerQA Perf.
No-Memory	69.09	69.00	71.18
Generative	66.67	70.00	72.35
Voyager	69.70	68.00	73.53
DILU	66.67	69.00	72.94
ExpeL	66.06	64.00	69.41
AWM	67.27	71.00	72.35
Mobile-E	69.09	68.00	71.76
Cheatsheet	68.48	65.00	72.94
MemEvolve	73.33	74.00	74.71

这个表支持两个重要结论：

“加记忆”不自动提高表现；无关记忆会伤害 agent。
在同一框架和 backbone 中，MemEvolve 是唯一在三个 benchmark 都稳定提高的设置。

6.4 成本、延迟和步数

Dataset	No-Memory cost	MemEvolve cost	No-Memory delay	MemEvolve delay	No-Memory steps	MemEvolve steps
GAIA	0.086	0.085	505.46	693.33	10.44	10.14
xBench	0.141	0.136	523.05	773.06	14.69	14.20
WebWalkerQA	0.048	0.040	251.57	332.49	6.91	6.64

论文强调 API cost 与无记忆相近甚至更低，这点成立。但 latency 并不相近：

\frac{693.33-505.46}{505.46} \approx 37.17\%

对 GAIA；

\frac{773.06-523.05}{523.05} \approx 47.80\%

对 xBench；

\frac{332.49-251.57}{251.57} \approx 32.17\%

对 WebWalkerQA。

步数反而略低，说明额外延迟主要来自每一步的记忆检索、LLM gate、摘要或管理开销。论文用“与其他 memory baseline 同一量级”描述延迟是可以理解的，但若比较部署基线，无记忆版本快约三到五成。

7. Camera-ready 新增实验

这些实验不在 arXiv v1 主体中，来自 rebuttal 后纳入的 ICML camera-ready。

7.1 模块级消融

Round	Only Encode	Only Retrieve	Only Manage	Only Store	Full MemEvolve
R0	61.67	61.67	61.67	61.67	61.67
R1 best	63.33	66.67	63.33	63.33	70.00
R2 best	66.67	71.67	65.00	63.33	75.00
R3 best	68.33	71.67	66.67	65.00	78.33
$\Delta$	$+6.66$	$+10.00$	$+5.00$	$+3.33$	$+16.66$

解释：

Retrieve 是最重要的单模块；
Store 的单独收益最小；
联合演化明显超过任何单模块，支持跨模块耦合；
但这里没有报告各设置的候选代码复杂度、额外 LLM 调用或方差。

7.2 三次运行

Method	GAIA	WebWalkerQA	xBench
Voyager	$69.90\pm0.76$	$73.14\pm1.00$	$68.00\pm1.63$
AWM	$67.68\pm1.51$	$72.16\pm0.28$	$70.33\pm0.47$
Mobile-E	$68.69\pm1.03$	$71.76\pm1.44$	$68.33\pm1.25$
MemEvolve	$73.94\pm0.86$	$76.27\pm1.47$	$73.67\pm0.47$

表格显示排序稳定，但标题“Statistical Significance Testing”不准确：

$n=3$ 很小；
报告的是 mean $\pm$ standard deviation；
没有说明随机性来源；
没有配对检验；
没有 $p$ 值或多重比较校正；
没有置信区间。

因此它是重复运行的稳健性描述，不是严格的显著性检验。

7.3 五轮演化

Round	TaskCraft	Cost	Delay	OOD WebWalkerQA
R0	61.67	0.092	485.25	$65.10\pm2.65$
R1 best	70.00	0.105	512.40	$67.06\pm0.96$
R2 best	75.00	0.073	355.40	$70.20\pm1.47$
R3 best	78.33	0.056	364.37	$76.27\pm1.47$
R4 best	80.00	0.048	318.52	$76.86\pm1.94$
R5 best	80.00	0.043	295.60	$77.65\pm1.44$

这表明三轮后 TaskCraft 基本饱和，但后续轮次仍在优化成本和延迟。它支持 $K_{\max}=3$ 是一个经济默认值，不证明三轮足以发现全局最优架构。

7.4 Claude-3.7 跨 backbone 迁移

Framework	WebWalkerQA	xBench-DS	TaskCraft	GAIA Avg.
OAgents	58.23	47.00	-	66.67
CK-Pro pass@1	60.64	56.00	66.00	60.00
CK-Pro pass@3	65.88	67.00	70.66	75.15
MemEvolve + Flash pass@1	71.76	69.00	69.33	69.69
MemEvolve + Flash pass@3	77.05	74.00	75.33	78.78

这回应了“不同 framework 使用不同 LLM，比较不公平”的评审意见。不过 framework 本身仍不同，最干净的因果结论仍来自同一 Flash-Searcher 内加/不加记忆的对照。

7.5 搜索基线

Round	MemEvolve TaskCraft	Random TaskCraft	Greedy TaskCraft	MemEvolve OOD	Random OOD	Greedy OOD
R0	61.67	61.67	61.67	65.10	65.10	65.10
R1 best	70.00	63.33	65.00	67.06	64.51	65.88
R2 best	75.00	66.67	68.33	70.20	67.84	68.24
R3 best	78.33	65.00	70.00	76.27	65.88	70.59
$\Delta$	$+16.66$	$+3.33$	$+8.33$	$+11.17$	$+0.78$	$+5.49$

Greedy Search 每轮枚举 $4\times2=8$ 个单模块替换，约 $480$ 条轨迹；MemEvolve 用三个整体后代，约 $180$ 条轨迹。因此诊断驱动搜索在该预算下更有效。

仍缺少更强的黑盒优化基线，例如：

Bayesian optimization over modular configurations；
MAP-Elites / quality-diversity；
evolutionary archive；
beam search；
GEPA 风格 Pareto prompt evolution；
基于历史候选的 surrogate ranking。

最终 Decision 也明确指出，随机与贪心基线太基础，不能把算法新颖性评价得过高。

8. Claims → Evidence 映射

Claim	类型	证据	强度	主要风险
记忆架构显著影响 agent performance	Empirical	表 2、表 3；多个固定记忆会升降不一	强	只覆盖深度研究/工具任务族
MemEvolve 优于人类设计记忆	Empirical	同一 Flash-Searcher + GPT-5-mini 的统一比较	中强	基线复现 fidelity 无独立核验
Diagnose-and-Design 优于简单搜索	Empirical	camera-ready 表 8	中	只有随机和局部贪心，且搜索预算不同
四模块联合演化有协同效应	Empirical	camera-ready 表 4	中强	单次主结果，未报告方差与复杂度
架构跨任务迁移	Empirical	TaskCraft $\to$ WebWalkerQA/xBench；OOD 表	中强	任务仍同属 web/deep-research regime
架构跨 LLM 迁移	Empirical	Kimi K2、DeepSeek V3.2、Claude-3.7	中强	都是强模型，较小开源模型只在 rebuttal 外链说明
架构跨 framework 迁移	Empirical	OWL、CK-Pro 图 3	中	framework 与模型耦合，样本/运行细节不足
发现 task-agnostic memory principles	Interpretation	多 benchmark 稳定收益、Riva/Cerebra 案例	中弱	同任务族迁移不能证明普适性
记忆内容与架构共同持续演化	Conceptual	式 (3)–(10)	中弱	每轮默认清空记忆，跨轮主要继承架构
EvolveLab 覆盖 12 个记忆系统	Engineering	论文表 1	中	当前仓库只有 11 个 baseline provider，缺 G-Memory
成本与无记忆相当	Empirical	表 3 API cost	中	只指 API cost；推理延迟增加约 $32\%$ – $48\%$ ，且不含搜索成本

9. 数学与理论严谨性审查

9.1 做得好的地方

把记忆拆成四个操作，比按“向量库/知识图/工具库”分类更接近机制。
将 performance、cost、delay 放入同一选择框架，避免只追逐 accuracy。
明确把候选架构视为可执行程序，而不是抽象 prompt。
内循环与外循环的分工直观，足以指导实现。

9.2 主要数学问题

问题 1： $\Omega$ 被过度重载

$\Omega$ 同时表示：

整体记忆系统；
随机检索分布；
状态更新函数；
四元操作集合。

更严谨的写法应分别使用：

c_t \sim \mathcal{R}_{\Omega} \left( \cdot\mid M_t,s_t,\mathcal{Q} \right)

和

M_{t+1} = \mathcal{U}_{\Omega} \left( M_t, \mathcal{E}_{\Omega}(\tau) \right).

问题 2：内循环不是“学习到最优内容”

内循环只是依次处理有限任务并更新记忆，没有定义：

M^\star(\Omega) = \operatorname*{arg\,max}_M J(M,\Omega).

因此 bilevel optimization 主要是概念类比，不是标准双层优化。

问题 3：跨轮 co-evolution 语义不成立

若下一轮记忆为空，则严格的系统状态是

\left( \Omega^{(k)},M_{\mathrm{end}}^{(k)} \right) \longrightarrow \left( \Omega^{(k+1)},\varnothing \right).

这不是两个状态变量都连续遗传。可以说“架构由内容生成的证据驱动”，但不应说记忆内容也与架构一起跨代保留。

问题 4：父代保留与式 (10) 不一致

式 (10) 是 offspring-only，代码是 parent-plus-offspring。若父代不进入候选，性能可能退化；若父代进入，则公式应显式写并集。

问题 5：Pareto 选择缺少完整定义

论文没有定义：

cost 是美元还是 token；
token 是否跨模型可直接比较；
delay 是否在相同并发、网络、cache 条件下测量；
Pareto 同 rank 时是否只看 Perf；
多次运行下用均值还是单次结果。

问题 6：没有泛化或收敛保证

没有证明：

\Omega^{(k+1)} \succeq \Omega^{(k)},

也没有证明 OOD 风险

\mathbb{E}_{\mathcal{Q}\sim\mathcal{D}_{\mathrm{test}}} \left[ R(\tau) \right]

会随 $k$ 单调提高。camera-ready 的五轮曲线只是特定设置下的经验证据。

问题 7：程序正确性只做经验验证

生成程序能导入和返回正确类型，不等于：

记忆没有泄漏；
存储不会无限增长；
工具代码安全；
并发时状态一致；
检索无偏；
跨版本 schema 可迁移。

这对自修改 agent 尤其重要。

10. 实验设计与统计审查

10.1 优点

有同 framework、同 backbone 的 clean add-memory 对照；
同时报告性能、成本、延迟、步骤；
固定记忆 baseline 数量较多；
有 task、LLM、framework 三种迁移；
rebuttal 后补了模块消融、搜索基线和多轮演化；
对“memory is not a panacea”有诚实讨论。

10.2 重大问题

1. 数据隔离不够清楚

TaskCraft 工作子集有 $300$ 条，演化使用 $120$ 条，但表 2 的 TaskCraft 评估集是否严格排除这些条目没有明确说明。

GAIA 的部分架构使用全部 Level-1 任务和 67 个 TaskCraft query 演化，而表 2 又报告完整 GAIA。若 Level-1 任务同时参与架构搜索和最终分数，GAIA 平均分不是纯 holdout。

这不等于标签泄漏，但属于 architecture-selection leakage。

2. 统计声明过强

三次运行只能提供初步方差估计。没有检验：

H_0: \mu_{\mathrm{MemEvolve}} = \mu_{\mathrm{baseline}}.

也没有报告 effect size 或 paired bootstrap。

3. baseline fairness 仍有限

不同 framework 使用不同 LLM；
有的数字来自 pass@3，有的是 pass@1；
baseline 是否使用原作者最优 prompt、存储规模与调参预算不透明；
论文声称“faithful re-implementation”，但当前仓库缺少逐系统复现日志和对原论文数字的回归测试。

4. 主表不含架构搜索成本

表 3 的 cost 是部署时每任务 API cost，不包括：

轨迹收集；
诊断 LLM；
三个 provider 生成；
创建和自动修复；
tournament 与 finals；
失败候选成本。

rebuttal 的三轮不足 $\$65$ 是有价值的补充，但估算没有给出完整 token ledger，也不一定包含所有生成、验证和失败重试。

5. 结果可能依赖强 evaluator / designer

主实验用 GPT-5-mini 同时承担底层 agent 和外层设计。方法可能更多是在蒸馏强模型的工程直觉，而不是一个模型无关的搜索算法。跨 backbone 部署证明了产物可迁移，但没有充分测试“较弱设计器能否演化出同样好的架构”。

6. 没有极端域迁移

论文自己承认 TaskCraft 上的架构未必适合 embodied action。当前 cross-task 实验主要仍在 web/deep research/tool-use 任务族内，因此“task-agnostic”应改成：

transferable within a related agentic task regime

而不是普适记忆原则。

11. 官方代码核验

核验对象：官方仓库提交 6035d565。

11.1 Claims → Code

Claim	论文	代码事实	状态
统一 memory provider	所有系统共享接口	`BaseMemoryProvider` 统一 `initialize`、`provide_memory`、`take_in_memory`	部分一致
四模块显式可替换	Encode/Store/Retrieve/Manage	四模块没有四个独立 abstract method；Encode+Store 合并，Manage 为辅助逻辑	抽象层不完全一致
12 个 baseline	表 1 含 G-Memory	`MemoryType` 和 provider 文件只有 11 个 baseline；缺 G-Memory	不一致
三个演化系统示例	Lightweight、Riva、Cerebra	仓库有 Lightweight 和 Cerebra，没有 Riva provider	不完整
Pareto selection	正文默认使用	代码默认 `use_pareto_selection=False`，需显式 flag	默认不一致
同 rank 以 Perf 破平	式 (8)	代码使用 $0.6/0.25/0.15$ 加权分数	不一致
每轮空记忆	正文明确空初始化	默认 `clear_storage_per_round=True`，会重命名并清空父代存储	一致
$K=1,S=3$	一个 survivor，三个 descendants	README 示例 `top_t=2`；代码先选两个 finalist，再选一个 winner	工作流更复杂
40 新 + 20 复用	每候选 60 轨迹	README 示例是 $x=40,y=20$ ；代码默认是 $20,5$	需手工匹配
自动诊断和程序生成	LLM 读取轨迹并改写模块	有 Analyzer、Generator、Creator、Validator 和 checkpoint	一致
可复现实验结果	四 benchmark 主表	仓库没有提交 TaskCraft 数据、论文运行日志、候选谱系或主表复算脚本	不完整

11.2 实现中值得肯定的部分

候选先做静态和模拟调用验证；
支持 checkpoint 和人工修复后继续；
父代与后代在相同任务上比较；
finals 混合旧任务与新任务；
可选 Pareto 排序；
provider 数据载体类型清楚；
Cerebra 的文本、图和工具检索路径可读。

11.3 可复现性风险

README 明确写着“not the final release”。
核心 MemEvolve/EvolveLab 没有自己的单元测试；仓库中的 tests 基本来自 vendored mini-swe-agent。
requirements.txt 很大，包含大量与核心方法无关的固定依赖，环境重建成本高。
没有提交论文结果 JSON、随机种子运行记录、模型 endpoint 版本和完整费用账单。
商业模型名称会漂移，GPT-5-mini、Claude 与 API 行为难以长期锁定。
pass@k 复算链缺失。
当前代码没有 G-Memory 和 Riva，不能完整复现论文表 1 与图 6 的全部对象。

11.4 静态验证范围

本次核验完成了：

克隆官方仓库；
固定并记录 commit；
检查 provider、配置、选择、存储清空与 README；
对 MemEvolve、EvolveLab 和 CLI 源码执行 Python 静态编译检查。

没有实际运行完整 benchmark，因为它需要：

商业模型 API；
GAIA、WebWalkerQA、xBench、TaskCraft 数据；
数小时到数天的 agent 执行；
每轮数百次外部检索与模型调用。

因此代码验证结论是“实现结构可读、可静态检查”，不是“论文数值已独立复现”。

12. OpenReview 评审与 rebuttal

12.1 Reviewer 1

主要评价：

强项：双层演化视角、EvolveLab、跨模型和 benchmark 收益、写作清楚；
弱项：演化架构的可解释性不足；应加入更难 benchmark；
问题：为什么不测试纯推理 benchmark。

作者回应：

解释 Riva 的 agent-gated retrieval；
解释 Cerebra 的多粒度编码和周期维护；
新增 DeepSearchQA：DeepSeek V3.2 从 $56.5$ 提到 $64.0$ ，同时成本和 turns 下降；
承诺在 revision 中加强分析。

Reviewer 认为主要问题 fully resolved，维持正面评分。

12.2 Reviewer 2

主要问题最全面：

三轮、一个 survivor、三个 descendants 的搜索太小；
每候选只有 $60$ 条轨迹，方差可能很大；
framework 与模型混杂；
表 3 未写 backbone；
缺小模型；
缺搜索超参数敏感性；
缺随机或规则搜索；
缺总演化成本。

作者补充：

五轮演化；
小模型结果；
随机搜索；
贪心搜索；
三次运行；
Claude-3.7 同 backbone 比较；
每轮约 $\$20.42$ 、三轮低于 $\$65$ 。

Reviewer 最终把评分提高到 Weak Accept，但仍指出随机和贪心搜索过于基础。

12.3 Reviewer 3

主要问题：

缺模块级消融；
$K=1,S=3$ 易陷入局部最优；
GPT-5-mini 依赖；
自动改写架构增加调试风险。

作者补充：

Only Encode/Retrieve/Store/Manage 消融；
随机搜索；
五轮演化；
跨 LLM；
修改日志和模块化代码可作为 audit trail。

Reviewer 在第一次 acknowledgement 时只认为 partially resolved；作者随后补上完整模块消融。

12.4 最终决定

最终决定为 Accept (regular)。Decision 的核心判断可以概括为：

EvolveLab 对社区有明确实用价值，rebuttal 基本补齐了实证缺口；但搜索方法较基础，因此工作更像扎实的工程与评测贡献，而非高算法新颖性的突破。

Decision 还提示两条引用问题：

AutoGen 引用未被自动检查器完整验证；
AgentOrchestra 引用版本过时。

手工核对确认：

arXiv:2308.08155 的 AutoGen 当前作者列表比论文 BibTeX 中的列表更完整；
arXiv:2506.12508 已更新到 v6，标题和作者也已变化；
因此 camera-ready 应使用当前元数据，而不是 arXiv v1 中的旧条目。

13. 与相关工作的定位

工作	优化对象	是否改记忆内容	是否改记忆架构	搜索/学习方式	相比 MemEvolve
Dynamic Cheatsheet	精简策略与代码片段	是	否	测试时自整理	更轻、更适合推理；不搜索程序结构
Agent-KB	跨 framework 经验库	是	否	混合检索与 disagreement gate	知识规模更大；架构固定
G-Memory	多 agent 层级图记忆	是	否	预定义三层图	MAS 结构更专门；不是自动架构搜索
Memp	procedural memory	是	否	build/retrieve/update	对过程记忆分析更细；设计仍人工
EvolveR	经验生命周期	是	否	离线蒸馏 + 在线强化	更强调内容策略；不改 provider 代码
MemEngine	统一模块化记忆库	是	否	人工配置	与 EvolveLab 最接近；缺自动演化
GEPA	LLM prompt	间接	改 prompt，不改完整 memory program	反思 + Pareto prompt evolution	搜索算法更系统；对象更窄
Darwin Gödel Machine	整个 coding agent codebase	可包含	是，且范围更广	开放式 archive + 自修改	搜索更开放；成本、安全和域限制更大
MemEvolve	memory provider program	是	是	轨迹诊断 + 程序生成 + tournament	在“记忆架构搜索”上最直接

最准确的定位

MemEvolve 位于三条研究线的交点：

test-time / lifelong memory；
automatic agent design；
LLM-driven program evolution。

它比 Dynamic Cheatsheet、Agent-KB、G-Memory 多优化一层“机制”；比 Darwin Gödel Machine 限定了更窄、更可控的搜索空间；与 GEPA 的共同点是都用自然语言反思和 Pareto 思想从少量昂贵 rollout 中提取高层改进。

14. 贡献类型与增量评估

14.1 类型

[x] 概念创新：把 memory architecture 本身设为 self-evolution 对象；
[ ] 理论创新：没有新定理、证明或优化界；
[x] 方法创新：诊断驱动的记忆程序生成；
[x] 经验创新：跨 task、LLM、framework 的统一实验；
[x] 工程创新：EvolveLab 和可执行 provider pipeline。

14.2 增量来自哪里

相对固定记忆：

\mathrm{UpdateContent} \quad\longrightarrow\quad \mathrm{UpdateContent} {}+ \mathrm{RewriteMechanism}.

相对通用 agent evolution：

\mathrm{SearchEntireAgent} \quad\longrightarrow\quad \mathrm{SearchMemorySubsystemOnly}.

缩小搜索空间是优点：更容易执行、解释和迁移。它也是局限：真正性能瓶颈可能在 planner、tool API、context policy 或 multi-agent orchestration，而不在 memory。

14.3 创新评分

创新度： $7/10$

问题视角及时且清晰；
将记忆程序作为可执行 genotype 有价值；
但算法组件主要来自 LLM reflection、program generation、Pareto/tournament selection；
最终 Decision 也认为搜索方法比较基础。

15. 审稿人视角

15.1 Strengths

问题真实：固定记忆确实不能适配所有 agent domain。
统一实现有社区价值，比只提出一个新 memory provider 更可复用。
同框架对照证明“架构选择”确实影响性能。
OOD task、LLM、framework 迁移比只在 TaskCraft 内优化更有说服力。
camera-ready 的消融和搜索基线直接回应了核心质疑。
演化出的结构具有一定可解释性，不是不可读的参数张量。

15.2 Fundamental flaws

当前没有发现足以否定全部主结论的致命错误。最接近 fundamental concern 的是演化任务与最终评估集隔离不够清楚；如果完整复现实验发现 TaskCraft 或 GAIA 结果包含大量架构搜索题，相关 ID 数字需要重算。

15.3 Significant concerns

“co-evolution”跨轮表述比实现更强；
Pareto 公式与默认代码不一致；
$n=3$ 的均值标准差被称为显著性检验；
pass@ $k$ 未定义；
搜索基线仍弱；
主表不含架构搜索总成本；
当前仓库不能完整复现 12 baseline 与所有演化架构；
迁移主要发生在相近 task regime。

15.4 Minor issues

percentage points 与 relative percent 混用；
$\Omega$ 、 $\mathcal{E}$ 符号重载；
式 (10) 缺父代；
表 2 中 framework 图标降低可读性；
arXiv v1 有拼写与引用元数据问题；
延迟结论写得过于温和。

15.5 推荐

Weak Accept / Accept with substantial clarification

需要在最终版本或后续工作补充：

严格的 evolution/selection/test split；
pass@ $k$ 定义和复算脚本；
完整搜索成本与失败候选成本；
更强 search baselines；
真正的统计检验；
memory migration 或更准确的 co-evolution 表述；
论文配置的一键复现；
G-Memory、Riva 和实验日志的完整发布。

16. 值得复用的研究想法

16.1 把架构候选当作 typed program

下一步不应只让 LLM 自由写 Python，而应定义显式类型：

\mathcal{E}: \mathrm{Trajectory} \to \mathrm{List[MemoryItem]},

\mathcal{U}: \mathrm{MemoryState} \times \mathrm{List[MemoryItem]} \to \mathrm{MemoryState},

\mathcal{R}: \mathrm{MemoryState} \times \mathrm{Request} \to \mathrm{MemoryResponse},

\mathcal{G}: \mathrm{MemoryState} \to \mathrm{MemoryState}.

这样可以做：

schema checking；
property-based testing；
自动 migration；
模块级替换；
更公平的复杂度约束。

16.2 把选择目标扩展为风险约束

仅优化性能、成本、延迟不够。可加入：

\mathbf{F} = \left( \mathrm{Perf}, {}-\mathrm{Cost}, {}-\mathrm{Delay}, {}-\mathrm{Leakage}, {}-\mathrm{Growth}, {}-\mathrm{Instability} \right).

其中：

Leakage：记忆是否泄露标签、隐私或未来信息；
Growth：存储是否无界；
Instability：同一 query 的检索与执行方差。

16.3 让内容和架构真正共同遗传

需要显式 memory migration：

M_0^{(k+1)} = \Gamma_{k\to k+1} \left( M_{\mathrm{end}}^{(k)} \right),

其中

\Gamma_{k\to k+1} : \mathfrak{M}_{\Omega^{(k)}} \to \mathfrak{M}_{\Omega^{(k+1)}}.

若 schema 不兼容，可以由迁移器压缩、重编码或丢弃旧内容，并将迁移损失纳入 fitness。

16.4 使用 quality-diversity 而非单父代

$K=1$ 会快速丢失多样性。可以维护 archive：

\mathcal{A}_{\mathrm{archive}} = \left\{ \Omega: \mathrm{niche}(\Omega) \right\},

按以下行为特征划分 niche：

文本 vs 工具记忆；
online vs offline；
graph vs flat；
agent-gated vs deterministic retrieval；
cheap vs high-accuracy。

这会更接近 DGM 的开放式探索，又保留记忆子系统的可控边界。

16.5 把“检索是否有用”做成可归因目标

当前 reward 只看最终任务结果。更精细的诊断可以估计：

\Delta_t = R(\tau\mid c_t) {}- R(\tau\mid c_t=\varnothing),

或用 paired replay 测量某个记忆 item 的边际贡献。这样 Diagnose 阶段不必仅依赖 LLM 阅读日志。

17. 研究方向与长期前景

17.1 值得跟进吗

值得参考并进一步研究。

原因不是当前算法已经成熟，而是它抓住了一个未来会越来越重要的问题：

当 foundation model 越来越强时，系统差异会更多来自 agent harness、memory、tools、planning 和 evaluation loop；这些组件不应永远由人手工调。

17.2 未来五年的关键问题

搜索空间：自由 Python、DSL 还是组件图？
信用分配：成功来自哪条记忆、哪个模块和哪次修改？
持续性：如何在改 schema 时保留旧记忆？
安全：自生成工具和记忆代码怎样沙箱化？
稳定性：如何防止记忆污染、漂移与无界增长？
泛化：如何从 web research 迁移到 embodied、coding、science 和 personalization？
评测：如何构造真正无泄漏的长期 task stream？
成本：何时搜索成本能被长期部署收益摊销？

17.3 如果我是作者的 advisor

我会建议下一篇工作不要再只增加更多 memory provider，而应集中解决三个硬问题：

typed memory DSL + automatic migration；
具有 archive 和 surrogate 的更强搜索；
严格的跨域 continual benchmark，并报告完整成本与安全约束。

18. 科研品味评分

维度	评分	理由
Novelty	★★★★☆ $3.8/5$	问题定义好，机制增量中等
Rigor	★★★☆☆ $3.0/5$	camera-ready 补强明显，但统计、形式化和复现链仍有缺口
Impact	★★★★☆ $3.8/5$	EvolveLab 与 harness evolution 方向可能有持续影响
Clarity	★★★★☆ $4.0/5$	故事清楚，公式可读；部分术语和结果表达过强
Reproducibility	★★★☆☆ $2.7/5$	代码已开源但不是最终版本，关键实验资产缺失

最终一句话

这篇论文在 self-evolving agent 方向上，把“记忆内容学习”推进到“记忆程序搜索”，并用统一代码库和跨任务迁移证明这个问题值得研究；它是一篇问题品味和工程价值高于理论与搜索算法新颖性的扎实 ICML 论文。

MemEvolve：智能体记忆系统的元演化 ​

一句话总结 ​

0. 先给结论 ​

0.1 这篇论文真正做了什么 ​

0.2 主要实验证据 ​

0.3 证据应如何降温 ​

0.4 我的总体判断 ​

1. 版本、作者与公开评审状态 ​

1.1 arXiv v1 与 camera-ready 不完全相同 ​

1.2 公开评审概况 ​

2. 问题定义与核心主张 ​

2.1 普通自改进记忆只改变“记住了什么” ​

2.2 为什么不存在单一最优记忆 ​

2.3 论文的四项核心主张 ​

3. 完整数学形式化 ​

3.1 智能体系统 ​

3.2 四模块记忆架构 ​

Encode ​

Store ​

Retrieve ​

Manage ​

3.3 固定架构下的一阶经验演化 ​

3.4 内循环：经验演化 ​

3.5 外循环：架构演化 ​

3.6 三目标选择 ​

3.7 Diagnose-and-Design ​

Diagnosis ​

Design ​

3.8 它不是梯度型双层优化 ​

4. 系统架构与完整算法流程 ​

4.1 EvolveLab 的抽象层 ​

4.2 一轮自动演化的真实执行 ​

4.3 默认超参数 ​

4.4 训练与推理的区别 ​

4.5 三个代表性演化结果 ​

Lightweight ​

Riva ​

Cerebra ​

5. 数据集、模型与评测设置 ​

5.1 数据集 ​

5.2 Agent framework 与 backbone ​

5.3 评价指标 ​

6. 主实验结果 ​

6.1 与无记忆 agent 的直接比较 ​

6.2 跨 LLM 迁移 ​

6.3 与七种固定记忆的统一比较 ​

6.4 成本、延迟和步数 ​

7. Camera-ready 新增实验 ​

7.1 模块级消融 ​

7.2 三次运行 ​

7.3 五轮演化 ​

7.4 Claude-3.7 跨 backbone 迁移 ​

7.5 搜索基线 ​

8. Claims → Evidence 映射 ​

9. 数学与理论严谨性审查 ​

9.1 做得好的地方 ​

9.2 主要数学问题 ​

问题 1：Ω\OmegaΩ 被过度重载 ​

问题 2：内循环不是“学习到最优内容” ​

问题 3：跨轮 co-evolution 语义不成立 ​

问题 4：父代保留与式 (10) 不一致 ​

问题 5：Pareto 选择缺少完整定义 ​

问题 6：没有泛化或收敛保证 ​

问题 7：程序正确性只做经验验证 ​

10. 实验设计与统计审查 ​

10.1 优点 ​

10.2 重大问题 ​

1. 数据隔离不够清楚 ​

2. 统计声明过强 ​

3. baseline fairness 仍有限 ​

4. 主表不含架构搜索成本 ​

5. 结果可能依赖强 evaluator / designer ​

6. 没有极端域迁移 ​

11. 官方代码核验 ​

11.1 Claims → Code ​

11.2 实现中值得肯定的部分 ​

11.3 可复现性风险 ​

11.4 静态验证范围 ​

12. OpenReview 评审与 rebuttal ​

12.1 Reviewer 1 ​