我如何设计一个面向真实业务的 AI 助手记忆系统

刚开始做 AI 助手的时候，我对“记忆”这件事的理解其实挺简单的：把用户以前说过的话存下来，后面需要的时候再拿出来，不就行了吗？

后来我越来越觉得，这种想法太像聊天产品了，不太像业务系统。

因为真实业务里的记忆，不是“存得越多越好”，而是“什么该记，什么不该记，什么时候该忘”。如果这些边界不清楚，所谓记忆系统最后很容易变成一个既脏又乱、还不太安全的历史聊天垃圾桶。

我最先修正的一点：记忆不是聊天记录备份

聊天记录当然有价值，但它不等于记忆。

很多对话其实是一次性的，比如用户临时问了一句某个数据、让系统帮忙总结一段内容、或者试探性问一个方案。这些上下文如果全都被长期保留，后面反而会污染判断。

所以我现在会先把“原始对话”和“整理记忆”分开看：

• 原始对话是过程数据，不一定长期保留。
• 记忆是系统从过程里提炼出来、后续确实可能复用的稳定信息。

这两者如果不拆开，记忆系统就会越来越重，而且越来越不可信。

我现在比较认可的记忆分层

如果是做一个面向真实业务的 AI 助手，我会把记忆至少分成三层。

1. 用户画像和长期偏好

这一层比较稳定，比如：

• 用户常用什么表达方式。
• 输出更偏简洁还是详细。
• 对某类任务有没有固定偏好。

这类信息适合长期存在，但也不能无脑写入。最好满足两个条件再存：

• 重复出现过，不是一时兴起。
• 对后续交互确实有帮助。

2. 业务事实和长期状态

这一层更接近“系统事实”，比如：

• 某个客户当前由谁跟进。
• 某个任务处于什么阶段。
• 某个项目最近有哪些明确决策。

这类记忆不能只依赖模型总结，最好有结构化来源，或者至少能被来源验证。否则模型哪怕只是总结偏了一点，后面都会把偏差继续传下去。

3. 短期工作记忆

这一层我反而觉得最重要。

因为很多任务不是一次完成的，而是跨几轮、跨几天推进。系统需要记住“这次任务正在做什么、做到哪一步、下一步卡在哪”。

这类记忆的特点不是长期，而是对当前任务强相关。所以它更像一个任务状态层，而不是传统意义上的用户画像。

我不太赞成“什么都存”

这个态度我现在挺明确的。

原因不是我不想让系统更聪明，而是记忆一旦写进去，后面就会持续影响模型判断。错的记忆比没有记忆更危险。

所以我会特别关注写入条件。

比如什么情况下我认为一条信息值得写入：

• 它不是临时噪音。
• 它未来复用概率高。
• 它能被验证或者至少被追溯。
• 它不会触碰不该长期保留的敏感信息。

如果做不到这些，我宁愿系统短期“记性差一点”，也不想让它带着一堆半真半假的东西长期工作。

记忆系统最难的，很多时候不是记，而是忘

这个我后面体会特别深。

因为业务是会变的。一个月前的偏好、负责人、规则和项目状态，今天可能就不成立了。如果系统只会累计，不会淘汰，它的回答只会越来越像拿旧世界解释新问题。

所以一个靠谱的记忆系统，我觉得至少要有：

• 过期机制。
• 覆盖机制。
• 人工修正入口。
• 来源和时间戳。

有了这些，系统才不会把“曾经是对的”误当成“永远都对”。

我会怎么处理安全和权限

这件事不能拖到最后才想。

因为业务助手一旦开始记东西，马上就会碰到权限边界。某个人对某条项目状态有访问权，不代表另一个人也应该看到。某些对话里提到的内部信息，甚至不应该被长期整理。

所以在我看来，记忆系统不是一个单纯的“增强智能”模块，它本身就是数据治理的一部分。

如果没有权限视角，所谓长期记忆最后很可能就是长期风险。

我现在更想做的，不是“最强记忆”，而是“可信记忆”

现在很多产品一提记忆，就容易往“越来越懂你”那个方向去讲。

但对真实业务来说，我反而更看重另外几件事：

• 它记住的是不是真的值得记。
• 它记住的东西能不能追溯来源。
• 它该忘的时候会不会忘。
• 它会不会把旧结论硬套到新场景。

如果这些问题解决不好，记忆只会让系统表面更像人，底层却更不可靠。

所以如果现在让我设计一个业务 AI 助手的记忆系统，我不会先想“怎么多存一点”，我会先想“怎么少而准地存”。至少在现阶段，我觉得这比追求一种无所不记的聪明感更重要。