【论文阅读】Agent 记忆机制（103）：Dynamic Coding Memory——记忆为何让 Agent 更可靠，却可能更平庸

文章目录

前言
零、论文基本信息
[一、问题背景：MLE Agent 为什么会反复犯同一种错](#一、问题背景：MLE Agent 为什么会反复犯同一种错)
- [1. MLE 不是一次性代码生成](#1. MLE 不是一次性代码生成)
- [2. 错误会在同一轨迹、不同分支和不同运行间复现](#2. 错误会在同一轨迹、不同分支和不同运行间复现)
- [3. 记忆的目标不应只定义为"减少错误"](#3. 记忆的目标不应只定义为“减少错误”)
二、相关工作：本文研究的是记忆的行为效应
- [1. MLE Agent 的两种基本搜索范式](#1. MLE Agent 的两种基本搜索范式)
- [2. 通用 Agent Memory 与代码错误记忆](#2. 通用 Agent Memory 与代码错误记忆)
- [3. 与"证明记忆有效"的工作有何不同](#3. 与“证明记忆有效”的工作有何不同)
[三、两类 MLE Agent：同一记忆为什么会产生不同影响](#三、两类 MLE Agent：同一记忆为什么会产生不同影响)
- [1. OpenHands：单轨迹的顺序修正](#1. OpenHands：单轨迹的顺序修正)
- [2. AIDE：代码空间的树式搜索](#2. AIDE：代码空间的树式搜索)
[四、Dynamic Coding Memory 方法总览](#四、Dynamic Coding Memory 方法总览)
[五、记忆表示：把一次 Debug 压缩成可检索的 error-fix 对](#五、记忆表示：把一次 Debug 压缩成可检索的 error-fix 对)
- [1. 结构化条目](#1. 结构化条目)
- [2. 为什么必须同时保存 Error 与 Fix](#2. 为什么必须同时保存 Error 与 Fix)
[六、检索与更新：为什么只在同一 Task 内搜索](#六、检索与更新：为什么只在同一 Task 内搜索)
- [1. Task-indexed Retrieval](#1. Task-indexed Retrieval)
- [2. 在线更新与去重](#2. 在线更新与去重)
- [3. 怎样接入两类 Agent](#3. 怎样接入两类 Agent)
七、实验设置
- [1. 数据集与评价方式](#1. 数据集与评价方式)
- [2. Backbone 与搜索预算](#2. Backbone 与搜索预算)
- [3. 计算环境](#3. 计算环境)
八、主实验：同样减少错误，最终效果却相反
- [1. OpenHands：可靠性与结果同向改善](#1. OpenHands：可靠性与结果同向改善)
- [2. AIDE：有效提交更多，高质量方案反而更少](#2. AIDE：有效提交更多，高质量方案反而更少)
[九、过程分析：Bug 少了 23%，最终得分却不一定更高](#九、过程分析：Bug 少了 23%，最终得分却不一定更高)
十、探索---利用分析：记忆究竟改变了什么
- [1. 多样性指标](#1. 多样性指标)
- [2. AIDE：更早得到可运行代码，但搜索范围收缩](#2. AIDE：更早得到可运行代码，但搜索范围收缩)
- [3. OpenHands：工具类型略少，具体命令反而更多](#3. OpenHands：工具类型略少，具体命令反而更多)
十一、模态敏感性：结构化任务更容易从错误记忆中获益
[十二、成功案例：记忆如何切断重复 API 错误](#十二、成功案例：记忆如何切断重复 API 错误)
[十三、失败案例：Timeout 记忆如何把图像搜索推向错误方向](#十三、失败案例：Timeout 记忆如何把图像搜索推向错误方向)
十四、附录中的错误复现证据
[十五、与 Agent Memory 系列方法的横向比较](#十五、与 Agent Memory 系列方法的横向比较)
[十六、对 Coding Agent、Tool Agent 与 Multi-Agent 的启发](#十六、对 Coding Agent、Tool Agent 与 Multi-Agent 的启发)
- [1. Coding Agent：区分确定性错误与探索性失败](#1. Coding Agent：区分确定性错误与探索性失败)
- [2. Tool Agent：记忆需要作用域与有效期](#2. Tool Agent：记忆需要作用域与有效期)
- [3. Multi-Agent：共享记忆会让并行 Agent 同质化](#3. Multi-Agent：共享记忆会让并行 Agent 同质化)
- [4. 自适应记忆调度](#4. 自适应记忆调度)
十七、局限性与证据边界
- [1. 只验证两个 Scaffold](#1. 只验证两个 Scaffold)
- [2. Backbone 与预算不一致](#2. Backbone 与预算不一致)
- [3. MLE-Bench Lite 只有 22 个任务](#3. MLE-Bench Lite 只有 22 个任务)
- [4. 默认不做跨任务迁移](#4. 默认不做跨任务迁移)
- [5. 记忆更新只有 ADD/NOOP](#5. 记忆更新只有 ADD/NOOP)
- [6. 缺少成本分析](#6. 缺少成本分析)
- [7. 缺少显著性检验与更强因果控制](#7. 缺少显著性检验与更强因果控制)
- [8. 持久偏见与错误传播](#8. 持久偏见与错误传播)
十八、我的理解与启发
- [1. Agent Memory 本质上也是 Policy Regularizer](#1. Agent Memory 本质上也是 Policy Regularizer)
- [2. 记忆评价需要同时看结果、过程和分布](#2. 记忆评价需要同时看结果、过程和分布)
- [3. "不要重复过去的错误"不是无条件正确的规则](#3. “不要重复过去的错误”不是无条件正确的规则)
- [4. 多样性应该成为 Memory Optimization 的显式目标](#4. 多样性应该成为 Memory Optimization 的显式目标)
- [5. 最优记忆策略可能是动态门控，而非始终开启](#5. 最优记忆策略可能是动态门控，而非始终开启)
十九、总结
参考资料

前言

给 Coding Agent 增加长期记忆，听起来几乎一定是好事。

它可以记住某个 API 已经过时、某个数据文件的维度与预期不符、当前环境无法联网下载预训练权重。下一次遇到相同错误时，不必再次从头排查。

但机器学习工程 Agent 不只是"把程序运行起来"。它还需要在庞大的方案空间中寻找更好的特征、模型、损失函数和训练配置。一个过度相信历史经验的 Agent，可能更少犯错，却也更少尝试新路线。

这就产生了一个此前 Agent Memory 研究中容易被忽略的问题：记忆是否总能提高 Agent 的最终任务表现？

在 A-MEM、MAGMA、CoM、ReMemR1、Mem²Evolve 等工作中，研究重点通常是如何写入、组织、回看、压缩或演化记忆。它们共同推动了记忆系统从静态存储走向主动管理。但"更稳定地复用过去"本身也会改变 Agent 的行为分布：它可能减少无效重复，也可能把搜索锁定在熟悉区域。

本文把这个问题放到 Machine Learning Engineering（MLE）Agent 中研究。作者构建 Dynamic Coding Memory，专门保存代码执行中的 error-fix 经验，再把同一套记忆模块分别接入两种代表性架构：

顺序、单轨迹的链式 Agent：OpenHands；
并行、多分支的树式搜索 Agent：AIDE。

实验得到的不是"记忆有用"这样简单的结论，而是一个明显依赖架构的结果：

对链式 Agent，记忆减少重复错误，改善提交成功率与最终表现；
对树式 Agent，记忆同样减少错误，却可能压缩搜索多样性，使最终方案更安全但更平庸。

因此，本文的唯一核心增量是：

通过在链式与树式 MLE Agent 中控制性接入同一套动态错误记忆，论文实证揭示了记忆并非普遍增益模块，而是一个会依 Agent 搜索架构重新调节"执行可靠性---探索创新性"平衡的行为机制。

Dynamic Coding Memory 是完成这项研究的实验载体；真正重要的贡献，是把"记忆让 Agent 更稳定"与"记忆让 Agent 找到更好方案"明确区分开。

零、论文基本信息

论文名称： Demystify the Role of Memory in Machine Learning Engineering Agents
发表平台： Findings of the Association for Computational Linguistics: ACL 2026
代码仓库： 论文与 ACL Anthology 页面未提供公开代码仓库
作者： Xinyu Zhao、Junpeng Wang、Yuzhong Chen、Menghai Pan、Chin-Chia Michael Yeh、Jiarui Sun、Yan Zheng、Mahashweta Das、Tianlong Chen

一、问题背景：MLE Agent 为什么会反复犯同一种错

1. MLE 不是一次性代码生成

机器学习工程任务通常包含一整条长链路：读取数据、理解 Schema、预处理、选择模型、训练、调参、生成提交文件，再根据执行结果继续修正。

对任务 t t t，数据集记为：

D t = ( X t , Y t ) D_t=(X_t,Y_t) Dt=(Xt,Yt)

一个候选实现写为：

z = ( f , λ ) ∈ Z z=(f,\lambda)\in\mathcal{Z} z=(f,λ)∈Z

其中 f f f 是可执行 Python 程序， λ \lambda λ 是随机种子、运行 Flag 等轻量配置。执行后得到验证分数：

J t ( z ) = Eval ⁡ t ( z ; D t ) J_t(z)=\operatorname{Eval}_t(z;D_t) Jt(z)=Evalt(z;Dt)

Agent 的目标是找到高分实现：

z ∗ ∈ arg ⁡ max ⁡ z ∈ Z J t ( z ) z^*\in\arg\max_{z\in\mathcal{Z}}J_t(z) z∗∈argz∈ZmaxJt(z)

这意味着"程序能运行"只是必要条件，而不是最终目标。一个从不报错但模型选择错误的方案，可能远不如偶尔失败、最终发现高回报路线的探索过程。

2. 错误会在同一轨迹、不同分支和不同运行间复现

先看论文观察到的两类重复失败：

Figure 1：MLE Agent 的重复错误模式。 AIDE 会在不同搜索节点重复已经出现过的 API 错误，OpenHands 也会在同一任务的独立运行中重现相同文件格式错误。

树式 AIDE 的一个分支已经发现 LGBMClassifier.train() 不接受某参数，但另一个分支仍可能再次使用同样的错误调用。链式 OpenHands 的一次运行已经知道目标文件不是 DOCX，下一次独立运行却会重新尝试 DOCX 解析。

这些失败不是模型完全没有调试能力，而是局部修复没有沉淀为可复用经验。错误在当前上下文消失后，Agent 又回到"第一次遇见它"的状态。

3. 记忆的目标不应只定义为"减少错误"

若只统计 Bug 数量，记忆当然越强越好。但 MLE Agent 同时面对两个目标：

Execution Reliability 与 Search Innovation \text{Execution Reliability}\quad\text{与}\quad\text{Search Innovation} Execution Reliability与Search Innovation

前者要求少报错、尽快找到可运行方案；后者要求保持足够广的模型与代码搜索空间。

记忆会提醒 Agent 避免已知风险，这通常提升可靠性；但如果"已知风险"恰好来自计算密集、却更适合任务的路线，记忆也可能将 Agent 过早推向安全但次优的方案。

二、相关工作：本文研究的是记忆的行为效应

1. MLE Agent 的两种基本搜索范式

一类系统采用链式事件---观察循环。Agent 执行动作、读取输出、修改代码，再沿同一轨迹继续。OpenHands、DS-Agent、MLE-STAR 等更接近这一模式。

另一类系统显式维护候选解树，在多个分支间 Draft、Debug 和 Improve。AIDE、ML-Master、MLZero 更接近代码空间搜索。

二者的根本差别在于：链式 Agent 只有一条当前路线，错误会直接阻断后续进展；树式 Agent 已经依靠多分支分散风险，错误有时也是探索新区域的代价。

2. 通用 Agent Memory 与代码错误记忆

通用对话记忆常保存用户偏好、事件、事实或会话摘要。MLE 中真正反复出现的却是更结构化的知识：

哪个 Package 导致错误；
具体 Error Type 与 Traceback；
哪个函数或参数不兼容；
什么修改曾经成功修复。

若只对整段历史做通用 RAG，检索结果可能缺少可操作的 error-fix 对应关系。因此本文按照 Task 与 Package 组织记忆，而不是保存自由文本对话片段。

3. 与"证明记忆有效"的工作有何不同

MLZero、MLE-STAR 等系统已经使用不同形式的记忆。本文不再只问"加记忆后平均分是否上升"，而是同时观测：

Bug Rate；
首次得到有效程序的时间；
Package、工具、命令和 AST Operator 的多样性；
可运行代码之间的距离；
最终 Kaggle 排名与奖牌率。

这种评估把过程稳定性与结果质量拆开，使"少犯错但成绩更差"不再被平均分掩盖。

三、两类 MLE Agent：同一记忆为什么会产生不同影响

1. OpenHands：单轨迹的顺序修正

OpenHands 的状态是按时间排列的 Action---Observation Event Stream。每次迭代执行：

step ⁡ ( s t a t e ) → A c t i o n \operatorname{step}(state)\rightarrow Action step(state)→Action

论文将操作概括为：

EXECUTE： 运行 Python 或 Shell 命令；
OBSERVE： 阅读控制台输出和错误 Trace；
REVISE： 根据结果修改代码。

它像一个开发者沿当前实现持续 Debug。若早期被相同错误反复阻断，整个 24 小时时间预算都会被浪费。因此，避免重复 Bug 与最终完成任务通常方向一致。

2. AIDE：代码空间的树式搜索

AIDE 的每个节点都是一份可执行 Python Script，并带有验证分数。策略 Π \Pi Π 在三类操作间选择：

DRAFT： 从头生成一个新方案，形成新根分支；
DEBUG： 修复失败节点，同时保留该节点的设计意图；
IMPROVE： 在有效程序上做增量优化。

树搜索天然允许多种算法路线并行存在。某个分支失败不会终止整个任务，反而可能提供关于方案边界的信息。

这时，记忆对所有分支反复强调同一批"安全修复"，就可能让原本相互独立的分支趋同。Bug 少了，但搜索树也变窄了。

四、Dynamic Coding Memory 方法总览

理解本文，需要先看清记忆是怎样构建、检索和更新的：

Figure 2：Dynamic Coding Memory。 系统把历史任务中的 error-fix 对结构化保存，运行时按任务检索相关经验，并通过 ADD/NOOP 过滤重复条目。

整体流程包含三个环节：

从失败执行与成功修复中构建结构化条目；
新运行开始或继续搜索时，检索同任务经验；
新错误出现后，判断它是否与已有错误重复，再决定追加或忽略。

它不是完整的 Agent Memory OS，也不保存所有代码与推理历史。它有意只聚焦"可复用的调试经验"，以便研究错误记忆如何改变搜索行为。

五、记忆表示：把一次 Debug 压缩成可检索的 error-fix 对

1. 结构化条目

每个记忆条目表示为：

e = ( t , package ⁡ , error ⁡ , fix ⁡ , ϕ ( e ) ) e=(t,\operatorname{package},\operatorname{error},\operatorname{fix},\phi(e)) e=(t,package,error,fix,ϕ(e))

其中：

t t t：任务标识；
package：导致错误的软件包，例如 lightgbm、sklearn；
error：规范化后的运行时 Traceback；
fix：曾经成功解决错误的修改；
ϕ ( e ) ∈ R d \phi(e)\in\mathbb{R}^d ϕ(e)∈Rd：将错误文本与修复摘要拼接后得到的 Embedding。

若错误不能归因于具体软件包，例如文件 I/O、环境或外部依赖问题，系统将 Package 记为 general。

2. 为什么必须同时保存 Error 与 Fix

只保存"出现过 TypeError"没有行动价值。可复用经验需要包含足够精确的调用位置与已验证修复。

例如：

Task	Package	Error	Fix
leaf-classification	lightgbm	`LGBMClassifier.fit()` 不接受 `early_stopping_rounds`	改用 `callbacks=[lgb.early_stopping(50)]`
leaf-classification	xgboost	`XGBClassifier.fit()` 不接受 `eval_metric`	将 `eval_metric` 移到构造函数
aerial-cactus	timm	无网络时无法下载预训练权重	设置 `pretrained=False`
denoising-dirty	sklearn	`HistGradientBoostingRegressor` 不接受 `n_jobs`	删除 `n_jobs=-1`

Table 4：AIDE 积累的代表性记忆。 每条记忆将具体 API 或环境错误绑定到已经验证的解决办法。

这种表示使记忆更像 Debugging Knowledge Base，而不是聊天摘要。

六、检索与更新：为什么只在同一 Task 内搜索

1. Task-indexed Retrieval

对当前任务 t t t，系统先把记忆库限制到：

M t = { e ∈ M ∣ task ⁡ ( e ) = t } \mathcal{M}_t=\{e\in\mathcal{M}\mid\operatorname{task}(e)=t\} Mt={e∈M∣task(e)=t}

也就是说，默认不跨任务迁移。随后再在同一任务、相关 Package 的条目中根据 Embedding 相似度检索。

这一选择看起来保守，但附录给出了依据：同任务检索的平均相似度为 0.032 ± 0.009 0.032\pm0.009 0.032±0.009，跨任务只有 0.013 ± 0.003 0.013\pm0.003 0.013±0.003，差距约 2.0--4.9 倍；统计量为 t = 10.69 t=10.69 t=10.69、 p < 10 − 9 p<10^{-9} p<10−9、Cohen's d = 2.28 d=2.28 d=2.28。

跨任务最相似的内容往往只是通用 API 弃用提示，缺少当前数据 Schema 和任务环境。更重要的是，若让后执行任务读取先执行任务的经验，任务顺序会成为新的实验混杂因素。

2. 在线更新与去重

新的执行错误被整理为：

e ′ = ( t , package ⁡ ′ , error ⁡ ′ , fix ⁡ ′ , ϕ ( e ′ ) ) e'=(t,\operatorname{package}',\operatorname{error}',\operatorname{fix}',\phi(e')) e′=(t,package′,error′,fix′,ϕ(e′))

系统从相同 Task 与 Package 中检索最多 5 条近邻，再由轻量管理模块决定：

ADD： 新错误与已有条目不同，加入记忆库；
NOOP： 与已有错误完全相同，不重复写入。

附录提示词采取非常保守的去重规则：不同函数、不同 Error Type、不同错误消息或不同根因都应 ADD；只有相同 Package、函数、错误类型与根因才 NOOP。

这种策略减少完全重复项，但也容易让记忆快速增长。dog-breed 案例中同一任务积累到 1,348 条，其中 548 条是 Timeout，说明"避免完全重复"并不等于"保证记忆分布健康"。

3. 怎样接入两类 Agent

对 OpenHands，检索结果被放进每次尝试的初始消息，提醒顺序 Agent 避免已知 Package 错误并采用验证过的修改。

对 AIDE，记忆同时影响 DEBUG 与 IMPROVE：生成新节点时，模型会看到此前分支中解决过的错误。

表面上只是相同信息插入不同 Prompt，实际却改变了两种搜索过程：OpenHands 得到一条更连贯的修正链；AIDE 的多个分支则受到共同先验约束。

七、实验设置

1. 数据集与评价方式

实验使用 MLE-Bench Lite，包括 22 个来自 Kaggle 的任务，覆盖图像、文本、表格与音频。

评价指标分两组：

提交能力： Made Submission、Valid Submission；
竞争表现： Above Median、Bronze、Silver、Gold、Any Medal。

Any Medal 表示提交达到 Kaggle 铜牌及以上，是论文的 Headline Metric。它比"程序成功运行"更接近最终 MLE 质量。

2. Backbone 与搜索预算

AIDE 使用 o3 作为代码搜索模型、GPT-4.1 作为 Feedback Model，最多 30 个 Step，最大 Debug Depth 为 3，Debug Probability 为 0.5，单次执行 Timeout 为 7,200 秒。

OpenHands 使用 GPT-4o、CodeActAgent，最多 500 Step。每个任务为 Agent 分配 24 小时 Wall-clock Budget。

AIDE 每个任务使用 16 个 Seed；OpenHands 每个任务重复 3 次。结果报告均值与一个标准误差（SEM）。两种 Agent 的 Backbone、搜索步数与重复次数都不同，因此适合比较"各自加记忆前后"的变化，不适合直接比较 AIDE 与 OpenHands 哪个绝对更强。

3. 计算环境

实验服务器使用 Ubuntu 20.04、双 AMD EPYC 7513 32 核 CPU、448 GB RAM、单张 NVIDIA A100-SXM4 40GB，以及 2TB SSD。

论文没有报告 Token 消耗、API 费用或完整内存占用，因此无法评估记忆模块带来的真实经济成本变化。

八、主实验：同样减少错误，最终效果却相反

Agent	设置	Made Submission	Valid Submission	Above Median	Any Medal
AIDE（o3）	Baseline	100.00±0.00	91.27±0.83	55.47±1.94	34.40±1.83
AIDE（o3）	+Memory	100.00±0.00	94.80±0.95	44.77±1.61	22.95±1.77
OpenHands（GPT-4o）	Baseline	31.82±6.94	28.79±6.06	15.15±4.01	15.15±4.01
OpenHands（GPT-4o）	+Memory	34.85±1.52	34.85±1.52	19.70±1.52	18.18±0.00

Table 1：AIDE 与 OpenHands 的主实验。 记忆提高两类 Agent 的提交稳定性，却只提高链式 OpenHands 的最终竞争表现，反而降低树式 AIDE 的高质量方案比例。

1. OpenHands：可靠性与结果同向改善

加入记忆后：

Made Submission 提升 3.03 个百分点；
Valid Submission 提升 6.06 个百分点；
Above Median 提升 4.55 个百分点；
Any Medal 提升 3.03 个百分点。

对单轨迹 Agent，Debug 错误就是主要瓶颈。记忆减少重复失败后，Agent 有更多预算继续当前路线，修复链也更连贯。因此可靠性改善能够传导到最终结果。

但 OpenHands 只有 3 次重复，标准误差较大；Any Medal 的变化只有约 3 个百分点。该结论方向一致，却不应被解读为已经证明大幅且稳定的普遍增益。

2. AIDE：有效提交更多，高质量方案反而更少

AIDE 的 Valid Submission 从 91.27% 升至 94.80%，说明记忆确实让代码更容易运行。

与此同时：

Above Median 从 55.47% 降至 44.77%，下降 10.70 个百分点；
Any Medal 从 34.40% 降至 22.95%，下降 11.45 个百分点；
Gold 从 10.61% 降至 4.87%。

这组数据是全文最重要的证据：可运行性不是方案质量的代理指标。

AIDE 本来通过多分支承担风险。记忆让每个分支更倾向于采用已经验证、安全的修复和工具，从而提高有效节点比例，却削弱了候选方案之间的差异。

九、过程分析：Bug 少了 23%，最终得分却不一定更高

论文进一步跟踪 AIDE 各 Step 的累计 Bug 与 Best-so-far Validation Metric：

Figure 3：AIDE 搜索过程中的最佳验证分数与累计 Bug。 记忆在分类、回归和文本归一化任务上都压低累计错误，但验证指标的改善并不一致。

跨任务组汇总后，记忆让累计 Bug 数下降约 23%。但 22 个任务中，11 个性能改善，10 个轻微下降；Bug Reduction 与最终验证表现的 Pearson 相关系数只有：

r = 0.21 r=0.21 r=0.21

这说明减少 Bug 与找到更好模型只有弱相关。分类与回归的搜索曲线在记忆下更稳定，文本归一化任务却更早进入平台期。

对 Tree Search 来说，某些失败节点并非纯浪费。它们可能是通往新模型族、复杂特征或更高回报区域的必经试错。若记忆过早把这些路线标记为危险，搜索就会更稳定，也更保守。

十、探索---利用分析：记忆究竟改变了什么

1. 多样性指标

作者用 Shannon Entropy 衡量 Package 与 AST Operator 的分布，再转换成有效类别数：

N e f f = exp ⁡ ( H ) N_{eff}=\exp(H) Neff=exp(H)

若所有类别使用均匀， N e f f N_{eff} Neff 可理解为具有相同熵的等频类别数量。它比只统计"出现过多少种 Package"更能反映实际使用是否集中。

对 AIDE，还计算：

First Valid Node：首次出现可运行解的 Step，越小越好；
Valid Code Distance：连续可运行代码间的 Token-set Jaccard Distance，越小表示更偏局部修改。

对 OpenHands，则区分高层 Tool Diversity、具体 Command Diversity 与 AST Operator Diversity。

2. AIDE：更早得到可运行代码，但搜索范围收缩

指标	Baseline	+Memory	差值
Bug Rate（%）↓	46.72±1.58	24.02±1.06	-22.70
N e f f N_{eff} Neff ↑	8.45±0.16	8.10±0.14	-0.34
First Valid Node ↓	3.12±0.30	0.80±0.14	-2.32
Valid Code Distance ↓	29.17±0.54	27.18±0.41	-0.02

Table 2：AIDE 的探索---利用指标。 记忆大幅降低 Bug Rate，并让 Agent 更早找到可运行解，但有效搜索类别数与代码距离同时下降。

First Valid Node 从 3.12 降到 0.80，说明 Agent 几乎一开始就能进入可运行区域。问题在于，后续搜索也更靠近该区域做局部改进。

Valid Code Distance 的论文表格差值写为 -0.02，和两列均值的直接差并不在同一数值尺度，可能来自 Pair-wise Aggregation 后再求平均。成稿应保留论文报告值，而不能自行用聚合均值重算替换。

3. OpenHands：工具类型略少，具体命令反而更多

指标	Baseline	+Memory	差值
Bug Rate（%）↓	16.27±1.48	14.11±1.66	-2.16
N e f f ( t o o l ) N_{eff}(tool) Neff(tool) ↑	2.13±0.08	1.93±0.09	-0.20
N e f f ( c o m m a n d ) N_{eff}(command) Neff(command) ↑	115.24±23.60	181.19±28.19	+65.95
N e f f ( o p s ) N_{eff}(ops) Neff(ops) ↑	0.66±0.17	0.53±0.16	-0.13

Table 3：OpenHands 的探索---利用指标。 记忆略微减少高层工具与 AST Operator 多样性，却显著增加具体命令多样性。

这并不意味着 OpenHands 开始做更广泛的架构搜索。更合理的解释是：记忆减少无效重复后，Agent 会在同一条路线中尝试更多具体命令和修复方式，形成更有效的局部利用。

十一、模态敏感性：结构化任务更容易从错误记忆中获益

Figure 4：各任务加入记忆后的 Any Medal 变化。 蓝色表示提升，橙色表示下降；同一记忆机制在不同 Agent 与任务上表现出明显异质性。

Agent	模态	Baseline	+Memory	差值
AIDE	Audio	25.00±17.68	20.00±14.14	-5.00
AIDE	Image	37.50±12.09	14.37±7.24	-23.13
AIDE	Tabular	18.75±16.24	35.00±20.46	+16.25
AIDE	Text	35.42±15.21	30.21±11.06	-5.21
OpenHands	Audio	0.00±0.00	0.00±0.00	0.00
OpenHands	Image	13.33±9.66	10.00±6.75	-3.33
OpenHands	Tabular	25.00±13.82	33.33±16.67	+8.33
OpenHands	Text	16.67±6.80	27.78±12.21	+11.11

Table 5：不同数据模态下的 Any Medal。 AIDE 在表格任务上获益最大、图像任务下降最明显；OpenHands 在表格与文本任务上改善。

表格与文本任务中的错误往往与 Schema、列名、Parser、传统 ML API 或符号操作有关，error-fix 对容易迁移。

图像任务的高性能路线更依赖深度模型、预训练权重和较高计算预算。若记忆里累积大量 Timeout 与环境限制，Agent 会把"耗时"误当作"方案不值得尝试"，因此对图像任务伤害更大。

各模态任务数有限，标准误差也很大。这些数字更适合支持机制解释，而不足以给出"记忆适合表格、不适合图像"的普遍定律。

十二、成功案例：记忆如何切断重复 API 错误

在 leaf-classification 中，Baseline 持续遇到 LightGBM 与 XGBoost 的 API 版本不兼容：旧参数被放在错误位置，并在不同 Branch 中重复。

加入记忆后，已验证的修复在 74% 的 Buggy Node 中被检索。结果如下：

指标	Baseline	+Memory
Bug Rate	91.7%（440/480）	21.2%（102/480）
主导 TypeError 次数	260	18

leaf-classification 案例。 精确、可执行的 API 修复能够跨搜索分支复用，使相同错误不再被每个分支独立学习一次。

这个案例展示了 Dynamic Coding Memory 最理想的工作条件：

错误根因明确；
修复具有稳定确定性；
修复不会排除高潜力模型族；
多个分支确实会重复相同错误。

十三、失败案例：Timeout 记忆如何把图像搜索推向错误方向

dog-breed-identification 是全文最重要的反例。

加入记忆后，Bug Rate 从 39.8% 降到 34.6%，表面上系统更可靠；但 Best-so-far Score 从 0.622 暴跌到 0.294。

作者追踪出四步因果链：

1,348 条记忆中有 548 条是 Timeout，占 40.7%；
Buggy Node 的 95 次检索中，55 次返回 Timeout Guidance，占 57.9%；
成功节点中的深度图像 Package 显著减少：torch 从 280 降到 107，timm 从 20 降到 3；
表格模型栈反而增加：lightgbm 从 1 增到 35，catboost 从 0 增到 26，sklearn 从 289 增到 314。

记忆没有直接告诉 Agent"不要做图像模型"，但反复出现的 Timeout 经验形成了隐式正则：计算昂贵的路线被持续标记为风险，Agent 最终收敛到更轻量、可运行，却不适合图像识别的方案。

这说明 Memory Quality 不能只靠去重保证。环境错误、资源限制、代码 Bug 和算法失败必须区分；否则记忆会把临时约束固化成长期偏见。

十四、附录中的错误复现证据

作者还比较 OpenHands 的早期错误（Step 0--9）与后期错误（Step ≥10）。22 个任务中，记忆减少了 11 个任务的后期错误，但也有任务明显恶化。

例如 siim-isic-melanoma-classification 中，Baseline 某次运行从 Step 13 开始陷入 KeyError: 'sex' 循环，在 263 个 Step 中重复 84 次；三个 Memory Run 则没有再出现该 KeyError。

相反，mlsp-2013-birds 的平均后期错误从 7.3 增到 31.0，the-icml-2013-whale-challenge 从 0.7 增到 12.3。记忆不是自动消除所有错误，它可能阻断一种错误，又把搜索推入另一种失败模式。

这也是为什么论文主结论应是"架构与任务依赖的行为调节"，而不是"记忆防止重复错误"。

十五、与 Agent Memory 系列方法的横向比较

方法	主要研究对象	核心问题	与本文的差别
A-MEM	可链接、可演化的外部记忆	如何让记忆自动组织与关联	本文结构更简单，重点研究记忆如何改变代码搜索行为
MAGMA	多图协同记忆	如何用多种关系视图支持检索	本文不追求丰富拓扑，而按 Task/Package 存储 error-fix 对
CoM	可学习的压缩记忆	在有限容量中保留什么	本文不是训练压缩策略，而是测量复用过去错误对探索的副作用
ReMemR1	可回看的读时记忆	如何避免顺序压缩中的不可逆遗忘	本文关注 Debug 经验跨运行复用，以及这种复用是否压缩搜索多样性
Mem²Evolve	记忆与经验的持续演化	如何让长期经验自我更新	本文仅做 ADD/NOOP，反而暴露了缺少质量治理时的偏见累积
UMA	一次构建、多问题复用的共享记忆	如何用下游效用训练 Query-agnostic Memory	UMA 优化记忆效用；本文提醒下游效用也必须覆盖创新与多样性，不能只奖励稳定性
Dynamic Coding Memory	MLE 中的错误与修复	记忆对不同搜索架构产生什么行为影响	核心是可靠性---创新性 Trade-off，而非通用记忆能力升级

Agent Memory 方法横向比较。 本文把评价视角从"记忆是否保存和找回信息"扩展到"记忆如何改变 Agent 的搜索分布"。

它对既有系列的重要补充是：更高的 Recall、更少的 Bug 和更稳定的轨迹，都不能单独证明记忆提高了最终任务能力。对开放式 Agent，记忆还承担 Policy Prior 的作用。

十六、对 Coding Agent、Tool Agent 与 Multi-Agent 的启发

以下内容是基于论文证据的工程推演，不是论文已经完成的实验。

1. Coding Agent：区分确定性错误与探索性失败

适合强复用的记忆包括：

API 参数已弃用；
当前环境没有某 Package；
文件格式或 Schema 已确认；
某个修复已经多次验证成功。

不应无条件强化的记忆包括：

某模型训练曾经 Timeout；
某次超参数效果不好；
某路线在单一 Seed 下失败；
因临时资源限制而中断。

前者接近确定性约束，后者只是带条件的经验。将二者放进同一种 Error Memory，会让系统把偶然失败误写成禁令。

2. Tool Agent：记忆需要作用域与有效期

工具失败可能来自参数错误、权限、服务暂时不可用或限流。记忆条目至少应保存：

失败类型与责任层；
发生时的环境与版本；
修复是否经过验证；
适用范围；
过期时间与反例。

否则，"今天 API 超时"可能演变成"以后永远不要调用这个 API"。

3. Multi-Agent：共享记忆会让并行 Agent 同质化

多个 Agent 并行探索的价值来自初始条件、策略或信息差异。如果它们都读取同一批强约束记忆，分支数量看似不变，实际行为却高度相关。

工程上可以考虑：

只向部分 Explorer 暴露历史记忆；
让不同 Agent 读取不同 Memory Sample；
保留一个不使用记忆的 Control Branch；
在汇合阶段再共享确定性错误与验证结果。

4. 自适应记忆调度

论文最直接的设计启发是分阶段使用记忆：

Early Exploration：弱记忆 → Late Debugging：强记忆 \text{Early Exploration：弱记忆}\quad\rightarrow\quad\text{Late Debugging：强记忆} Early Exploration：弱记忆→Late Debugging：强记忆

搜索早期需要路线多样性，记忆只应阻止完全确定的环境错误；进入高潜力方案后，再强化 error-fix 复用，减少局部 Debug 浪费。

十七、局限性与证据边界

1. 只验证两个 Scaffold

链式与树式是有用抽象，但 OpenHands 与 AIDE 并不能代表所有 Agent。带回溯的 Chain、分层 Planner、Population-based Search 或多 Agent Debate 可能呈现不同结果。

2. Backbone 与预算不一致

AIDE 使用 o3、30 Step、16 Seed；OpenHands 使用 GPT-4o、500 Step、3 次重复。论文考察的是各 Scaffold 内部的 Memory Effect，而不是严格控制 Backbone 后的架构因果效应。

3. MLE-Bench Lite 只有 22 个任务

模态拆分后样本更少，部分 SEM 很大。尤其 Audio 任务数量有限，不应据此形成稳定的模态结论。

4. 默认不做跨任务迁移

Task-indexed Retrieval 降低实验混杂，也限制了长期记忆最有价值的一部分：把一个任务中学到的 API 或环境经验带到另一个任务。当前系统更接近"跨 Run 记忆"，而不是完整的跨任务终身学习。

5. 记忆更新只有 ADD/NOOP

系统不能合并、降权、纠错、设置有效期，也不能把 Timeout 从 Code Bug 中分离。失败案例说明，错误分布一旦进入记忆，可能持续放大偏见。

6. 缺少成本分析

论文没有报告 Memory Retrieval、Embedding、LLM Summary 带来的 Token、时延与费用。虽然 Bug 减少可能节省执行成本，但是否抵消额外记忆调用，尚无直接证据。

7. 缺少显著性检验与更强因果控制

主表报告 Mean±SEM，但没有针对主要绩效差异给出完整显著性检验。AIDE 的 16 Seed 提供了较好稳定性，OpenHands 只有 3 次重复，结论强度较弱。

8. 持久偏见与错误传播

论文自己指出，记忆会把过去的错误推理固化为持续行为模式。对生产 Coding Agent，这不只是得分问题，还涉及供应链风险、安全建议和过时 API 的长期传播。

十八、我的理解与启发

1. Agent Memory 本质上也是 Policy Regularizer

记忆通常被描述为外部信息库，但它进入 Prompt 后会改变动作概率：

π ( a ∣ s ) ⟶ π ( a ∣ s , M ) \pi(a\mid s)\quad\longrightarrow\quad\pi(a\mid s,M) π(a∣s)⟶π(a∣s,M)

因此，记忆不只是"让模型知道更多"，还会使某些动作更常见、另一些动作更少见。在 AIDE 中，它表现为更低 Bug、更早 Valid Node，以及更低的有效类别数。

2. 记忆评价需要同时看结果、过程和分布

一个成熟的 Memory Agent Benchmark 至少要测三层：

结果层： 最终任务是否更好；
过程层： 是否减少错误、成本与无效步骤；
分布层： 是否造成策略收缩、同质化或偏见累积。

只看 Recall 会忽略行为影响；只看 Bug Rate 会误判 AIDE；只看最终平均分又无法解释为什么某些任务显著恶化。

3. "不要重复过去的错误"不是无条件正确的规则

API 调用错误应该避免，模型训练 Timeout 却未必代表算法路线错误。错误记忆必须回答：

这个失败是逻辑上不可行，还是只在特定预算、环境和实现下失败？

缺少条件的记忆会把经验压缩成过度泛化的禁令。

4. 多样性应该成为 Memory Optimization 的显式目标

未来若用 RL 训练 Coding Memory，奖励不应只有成功率或 Bug Reduction。对并行搜索 Agent，可以加入：

R = R t a s k − λ R b u g + β R d i v e r s i t y R=R_{task}-\lambda R_{bug}+\beta R_{diversity} R=Rtask−λRbug+βRdiversity

R t a s k R_{task} Rtask 衡量最终方案质量， R b u g R_{bug} Rbug 惩罚真正无效的重复错误， R d i v e r s i t y R_{diversity} Rdiversity 保护不同分支的模型、Package 或程序结构差异。

这不是论文已有公式，而是由实验证据导出的设计方向。关键是让记忆降低冗余，而不是降低所有探索。

5. 最优记忆策略可能是动态门控，而非始终开启

对 Chain Agent，记忆可以较早介入，因为它没有平行分支承担失败风险。对 Tree Agent，更合理的策略是：

Draft 阶段少用或不用经验记忆；
Debug 阶段强检索精确 error-fix；
Improve 阶段根据搜索饱和度逐步增强记忆；
若 Branch Diversity 过低，自动降低记忆权重。

这比在所有阶段统一拼接 Memory 更符合探索---利用的动态变化。

十九、总结

本文没有试图证明"有记忆的 MLE Agent 一定更强"，反而给出了更有价值的负面证据。

Dynamic Coding Memory 将历史错误组织为 Task---Package---Error---Fix 条目，并通过同任务检索和 ADD/NOOP 更新实现跨运行复用。它对链式 OpenHands 有直接帮助：Valid Submission 与 Any Medal 都得到改善。

但在树式 AIDE 中，记忆把 Bug Rate 从 46.72% 降到 24.02%，让首次有效节点更早出现，却同时使 Above Median 和 Any Medal 分别下降 10.70 与 11.45 个百分点。dog-breed 案例进一步揭示，过多 Timeout 记忆会把搜索从深度图像模型推向轻量表格模型。

因此，论文真正推进的不是一种更复杂的 Memory Structure，而是对 Agent Memory 作用机制的理解：

记忆既是经验库，也是行为先验；它能消除重复错误，也能压缩探索空间。其收益取决于 Agent 架构、任务模态、记忆质量以及介入搜索的时机。

对下一代 Coding Agent 来说，目标不应是"记住更多"，而应是：在正确阶段，以正确作用域，记住那些不会扼杀创新的经验。

参考资料

Xinyu Zhao, Junpeng Wang, Yuzhong Chen, Menghai Pan, Chin-Chia Michael Yeh, Jiarui Sun, Yan Zheng, Mahashweta Das, Tianlong Chen. Demystify the Role of Memory in Machine Learning Engineering Agents. Findings of ACL 2026, pages 10811--10826.
论文页面：https://aclanthology.org/2026.findings-acl.525/
正式 PDF：https://aclanthology.org/2026.findings-acl.525.pdf
Jun Shern Chan et al. MLE-Bench: Evaluating Machine Learning Agents on Machine Learning Engineering. ICLR 2025.
Yizhou Jiang et al. AIDE: AI-Driven Exploration in the Space of Code. 2025.