AI 产品Memory怎么做?

过去一年，越来越多 AI 产品开始做 memory。

表面上看，memory 是一个很自然的能力：用户说过的话，AI 下次还能记得；用户的偏好、习惯、背景，AI 能逐渐理解；用户不用每次都从头解释，产品也能显得越来越“懂我”。

但真正开始设计时你会发现，memory 不是一个简单的“保存用户信息”的功能。

它更像一套长期运行的信任系统：要判断什么值得记，要决定什么时候记，要让用户知道自己被记住了，要允许用户查看、修改和删除，还要在记错、用错、过期、冲突时有一整套补救机制。

更麻烦的是，memory 一旦出错，伤害的往往不是某一次回答质量，而是用户对产品的信任。

普通回答错了，用户可能觉得这次效果不好。但 memory 出错，用户会觉得：这个产品在用错误的方式理解我。

所以，做 memory 之前，PM 不应该只问：

我们能不能记住用户？

更应该问：

我们该不该记？记什么？怎么记？怎么让用户知道和控制？记错了怎么办？用户不想被记住时，能不能真的退出？

这篇文章，我深度梳理了关于 memory 的各种视角，你可以把它当成一次 memory 产品评审的 checklist。

一、先划边界，本文说的Memory 到底是什么？

在讨论要不要做 memory 之前，先要把概念边界划清楚。

AI 产品里有很多东西都看起来像“记忆”，但它们解决的问题不一样。

最容易混在一起的有三类：上下文/长记忆/个性化

本文讨论的 memory，主要指 跨 session 的长期记忆。也就是：用户下次回来时，产品还应该记得什么。

这和同一 session 内的超长对话不是一回事。

比如，用户和 AI 连续聊了两个小时，一起写报告、改代码、打磨产品方案。即使用户没有关闭页面，前面出现过的信息也可能因为上下文太长、窗口限制、摘要压缩或模型注意力稀释而变得不可用。

这当然也需要“记忆能力”，但它更接近 context management / working memory。

它要解决的是：当前任务已经发生了什么，模型怎样不丢线索。

比如：用户已经确定过的目标/ 已经排除过的方案/ 前面做过的关键决策 等，这些信息未必应该永久保存，但在当前任务结束前非常重要。

而长期记忆要解决的是另一类问题：用户下次再来，产品是否还能延续对他的理解。

比如：用户不吃辣/ 用户长期负责某个项目/ 用户希望 AI 在写作时少用夸张表达 等

这些信息可能会跨越多次会话反复影响体验，因此才值得进入长期 memory。

所以，判断产品要不要做 memory 时，首先要问清楚：我们讨论的是当前任务连续性，还是跨 session 的用户连续性？

前者我们放到后续的上下文管理文章中再去做详细拆解。

还有一个容易混淆的概念是 personalization。个性化通常基于聚合的、统计的、长期稳定的用户画像，更新较慢，更多由后端管线驱动。

memory 通常是具体的、事件性的、可被对话即时更新的，更新更快，也更需要用户可见、可改、可删。

成熟产品里，memory 和 personalization 会并存，也会互相喂养：memory 是个性化的原料，个性化是 memory 的高层抽象。

但它们的实现路径、更新频率和用户控制方式完全不同，如果一开始混在一起设计，最后往往两个都做不好。

二、我的产品到底要不要做 Memory？

不是所有 AI 产品都需要长期 memory。

很多团队想做 memory，是因为它听起来像一个 AI 产品标配能力：能记住用户，当然更智能。

但 memory 不是免费的。它会增加产品复杂度，引入隐私风险，需要持续运维，还会在出错时伤害用户信任。

所以，是否要做长期 memory，不能只看它有没有技术可行性，而要看它有没有明确的产品价值。

1. 核心判断：是否依赖跨 session 的用户连续性

一个产品是否需要长期 memory，核心看一件事：产品价值是否依赖跨 session 的用户连续性。

如果用户每次来，都是一个相对独立的任务，那么长期 memory 的价值可能并不高。

比如：一次性翻译、图片格式转换，这类工具型产品的主要价值是“当下完成任务”。用户未必期待产品记住自己是谁，也不一定希望它带着过去的信息来影响这次结果。

甚至在某些工具型场景里，长期 memory 还可能干扰体验。

比如：我只是想临时翻译一段法律文本，产品却根据我过去写营销文案的偏好自动调整语气，这不一定是加分项。用户要的是准确、稳定、可控，而不是“懂我”。

相反，如果产品本身依赖长期关系、持续陪伴、个性化成长或长期状态追踪，那么 memory 就会变得非常关键。

比如：情感陪伴型产品、教育型产品、健康管理产品、长期创作工具。这些产品的价值不是只完成一次任务，而是随着时间越来越懂用户。

用户希望它知道自己的偏好、目标、限制、背景、历史选择，以及上次聊到哪里。就像健康管理产品里，用户不希望每次都重新交代自己的睡眠、饮食、运动和用药情况。

但中间地带也很多，比如客服。如果客服只是回答标准问题，memory 的价值有限。

但如果它服务的是老客户、复杂售后、企业账户、长期项目，那么 memory 就可能显著提升体验。它知道用户买过什么、之前遇到过什么问题、上次处理到哪一步、哪些方案已经试过，就能减少大量重复沟通。

2. 一个实用公式：Memory 价值怎么算？

可以用一个粗略公式判断 memory 是否值得做：

Memory 价值 = 重复表达成本 × 个性化收益 × 长期关系强度 – 隐私 / 信任 / 运维成本

这个公式不需要精确计算，主要是帮助 PM 做产品判断。

并不是“越懂用户越好”。真正值得做 memory 的场景，一定是收益明显大于成本，以下是目前常见的AI应用场景，可以试着代入下公式感受。

3. 先问自己五个问题

如果你正在评审一个产品要不要做长期 memory，可以先问五个问题：

如果五个问题里有三个以上回答是“是”，长期 memory 才值得认真考虑。

如果你只能说“有 memory 会更智能”“会更个性化”，但说不出具体损失，那么可能还不到做 memory 的时候。

三、到底什么信息应该被记住？

决定做 memory 之后，第二个核心问题是：到底什么应该进入长期 memory？

很多 memory 系统最早出问题，不是因为没有记，而是因为记得太多、太杂、太随意。

一个基本原则是：

Memory 里应该保存“未来会反复影响体验的信息”，而不是“对话里出现过的一切信息”。

用户说过 ≠ 值得记、当前有用 ≠ 长期有用、模型能抽取 ≠ 产品应该保存。

1. 应该记与不该记的信息

这张表的关键不是覆盖所有情况，而是给出一套可参考的立场。

长期 memory 应该优先保存三类信息：第一，用户明确要求记住的信息。第二，稳定且会反复影响体验的偏好。第三，跨 session 延续的目标、项目和关系状态。

这几类信息要非常谨慎：临时任务状态、短期情绪、敏感信息、模型推测出来的结论、用户已经删除或拒绝过的信息。

2. 不要把临时任务状态放进长期 memory

这是一个很常见的错误，用户在当前对话里说：“这篇文章我们先写得犀利一点。”这不一定意味着用户长期喜欢犀利风格。

用户说：“这周我在减肥。”也不一定意味着用户长期处于减肥状态。

用户说：“这个项目先不要考虑商业化。”这可能只是当前项目阶段的约束，不应该变成用户长期偏好。

这些信息在当前任务里很重要，但未必适合进入长期 memory。

更合适的做法是把它们放在 session memory 或 project memory 中。不是所有重要信息都应该进入用户级长期记忆。

这就引出一个更重要的设计：memory 分层。

3. Memory 不应该只有 user-level

很多产品一开始会把 memory 简单理解为“关于这个用户的长期资料”。

但成熟的 memory 系统不应该只有 user-level。更合理的分层至少包括四类：

这个分层非常重要。如果所有信息都塞进 user memory，系统很快会混乱。

工作信息会污染个人信息，项目临时约束会变成长期偏好，当前任务状态会影响未来无关任务，用户删除时也很难判断到底该删哪一层。

所以，设计 memory 时不要只问：“这条信息要不要记？”还要问：它应该记在哪一层？

一条信息是否值得长期保存，和它是否值得放进 user memory，是两个问题。

4. 一条成熟的 memory entry 应该长什么样？

前面讲了什么该记、什么不该记，也讲了 memory 应该分 user / workspace / project / session 几层。

但还需要再往下拆一层：每一条 memory entry 自己应该带什么信息？

如果一条记忆只是简单的一句话，比如：“用户不吃辣”，那它在早期 demo 里可能够用，但真正进入长期系统后，很快会遇到问题：

这条记忆是用户明确说的，还是模型推测的？它是什么时候出现的？最近有没有被用户确认过？

它适用于所有场景，还是只适用于某个 workspace 或 project？它会不会过期？

如果用户后来又说“我最近开始吃辣了”，系统应该覆盖、保留，还是降权？

这些问题都依赖 memory entry 的元数据，一条成熟的 memory entry，至少应该包含下面这些字段：

这些字段听起来偏工程，但本质上是产品能力的前置条件。

所以，memory entry 不是一句文本，而是一个带来源、置信度、时间性、作用域和生命周期的对象。

很多产品 memory 后期难以迭代，不是因为模型不够强，而是因为早期 memory schema 设计得太薄。

四、显式记忆和隐式记忆怎么选？

决定什么该记之后，下一个问题是：

这条记忆应该由用户主动触发，还是由 AI 自动抽取？也就是显式记忆和隐式记忆的选择。

所谓显式记忆，是用户主动说：“记住这个。”、“以后都按这个风格写。”、“我不吃香菜。”。

这种方式的优点是可预测、边界清晰、用户信任成本低。用户知道自己说了什么，产品也知道自己为什么记住。

但缺点是召回率低。

大多数用户不会主动管理记忆，也不会在每个值得记录的瞬间都说一句“请记住”。他们更自然的期待是：

我已经说过了，你为什么还不知道？

隐式记忆是 AI 自动从对话中识别出可能值得长期保存的信息，比如用户偏好、背景、目标、习惯、长期项目状态等。

它的优点是体验更顺滑，召回率更高，用户不需要额外操作，产品也更容易显得“懂我”。

但隐式记忆的风险也更高。AI 可能抽错，可能抽多，可能记住用户只是随口一说的内容，也可能记住用户并不希望被长期保存的信息。

显式记忆像是用户亲手写进笔记本。隐式记忆像是产品在旁边默默做笔记。

前者可靠但不够主动，后者聪明但容易越界。

1. 不要只做显式 / 隐式二分，还要看置信度！

显式和隐式是一个有用的起点，但真实产品里，这个二分还不够细。

因为所谓“隐式记忆”内部，其实包含很多不同来源，可信度和用户接受度差异很大。

不是所有隐式记忆都一样。

用户明确说过的事实，和模型根据多轮对话归纳出的画像，在产品上完全不是一类东西。

前者更接近记录。后者更接近判断。

记录可以相对积极，判断必须非常谨慎。

2. Memory信息分流策略

大多数产品不应该一上来全隐式。更稳妥的路径是：

显式记忆起步，低风险隐式补充，高敏感信息必须确认。

所以产品策略上需要根据风险与意图做信息分流：

五、Memory 的产品逻辑如何设计？

首先，在 AI 应用层，先明确Memory 的定义：

系统在一次或多次交互中，选择性保留、组织、更新和调用与用户、任务、环境或历史行为相关的信息，以便未来提供更连续、个性化、上下文一致的服务。

所以，一个实用的 memory 系统通常不是一次写入就结束，而是一个闭环。

近期关于 agent memory 的研究，也常把记忆抽象成 write–manage–read loop，也就是写入、管理、读取的循环。

但对产品来说，真正重要的不只是这个 loop 能不能跑起来，而是每一环用户是否能理解、接受并控制。

这张表啰哩叭嗦写这么多，是为了让你在产品评审时应对连环 argue，按实际产品需求参考。

下面重点展开几个最容易出问题的环节。

1. memory 可见性如何设计？

memory 是一个用户大部分时候看不见、但偶尔会撞见的能力。

它的可见性主要发生在三个时刻：

基本原则：memory 的提示和展示，是用来服务信任的，不是用来刷存在感的。

工具型产品可以坚持只存事实；陪伴型产品可以适度做语义总结；但越是高敏感场景，越要克制推断。

无论哪种形态，都需要一件事：用户可以编辑、删除、追溯来源。

2. 用户说”你记错了”，纠错必须落到记忆层

“你记错了” 是 memory 产品最高频、也最关键的失败场景。

最差的处理是 AI 嘴硬。第二差的处理是只在对话里道歉，但 memory 里那条记错的记忆原封不动。

两条路径的真正分歧不在第二行（AI 怎么回应），而在第三行（memory 有没有真的改）。第二行很容易做得”看起来很好”——AI 道歉、解释、承诺。但如果第三行没动，第四行就一定会再次出错。

合格的处理是：道歉 → 定位相关记忆 → 修改或删除 → 告知改动 → 后续生效。

3. 用户删除一条记忆后，系统能不能重新学回来？

不能，但很多 memory 系统会踩这个坑。

如果你的系统会周期性从历史对话里重新抽取记忆，那么用户今天删除的一条记忆，下周可能又被系统学回来——因为原始对话还在，抽取器看到它，又一次提取出来。

对用户来说，T4 的左侧分支是相当严重的失控感。

在用户眼里，”我删掉了”就意味着”你不应该再记得”。如果一条被删除的记忆又重新出现，用户感受到的不是”系统智能”，而是”系统不听话”。

解决方案是维护一个 tombstone（否定列表）：

用户主动删除过的内容，要被标记为”不应再次抽取”。抽取器在处理历史对话时，需要先比对 tombstone，命中就跳过。即使原始对话还在，被 tombstoned 的事实也不能再被写入 memory。

这个机制看起来像工程细节，但本质上是一个产品承诺：用户控制权要在系统行为里真正生效，而不是在 UI 上表演一次然后消失。

4. 用户给出的新信息和已有记忆冲突时，怎么处理？

记忆一定会冲突。用户上个月说”我喜欢咖啡”，今天又说”我现在不喝咖啡了”。

模型推测”用户是金融从业者”，用户某天明确说”我其实是设计师”。

这些都被笼统地叫做”记忆冲突”。

但它们的产品含义完全不同——这是处理冲突时最容易踩的坑。大多数团队默认把冲突当成一个数据问题：两条信息打架，选一条留下。而真正合格的处理，需要先识别这是哪一种冲突。

这三种冲突里，只有第一种是真的需要”覆盖 vs 保留”取舍的冲突。其他本质上都不是冲突——它们看起来像冲突，是因为系统没有足够的元数据来区分。

真冲突要按时间性处理。 用户从”喜欢咖啡”变成”不喝咖啡了”，这不是矛盾，是状态变化。直接覆盖会丢失”用户过去喜欢”这个事实——下次用户说”我以前不是挺爱喝吗”，系统答不上来。保留两条等价又会让模型困惑。合理的做法是新记忆优先（默认召回它），旧记忆标为”过去状态”（必要时可追溯），并通过 updated_at 字段记录变化时间。

这里能不能做好，直接取决于第三章讲的元数据 schema。如果一条记忆只是一句文本，没有时间戳、没有状态字段，那”理解时间性”就是空话——系统只能在覆盖和保留之间二选一。

噪音冲突压根不该进长期 memory。 用户说”今天不想喝咖啡”和”我现在不喝咖啡了”是两件事。前者是当前情境，后者是状态更新。如果系统把”今天不想喝咖啡”也当成偏好写入并去覆盖已有记忆，那用户每次随口一说都会扰动长期画像。区分的方法第四章已经讲过：低置信、临时性表达，要么不写入，要么只进 session memory。

疑似冲突要按 confidence 处理。 模型推测的”金融从业”和用户明确说出的”设计师”，权重不能等价。明确陈述应该直接覆盖推测，并且不需要在历史里保留那条推测——因为它本来就不是事实。更重要的是，这种情况下应该回头看：抽取器为什么会把推测写成事实？这往往是写入策略需要修正的信号。

把三种冲突分清楚之后，会发现一个关键判断：

冲突处理的难度，取决于上游决策的颗粒度。

如果元数据足够（confidence、时间戳、状态），冲突几乎是自动化的——系统按规则处理，不需要每次都问用户。如果元数据不够，冲突就会反复出现，用户会觉得系统”忘性大”或”自相矛盾”。

六、Memory 的生命周期：冷启动、复利和规模化退化

Memory 的产品价值不是上线第一天就完整体现的。

它有一个很特殊的生命周期：早期很冷，中期开始复利，后期如果不治理会变乱。

有些产品低估 memory，是因为只看到了早期冷启动；有些产品高估 memory，是因为忽略了后期规模化退化。

1. 冷启动：前几次对话里，用户可能感受不到价值

memory 有一个天然尴尬期。

刚开始使用时，系统什么都不知道，用户也还没有建立足够多的历史。这时产品很难立刻呈现“越来越懂我”的感觉。

如果完全等待自然对话积累，用户可能在感受到 memory 价值之前就流失了。

所以产品需要考虑冷启动设计，常见以下两种：

建议最好：不要一上来问一堆问题，只问 2-3 个强决定性信息。

比如：你主要用我来做什么？你偏好简洁回答还是详细解释？你当前最重要的目标是什么？

其他信息，可以在后续对话中渐进式建立。

冷启动的目标不是一次性建立完整用户画像，而是让第一次体验不要太空。

2. 复利：memory 的价值通常是长周期出现的

Memory 的价值很像复利，这意味着，memory 很容易被短期评估低估。

如果一个团队只看上线后一两周的数据，很可能得出结论：“memory 对核心指标提升不明显。”

但这可能只是因为时间还不够。真正的 memory 价值，往往要进行长周期追踪。

3. 规模化退化：memory 多了以后，系统会开始变笨

当用户积累几十条记忆时，系统可能变得更懂用户。

Memory 不是越多越好，当用户积累几百甚至上千条记忆时，系统可能开始变笨。

原因很简单：召回噪音变多；过期信息变多；冲突信息变多；同义重复记忆变多；

模型看到太多不相关背景，反而更难判断重点，所以长期 memory 一定需要治理机制。

以下是常用的 6 种治理机制：

Memory 的长期问题，是记太多以后如何保持清爽、准确和克制。

七、怎么评估一个 Memory 系统是不是变好了？

有时产品汇报时会提到一个容易误导人的指标，记忆条目数。

但记忆条目数越多，不代表系统越好，很可能只是越记越乱。

Memory 的评估不能看“记了多少”，而要看“记得是否正确、是否有用、是否被用户接受”。

1. 为什么memory 很难用短期 A/B 测清楚？

既然memory 有冷启动期、复利期、退化期。这个生命周期决定了 memory 的评估有一个独特的难点：

短期看不到的东西，长期才会显形；长期才看得到的东西，短期一定会被低估。

如果团队只用通用的产品 A/B 框架来衡量 memory，几乎一定会得出错误结论。

常见的失败模式有两种：

第一种是”过早判死刑”。 团队上线 memory 两周，发现核心指标没有显著提升，决定下线或降低优先级。但这个时间窗口里，大多数用户还在冷启动期，系统积累的记忆条数还不够触发复利。这不是 memory 没价值，是评估时机错了。

第二种是”看不到隐性损害”。 团队只看短期点击率、留存率，忽略了写入质量、用户控制感、隐私边界这些长期才会反噬的指标。短期数据看起来很好，但用户的”被监视感”在累积，等到爆发为投诉或流失，已经回不去了。

所以 memory 的评估，必须分周期看：

短期看安全，中期看体验，长期看价值。 三个时间维度对应三组指标，不能混着看。

短期看不出价值，是 memory 的特性，不是 bug。但短期能看出的事情也很多——比如有没有写入用户没说过的信息、用户删了又被学回来、纠正之后没真改。这些都是会立刻出问题的事，不需要等长周期才能发现。

2. 那总不能等着吧，该看什么指标？

可以把 memory 系统拆成四层漏斗：

这四层对应不同问题。

写入差，说明系统不知道什么值得记；更新差，说明用户控制权没有真正生效；召回差，说明记忆存在但用不上；使用差，说明模型看到了记忆但没有自然正确地使用。

3. “AI 不记得我”的排障链路

用户说“AI 不记得我”，背后可能有很多原因。不要直接归因到“模型不行”，可以按顺序排查：

作为 PM，未必需要亲自解决技术问题，但要能快速判断大概是哪一层出了问题。

否则团队会陷入低效讨论：“模型不行。”、“检索不行。”、“用户表达不清。”、“这个 case 太边缘。”

真正要问的是：这条信息当初写进去了吗？写对了吗？召回了吗？模型看到了吗？用了没有？

把链路拆开，问题才有可能被修好。

4. Memory 的北极星不是“记得多”，而是“更少重复、更少纠错、更高信任”

一个好的 memory 系统，长期应该带来三类变化。

第一，用户重复表达减少。用户不需要每次都重新说自己的偏好、背景、目标和限制。

第二，用户纠错减少。AI 不再频繁误解用户，也不会反复使用过期或错误记忆。

第三，用户信任增加。用户知道系统记住了什么，也知道自己可以修改、删除和退出。

可以观察一些代理指标：

所以 memory 的评估要组合看，最重要的是，团队要先定义自己产品里的“懂我”到底是什么意思。

在写作助手里，懂我可能意味着更符合我的表达风格。

在教育产品里，懂我可能意味着知道我的薄弱点和学习节奏。

在陪伴产品里，懂我可能意味着记得我的关系、情绪和长期故事线。

不同产品的“懂我”不同，评估指标也应该不同。

最后、还可以看哪些产品和研究？

如果想进一步拆 memory，可以从两类对象入手：一类是产品形态，一类是系统 / 研究框架。

产品形态上，可以重点看三类：

系统和研究上，可以重点看：

这些案例的价值不在于直接照抄，而在于帮助我们看到：

memory 可以是用户级偏好；

memory 可以是项目级规则；

memory 可以是 agent 的长期状态；

memory 也可以是一套围绕写入、管理、读取、更新和删除的基础设施。

产品设计时最重要的是先判断：你的产品到底需要哪一类 memory。