因果情景记忆：给 Agent 的错误装一个经验硬盘
因果情景记忆：给 Agent 的错误装一个"经验硬盘"
你有没有这种体验：写代码遇到一个 bug，花了两小时修好了，下次遇到类似的 bug 又花了两个小时？不是你不记得上次怎么修的，而是你没想到"这次"和"上次"是同一类问题。人类的记忆不是按时间线检索的，是按因果结构检索的——"上次那个 bug 是因为线程安全问题，这次好像也是"。
AI Agent 也有这个毛病。现在的 Agent 修复系统大多是"无状态"的：遇到错误就从头开始试，不记得之前遇到过什么类似的错误、走过什么死胡同。给它加个记忆系统？之前的做法要么是简单存最近 N 次对话（太粗糙），要么是语义检索（丢了因果结构）。
2026 年 8 月发表的论文《Causal Episodic Memory for Feedback-Driven Agent Repair》提出了 MERIT（Memory-Augmented Error-Typed Retrieval），给 Agent 装了一个"经验硬盘"：按错误类型存、按因果结构取。
论文链接：https://arxiv.org/abs/2608.05906
一、问题：无状态修复 vs 有记忆修复
Text-to-SQL：一个理想的测试场景
论文选的场景是 Text-to-SQL：用户说自然语言（"查一下上个月销售额超过 10 万的门店"），Agent 翻译成 SQL 查询数据库。这个场景好在：
1. 错误可分类：SQL 错误有明确的类型——语法错误、表名错误、列名错误、JOIN 错误、聚合错误等 2. 修复可验证：跑一下 SQL 就知道对不对，有客观标准 3. 错误会重复：同一类错误会在不同查询中反复出现
这让它成为测试"记忆辅助修复"的理想场景。
无状态修复的局限
现有的 Text-to-SQL 修复方法大多是无状态的：遇到错误就重新生成，或者用动态 RAG 从文档里检索相关信息。问题是：
- 不记得之前修过什么：每次遇到"GROUP BY 缺少聚合列"的错误，都从头开始推理
- 不记得走过什么死胡同：可能反复尝试同一个看起来合理但实际不行的修复方向
- 不区分错误类型：用同一套策略应对所有错误，没有针对性
有记忆但不够好
之前也有有记忆的方法，比如 Dynamic RAG：把之前的修复经验存起来，遇到新错误时语义检索相似的案例。但 Dynamic RAG 有两个问题：
1. 检索粒度太粗：按语义相似度检索，可能检索到"看起来像但其实不是同一类错误"的案例 2. 不区分正负经验：只存成功案例，不存失败方向。但"这条路走不通"也是宝贵经验
MERIT 的切入点正是这两点：按错误类型存 + 正负经验都存。
二、MERIT 的核心设计
记忆结构：类型化的正负经验
MERIT 的记忆库不是一坨扁平的案例列表，而是结构化的：
正经验（Positive Memory）：Oracle 验证过的正确修复。存的是"遇到 X 类错误，Y 方案修好了"。
负经验（Negative Memory）：尝试过但没修好的方向。存的是"遇到 X 类错误，试过 Z 方案，没用"。
这就像一个老程序员的笔记本：不只记"这个 bug 怎么修的"，还记"这个 bug 别试什么方法，没用"。
类型条件检索
检索时不是纯语义相似度，而是先按错误类型过滤，再在类型内做语义检索。这避免了跨类型误检索：语法错误的修复经验不会被检索来应对逻辑错误，即使它们的自然语言描述很像。
因果时序约束
"因果"（Causal）在论文里有个特定含义：只有"已完成"的情景（episode）才能进入记忆。 正在进行的修复不能作为记忆源——因为你还不知道这个修复对不对。
这和人类的经验记忆很像：你不会把"正在尝试的方案"当成经验告诉别人，只有验证过的才说"我之前遇到过"。
三、实验结果：诚实的好消息和坏消息
主实验：Spider 和 BIRD 基准
论文在两个主流 Text-to-SQL 基准上测试：
| 方法 | Spider (EX) | BIRD (EX) |
|---|---|---|
| 迭代修复基线 | 66.34% | 47.35% |
| MERIT | 69.79% | 48.44% |
| Dynamic RAG | 69.51% | 48.16% |
诚实的坏消息：没赢 Dynamic RAG
但看仔细一点：MERIT 和 Dynamic RAG 的差距很小。Spider 上 MERIT 69.79% vs Dynamic RAG 69.51%，差 0.28pp；BIRD 上 48.44% vs 48.16%，差 0.28pp。
这个差距在统计噪声范围内，不能说 MERIT 可靠地优于 Dynamic RAG。
论文诚实地承认了这一点。这是一个值得赞赏的做法——很多论文会挑选有利的角度报告"MERIT 优于 Dynamic RAG"，但作者直接说"两者相当"。
为什么 MERIT 没有显著超过 Dynamic RAG？
论文分析了几个原因：
1. 错误分类器准确率只有 48%：MERIT 的类型条件检索依赖错误分类，但分类器准确率不到一半。这意味着接近一半的情况下，类型检索用的是错误的类型，反而会误导检索。
2. 查询顺序敏感：MERIT 的记忆是动态增长的，先遇到的错误会成为后续检索的记忆源。如果查询顺序变了，结果可能不一样。
3. 不比无状态方法便宜：维护和检索记忆有额外开销，但收益不明显。
四、为什么仍然有价值
你可能会问：既然没赢 Dynamic RAG，这篇论文为什么值得发？
1. 概念贡献大于数字贡献
MERIT 引入的"类型化正负经验"框架是一个概念贡献，不是数字贡献。它提出了一个更精细的记忆结构设计空间：错误类型 × 正/负经验 × 时序约束。即使当前实现没跑赢基线，这个设计空间为后续工作指明了方向。
2. 负经验是原创贡献
之前的记忆增强修复方法只存成功案例。MERIT 是第一个系统性地存储和利用"失败方向"的方法。这和人类专家的经验结构更接近：专家不只是知道"怎么做"，还知道"别怎么做"。
3. 诚实报告本身是贡献
在 AI 领域"刷榜"成风的环境下，这篇论文选择诚实报告"没显著超过基线"，这本身就是一个贡献。它告诉读者：记忆增强修复不是银弹，类型化检索在当前分类器准确率下收益有限。这避免了后续研究重复踩坑。
五、概念定位：颗粒度同构原理
MERIT 是"颗粒度同构"原理的一个新实例。这个原理说：优化颗粒度应该和被优化对象的颗粒度一致。
在 MERIT 之前：
- Heddle 和 CodeRescue 把决策颗粒度从"单次调用"提升到"轨迹/恢复动作"级别
- ACE 的 RPI 工作流把上下文管理颗粒度从"整个对话"切到"每个阶段独立压缩"
- Regression Tax 把评测颗粒度从"平均通过率"细化到"配对结构"
六、和"换层面解决问题"的关系
MERIT 也和"换层面解决问题"概念谱系有关。之前的成员：
- 章鱼 RNA 编辑：不改 DNA，改 RNA
- 黏菌外化记忆：不用神经元，用黏液
- MACRO：不改权重，改层执行路径
但 MERIT 的诚实报告也提醒我们：层面切换不一定总是有效。黏菌的外化记忆是亿万年进化的结果，MERIT 的外化记忆才刚开始，分类器准确率不够、检索策略不够精细，都可能导致层面切换的收益被噪声淹没。
七、局限与未来方向
论文的局限部分值得仔细读：
1. 错误分类器是瓶颈：48% 的准确率意味着类型条件检索接近一半时间是错的。如果分类器能提升到 80%+，MERIT 可能会显著超过 Dynamic RAG。
2. 只测了 Text-to-SQL：Text-to-SQL 的错误类型比较明确（SQL 语法错误有结构），其他领域（代码生成、数学推理）的错误类型可能不那么清晰。MERIT 的迁移性还需验证。
3. 记忆库的冷启动：一开始记忆库是空的，前几次修复没有经验可参考。论文没有讨论冷启动阶段的策略。
4. 记忆库的容量管理：随着时间推移，记忆库会越来越大，检索成本会上升。论文没有讨论记忆的遗忘和压缩策略。
未来最值得做的方向可能是：提升错误分类器准确率。 如果分类器从 48% 提升到 80%，MERIT 的类型条件检索可能真正发挥出优势。这就像给经验丰富的老程序员配了一个好的错误诊断工具——他的"经验硬盘"才能真正发挥作用。
八、结语
MERIT 给 Agent 装了一个"经验硬盘"，按错误类型存、按因果结构取。当前实现没显著超过 Dynamic RAG，但"类型化正负经验"的设计框架为后续工作指明了方向。
论文最值得记住的不是数字，而是一个设计原则：记忆不只是"存什么"，更是"怎么存"和"什么时候能取"。 错误类型 × 正负经验 × 时序约束，三个维度构成了记忆的结构化设计空间。
这让人想起一个老工程师的话："新手记得答案，专家记得坑。" MERIT 试图让 Agent 从"只记答案"进化到"也记坑"。虽然当前记坑的收益不明显，但方向是对的——毕竟，知道"别怎么做"往往比知道"怎么做"更值钱。
---
论文链接：https://arxiv.org/abs/2608.05906 分类：cs.CL, cs.AI