Agent 的长期记忆：难的不是检索，是决定什么不记

一、检索不是瓶颈

刚做记忆的时候我想的是检索：怎么把相关的东西找回来。做了一阵子发现，检索根本不是瓶颈。 真正的问题是存进去的东西太多了。跑了两周之后，长期记忆里堆满了「今天聊了什么」「用户说了句什么」这种一次性的东西。检索的时候它们和真正重要的条目权重差不多，于是相关的沉底、噪音浮上来。 什么都记，等于什么都检索不到。 而且这个问题会自己恶化：噪音越多，单条的相对权重越低，越需要提高召回数量，召回越多上下文越挤，最后又回到装不下的原点。

二、分成三份，各自淘汰

分成三份存，各自的淘汰规则完全不同。 短期记忆按会话滚动，超出窗口就摘要压缩。它的作用只有一个：让这一轮对话连贯。会话结束，绝大部分内容就该消失。 长期记忆单独落盘，而且写入要过一道判断 —— 这条信息在一周之后还有用吗？事实类的（他用什么技术栈、住在哪个时区）留下，事件类的（今天做了什么）除非有后续价值否则不留。这一步宁可漏记也不要多记：漏了下次还能再问，多了就得靠检索去和噪音搏斗。 第三份是空闲任务权重表，它不参与对话检索，只回答一个问题：没人说话的时候该做什么。这份得单独存，混进长期记忆里会污染检索结果。

三、七成时间花在写入上

做完之后回头看，我花在检索算法上的时间可能只有三成，剩下七成全在写入策略上。 这和直觉是反的。一提到记忆，大家想的都是怎么找回来，很少有人想怎么决定不记。但检索是可以事后优化的，写错的数据是要清理的 —— 而清理比一开始就不写难十倍。 还有一个副作用值得记一笔：因为写入要过判断，记忆库变小了，于是我第一次能把整个长期记忆打印出来通读一遍。能通读，就能发现哪些条目是垃圾、判断规则错在哪。规模失控之后这个反馈回路就没了。