Agent 记忆设计，先解决该忘掉什么

Agent 记忆出了问题，先别急着换 embedding 模型或重排器。作者折腾过向量索引、分块大小和检索排序，最后发现，真正拖累 Agent 的是存进去了太多不该记的东西。

这篇短文的主张是：记忆系统首先要解决筛选、遗忘和持久化，再谈检索。它没有给出跑分或完整实现，但提出了几条适合检查 AI 编程助手的原则，尤其是「历史记录是否正在干扰当前任务」。

为什么记得越多，Agent 反而越容易答错

作者最初把记忆当成检索问题：如何把信息切块、建立向量索引，再准确地找回来。但实际出问题的地方更靠前：哪些信息值得进入记忆库？

他们曾保存每次工具调用和每个未完成的思路。结果，Agent 经常依据过时上下文回答，而不是围绕当前任务行动。

对话记录保留的是「发生过什么」，记忆应该保留的是「以后做决定还需要什么」。一次探索过程里，可能有猜测、失败尝试和已经被推翻的方案，把这些全部带回上下文，会让旧信息继续影响新判断。

作者随后只持久化三类内容：决策、约束和例外情况。他描述的结果是，召回在纸面上变差了，实际使用却更好了。不过，原文没有说明这里采用了什么召回指标。

找回更多历史，不等于帮助 Agent 做出更好的下一步决策。

这也是标题把问题比作垃圾回收的原因：检索负责找出来，记忆管理还要决定哪些内容应该留下、哪些应该清走。

遗忘和重启，才是记忆系统的两道考题

第一道考题是时间。

上次会话里成立的事实，这次可能已经成为负担。作者给每条记忆附上来源和置信度，并让较旧、置信度较低的条目逐渐淡出，避免它们继续在提示词里争夺影响力。

来源帮助追溯一条信息是怎么来的，置信度表达它有多可靠。两者都不能保证信息永远正确，但能为后续保留或淘汰提供依据。

原文没有交代「淡出」的具体实现：是降低检索权重、停止注入上下文，还是直接删除，都没说清。因此，可以拿走这套原则，不能把它当成现成的衰减算法。

第二道考题是进程重启。

作者在任务执行到一半时杀掉进程，再回来继续，才发现之前关于「会话」的假设并不可靠。如果所谓记忆只在进程存活时有效，它更接近缓存。

真正的持久记忆必须活得比创建它的进程更久。这里检验的不只是数据有没有写到磁盘，还包括重新启动后，那些决策和约束能否继续支持任务。不过，原文没有提供恢复流程和存储方案。

作者最终采用了一条简单规则：少写、慎写，每条记录都要证明自己值得保留。如果一条记忆不会改变下一次决策，就不存。按他的观察，检索质量改善，主要来自候选内容减少。

我的判断

我认同作者把注意力从「怎么搜」往前移到了「该存什么」。如果旧猜测和失效约束持续进入上下文，单纯优化检索，可能只是更准确地找回干扰信息。

但这仍然是经验之谈。原文没有提供数据规模、任务类型、失败率，也没有拿全量历史检索与选择性记忆做对照，无法据此判断改善幅度，更不能断言所有 Agent 都该采用同样的保留策略。

只保存决策、约束和例外，也有前提：系统能正确识别它们。筛选时漏掉关键依据，后续同样可能出错。需要审计或排查问题的团队，还可以保留完整日志，同时单独维护供 Agent 使用的精简记忆。日志的保存需求，不必直接变成提示词的输入需求。

这篇文章更适合作为记忆系统的检查清单，而不是已经验证的架构方案。

能拿来做什么

• 给 AI 编程助手检查一次记忆写入规则，优先保留会影响后续修改的项目决策、约束和例外，别默认把所有工具输出都当成长期记忆。
• 给记忆附上来源和置信度，检查旧条目是否仍然成立；具体何时降权、何时删除，需要结合自己的任务验证。
• 对持续执行任务的 Node Agent 做一次中途退出再启动的恢复检查，确认关键决策和约束能够重新读取，而不只是留在进程内存里。
• 遇到检索结果干扰当前任务时，先检查候选记忆里有多少过时或无关内容，再决定是否调整分块、向量索引和重排器。