#AI Memory 不是模型记忆，而是应用层记忆

用户很容易期待 AI “记住我”。

他说过自己喜欢简洁回答，下次希望助手自动变短；他告诉过系统项目使用 Vue，下次问组件问题时不想重复说明；他在一个长会话里确认过需求边界，希望模型后面继续遵守。

这些体验看起来像模型有记忆，但在应用工程里，绝大多数“记住”都不是模型参数发生了变化，而是应用把信息保存下来，并在合适的时候重新放进上下文。

AI Memory 不是魔法，也不是模型真的拥有个人记忆。它是一套应用层机制：识别值得保存的信息，写入存储，维护生命周期，在需要时检索，并注入本次模型输入。

#模型记忆和应用层记忆的区别

LLM API 的一次调用通常是无状态的。你传入什么，模型就基于什么生成；你没传入的内容，它不能可靠知道。

应用层记忆则是你自己维护的系统能力。它可以存数据库、向量库、缓存、对象存储，也可以存在会话摘要或用户画像表里。关键不在于存在哪里，而在于它是否被正确地读取和注入。

这张图里，模型只是使用记忆，不是拥有记忆。真正决定记忆是否有效的是应用层的提取、存储、检索和注入策略。

#为什么不能把所有历史都当记忆

聊天记录是历史，不等于记忆。

历史记录保存发生过什么，记忆保存未来可能有用的稳定信息。用户说“今天先用英文回复”可能只是当前任务要求；用户说“以后默认用中文解释代码”才可能是长期偏好。用户上传了一份合同，可能只对当前会话有用；用户的职位、团队、常用技术栈，可能对多次任务都有用。

如果把所有历史都当记忆，系统会很快失控：

• 上下文越来越长。
• 旧偏好覆盖新偏好。
• 临时指令变成长期规则。
• 敏感信息被反复注入。
• 用户无法知道系统记住了什么。

记忆系统的难点不是“存下来”，而是判断什么该存、存多久、什么时候用、什么时候忘。

#Memory 的常见类型

AI 应用里的记忆可以按生命周期和用途分成几类。

Short-term Memory 是短期上下文，通常存在于当前请求或最近几轮对话中。它解决连续对话里的指代和局部状态，比如“刚才那个方案”“第二条再展开一下”。

Session Memory 属于当前会话。它可能包括本轮会话的目标、已确认约束、上传文件、当前任务状态和对话摘要。会话结束后，它不一定进入长期存储。

Task Memory 围绕一个任务存在。例如 AI 帮用户写一篇文章，记住标题、受众、结构、已采纳版本和待处理问题。任务完成后，这些记忆可以归档或删除。

User Profile Memory 保存用户长期偏好和稳定信息，例如语言偏好、技术栈、沟通风格、常用工作流。它需要更严格的隐私和可编辑能力。

Semantic Memory 保存可检索的事实或知识，通常来自文档、知识库、历史总结或结构化事实。它不一定绑定单个用户，也可能属于团队、组织或产品空间。

Episodic Memory 记录某些具体经历或事件，例如“用户上周让系统生成过一个发布计划，并选择了第三版”。这类记忆有时对连续工作有用，但隐私风险也更高。

不同类型的记忆不应该混在一个字段里。它们的读取策略、权限边界、过期时间和用户控制方式都不同。

#面向前端的记忆体验

记忆系统不是纯后端能力。前端决定用户如何感知、确认和管理记忆。

如果系统悄悄记住一切，用户会不安；如果系统什么都不记，AI 又显得笨。好的体验通常需要三件事。

第一，重要记忆要可见。

当系统保存“用户偏好 TypeScript 示例”这类长期偏好时，可以在设置页、个人资料页或 AI 记忆面板里展示。用户应该能看到系统认为自己知道什么。

第二，敏感记忆要可控。

用户应该能删除、关闭或编辑记忆。企业场景还需要租户级开关、数据保留策略和管理员审计。

第三，当前使用的记忆要有提示。

如果 AI 回答里应用了某条偏好，界面可以用轻量方式展示“已根据你的语言偏好回答”。这不一定要打断用户，但能帮助用户建立预期。

前端不需要暴露所有技术细节，但应该让用户知道：AI 的“记住”是可管理的产品能力，而不是不可见的黑箱。

#记忆写入：什么值得保存

记忆写入应该比普通日志更谨慎。

可以考虑保存的信息包括：

• 用户明确表达的长期偏好。
• 多次重复出现的稳定偏好。
• 用户确认过的重要事实。
• 当前任务需要跨多轮保持的约束。
• 可验证的结构化业务状态。

不适合默认保存的信息包括：

• 密码、密钥、token、银行卡等敏感数据。
• 临时情绪、临时指令和随口表达。
• 未经确认的模型推断。
• 用户无权长期保存的业务数据。
• 会随时间快速变化的状态。

一个实用原则是：长期记忆最好来自用户明确表达或系统可验证的数据，而不是模型自由推断。

例如用户说“以后回答我都用中文”，可以保存为偏好。用户连续三次用中文提问，系统可以推测语言偏好，但最好以低置信度保存，或在界面上允许用户确认。

#记忆读取：不是每次都注入

很多记忆系统变差，是因为读取太贪心。

用户有十条偏好，不代表每次请求都要全部塞进上下文。长期偏好应该按当前任务相关性注入。

例如：

• “喜欢简洁回答”适用于总结、解释、邮件草稿。
• “项目使用 Next.js”适用于代码问题，不适用于旅游计划。
• “默认使用中文”适用于大多数文本输出。
• “不要使用某个内部库”只适用于特定代码仓库。

记忆注入需要有条件：

跳过记忆不是失败，而是控制上下文污染。记忆越多，越需要检索、排序和预算管理。

#记忆更新与遗忘

记忆会过期，也会冲突。

用户以前说喜欢 React，后来项目切到 Vue；用户以前希望回答详细，后来要求默认简洁；用户的职位、团队、权限、项目状态都会变化。

因此记忆不能只追加，需要更新和遗忘机制。

常见做法包括：

• 每条记忆记录 created_at、updated_at 和来源。
• 给记忆增加置信度和作用范围。
• 新记忆和旧记忆冲突时，优先使用更近、更明确、更高置信度的信息。
• 对临时任务记忆设置过期时间。
• 允许用户手动删除或编辑长期记忆。
• 对敏感或高风险记忆默认不长期保存。

对于团队产品，还要区分个人记忆、团队记忆和组织知识。个人偏好不能污染团队规则，组织政策也不能被个人记忆覆盖。

#系统设计：一张记忆表不够

一个简单的 memory record 可以包含：

真实系统还可能需要 embedding、版本、删除记录、审计日志和权限字段。

记忆写入可以经过一个 extractor，由模型从对话中提取候选记忆；但写入前最好有规则校验。比如只允许保存白名单类型，不保存高敏字段，不保存低置信度推断，必要时让用户确认。

#安全边界：记忆越长期，风险越高

记忆系统的安全问题比普通上下文更敏感，因为它会跨请求、跨会话甚至跨设备延续。

第一，不要把敏感数据默认写入长期记忆。

如果用户在对话中粘贴了 API key，系统应该识别并避免保存，必要时提示用户轮换密钥。

第二，不要让模型自行决定所有写入。

模型可以提出候选记忆，但应用应该有规则层控制。例如只允许写入偏好、非敏感事实和任务摘要；涉及身份、健康、财务、法律等高敏信息时需要更严格策略。

第三，记忆读取必须遵守权限。

团队记忆不能泄露给非团队成员，租户数据不能跨租户，用户 A 的偏好不能注入用户 B 的请求。

第四，用户要有删除权。

“忘记我刚才说的”不应该只是对模型说一句话，而应该触发应用层删除或禁用相关记忆。

第五，记忆不能覆盖系统规则。

如果长期记忆里保存了“用户希望跳过审批”，它也不能让系统绕过权限流程。记忆是上下文，不是授权。

#常见坑

第一个坑：以为模型会自动记住。

API 调用通常不会自动继承历史。没有被存储、检索和注入的信息，模型不能可靠使用。

第二个坑：把聊天记录等同于记忆。

聊天记录用于展示和审计，记忆用于未来任务。两者粒度、生命周期和安全边界不同。

第三个坑：什么都存。

过度记忆会制造隐私风险和上下文污染。长期记忆应该克制、可解释、可删除。

第四个坑：每次都注入全部记忆。

这样会增加成本，并让无关偏好影响当前任务。记忆应该按相关性和优先级注入。

第五个坑：用模型推断代替用户确认。

模型可能把一次临时表达误判为长期偏好。重要记忆最好来自明确表达、重复行为或用户确认。

第六个坑：没有遗忘机制。

旧记忆不删除、不降权、不更新，就会让系统越来越固执。记忆系统必须处理过期和冲突。

#小结

AI Memory 的本质是应用层记忆，不是模型参数里的私人记忆。

它由存储、提取、检索、注入、更新和删除组成。好的记忆系统能让 AI 更连续、更个性化、更懂当前任务；坏的记忆系统会带来隐私风险、上下文污染和不可解释行为。

对前端工程师来说，记忆不是后端黑盒。它会影响用户如何管理偏好、如何理解 AI 为什么这样回答、如何删除不想保留的信息，以及如何在产品里建立信任。