不记得你的AI智能体，能力从根本上就受到了限制。每次对话都要从头开始：你必须再次介绍自己、重申偏好、重新说明正在推进的工作。这些摩擦会不断累积，信任也会随之下降。
这就是记忆问题。上下文窗口负责承载当前对话，而跨会话、跨天乃至跨月的长期记忆需要一套独立架构。实现起来也比看上去更难。
本文介绍真正用于生产环境的智能体记忆系统：它有哪些层次、如何选择存储方案、采用哪些检索模式，以及哪些权衡决定了记忆究竟能提供帮助，还是会制造幻觉。
“记忆”是什么
一种过于简单的理解是：记忆就是“模型能记住不同对话之间发生的事”。实际情况要复杂得多。认知科学会区分不同类型的记忆，AI智能体的记忆系统也适合采用类似的划分：
工作记忆。 当前对话，保存在上下文窗口中。对话结束后就会丢失，除非另行持久化。
情景记忆。 过去发生的具体事件，例如“上周二我们讨论了X”或“三个月前你决定了Y”。
语义记忆。 一般性事实，例如“你叫Alice”“你偏好简洁的回复”或“你的公司位于塔林”。
程序性记忆。 做事的方法，例如“用户要求安排会议时使用这个模板”或“客户属于X级别时遵循流程Y”。
不同类型的记忆承担不同功能。一套完整的智能体记忆系统需要覆盖所有这些类型。
记忆应该实现什么
在讨论架构之前，先明确目标：
连续性。 智能体能从上次中断的地方继续，不需要你每次会话都重新介绍自己。
个性化。 智能体无需提醒就能运用你的偏好，以你的风格写作、使用你的工具，并结合你的团队情况。
保留上下文。 过去对话中的决定会影响当前工作。智能体应该记得“我们上个月决定了X”。
积累技能。 智能体会学习并运用你的习惯。连续10次讨论Python编程后，它应该默认使用Python。
隐私与遗忘。 明确哪些内容会被记住、哪些不会，以及哪些内容会被删除。这既关系到用户信任，也关系到法律合规。
这些目标有时彼此冲突：连续性倾向于记住一切，隐私则倾向于什么都不记。架构需要妥善处理这些权衡。
架构
一种典型的分层架构如下：
┌─────────────────────────────────────┐
│ 工作记忆（上下文内） │ 当前对话
├─────────────────────────────────────┤
│ 会话记忆（近期） │ 最近N次对话
├─────────────────────────────────────┤
│ 情景记忆（长期） │ 过去的具体事件
├─────────────────────────────────────┤
│ 语义记忆（事实） │ 稳定的用户事实
├─────────────────────────────────────┤
│ 程序性记忆（偏好） │ 针对该用户的行为方式
└─────────────────────────────────────┘
每一层都有各自的存储、检索和衰减逻辑。
下面逐层说明。
第1层：工作记忆
上下文工程一文已经介绍过这一层，也就是上下文中的当前对话。对于多轮对话，可以采用分层上下文：近期轮次保留原文，较早的轮次则保留摘要。
会话结束时，系统会将信息移交给长期记忆：提取对话中的关键信息并加以存储。
第2层：会话记忆
近期会话——例如最近10次对话——以精简形式保留一定细节，供智能体在下一次会话中使用。
实现方式是为每次会话生成一份摘要，并连同时间戳和主题一起存储。用户回来后，智能体可以迅速了解近期进展。
{
"session_id": "abc-123",
"user_id": "alice",
"started": "2026-05-14T10:30:00Z",
"ended": "2026-05-14T10:45:00Z",
"topic": "为Acme Corp起草提案",
"summary": "完成了Acme提案第一版。决定以节省成本为切入点。Alice将审阅提案并于周五发送。",
"facts_learned": ["Acme是现有客户", "Alice的截止日期是周五"],
"open_items": ["Alice要在周四前审阅第一版"]
}
开始新会话时，可以自动加载最近3–5次会话的摘要，让智能体掌握近期动态。
这是最容易实现的跨会话记忆形式，实施简单，而且能立即产生价值。
第3层：情景记忆
情景记忆是值得长期保留的具体往事，包括决定、里程碑和重要对话。
当会话中出现值得记录的内容时，系统会将其提取出来，并连同丰富的元数据一起存储。
{
"event_id": "ev-456",
"user_id": "alice",
"date": "2026-04-22",
"type": "decision",
"description": "Alice决定将分析工作负载从Postgres迁移到ClickHouse，理由是查询性能更好。",
"context_summary": "此前进行了为期3周的评估，包括性能测试和成本分析。",
"related_topics": ["基础设施", "分析", "数据库"],
"importance": "high"
}
检索时，如果某段往事与当前对话相关，智能体就会取回对应的情景记忆。可以采用语义搜索（嵌入当前查询并查找匹配的情景记忆）、主题匹配，或时间条件查询（“上个月发生了什么？”）。
难点在于判断什么才算“值得记住的情景”。并非每次对话都值得长期保留。一种常见模式是在会话结束时，让LLM从对话中提取重要事件：存储决定、承诺和里程碑，忽略闲聊。
第4层：语义记忆
语义记忆是应该始终可用的稳定用户事实，例如“Alice是Acme的CEO。她偏好简洁的沟通方式。她在塔林时区工作。”
这类记忆的数量少于情景记忆，但检索频率更高，共同构成智能体对用户的认识。
可以用结构化档案来实现：
{
"user_id": "alice",
"profile": {
"name": "Alice Tamm",
"role": "Acme Corp的CEO",
"location": "爱沙尼亚塔林",
"timezone": "Europe/Tallinn",
"preferred_language": "英语",
"communication_style": "简洁、直接、不说套话",
"expertise_areas": ["产品战略", "市场进入策略"],
"tools_used": ["Notion", "Slack", "Linear"]
}
}
智能体了解到新事实时，就会更新这份档案。会话结束后，由LLM识别新出现的稳定事实并提出更新建议；这些建议可以自动合并，也可以进入审核队列。
关键在于，语义事实必须有足够把握，而且足够稳定。某次对话中随口说的一句“我可能会试试Python”，不应变成“Alice偏好Python”这样的语义事实。录入门槛应该更高。
可以采用基于置信度的方法：
- 只听到一次：视为候选事实，暂不存储。
- 听到两次或用户明确表达：以中等置信度存储。
- 用户明确确认或频繁提及：以高置信度存储。
这样可以防止智能体根据随口一说的内容“学到”错误事实。
第5层：程序性记忆
程序性记忆规定智能体应该如何服务这位用户，包括工作流、模板，以及执行特定操作时的偏好。
例如：
{
"user_id": "alice",
"procedural": {
"email_signature": "...",
"meeting_preferences": "始终提供3个备选时段，不安排上午9点前的会议",
"code_style": "使用Python，必须有类型提示，优先使用dataclass而非dict",
"tone_for_clients": "亲切、直接，并明确说明后续步骤",
"approval_process": "所有面向客户的沟通内容都必须经Alice审阅后才能发送"
}
}
遇到相关任务时，智能体会遵循这些模式。
更新可以来自明确指示（“Alice，请始终按这种方式做X”），也可以来自模式识别（连续5个相似请求都采用同一种处理方式后，将其记录为模式）。
存储方案
记忆应该存在哪里？
SQL数据库。 可靠、可查询，而且技术成熟。每种记忆类型使用一张表，通过联表查询完成检索，适合结构化访问模式。
向量数据库。 用于对情景记忆进行语义检索，例如“查找与这个主题有关的记忆”。先对情景记忆生成嵌入，再按相似度检索。
组合使用。 这通常是最佳选择：SQL负责结构化查询，向量数据库负责语义查询。记忆条目同时存入两者，并使用一致的ID。
专用记忆工具。 Mem0、Letta（原名MemGPT）和Zep都是专为智能体构建的记忆层。如果你需要更高层的抽象，值得考虑。
对大多数团队来说，简单的SQL加向量方案就够了。专用工具虽有帮助，但也会增加依赖。
检索模式
智能体如何把记忆放入上下文？
模式1：会话开始时自动加载
新会话开始时，自动读取：
- 用户的语义档案。
- 最近N次会话的摘要。
- 尚未完成的承诺或待跟进事项。
这构成了用户出现时智能体所拥有的基础上下文。
模式2：查询驱动的检索
当用户的消息涉及过去的主题时，检索相关的情景记忆。
例如，用户问“我们讨论数据库时得出了什么结论？”智能体就搜索与“数据库”有关的情景记忆，并取回相关条目。
实现方式是对用户消息生成嵌入，找出相似的情景记忆，再将其加入上下文。
模式3：显式记忆工具
智能体可以使用工具查询记忆：
search_episodes(query)：查找过去的具体事件。get_user_profile()：读取语义档案。list_open_items()：列出尚未完成的承诺。
智能体根据对话内容决定何时调用这些工具。
模式4：后台充实记忆
后台进程定期审查记忆，并执行以下操作：
- 将相关的情景记忆归并为主题。
- 更新事实的置信度。
- 让长期未被访问的旧记忆逐渐衰减。
这就是“记忆维护”——让记忆库随着时间推移仍然保持实用。
写入记忆
应该在什么时候写入记忆？
会话结束时提取
这是可靠的模式。会话结束时：
- LLM分析对话。
- 提取：
- 会话摘要。
- 重要事件（用于情景记忆）。
- 新事实（用于语义记忆）。
- 偏好信号（用于程序性记忆）。
- 更新并存储这些信息。
采用批处理可以保持会话期间的响应速度，因为对话过程中无需写入记忆。
用于提取的提示词：
分析这段对话，并输出包含以下字段的JSON：
1. summary：用2–3句话概括发生的事情。
2. notable_events：值得记住的重要事件数组（已做出的决定、里程碑、重要上下文）。
3. new_facts：从用户处了解到的稳定事实数组（只有高度确信时才纳入）。
4. preference_signals：观察到的偏好数组（只有明确表达或反复出现时才纳入）。
5. open_items：用户可能希望稍后继续处理的未解决事项数组。
务必保守。只纳入高度确信的内容。宁可遗漏，也不要凭空编造。
实时更新高价值事实
有些事实不能等到会话结束再处理。如果用户说“其实我叫Alex，不是Alice”，就应该立即应用这项更正。
一种模式是让智能体实时识别明确的纠正或重要新事实，并当场更新记忆。
这需要谨慎设计，因为LLM可能会“学到”错误事实。有些团队要求实时更新必须经用户确认后才能生效。
用户主动更新
用户可以明确告诉智能体要记住什么：
- “请记住，我偏好X。”
- “忘掉我说过的Y。”
- “以后始终做Z。”
这些指令应该成为系统的一等能力：立即执行，因为它们是置信度最高的信号。
智能体可以提供专门的工具：
remember(content: string, type: "fact" | "preference" | "procedure")
forget(content: string)
list_what_you_remember()
把这种控制权交给用户有助于建立信任。
遗忘与衰减
无限增长的记忆最终会变成噪声，因此衰减机制不可或缺。
基于时间的衰减
越旧的记忆，被检索到的可能性越低。实现方式包括：
- 按
relevance * recency_decay计算检索分数。 - 除非被明确提及，否则旧记忆实际上会逐渐淡出。
基于重要性的保留
重要情景保留得更久，琐碎内容衰减得更快。
- 写入情景记忆时标注重要性。
- 关键事件：无限期保留。
- 日常事件：在数月内逐渐衰减。
用户主动遗忘
用户可以要求删除特定记忆：
- 特定事实。
- 特定时间段。
- 特定主题。
实现方式是执行删除操作，移除相关条目或将其标记为已删除。
合规要求触发的删除
法律要求有时会强制删除数据，例如GDPR的被遗忘权和数据保留法规。
- 删除用户账户 → 删除全部记忆。
- 按请求删除数据 → 删除指定记忆。
- 保留期限 → N个月后自动删除。
这些能力必须从一开始就内置，事后补加会非常痛苦。
隐私考量
记忆数据十分敏感，因为智能体掌握了大量用户信息。需要考虑以下方面：
静态加密
对存储中的记忆数据进行加密，这是标准做法。
访问控制
谁能查看用户的记忆？只有用户本人、只有系统，还是支持人员可以在特定条件下查看？必须明确规定，并审计所有访问。
PII处理
个人身份信息（真实姓名、地址、财务信息）应该加以标记并谨慎处理，采用专门的访问控制和删除流程。
对用户可见
用户应该能够查看智能体记住了自己的哪些信息。这既符合伦理，也是良好的用户体验。可以提供一个“记忆面板”：
智能体记住了你的以下信息：
个人档案：
- 姓名：Alice Tamm
- 职务：Acme Corp的CEO
- 沟通风格：简洁、直接
近期会话：
- 2026-05-14：起草Acme提案
- 2026-05-12：审阅第一季度业绩
- ...
偏好：
- 偏好简洁的回复
- 使用Notion、Slack和Linear
[编辑] [删除指定条目] [全部删除]
这种透明度能够建立信任。暗中保存记忆会让人不安。
跨场景共享
如果用户有多种“模式”（例如工作智能体和个人智能体），可能希望各自的记忆彼此隔离。除非用户提出要求，否则不要在不同模式间自动共享记忆。
常见故障模式
常见问题包括：
故障1：虚构记忆
智能体声称记得从未发生过的事，例如“上周我们就X达成了一致”，但实际上从未讨论过X。
原因：LLM在提取或检索时“补全”了听起来合理的记忆。
解决方法：记忆操作必须以真实对话数据为依据。LLM负责提取，但应对照实际对话记录验证提取结果，并标记虚构的事实。
故障2：学到错误事实
智能体确信地陈述错误事实，例如“你说过你偏好Python”，而你其实说的是工作中不得不用Python。
原因：提取过程中产生误解。
解决方法：设置置信度阈值，只从明确、重复或经过确认的陈述中学习，并允许用户纠正。
故障3：隐私泄露
一个用户的记忆出现在另一个用户的对话中。这是灾难性问题。
原因：用户范围隔离逻辑存在缺陷。
解决方法：在存储层和检索层强制按用户隔离并进行审计，绝不能依赖LLM来过滤。
故障4：记忆膨胀
一年后，每名用户的记忆数据达到数MB，检索变慢，成本上升。
原因：没有衰减或清理机制。
解决方法：积极实施衰减。数月后，大部分记忆应因检索优先级降低而基本不可访问，并定期进行压缩整理。
故障5：事实过时
用户6个月前已经换了职位，智能体却仍在提及旧职位。
原因：旧事实被新事实取代时没有更新。
解决方法：检测矛盾。新事实与旧事实冲突时，以新事实为准；如果不能确定，则请用户确认。
故障6：归并后记忆失真
后台归并记忆时，偶尔会因为改写而丢失信息。
原因：摘要压缩过于激进，没有保留关键事实。
解决方法：归并时必须明确保留事实，并使用真实的记忆记录测试归并过程。
完整示例：具备记忆的个人助理
来看一个现实场景：面向个人用户的AI助理。
记忆层：
- 工作记忆： 当前对话。
- 会话记忆： 最近7次会话的摘要。
- 情景记忆： 最近100个重要事件，支持语义搜索。
- 语义记忆： 用户档案（姓名、职务、偏好、工具）。
- 程序性记忆： 用户明确设置的工作流。
存储：
- SQL（Postgres）：结构化档案、会话、情景和程序。
- 向量数据库（pgvector）：对情景记忆进行语义搜索。
操作：
- 会话开始：自动加载语义档案、最近3次会话和未完成事项。
- 会话期间：主题相关性达到条件时触发情景记忆检索。
- 会话结束：由LLM提取信息；用户可以审阅系统学到了什么。
- 后台任务：每周归并一次，将相关情景合并，并让过时内容衰减。
用户控制：
- 通过记忆面板查看系统记住的内容。
- 编辑或删除单个条目。
- “忘记最近一小时”按钮。
- 完整删除账户并清除全部数据。
效果：
- 连续性：用户表示，智能体在不同会话之间“像是同一个持续存在的助手”。
- 个性化：回复风格会自动匹配用户偏好，无需反复提示。
- 隐私：明确的控制机制让用户更有信心。
- 成本：记忆约占每次会话token用量的5%–15%，但物有所值。
已应对的故障模式：
- 提取时通过验证发现虚构记忆。
- 通过置信度阈值拦截错误事实。
- 在每个存储和检索环节强制执行隐私隔离。
- 通过衰减和归并控制记忆膨胀。
这是一套生产级记忆系统。它并不简单，但一个目标明确的团队完全有能力实现。
专用工具
下面简要介绍提供记忆即服务的方案：
Mem0。 开源且设计完善，覆盖了上述许多模式。如果你不想从头构建，值得考虑。
Letta（MemGPT）。 采用另一种范式：由LLM本身通过工具调用管理记忆。功能强大，但更复杂。
Zep。 托管式记忆层，易于集成。
Cognee。 较新的方案，以知识图谱为基础构建记忆。
这些工具可以节省开发时间，但也会增加依赖并限制定制。成熟的生产系统通常适合自建记忆；原型项目或小型团队使用现成工具也很合理。
要点总结
长期记忆让智能体显得聪明且有连续性，而不是每次都像失忆一样。这也是最难做好的能力之一。
整体架构分为以下层次：
- 工作记忆（上下文内）。
- 会话记忆（近期会话）。
- 情景记忆（具体事件）。
- 语义记忆（稳定事实）。
- 程序性记忆（偏好和工作流）。
每一层都有各自的存储、检索和衰减逻辑，也都能让智能体在长期使用中发挥更大价值。
真正重要的模式包括：
- 保守提取（不要虚构事实）。
- 基于置信度学习（不要把随口一说当成事实）。
- 主动遗忘（衰减和清理）。
- 用户控制（透明且可编辑）。
- 强制保护隐私（覆盖每一层）。
设计得当，记忆可以让AI从“每次对话都像初次见面的陌生人”，变成“持续陪伴且真正有用的伙伴”。这正是AI作为工具与AI作为同事之间的区别。
对于计划连续使用数日、数周乃至数月的智能体，记忆不是可选项，而是基础能力。应该有意识地构建它，并落实所需的分层设计和工程约束。
