长期记忆

模型本身没有记忆，所谓「记得你」都是你的系统在存和取。难点在提取、冲突、注入三处，而收益通常是更省更短，不是更准。

模型本身没有任何跨会话记忆。所有「它记得你」的时刻，都是你的系统在旁边替它存和取。locomo 做记忆功能不是给模型加能力，是给系统加一套存取流程——值不值得加、加在哪一步，要先想清楚。

读完你能回答：

• 记忆系统的价值为什么不落在准确率上？
• 存取分几步，每一步难在哪？
• 临时和长期打架时按什么判，这套系统又要付出哪三笔代价？
• 哪些信息做成设置项就够，哪些才值得上一套自动记忆？

收益不在准确率，在延迟和成本

拿准确率去衡量记忆系统，方向从一开始就是错的。

有一组基准测试把这件事量化得很清楚：把整段对话历史原样塞进上下文这个最笨的做法，总体得分高于所有专门做记忆管理的方案——全上下文基线 72.9 分，Mem0 是 66.9 分，图结构的 Mem0g 是 68.4 分。mem0 单看答对的比例，不做记忆管理的方案赢了。

那它的价值在哪？在延迟和成本。同一组测试里，全上下文基线的 p95 延迟约 17.1 秒，Mem0 只要约 1.4 秒，token 消耗省下超过 90%。mem0

这笔交换之所以划算，是因为全上下文方案的成本随对话长度持续增长：用户用得越久，每次请求越慢越贵，而且迟早会撞上窗口上限。记忆系统做的是把这条曲线压平，代价是准确率上让出一小步。需要秒级响应的生产场景里，这一步让得值；离线批处理场景里，可能就不值。

所以选型时该问的不是「记忆系统能提升多少准确率」，而是「我能不能接受用一点准确率换一个数量级的延迟和成本」。

三步存取，和 RAG 是同一套机制

存取分三步走。

一、提取。对话告一段落、或者还在进行中，都会有一次模型调用在做判断：哪些内容后面还会用到。比如用户说对外的文档一律用英文、客户数据不能离开境内、周报喜欢按项目分栏。

二、处理冲突。一条新事实写进来之前，先跟已有的内容对一遍，看有没有打架。用户原先说自己的直属上级是陈工，后来又说陈工调走了、现在汇报给林工——这两句没法同时成立，所以要做的是更新，而不是往后追加。

三、注入。下一个会话开场时，从记忆库挑出几条相关的，和系统提示或开头部分拼在一起。模型读到这些内容，表现出来的效果就是「它还记得我」。

第三步的本质值得说清：它和 RAG 是同一套机制——检索出相关内容、塞进上下文。真正的差别在于被检索的东西：这里找的是与当前用户有关的事实，而不是从文档里截出来的段落。MemGPT 这类研究正是把这个循环显式化了：模型需要一个「操作系统」替它分层存取记忆，这也是生产系统做记忆功能时最常见的蓝本。memgpt

提取难在没有客观标准

第一处难点在这里：「什么值得记」这件事没有客观标准。

记得太多，记忆库里很快堆满无关紧要的内容——随口说的一句玩笑、只在某一次适用的要求，都会被归入长期偏好保存下来。而它们往后每次会话都要被重新注入，费用和判断干扰都跟着上涨。反过来记得太少又没用，用户察觉不到任何区别。

比较落地的做法是先划定类别：只收身份事实、长期偏好、明确的禁止项这三种，归不进去的一概不留。一句笼统的「记住重要的事」，几乎注定会走偏。

另有一类不容易看见的隐患：记忆由模型提取，它就存在提错的可能。错的那一条只要写进库里，之后每一轮对话都会被它影响，而且很难暴露——系统在背后记过什么，用户根本无从得知。

冲突难在分不清临时和长期

默认的规则是按时间取新，但总有例外，第二处难点就在这里。

用户说的「这一次先按上一版口径算」只是当次需要，不应该盖掉「我们默认按最新政策」这条长期设定。反过来说，「陈工调走了、以后汇报给林工」是长期变化，就必须盖掉旧的汇报关系。这两条新事实从形式上看不出差别，一条该覆盖、一条不该覆盖，分界线只在时效上。

可行的办法是让提取阶段顺手把时间属性一起记下来：这条内容是只在当前任务里成立，还是长期有效？提取时漏了这一层，后面谁也判断不了，只能靠猜。这一处最容易失手的地方，就是分不清「临时」和「长期」。有研究干脆主张换个存法：把「记一条事实」和「按这条事实行动」合成一件事，用可执行的规则来表达用户的约束，因为把存储和行动分成两步，正是矛盾难解、规则难守的原因。user-as-code

注入的取舍，和三笔要算的账

第三步的问题在时机和数量。取得太多，每次会话开头就背着一大包事实，每一轮都要重发，成本固定增加；取得太少或取错，用户会觉得「上次说过了怎么又问」。注入的内容还会占用窗口——窗口是一份要分的预算，记忆多占一块，资料就少一块。所以注入要回答三个问题：这次会话和哪些记忆相关、取几条、放在什么位置。第一问决定准不准，后两问决定贵不贵。

把整套系统建起来，另外还有三笔账要算清：

一、每次对话多出提取的调用。这是一次额外的模型请求，账单由你承担，用户完全感知不到。

二、每次对话开头多出注入的内容。记忆越多，这笔固定开销越大。

三、隐私和合规成本。这一笔最容易被忽略。用户个人信息会被你长期保存，牵出的是隐私政策、留存期限、以及用户的删除权。动手之前先让法务看一遍。

产品层面还有一件事必须做到：用户要能查看并删除属于自己的记忆。也就是提供一个页面，列出「AI 记住了关于你的这些事」，并支持逐条删除。这既是为了合规，也是在建立信任——一旦用户发现系统背着自己存了一堆东西，反应会很激烈。

多数产品不需要完整记忆

通用记忆先别做，从一个字段明确定义的小范围开始。这是整套东西里最省钱的一条判断。

完整记忆系统对多数产品并不必要。你真正可能需要的，是记住回答用哪种语言、时间按哪个时区显示、引用按哪一套格式来写——而这些完全可以做成显式的设置项让用户自己填。结果可预期、随时能改、不会提取出错、也没有隐私争议，成本还接近于零。

判断线很干脆：用户本来就愿意主动告诉你的信息，就做成设置项，别让 AI 去猜。

真正值得上自动记忆的，是用户不会主动填、但确实影响体验的那些内容——他怎么工作、容易在哪儿出错、喜欢什么措辞。

还有一条边界要划清：记忆里放的是跟这个用户有关的事实，而不是他的全部聊天记录。后者属于日志，是另一回事，存储方式、保留期限、合规要求都不一样，别混在一起做。

记忆这套存取流程本质上还是在回答同一个问题：下一次请求该往里装什么。装进去的每一块都占预算、都参与竞争，上下文里到底装了什么把这份预算拆得更细。而模型可能提取错这件事也提醒我们，凡是跨会话积累起来的东西，都要有办法被人看见和纠正——保存经历不等于从经历学习讲的是这条原则的另一面。