会聊天的AI很多，能「记住」的很少：记忆系统的四种实现与选型

一个典型的产品困境

用户在第一天告诉AI：“我是做外贸的，主要客户在德国，报价习惯用欧元。”

第二天再问：“帮我写封邮件。” AI 一脸茫然。

Demo 里这种问题看不出来，因为 Demo 只有三轮对话。真实产品里，没有记忆就等于每次都是新客户。而记忆做错了方向，不仅不解决问题，还会让成本和错误一起放大。

方案一：全量上下文

最朴素的方案——把所有历史对话都塞进去。

• 优点：实现成本几乎为零，不改架构
• 缺点：成本随轮次线性增长（实际是超线性，因为每次都要重发全部历史）；超过窗口后必须截断，而截断策略往往丢掉的正是关键信息；长上下文中，模型对中段内容的注意力会下降

适用：单次会话内的短期对话（客服、问答）。一旦跨会话，就该换方案。

方案二：摘要滚动

每 N 轮对话后，用模型把历史压缩成一段摘要，只保留摘要 + 最近若干轮原文。

• 优点：成本可控，能跨会话延续
• 缺点：摘要是有损压缩且不可逆。今天觉得”客户提到想拓展东南亚”是废话被压缩掉了，三周后它变成关键需求。而且每次摘要都是一次模型调用，错误会累积

改进技巧：摘要时分离”事实层”和”叙事层”。事实层（用户属性、偏好、已确认的决定）用结构化格式保存，不参与压缩；叙事层（讨论过程）才允许丢失。这一条改进能解决摘要方案 80% 的失真问题。

方案三：向量检索记忆

把每轮对话或每个事件嵌成向量，需要时检索Top-K注入。

• 优点：不限时长，支持大量历史
• 缺点：检索依赖当前提问的语义相似度，而记忆的价值往往与相似度不一致

举个具体的失败案例：用户上次说”我不喜欢太长的邮件”。这次问”帮我写跟进邮件”。语义相似度里，“邮件”相关的内容会排前面，而”不喜欢太长”这条偏好可能排不进Top-K。

改进技巧：

• 对偏好类信息单独建索引，且无条件注入，不依赖检索
• 检索时用”当前问题 + 用户画像摘要”作为联合查询
• 给记忆加时间衰减，但不要衰减偏好（偏好通常稳定，事件才易过期）

方案四：结构化用户档案

把记忆分成明确的槽位：身份、偏好、约束、当前目标、历史决定。由模型在对话中增量更新，冲突时以新值为准并保留旧值。

• 优点：可审计、可编辑、可解释；成本低（一份档案通常几百 token）；用户能直接看到并纠正
• 缺点：需要设计schema；开放性内容（比如用户的长篇倾诉）难以结构化

实际最佳实践：方案四做骨架，方案三做补充。

档案（常驻注入，~300 token）
  ├─ 身份：外贸，主营家居，客户在德国
  ├─ 偏好：邮件简短；报价用欧元
  └─ 当前目标：开拓东南亚市场

事件记忆（按需检索）
  └─ "3月12日讨论过泰国代理商筛选标准"

成本对比（每轮对话的额外开销）

方案	上下文开销	额外调用	跨会话
全量上下文	高且递增	无	差
摘要滚动	中	每N轮1次	好
向量检索	低	1次embedding	好
结构化档案	很低	每次1次小模型抽取	很好

三个必须做的工程细节

1. 记忆写入要异步：不要让用户等”记忆更新”完成，抽取和写入放到后台队列
2. 记忆删除是刚需：用户说”忘掉这个”，必须真的能删（合规也是硬要求）。设计schema时就把删除路径想清楚
3. 记忆要可展示：给用户一个”AI 记住的关于你的事”页面。这既是信任建设，也是最便宜的纠错渠道

结论

记住用户这件事，关键不在模型有多强，而在你决定记住什么、以什么形式记住、什么时候让它遗忘。

先做结构化档案（一周能上线），再加事件检索（一个月能稳定），最后再考虑复杂的记忆重排和反思机制。反过来做，你会得到一个很聪明但经常记错事的AI。