Coding Agent的记忆能跨域迁移吗？这篇论文给出了让人信服的答案

你有没有碰到过这种情况——一个在SWE-Bench上表现不错的Coding Agent，换到竞赛编程任务上就又开始从头踩坑？明明两种任务都用Python、都跑在终端里、都要写测试验证，但Agent就是没法把之前踩过的坑"记住"并用到新场景。

这不是个小问题。现有的记忆增强Agent，无论是Reflexion的反思记忆，还是ReasoningBank的推理经验库，都有一个隐含假设：记忆只在"同类任务"里管用。你在SWE-Bench上积累的经验，就只给SWE-Bench用；LiveCodeBench上的教训，就只给LiveCodeBench用。但现实中，一个部署出去的Coding Agent面对的任务五花八门——修bug、写新功能、做数据科学、跑ML实验——这些任务虽然领域不同，却共享着大量的"基础设施"：运行环境、编程语言、调试策略、验证流程。

核心摘要：KAIST和NYU的这篇论文研究了Coding Agent中记忆的跨域迁移问题。核心发现是：跨域记忆确实有用，平均提升3.7%，但关键是迁移的是"元知识"（验证例程、编辑策略、护栏约束），而不是任务特定的代码。抽象程度决定迁移效果——高层Insight泛化良好，低层Trajectory反而导致负迁移。记忆池越大、来源域越多，迁移效果越好。记忆甚至可以跨模型迁移。431条记忆就能打败5,899条记忆的AgentKB。这篇论文的价值不在于方法多花哨，而在于把"记忆迁移"这件事的机理掰得很清楚，给出了三条非常实用的设计原则。

论文信息

  • 标题：Memory Transfer Learning: How Memories are Transferred Across Domains in Coding Agents
  • 作者：Kangsan Kim, Minki Kang, Taeil Kim, Yanlai Yang, Mengye Ren, Sung Ju Hwang
  • 机构：KAIST, New York University, DeepAuto.ai
  • 日期：2026年4月15日
  • 链接：https://arxiv.org/abs/2604.14004
  • 项目主页：https://memorytransfer.github.io/

现状：记忆用在了"信息孤岛"里

先说清楚当前的问题。自我演化Agent的研究路线大概是这样的：Agent先跑一批任务，把成功和失败的轨迹存下来，提炼成某种"记忆"格式，下次遇到相似任务就检索出来参考。Reflexion用自然语言反思，ExpeL提炼经验教训，ReasoningBank做推理策略库，AgentKB建分层知识库——思路各有不同，但有个共同的隐含假设：记忆的生成和检索都限制在同一基准测试内。

你想想看，这合理吗？SWE-Bench上的修bug经验和MLGym上的调参经验，虽然任务内容完全不同，但它们共享的"元知识"其实很多：都要先理解代码结构再动手、都要写最小化测试来验证、都要避免一次性大改、都该在修改后跑一遍验证——这些不是某个领域特有的，而是"编程行为"层面的通用知识。

所以作者提了三个研究问题：

  1. 来自异构领域的记忆能不能提升Coding Agent性能？
  2. 为什么跨域迁移的记忆能产生收益？
  3. 什么因素最影响迁移效果？

三个问题层层递进，不是只看"有没有用"，而是要搞清楚"为什么有用"和"怎么才能更有用"。这个研究思路我很认同。

图1：Memory Transfer Learning概念概览

图1：MTL概念概览。对比了三种范式——(A)无记忆Agent反复失败，(B)单域自我演化Agent只能利用同域记忆，(C)MTL方法利用来自异构领域的统一记忆池

方法：四种抽象级别的记忆 + 统一记忆池

记忆的四层抽象

这篇论文没有发明新的记忆提取方法，而是把现有方案统一到一个框架下，按抽象程度从低到高分为四类：

记忆格式 表示方法 抽象级别 特点
Trajectory \(M_T=(t, [(a_1, o_1), ..., (a_n, o_n)])\) 最低 保留完整命令序列和输出，包含失败步骤
Workflow \(M_W=(g, [a_i, a_j, ..., a_k])\) 中低 提取可复用的操作序列，包含目标\(g\)和关键动作
Summary \(M_S=(s_t, s_e)\) 中高 包含任务摘要\(s_t\)和经验总结\(s_e\)，分析成败原因
Insight \(M_I=(i_t, i_d, i_c)\) 最高 任务无关的泛化洞察，包含标题、描述和内容

图2：四种记忆格式的示例

图2：从Trajectory到Insight，抽象程度逐步升高。Trajectory保留所有细节（包括失败步骤），Workflow提取关键操作，Summary总结经验，Insight提炼任务无关的通用洞察

说实话，这四种格式的划分并不新鲜——Trajectory对应原始日志，Workflow对应SOP，Summary对应经验总结，Insight对应方法论提炼。但把它们放在同一个框架下做对比，并且系统性地研究抽象程度对跨域迁移效果的影响，这个视角是有价值的。

统一记忆池

这是方法的核心设计。不同于现有方法"每个域各管各的记忆"，MTL构建了一个跨域的统一记忆池：

\[\mathcal{P}_\tau(B_i) = \{M_\tau^{(k)} \mid t^{(k)} \notin B_i\}_{k=1}^{N_i}\]

简单说就是：评估基准\(B_i\)时，记忆池里排除\(B_i\)本身的记忆，只用来自其他基准的记忆。这个设计很关键——它保证了实验测的是"跨域迁移"的效果，而不是同域记忆的简单复用。

检索方式也值得一提：Trajectory格式用任务描述的嵌入相似度来检索，其他三种格式则让模型先写一个4-5句的"编码计划"，用计划作为查询来检索。直觉上这很合理——Trajectory是任务特定的，所以用任务相似性匹配；而更高层的记忆是行为指导，用"你打算怎么做"来匹配更合适。

主实验：跨域记忆确实管用

实验覆盖了6个编码基准，横跨三个难度层级：

  • 函数级编程：LiveCodeBenchv6、Aider-Polyglot
  • 仓库级编码：SWE-Bench Verified、TerminalBench2
  • 领域特定：ReplicationBench（科学论文复现）、MLGym-Bench（ML研究）

主模型用的是GPT-5-mini，还跑了DeepSeek V3.2和Qwen3-Coder做验证。看GPT-5-mini的结果：

基准测试 Zero-shot MTL-Trajectory MTL-Workflow MTL-Summary MTL-Insight Δ提升
LiveCodeBenchv6 0.910 0.940 0.920 0.930 0.930 +2.0%
Aider-Polyglot 0.470 0.490 0.470 0.460 0.470 0.0%
SWEBench-Verified 0.730 0.770 0.770 0.760 0.770 +4.0%
TerminalBench2 0.315 0.270 0.348 0.371 0.360 +4.5%
ReplicationBench 0.111 0.122 0.111 0.133 0.189 +7.8%
MLGym-Bench 0.667 0.583 0.583 0.667 0.750 +8.3%
平均 0.523 0.534 0.538 0.546 0.560 +3.7%

几个观察：

Insight格式效果最好，平均0.560，比Zero-shot涨了3.7个点。这个数字本身不算炸裂，但考虑到这完全是"跨域迁移"——用的全是来自其他基准的记忆——我觉得还是能说明问题的。

Trajectory反而有负迁移风险。看TerminalBench2：Zero-shot是0.315，MTL-Trajectory降到了0.270。MLGym-Bench更明显：从0.667降到0.583。低层轨迹太具体了，Agent容易死板地照搬，反而被带偏。

越难的基准提升越大。ReplicationBench和MLGym-Bench涨了7.8%和8.3%，而简单的LiveCodeBench只涨2.0%。这合理——简单任务Agent自己就能搞定，记忆的价值在于帮你处理那些"不知道该怎么下手"的复杂问题。

跟自我演化方法的对比更说明问题：

方法 记忆数量 LiveCodeBenchv6 SWEBench-Verified ReplicationBench 平均
Zero-shot - 0.910 0.730 0.111 0.584
ReasoningBank 97 0.920 0.750 0.133 0.601
AgentKB 5,899 0.920 0.720 0.200 0.613
MTL (Ours) 431 0.930 0.770 0.189 0.630

431条记忆 > 5,899条记忆。数量少了一个数量级，效果反而更好。这直接说明跨域记忆的密度更高——每条记忆包含的是可迁移的元知识，不是某个特定任务的冗余细节。

为什么跨域记忆能起作用？元知识才是核心

这是论文最有意思的部分。作者不只是说"跨域记忆有用"，而是拆解了"到底迁移了什么"。

通过LLM和人工分析，迁移记忆的贡献被分成了几大类：

图3：记忆迁移贡献分解

图3：迁移记忆的贡献分解。元知识（验证例程、交互协议、编辑策略等）占主导，而算法策略转移仅占5.5%

看这个分布：

  • 测试驱动验证 14.5%——先写测试再改代码、用内联Python做快速自包含验证
  • 交互协议 14.4%——安全地与执行环境交互、预判工具链故障
  • 迭代工作流纪律 15.0%——检查→编辑→验证→提交的标准流程
  • 反模式规避 10.4%——避免大改、避免盲目覆盖、避免脆弱硬编码
  • API与接口合规 9.5%——输出格式、函数签名、API契约
  • 环境适应 8.5%——处理外部依赖、工具链差异
  • 探索策略 8.1%——搜索代码、定位文件的方法
  • 输入验证与鲁棒性 7.8%
  • 文件与语法管理 6.4%
  • 算法策略转移 5.5%

算法策略只占5.5%。这个数字太关键了。它直接回答了一个很多人可能会有的直觉——"跨域迁移是不是就是把A领域的算法技巧搬到B领域？"答案是：不是。真正迁移的是"怎么写代码"的方法论，而不是"写什么代码"的领域知识。

举个具体例子。论文里有个case study：SWE-Bench上的Django修bug任务，Zero-shot的Agent直接改代码然后跑测试，失败了；MTL的Agent检索到了一条来自LiveCodeBench的Insight——"用内联Python here-doc做快速自包含测试验证"。这条Insight跟Django毫无关系，但"先写测试验证再改代码"这个行为模式是跨域通用的，Agent照做后就成功了。

抽象程度决定迁移命运

这是论文的核心洞察，也是最有实践指导价值的发现。

高层Insight vs 低层Trajectory

论文从两个角度论证了"抽象决定迁移"：

角度1：嵌入空间分析

图4：不同记忆格式的t-SNE可视化

图4：t-SNE可视化。左侧是任务嵌入，后面依次是Workflow、Summary、Insight嵌入。每种颜色代表一个基准。任务和Workflow嵌入在各自域内明显聚类，而Insight嵌入稀疏且混合——反映了其任务无关的性质

Task嵌入和Workflow嵌入在各自基准内扎堆聚类——说明它们携带了大量域特定信息。而Insight嵌入几乎均匀散布，不同域的颜色混在一起——说明它捕获的是跨域共享的通用知识。

定量分析也支持这个结论。用DBI（Davies-Bouldin Index，越低聚类越紧）和LISI（Local Inverse Simpson Index，越高混合越好）来衡量：

图5：嵌入分布分析

图5：DBI和LISI指标随抽象级别变化。抽象程度越高，DBI越低（聚类越松散）、LISI越高（混合越充分）

Trajectory的DBI=6.50、LISI=1.70，而Insight的DBI=2.33、LISI=4.47。数字很清楚：抽象程度越高，嵌入的域间区分度越低、混合度越高。

角度2：同格式内的抽象对比

即使在同一种Insight格式内，作者还做了更细的区分——把Insight按"与当前任务的相关度"分成前30%（任务特定Insight）和后30%（任务无关Insight）：

方法 LiveCodeBenchv6 SWEBench-Verified ReplicationBench 平均
Task-specific Insights（前30%） 0.887 0.617 0.067 0.523
Task-agnostic Insights（后30%） 0.893 0.627 0.082 0.534
Δ提升 +0.6% +1.0% +1.5% +1.1%

即便在同一个格式里，任务无关的Insight也比任务特定的好。这进一步确认了：驱动迁移效果的关键因素不是"记忆跟任务有多像"，而是"记忆有多通用"。

负迁移：当记忆帮了倒忙

这篇论文没有回避负迁移问题，坦率地讨论了三种负迁移模式：

  1. 领域不匹配锚定：结构上无关但表面相似的记忆作为误导锚点。比如一个C++的记忆被错误地匹配到R任务上，Agent就开始按C++的方式写代码。
  2. 虚假验证信心：验证类的记忆造成虚假确定感。Agent觉得自己"按记忆说的验证了"，但实际上验证的是错误的东西，形成自我确认循环。
  3. 误用最佳实践转移：不加区分地套用"成功模式"。比如"合并训练和验证集"在某些ML任务里是合理策略，但在需要严格评估的场景里就是灾难。

Trajectory格式的负迁移尤其严重——论文里有个案例，Agent从MLGym-Bench迁移了一条Trajectory到别的任务，结果因为sparse参数在不同库里API不一样，直接运行报错。Agent死板地跟着低层命令走，完全不知道变通。

形式化：抽象-迁移权衡

论文附录里给了一个形式化的解释，把记忆嵌入分解为域不变分量\(z_{\text{inv}}\)（元知识）和域特定分量\(z_{\text{sp}}\)：

\[e(m) = z_{\text{inv}}(m) + z_{\text{sp}}(m)\]

迁移记忆\(m\)对目标任务\(x\)的效用：

\[U(x,m) \propto \underbrace{\langle e(x), z_{\text{inv}}(m) \rangle}_{\text{可迁移指导}} - \underbrace{\langle e(x), z_{\text{sp}}(m) \rangle}_{\text{域不匹配惩罚}}\]

抽象水平\(A\)定义为域不变分量的占比：

\[A = \frac{\|z_{\text{inv}}(m)\|^2}{\|z_{\text{inv}}(m)\|^2 + \|z_{\text{sp}}(m)\|^2}\]

命题1：期望迁移增益随抽象水平\(A\)严格递增。换句话说，Insight中\(z_{\text{inv}}\)占比高、\(z_{\text{sp}}\)占比低，所以迁移效果好；Trajectory正好反过来。

这个形式化虽然模型比较理想化，但直觉是对的——迁移的收益来自元知识的指导，代价来自域特定信息的干扰。抽象程度越高，收益越大、代价越小。

记忆池规模和跨模型迁移

越多越好

论文还研究了记忆池规模对迁移效果的影响。从1/4池到全部池，平均性能持续提升。使用9个领域的记忆比6个领域更好。

这个结果不难理解——更大的记忆池意味着更多样的元知识，检索到"正好管用"的那条记忆的概率更高。跟RAG的scaling law一个道理：知识库越大，覆盖面越广，召回质量越高。

记忆可以跨模型迁移

这是一个实用的发现。用GPT-5-mini生成的Insight，给DeepSeek V3.2和Qwen3-Coder用，照样有提升：

源模型 → 目标模型 LiveCodeBench SWEBench ReplicationBench 平均
Zero-shot → GPT-5-mini 0.863 0.623 0.059 0.515
DeepSeek V3.2 → GPT-5-mini 0.890 0.617 0.048 0.518
GPT-5-mini → GPT-5-mini 0.877 0.633 0.119 0.543
Zero-shot → DeepSeek V3.2 0.890 0.423 0.144 0.486
GPT-5-mini → DeepSeek V3.2 0.890 0.450 0.163 0.501
DeepSeek V3.2 → DeepSeek V3.2 0.893 0.463 0.178 0.511

两个方向都有效——强模型→弱模型、弱模型→强模型都有提升。但自生成记忆效果始终最好（同模型行列）。这说明元知识确实有模型无关性，但"自己总结的心得"总比"别人总结的"更好理解，这也很合理。

检索方法的反直觉发现

还有一个有意思的发现——简单的嵌入相似度检索，居然比LLM重排序和自适应重写都好：

检索方法 LiveCodeBench SWEBench ReplicationBench 平均
No Memory 0.910 0.730 0.111 0.584
LLM Reranking 0.920 0.730 0.144 0.598
Adaptive Rewriting 0.920 0.760 0.144 0.608
Embedding Similarity 0.930 0.770 0.189 0.630

我的第一反应是有点意外——通常LLM重排序在RAG系统里效果更好啊？但仔细想想，这个结果其实说得通。跨域检索的核心挑战是语义鸿沟——不同领域的任务描述差异很大，LLM重排序可能反而过度匹配了表面相似性，把那些"看起来像但实际不通用"的记忆排到前面。而嵌入相似度虽然粗糙，但在高维空间里更容易捕获到元知识层面的相似性。

不过说实话，这块我觉得还有优化空间。当前的检索是静态的——不管任务是什么，都用同样的策略。如果能根据任务特征动态选择检索策略（比如简单任务用嵌入、复杂任务用LLM重排序），可能会有更好的效果。论文自己也承认"跨域记忆检索本身就是个难题"。

我的判断

这篇论文的定位很清楚——不是要提出一个新的SOTA方法，而是做一个系统性的实证研究，搞清楚"记忆迁移到底怎么work"。从这个角度看，它做得很扎实。

三个亮点：

  1. 问题定义清晰。把"记忆迁移"从自我演化的框架里单独拎出来，设计了严格的跨域评估协议（排除同域记忆），让结果可信。
  2. 机理分析深入。不只是说"有用"，而是拆解了迁移的是什么（元知识vs领域知识）、为什么抽象程度决定迁移效果、负迁移的三大模式。形式化的抽象-迁移权衡给了一个理论锚点。
  3. 实验覆盖全面。6个基准、3个模型、4种记忆格式、多种消融维度。431条记忆打败5899条的对比特别有说服力。

也有让我皱眉的地方：

  1. 3.7%的平均提升不算大。在Aider-Polyglot上甚至完全没提升。如果记忆迁移的上限就是这么个量级，那在工程落地上可能不够"痛"——部署跨域记忆池的成本（离线推理、存储、检索延迟）和收益之间的ROI需要仔细算。
  2. 记忆生成成本不低。要在6个基准上各跑一遍推理来生成记忆，这本身就需要不少API调用。论文没有讨论记忆生成的成本效率比。
  3. 检索方法的探索不够充分。简单嵌入>LLM重排序的结果很有意思，但只试了三种方法。如果用更精细的检索策略（比如按元知识类别分桶检索），效果可能更好。

对工程的启发：

如果你在做Coding Agent，而且已经在用某种记忆机制，这篇论文给你的直接建议是：

  • 记忆格式选高层抽象的Insight，别用原始Trajectory
  • 记忆池跨域共享，不要每个任务类型各管各的
  • 元知识的提炼要任务无关化——"怎么验证"比"验证了什么"有价值得多
  • 更大的记忆池更好，但质量比数量重要——431条好的记忆>5899条杂的记忆

如果你还没用记忆机制，MTL提供了一个低成本的起步方案——不需要训练、不需要改模型架构，只需要在推理时加一个检索+注入的步骤。

说到底，这篇论文的核心洞察其实可以用一句话概括：编程行为的元知识比编程内容的知识更有迁移价值。这跟人类工程师的经验完全一致——一个资深工程师换到新领域，带过去的不是具体的代码，而是"先理解再改、小步验证、避免大改"这些行为习惯。Agent也一样。

觉得有启发的话，欢迎点赞、在看、转发。跟进最新AI前沿，关注我