Memory Transfer Learning for Coding Agents 技术解析 ✍ AVB🕐 2026-04-21📦 12.9 KB 🟢 已读 𝕏 文章列表 本文深入探讨了一篇关于编码智能体的 Memory Transfer Learning (MTL) 论文。文章解释了如何将过往编码任务的“记忆”复用到新任务中，比较了 Trajectory、Workflow、Summary 和 Insight 四种记忆格式的效果。研究通过在多个基准测试中复用异构记忆池，证明了提取的元知识能有效提升智能体解决新问题的能力。 AgentLLMMemoryTransfer LearningCoding AgentRAGReinforcement Learning论文解读 # 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*
A Agents Are Stuck in a Loop: Memory Growth and Propagation 文章深入探讨了 AI Agent 面临的记忆系统瓶颈：无限记忆增长（UMG）导致检索效率低下和噪声干扰，以及虚假记忆传播（FMP）利用思维链错误放大幻觉。作者指出现有的 RAG 系统因读写混合而加剧了该问题，并提出可以借鉴强化学习（RL）机制，根据任务验证结果对记忆进行奖惩打分，从而过滤无效记忆。 技术 › Agent ✍ Siddharth🕐 2026-04-20 AgentLLMMemoryRAGReinforcement LearningHallucinationMemGPTCoT
A Agent 的数据面概念扫盲-建立技术侧认知体系 本文深入解析了 Agent 数据面的核心概念，将其比作操作系统的内存管理单元。文章详细阐述了 Context Engineering 的演变、Session/Thread/Profile 的架构差异，以及 Session Memory 与 Long-term Memory 的区别。作者还重点介绍了 Hermes 中的 Memory 设计方案、SQLite FTS5 与 BM25 算法原理，以及向量检索与关键词检索在 RAG 中的混合应用，旨在为开发者建立一套完整的 Agent 数据面技术认知体系。 技术 › Agent ✍ MateMatt🕐 2026-07-12 AgentContext EngineeringRAGMemoryBM25SQLite FTS5向量检索HermesLong-term MemoryLLM
A Agent Memory Framework: Remember, Cite, Forget 本文提出了一个智能体记忆系统的可靠框架，该框架需同时完成三个核心任务：记住该记的、引用可信的、遗忘过期的。文章详细介绍了记忆的六个层级（如会话状态、项目记忆、索引检索等），阐述了如何通过权威排序解决冲突，并强调了通过硬过期、双时序或软衰减等机制让旧记忆失效的重要性。 技术 › Agent ✍ Vox🕐 2026-05-23 AgentMemoryRAGLangGraphMem0ZepGBrainLLM系统架构工程实践
A Agentic Memory: 详解 Agent 记忆系统的架构与实现 文章通过生动的类比，指出缺乏记忆是当前 LLM Agent 的主要短板。作者详细拆解了 Agent 记忆系统的三个核心功能：连续性、上下文和学习。文章重点介绍了四种记忆类型：上下文记忆、外部记忆、情景记忆和参数记忆，并深入探讨了如何通过检索增强（RAG）和反思循环来构建持久的智能。 技术 › Agent ✍ Ramakrishna (techwith_ram)🕐 2026-05-17 AgentLLMMemoryArchitectureRAGVectorStoreContextEpisodic向量数据库系统设计
A Agent Memory Engineering 文章探讨了 AI Agent 的记忆机制，解释了为何不同 Agent（如 Claude Code 和 Codex）之间无法直接通过复制文件来迁移记忆。作者指出，这是因为模型在后期训练时与特定的记忆层“融合”了。文章对比了 Hermes、Codex CLI 和 Claude Code 三种实现，并得出结论：最聪明的架构（如向量数据库、知识图谱）输给了最简单的方案（LLM + Markdown + Bash 工具）。核心在于 Agent 遵循的读写规范，而非数据结构本身。 技术 › Agent ✍ Nicolas Bustamante🕐 2026-05-02 AgentMemoryLLMEngineeringClaude CodeCodexRAGPost TrainingMarkdownHermes
W Why Karpathy’s Second Brain Breaks at Agent Scale. How Mercury Solves It. 本文探讨了 Andrej Karpathy 的 LLM Wiki 工作流在人类“第二大脑”场景下的优势，指出其在处理 AI Agent 时的局限性。文章强调，人类记忆优先考虑可读性和反思，而 Agent 记忆系统则需要快速检索、低 Token 成本和冲突解决。Mercury 提出的混合架构方案，主张使用 Markdown 作为人类界面，同时采用结构化内存作为 Agent 的底层设施，以实现上下文的持续累积和可靠运行。 技术 › Agent ✍ Zaid🕐 2026-04-29 AgentMemoryLLMKarpathyRAGMercuryArchitectureSecond BrainDesign
A AI 记忆工具两大阵营：Memory Backends 与 Context Substrates 文章深入分析了 GitHub 上的 AI Agent 记忆工具，将其分为两大阵营：一是“记忆后端”，如 Mem0 和 Supermemory，主要提取事实并存储于向量数据库；二是“上下文基底”，如 OpenClaw，通过人类可读的结构化文件让会话在上下文中累积。作者指出，虽然 Camp 1 主导了市场，但 Camp 2 的架构才是支持连续、多会话工作的未来方向，例如 Zep 已开始从“记忆”转型为“上下文工程”。 技术 › Agent ✍ witcheer🕐 2026-04-17 AgentOpenClawMem0ContextMemoryRAGLLM向量数据库知识图谱
本 本周顶级 AI 论文精选 文章精选了本周 6 篇顶级 AI 论文，涵盖 Harness Handbook、MSCE 记忆技能框架、PRO-LONG 长程记忆机制、Anthropic 全局工作空间解释性研究、Meta 的 GAMUT 完整性基准测试以及渐进式披露模式。 技术 › LLM ✍ DAIR.AI🕐 2026-07-27 AI论文AgentMemoryInterpretabilityAnthropicMetaLLMResearch
2 2026年如何成为AI工程师（无需CS学位） 文章指出2026年AI工程师角色已分化为机器学习工程师和应用AI工程师。对于非CS学位求职者，后者是主要机会。文章详细列出了必备技能（Python、LLM行为、RAG系统、评估观测），并提出了三个能替代学历证明的实战项目建议。 技术 › LLM ✍ Harman🕐 2026-07-24 AI工程师职业发展RAGLLMAgentPrompt无学位
A Agent Wikis 的现状与发展 文章探讨了 LLM Wiki 模式的兴起，即通过在摄取时编译知识而非查询时检索，解决传统 RAG 无法积累知识的问题。介绍了 Cognition、FactoryAI、LangChain 等团队构建的 Agent Wiki 系统，分析了其架构原理及在维护成本上的优势。 技术 › Agent ✍ mem0🕐 2026-07-22 LLMAgentWikiRAGCognitionLangChainDeepWikiAutoWiki
写 写作即编排——当方法论指向自己 本文是“AI时代的知识编排”系列收官之作。作者回顾了利用AI与结构化知识库高效产出技术博客的实践，发现写作过程本身遵循着“文档驱动”（SDD）的逻辑。文章通过信息论、认知科学及实证数据论证了结构化输入的重要性，并指出知识编排已成为AI时代内容生产的生存必需，强调了核查与人工判断不可替代。 技术 › AI ✍ SagaSu🕐 2026-07-16 AI知识编排写作方法论SDDRAG结构化输入信息核查AgentLLM
如 如何在 2026 年成为AI工程师 文章指出 2026 年 AI 工程师的门槛已变，不再看重学历，而是看重作品集与交付能力。作者拆解了 AI 工程师的三个核心能力：软件工程、LLM 使用及产品思维，并规划了一份为期 12 个月的六阶段实战路线图，涵盖 Python 基础、LLM API、RAG、Agent 系统开发、评估部署及求职准备。 技术 › LLM ✍ 路飞 AI 研究员🕐 2026-07-08 AI工程师职业发展学习路线RAGAgentLLMPythonPrompt实战指南求职