推文

@kafkaup · 2026-10-16 02:53

最近在看 Agent Memory 的时候，发现一个比较容易被忽略的问题。 我们经常会讲给 Agent 做长期记忆，就是让它从历史任务里找到和当前问题有关的经验。但这里其实藏着一个很大的坑：相关不等于可复用。 最近看到一篇 Agent Memory 的相关实践文章，叫做《任何错误只犯一次》，里面有一组数据特别有意思：他们从 2600 个历史 session 里拆出了 5000 个 task，然后尝试判断不同任务之间有什么关系。结果有一类被模型判断成 same problem（同一个问题）的数据，精确类型判断正确率只有 38%，但其中 95% 的样本确实存在某种关系。 这个 38% 不能理解成只有 38% 的 memory 可以复用，它真正反映的是：模型其实擅长发现两个任务之间有关，但很难继续准确判断它们到底是同一个问题、相似问题，还是一条真正可以迁移执行的经验。 这件事在 Agent Memory 的研究里其实一直存在。2024 年有一篇论文叫《Agent Workflow Memory》，它的思路是从过往任务里提炼出可复用的 workflow，再选择性地提供给后续任务，而不是把所有历史经验都塞给 Agent。它其实隐含了一个前提：过去的经验有价值，但前提是你得先判断哪一条适用于现在的问题。 举个简单的例子：一个 Agent 工具调用的问题，当时发现某个接口必须额外传一个参数。今天另一个 Agent 又出现了一个非常相似的报错。这个时候如果只做向量检索，这两个 case 的语义相似度可能很高，系统很容易把上一次的方案召回来。 但问题是，上一次可能用的是 V1 接口，现在已经升级成了 V2；或者上次发生在测试环境，现在是生产环境；甚至有可能只是错误信息长得像，但真正的根因不同。这时候 memory 的召回其实不能算失败，它确实找到了一条相关的经验。出问题的是下一步：判断这条经验适不适合当前的任务。 今年 ACL Findings 有一篇论文专门讨论了这个问题。它指出，如果 memory 在任务分布发生变化之后，依然按照固定的方式被复用，就可能出现 negative transfer（负迁移），也就是过去的经验没有帮助到当前的任务，反而把当前任务带偏了。另一篇论文也发现，持续学习的问题并没有消失，只是从模型参数转移到了 memory 的表示和检索上，其中错误经验导致的 negative transfer 对一些更难的任务伤害更明显。 所以我现在会把企业级的 Agent Memory 拆成三层： 1. 相关性：判断历史经验里有没有跟当前任务有关的东西。这一层其实已经有很多成熟的手段，比如向量检索、BM25、rerank。 2. 适用性：解决这条经验属于哪个项目、哪个版本、哪个 branch，它的产生时间是何时，当时成立的前提是什么，以及这个前提现在是否还成立。文章里的 Redis case 做得很典型：同一个 repo 都还不够，因为 branch、path、配置、运行环境、时间都可能不同，这些 scope 要跟着 memory 一起被管理。 3. 可执行性：判断这个东西到底是什么性质，它的历史背景如何。它是一个待验证的猜测、一次失败的经验，还是一个经过测试或人工 review 的解决方案？文章里的实践也是这么处理的：未经验证的轨迹先作为低权重背景，只有经过测试、提交或人工 review 支持之后，才逐渐升级成更稳定的 memory scope。 做企业级的 memory 系统，不能把它做成一个更大的 RAG。检索主要解决的问题是“我能不能找到”，而 memory 还需要继续回答：这条线索现在是否还适用？它的可信度到了什么程度？以及这条信息有没有资格直接影响 Agent 下一步的推理和行动？ 这也是为什么文章里提到有两万多条关联的历史关系，最后真正作为强关联留下的只有很少一部分，大量内容都被降成 shadow，只负责帮助背景发现，不负责驱动执行。 这里还有一个很有意思的产品判断：对于 Agent 来说，最危险的情况往往不是什么都没召回，而是召回了一条看起来特别相关、特别合理，但实际上已经不适用当前任务的信息，然后 Agent 非常自信地继续向下执行。 所以 memory 做得越深，核心问题就会从“怎么记得更多”，变成“怎么判断过去的经验在今天这个任务里还有没有资格被使用”。

曝光 72 · 评论 0 · 点赞 0 · 书签 0