# Memory Transfer Learning (MTL) for Coding Agents, explained
**作者**: AVB
**日期**: 2026-04-20T16:44:24.000Z
**来源**: [https://x.com/neural_avb/status/2046268757774041168](https://x.com/neural_avb/status/2046268757774041168)
---
There is a new paper on How to reuse “memories” from past coding tasks to help an AI coding agent solve new coding tasks. Let's see all the things we can learn about memory systems from this one!
## What is this paper trying to do
This paper shows that coding-agent “memories” can transfer across very different benchmarks/tasks.
It explores multiple different types of commonly used memory implementations like:
- trajectory memories
- workflow memories
- summarization memories
- insights as memories
... and then compare results to figure out which memory format work the best!
## But first, what does this paper mean by "memory"
Honestly the research community needs to settle on a good definition of memory. In this paper, memory is:
Memory IS (in this paper)
- An external store of past agent experience gathered from prior runs on coding tasks
- Built from full agent interaction histories where each step includes reasoning, actions, and observations.
- A representation of experience - not direct raw logs. They construct four explicit memory formats with different abstraction: Trajectory, Workflow, Summary, Insight. We will talk about this a bit later.
- These experiences can be transferred across other tasks via a shared memory pool. This is the main idea of Memory Transfer Learning!
- Primarily valuable because it carries meta-knowledge (operational know-how, task-solving routines, validation practices) more than task-specific code. 4
Memory IS NOT (in this paper)
- Not weight updates / training / internalized skills: the “learning” is largely from retrieving text memories into context, not from updating network weights.
- Not inherently self-evolving online: their default setup generates memories offline and then uses them during inference. This is not an always-on loop "continual learning loop"
- Not guaranteed helpful: memory can cause negative transfer when retrieval is wrong or adaptation fails.
- Not a sophisticated lifelong memory maintenance system: the paper does not try to solve common problems with long-term memory system, like staleness detection, pruning, consolidation, etc!
> In this paper, “memory” is best thought of as a retrieved library of experiences or skills that can be applied to more tasks!
I like standalone papers like these because it helps us isolate different related solutions and focus on one thing at a time.
They actually have a very clear hypothesis.
Let's see what their experiments are.
## Step 1: Choose heterogeneous coding domains (benchmarks)
They evaluate on 6 benchmarks spanning function-level competitive coding, repository-level software engineering, and domain-specific code generation (science grounding, ML research).
These benchmarks include:
- Aider Polyglot, LiveCodeBench v6 (programming)
- SWE-Bench Verified, Terminal Bench (multi-file edits, tooling, SWE)
- ReplicationBench (scientific knowledge-grounded code)
- MLGym-Bench (machine learning research tasks)
## Step 2: Run a baseline coding agent to collect raw interaction traces
They first run inference and collect full trajectories consisting of task forming the full history. Each step contains: the observation, the reasoning, and the action.
They use gpt-5-mini to do these traces. It's a sufficiently good model to do in-context reasoning, but not an overpowered model that will solve these benchmarks as-is.
We will see what the performance delta of the MTL algorithm is on gpt-5-mini!
## Step 3: Label each attempt as success/failure
They use an LLM judge (also gpt-5-mini) to determine whether each attempt succeeded or failed, and this conditions how memories are generated.
> This labelling is kinda important as well because it makes a standard universal contract for ALL those benchmarks that they ran traces on (which all have their own peculiar output formats and eval scoring)
## Step 4: Generate “memories” offline from the traces (four representations)
From the same underlying history, they construct four memory formats: Trajectory, Workflow, Summary, Insight.
Basically, after they run the agent and log a full trajectory for a task, they convert that trajectory into one of four “memory” formats. This is done offline (precomputed) and then stored in a memory pool for later retrieval.
> The goal is NOT to use all of these memory types during inference.
> The goal is to figure out WHICH of these 4 memory types are the best to use for coding tasks.
> This is basically one of the MAIN takeaways from the paper - which of these 4 memory types lead to best results
4.1 Trajectory memory (most concrete)
- Goal: store the raw “what happened” interaction trace.
- Construction: concatenate actions and code plus their execution results/observations, and omit reasoning text
- They also store it with the source task (so the memory explicitly contains the task context).
These memories preserve detailed operational information (including failed steps), so a future agent can pattern-match commands and expected outputs.
For this trajectory memory specifically, they note it contains detailed history “even with failed steps"!
4.2 Workflow memory (filtered action subset)
- Goal: keep only “meaningful” reusable actions, reduce irrelevant noise from long trajectories.
- Construction: give the whole trajectory H to an LLM and ask it to: generate a workflow goal and extract a subset of meaningful actions that achieve that goal
These are much shorter than a full trajectory → less distraction from unrelated details.
4.3 Summary memory (explicit reflection)
- Goal: go beyond actions/logs and capture why it worked or failed.
- Construction: prompt the LLM to summarize:the task, environment, actions taken, results, and an analysis of why the attempt succeeded/failed
4.4 Insight memory (most abstract / intended to transfer)
- Goal: distill generalizable principles that can transfer across tasks/domains.
- Construction: following their cited design, an Insight has:
title,
description,
and content.
> The appendix section of the paper contains raw prompts for each memory type (also different prompts based on success/failure cases.
> Here is an example of the Insight task for example:
Each memory item is then indexed by a vector:
- they compute an embedding using a text embedding model,
- store that embedding alongside the memory content.
## Step 5: Define the evaluation comparison: Zero-shot vs Memory Transfer Learning (MTL)
Now we are getting into the actual online parts of the paper. They take tasks from any one of the benchmarks (aka the "target task") and use the experiences from all the other other tasks to complete it.
In other words, it is the classic "hold-one-out" pattern, where every task gets to reuse memories from every other tasks generated in the offline phase.
For each target task, they are going to compare agent performance:
- Zero-shot: solve without retrieved memories
- MTL: solve with retrieved memories from a shared pool (including cross-domain).
(The hypothesis of the MTL paper is MTL is gonna win)
At inference time for a task:
compute an embedding for the “query” (more on what the query text is below)
compute cosine similarity between the query embedding and each memory embedding
select top-N most similar memories and pass them into the agent prompt at the beginning of solving.
They mention they select three memories per query. Instead of picking memories from ALL different types of memory types (trajectory, workflow, summary, insights), they run separate tests that individually cover any ONE memory type at once.
This allows them to run ablation studies about which types of memories work best for coding tasks!
> What text do they embed as the “query” depends on the memory type.
This matters a lot for the online part:
- Trajectory memory has the original Task info stored with it, so they can retrieve by directly embedding the target task and matching against stored task text.
- Workflow/Summary/Insight do not have Task info, so they can’t just “task-to-task” match. Instead, they ask the model to write a short coding plan (4–5 sentences) for the current task, and use that plan as the retrieval query text. This is similar to HyDE (hypothetical document embedding) search.
These memories are passed into the agent's prompt to complete tasks!
> My note:
> I am not a big fan of vector embeddings anymore coz it just requires new databases and indexing. But for this specific use case it makes a ton of sense.
> It would be lovely to benchmark more retrieval methods like agentic searches, BM-25 level querying in a multi-hop loop, or even RLM (recursive language models) to do this.
> In my opinion, how the "retrieval" is done is a design choice in most applications.
## Step 7: Evaluate success using each benchmark’s protocol
They sample up to 100 tasks per benchmark (if more exist) and report performance using the benchmark’s evaluation protocol, reported as Pass@3 (Passed with 3 retrieved memories)
Findings
1) MTL > zero-shot (duh but by how much?)
Across six coding benchmarks, MTL improves over zero-shot, with the largest improvements when transferring Insight memories. In their main results, Insight transfer yields more than 4.0% and up to 8.3% gains on four benchmarks.
> 8% is a significant bump in 2026 economy
2) The “best” memory type: Insight (most abstract) is strongest
Although all memory variants outperform zero-shot, some memory options perform better than other.
> Their ranking (from best to worst) is:
> Insight > Summary > Workflow > Trajectory,
> Interpretation: abstract memories generalize; concrete traces contain too much task-specific detail and can distract.
Check this image below:
3) What actually transfers: meta-knowledge (procedures + guardrails)
From their case analysis of instances that fail zero-shot but succeed with Insight-MTL, they find the transferred memory mainly provides:
- Structured action workflows (inspect → edit → verify → submit)
- Guardrails for external constraints (output formats, function signatures, API contracts)
- Disciplined programming practices (avoid blind overwrites, huge refactors, brittle hardcoding)
- Risk-controlled editing (minimal patches)
- Self-generated verification when official tests aren’t available
- Safer tool/runtime interaction (anticipate toolchain / infra failures)
And notably, algorithmic strategy transfer is small: they report it accounts for only 5.5% of the gains in their breakdown.
4) Efficient vs “self-evolving” baselines
When compared to self-evolving memory systems (Reasoning-Bank, AgentKB), MTL performs better on the reported benchmarks and does so with a much smaller memory pool (e.g., 431 memories vs AgentKB’s ~5.8k). 26 They summarize this as a core finding.
5) Scaling: bigger memory pools and more domains help
They find performance improves as:
- the memory pool size increases, and
- the number of source domains increases (they mention best overall at 9 domains in that experiment
Read the original paper on Arxiv to check for more experiment results, prompts, and analysis of when MTL fails:
https://arxiv.org/abs/2604.14004
Or read the paper for free with an AI here (requires desktop):
https://paperbreakdown.com/abs/2604.14004
I am building Paper Breakdown to help me understand technical papers like these. Check our landing page here:
paperbreakdown.com/landing-page
It helped me immensely write this article!
Like and RT to share with others!
## 相关链接
- [AVB](https://x.com/neural_avb)
- [@neural_avb](https://x.com/neural_avb)
- [4.5K](https://x.com/neural_avb/status/2046268757774041168/analytics)
- [https://arxiv.org/abs/2604.14004](https://arxiv.org/abs/2604.14004)
- [https://paperbreakdown.com/abs/2604.14004](https://paperbreakdown.com/abs/2604.14004)
- [paperbreakdown.com/landing-page](https://paperbreakdown.com/landing-page)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [12:44 AM · Apr 21, 2026](https://x.com/neural_avb/status/2046268757774041168)
- [4,578 Views](https://x.com/neural_avb/status/2046268757774041168/analytics)
- [View quotes](https://x.com/neural_avb/status/2046268757774041168/quotes)
---
*导出时间: 2026/4/21 10:21:27*
---
## 中文翻译
# 编程智能体的记忆迁移学习（MTL），详解
**作者**: AVB
**日期**: 2026-04-20T16:44:24.000Z
**来源**: [https://x.com/neural_avb/status/2046268757774041168](https://x.com/neural_avb/status/2046268757774041168)
---
有一篇新论文探讨了如何复用过去编程任务中的“记忆”，以帮助 AI 编程智能体解决新的编程任务。让我们看看从这一篇论文中我们能学到多少关于记忆系统的东西！
## 这篇论文想做什么
这篇论文表明，编程智能体的“记忆”可以在截然不同的基准测试/任务之间进行迁移。
它探索了多种常用的记忆实现类型，例如：
- 轨迹记忆
- 工作流记忆
- 摘要记忆
- 洞察记忆
……然后对比结果，找出哪种记忆格式效果最好！
## 但首先，这篇论文所说的“记忆”是什么意思
说实话，研究界需要就记忆的准确定义达成共识。在这篇论文中，记忆是：
记忆是（在这篇论文中）
- 一个外部存储库，保存来自先前编程任务运行中收集的智能体经验
- 由完整的智能体交互历史构建而成，其中每一步都包含推理、动作和观察。
- 一种经验的表示——而非直接的原始日志。他们构建了四种不同抽象层次的显式记忆格式：轨迹、工作流、摘要、洞察。我们稍后会讨论这一点。
- 这些经验可以通过共享记忆池迁移到其他任务。这就是记忆迁移学习的核心思想！
- 其主要价值在于承载元知识（操作诀窍、任务解决流程、验证实践），而非特定任务的代码。4
记忆不是（在这篇论文中）
- 不是权重更新/训练/内化技能：这里的“学习”主要是将文本记忆检索到上下文中，而不是更新网络权重。
- 不是本质上在线自进化的：其默认设置是离线生成记忆，然后在推理时使用。这不是一个始终运行的“持续学习循环”
- 不保证有帮助：当检索错误或适配失败时，记忆可能导致负迁移。
- 不是一个复杂的终身记忆维护系统：这篇论文并不试图解决长期记忆系统的常见问题，比如过期检测、剪枝、整合等！
> 在这篇论文中，“记忆”最好被理解为一种可检索的经验或技能库，可以应用于更多任务！
我喜欢这类独立的论文，因为它帮助我们隔离各种相关解决方案，一次只专注于一件事。
他们实际上有一个非常清晰的假设。
让我们看看他们的实验。
## 第一步：选择异构的编程领域（基准测试）
他们在 6 个基准测试上进行评估，涵盖函数级竞赛编程、仓库级软件工程和特定领域的代码生成（科学知识、机器学习研究）。
这些基准测试包括：
- Aider Polyglot、LiveCodeBench v6（编程）
- SWE-Bench Verified、Terminal Bench（多文件编辑、工具使用、软件工程）
- ReplicationBench（基于科学知识的代码）
- MLGym-Bench（机器学习研究任务）
## 第二步：运行基线编程智能体以收集原始交互轨迹
他们首先运行推理并收集完整的轨迹，由构成完整历史的任务组成。每一步包含：观察、推理和动作。
他们使用 gpt-5-mini 来生成这些轨迹。这是一个足够好的模型，可以进行上下文推理，但又不是一个强大到能直接解决这些基准测试的模型。
我们将看到 MTL 算法在 gpt-5-mini 上的性能提升！
## 第三步：将每次尝试标记为成功/失败
他们使用一个 LLM 评判器（同样是 gpt-5-mini）来判断每次尝试是成功还是失败，这决定了记忆的生成方式。
> 这种标记也相当重要，因为它为所有这些基准测试建立了一个标准的统一契约（这些基准测试各自都有独特的输出格式和评估评分方式）
## 第四步：从轨迹离线生成“记忆”（四种表示）
基于相同的底层历史，他们构建了四种记忆格式：轨迹、工作流、摘要、洞察。
基本上，在他们运行智能体并记录某个任务的完整轨迹后，他们会将该轨迹转换为四种“记忆”格式之一。这是离线完成的（预先计算），然后存储在记忆池中以供后续检索。
> 目标不是在推理时使用所有这些记忆类型。
> 目标是弄清楚这 4 种记忆类型中哪一种最适合编程任务。
> 这基本上是这篇论文的主要结论之一——这 4 种记忆类型中哪一种能带来最佳结果
4.1 轨迹记忆（最具体）
- 目标：存储原始的“发生了什么”交互轨迹。
- 构建方式：将动作和代码及其执行结果/观察串联起来，并省略推理文本
- 他们还会将其与源任务一起存储（因此记忆中显式包含任务上下文）。
这些记忆保留了详细的操作信息（包括失败的步骤），因此未来的智能体可以进行命令和预期输出的模式匹配。
对于这种轨迹记忆，他们特别指出它包含详细的历史，“即使包含失败的步骤”！
4.2 工作流记忆（过滤后的动作子集）
- 目标：只保留“有意义的”可复用动作，减少长轨迹中不相关的噪音。
- 构建方式：将整个轨迹 H 交给 LLM，要求它：生成一个工作流目标，并提取实现该目标的有意义动作的子集
这些比完整轨迹短得多 → 减少了不相关细节的干扰。
4.3 摘要记忆（显式反思）
- 目标：超越动作/日志层面，捕捉任务成功或失败的原因。
- 构建：提示 LLM 总结：任务内容、环境、采取的行动、结果，以及对该次尝试成功/失败原因的分析。
4.4 洞察记忆（最抽象 / 旨在迁移）
- 目标：提炼出可跨任务/领域迁移的通用原则。
- 构建：按照他们引用的设计，一条洞察（Insight）包含：
标题，
描述，
和内容。
> 论文的附录部分包含每种记忆类型的原始提示词（并根据成功/失败案例使用不同的提示词）。
> 以下是洞察任务的一个示例：
然后，每条记忆项都通过一个向量进行索引：
- 他们使用文本嵌入模型计算嵌入（embedding），
- 并将该嵌入与记忆内容一起存储。
## 步骤 5：定义评估对比：零样本 vs 记忆迁移学习（MTL）
现在我们进入论文中真正在线的部分。他们从任一基准中选取任务（即“目标任务”），并利用来自所有其他任务的经验来完成它。
换句话说，这是经典的“留一法”（hold-one-out）模式，即每个任务都可以复用离线阶段生成的所有其他任务的记忆。
对于每个目标任务，他们将比较智能体的表现：
- 零样本：在不检索记忆的情况下解决任务
- MTL：在共享记忆池（包括跨领域记忆）检索记忆的帮助下解决任务
（MTL 论文的假设是 MTL 会获胜）
在任务推理时：
为“查询”（query）计算一个嵌入（关于查询文本是什么，详见下文）
计算查询嵌入与每条记忆嵌入之间的余弦相似度
选出最相似的前 N 条记忆，并在开始解决任务时将它们传入智能体的提示词中。
他们提到每个查询会选择三条记忆。他们不是从所有不同的记忆类型（轨迹、工作流、摘要、洞察）中挑选记忆，而是分别运行测试，每次仅覆盖一种记忆类型。
这使他们能够进行消融实验，研究哪种类型的记忆对编程任务最有效！
> 他们将什么文本作为“查询”进行嵌入，取决于记忆类型。
这一点对在线部分影响很大：
- 轨迹记忆中存储了原始任务信息，因此他们可以直接嵌入目标任务并与存储的任务文本进行匹配检索。
- 工作流/摘要/洞察不包含任务信息，因此无法进行“任务对任务”的匹配。于是，他们让模型为当前任务编写一个简短的编程计划（4-5 句话），并将该计划作为检索查询文本。这类似于 HyDE（假设性文档嵌入）搜索。
这些记忆会被传入智能体的提示词中以完成任务！
> 我的笔记：
> 我已经不太喜欢向量嵌入了，因为它需要新的数据库和索引。但在这个具体的使用场景中，它非常合理。
> 如果能对更多检索方法进行基准测试就更好了，例如智能体搜索（agentic search）、多跳循环中的 BM-25 级查询，甚至 RLM（递归语言模型）。
> 在我看来，“检索”如何实现，在大多数应用中都是一个设计选择。
## 步骤 7：按照每个基准的评估协议评估成功率
他们在每个基准中最多采样 100 个任务（如果存在更多任务），并使用该基准的评估协议报告性能，报告为 Pass@3（在检索到 3 条记忆的情况下通过）
发现
1) MTL > 零样本（这显而易见，但提升多少呢？）
在六个编程基准上，MTL 都优于零样本，其中迁移洞察记忆时提升最大。在他们的主要结果中，洞察迁移在四个基准上带来了超过 4.0%、最高达 8.3% 的提升。
> 在 2026 年的经济环境下，8% 的提升相当可观
2) “最佳”记忆类型：洞察（最抽象）表现最强
虽然所有记忆变体都优于零样本，但某些记忆选项比其他的表现更好。
> 他们的排名（从最好到最差）是：
> 洞察 > 摘要 > 工作流 > 轨迹，
> 解读：抽象记忆具有泛化能力；具体的轨迹包含太多任务特定的细节，可能会造成干扰。
请看下图：
3) 真正迁移的是什么：元知识（流程 + 护栏）
 高效 vs “自我进化”基线
与自我进化的记忆系统（Reasoning-Bank、AgentKB）相比，MTL 在所报告的基准上表现更好，且使用的记忆池要小得多（例如，431 条记忆 vs AgentKB 的约 5.8k 条）。他们将此总结为一项核心发现。
5) 规模化：更大的记忆池和更多的领域有帮助
他们发现性能随着以下因素提升：
- 记忆池规模的增大，以及
- 源领域数量的增加（他们提到在该实验中 9 个领域时整体表现最佳）
阅读 Arxiv 上的原始论文，查看更多实验结果、提示词，以及 MTL 何时会失败的分析：
https://arxiv.org/abs/2604.14004
或者在这里使用 AI 免费阅读论文（需要桌面端）：
https://paperbreakdown.com/abs/2604.14004
我正在开发 Paper Breakdown 来帮助我理解这类技术论文。欢迎访问我们的落地页：
paperbreakdown.com/landing-page
它对我撰写这篇文章帮助巨大！
点赞并转发，分享给更多人！
## 相关链接
- [AVB](https://x.com/neural_avb)
- [@neural_avb](https://x.com/neural_avb)
- [4.5K](https://x.com/neural_avb/status/2046268757774041168/analytics)
- [https://arxiv.org/abs/2604.14004](https://arxiv.org/abs/2604.14004)
- [https://paperbreakdown.com/abs/2604.14004](https://paperbreakdown.com/abs/2604.14004)
- [paperbreakdown.com/landing-page](https://paperbreakdown.com/landing-page)
- [升级到 Premium](https://x.com/i/premium_sign_up)
- [2026年4月21日 12:44 AM](https://x.com/neural_avb/status/2046268757774041168)
- [4,578 次浏览](https://x.com/neural_avb/status/2046268757774041168/analytics)
- [查看引用](https://x.com/neural_avb/status/2046268757774041168/quotes)
---
*导出时间: 2026/4/21 10:21:27*
