没有跨会话持久化能力的智能体，每次都只能从当前提供的上下文开始。持久化可以减少重复说明，但也会带来隐私、准确性、隔离和删除方面的责任。
这就是记忆问题。上下文窗口负责承载当前对话，而跨会话、跨天乃至跨月的长期记忆需要一套独立架构。实现起来也比看上去更难。
本文提供了一个用于测试的参考设计，而非经过认证的实现。产品团队必须在其自身的系统中验证访问控制、更正、保留、删除、恢复和检索质量。
“记忆”是什么
一种过于简单的理解是：记忆就是“模型能记住不同对话之间发生的事”。实际情况要复杂得多。认知科学会区分不同类型的记忆，AI智能体的记忆系统也适合采用类似的划分：
工作记忆。 当前对话，保存在上下文窗口中。对话结束后就会丢失，除非另行持久化。
情景记忆。 过去发生的具体事件，例如“上周二我们讨论了X”或“三个月前你决定了Y”。
语义记忆。 一般性事实，例如“你叫Alice”“你偏好简洁的回复”或“你的公司位于塔林”。
程序性记忆。 做事的方法，例如“用户要求安排会议时使用这个模板”或“客户属于X级别时遵循流程Y”。
不同类型的记忆各有不同作用。仅使用产品可以合理说明并操作的记忆层级；存储更多并不一定更好。
记忆应该实现什么
在讨论架构之前，先明确目标：
连续性。 智能体能从上次中断的地方继续，不需要你每次会话都重新介绍自己。
个性化。 智能体无需提醒就能运用你的偏好，以你的风格写作、使用你的工具，并结合你的团队情况。
保留上下文。 过去对话中的决定会影响当前工作。智能体应该记得“我们上个月决定了X”。
已确认的偏好重用。 系统可以在其有效范围内重新应用明确或已验证的偏好。重复本身并不能证明某个工具、语言或行为应成为默认选项。
隐私与遗忘。 明确哪些内容会被记住、哪些不会，以及哪些内容会被删除。这既关系到用户信任，也关系到法律合规。
这些目标可能会发生冲突。连续性可能需要选择性持久性，而隐私和准确性则倾向于最小化、目的限制、更正和删除。架构必须明确做出这些权衡。
架构
一种典型的分层架构如下：
┌─────────────────────────────────────┐
│ 工作记忆（上下文内） │ 当前对话
├─────────────────────────────────────┤
│ 会话记忆（近期） │ 最近N次对话
├─────────────────────────────────────┤
│ 情景记忆（长期） │ 过去的具体事件
├─────────────────────────────────────┤
│ 语义记忆（事实） │ 稳定的用户事实
├─────────────────────────────────────┤
│ 程序性记忆（偏好） │ 针对该用户的行为方式
└─────────────────────────────────────┘
每一层都需要明确的存储、检索、访问、来源、更正、保留和删除行为；多个逻辑层可能共享一个物理存储。
下面逐层说明。
第1层：工作记忆
上下文工程一文已经介绍过这一层，也就是上下文中的当前对话。对于多轮对话，可以采用分层上下文：近期轮次保留原文，较早的轮次则保留摘要。
长期记忆的交接可能发生在显式检查点、持久事件或会话结束时。由于会话可能突然结束，因此仅应持久化经过批准的候选内容，并使写入状态可观察，而不是假设会话结束时的钩子始终运行。
第2层：会话记忆
当产品有正当理由时，近期会话的摘要可以以有限的详细程度保留。例如，最近的十次对话是一个说明性策略输入，而非默认设置。
实现方式是为每次会话生成一份摘要，并连同时间戳和主题一起存储。用户回来后，智能体可以迅速了解近期进展。
{
"session_id": "abc-123",
"user_id": "alice",
"started": "2026-05-14T10:30:00Z",
"ended": "2026-05-14T10:45:00Z",
"topic": "Drafting proposal for Acme Corp",
"summary": "Drafted v1 of the Acme proposal. Decided to lead with the cost-savings angle. Alice will review and send Friday.",
"facts_learned": ["Acme is a current customer", "Alice's deadline is Friday"],
"open_items": ["Alice to review v1 by Thursday"]
}
在新会话中，经过检索质量、相关性、令牌预算和隐私测试后，可以加载经过授权的近期摘要子集。默认情况下，不应自动将固定数量的内容加载到每个上下文中。
这是跨会话记忆的一种相对简单的形式，但仍需要隔离、来源、纠正、生命周期和检索测试。
第3层：情景记忆
情景记忆是值得长期保留的具体往事，包括决定、里程碑和重要对话。
当会话中出现值得记录的内容时，系统会将其提取出来，并连同丰富的元数据一起存储。
{
"event_id": "ev-456",
"user_id": "alice",
"date": "2026-04-22",
"type": "decision",
"description": "Alice decided to migrate from Postgres to ClickHouse for the analytics workload, citing query performance.",
"context_summary": "After 3 weeks of evaluation including performance tests and cost analysis.",
"related_topics": ["infrastructure", "analytics", "database"],
"importance": "high"
}
检索时，如果某段往事与当前对话相关，智能体就会取回对应的情景记忆。可以采用语义搜索（嵌入当前查询并查找匹配的情景记忆）、主题匹配，或时间条件查询（“上个月发生了什么？”）。
挑战在于决定哪些事件值得记忆。一个候选模式是模型在批准的检查点提出决策、承诺或里程碑，并附带来源片段和确认规则。模型生成的重要性标签并不构成持久化个人数据的权威依据。
第4层：语义记忆
语义记忆是应该始终可用的稳定用户事实，例如“Alice是Acme的CEO。她偏好简洁的沟通方式。她在塔林时区工作。”
这类记忆的数量少于情景记忆，但检索频率更高，共同构成智能体对用户的认识。
可以用结构化档案来实现：
{
"user_id": "alice",
"profile": {
"name": "Alice Tamm",
"role": "CEO at Acme Corp",
"location": "Tallinn, Estonia",
"timezone": "Europe/Tallinn",
"preferred_language": "English",
"communication_style": "concise, direct, no preamble",
"expertise_areas": ["product strategy", "go-to-market"],
"tools_used": ["Notion", "Slack", "Linear"]
}
}
智能体了解到新事实时，就会更新这份档案。会话结束后，由LLM识别新出现的稳定事实并提出更新建议；这些建议可以自动合并，也可以进入审核队列。
关键在于，语义事实必须有足够把握，而且足够稳定。某次对话中随口说的一句“我可能会试试Python”，不应变成“Alice偏好Python”这样的语义事实。录入门槛应该更高。
一个纯粹说明性的置信度工作流程，仍需要来源和校准：
- 推断一次：仅作为候选，包含来源片段，但不具有自动行为效果。
- 明确声明：适用于声明的范围；在后续重要复用前需确认。
- 明确确认：存储时包含来源信息、适用范围、审核日期和用户控制。
这样可以防止智能体根据随口一说的内容“学到”错误事实。
第5层：程序性记忆
程序性记忆规定智能体应该如何服务这位用户，包括工作流、模板，以及执行特定操作时的偏好。
例如：
{
"user_id": "alice",
"procedural": {
"email_signature": "...",
"meeting_preferences": "always offer 3 time slots, never schedule before 9am",
"code_style": "Python, type hints required, dataclasses over dicts",
"tone_for_clients": "warm, direct, with explicit next steps",
"approval_process": "all customer-facing communications need Alice's review before sending"
}
}
遇到相关任务时，智能体会遵循这些模式。
更新可能始于明确指令或重复模式。重复行为可能触发确认请求，但不应静默创建持久化流程。
存储方案
记忆应该存在哪里？
SQL数据库。 可靠、可查询，而且技术成熟。每种记忆类型使用一张表，通过联表查询完成检索，适合结构化访问模式。
向量数据库。 用于对情景记忆进行语义检索，例如“查找与这个主题有关的记忆”。先对情景记忆生成嵌入，再按相似度检索。
组合方案。 当需要同时进行结构化访问和语义检索时，SQL 加上向量索引是一个候选方案。重复表示会增加同步和删除的义务，因此应与更简单的存储方案进行基准测试。
专用记忆工具。 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计算检索分数。 - 除非被明确提及，否则旧记忆实际上会逐渐淡出。
基于重要性的保留
重要情景保留得更久，琐碎内容衰减得更快。
- 在写入时对事件进行重要性标记。
- 高价值事件：设定特定用途的保留期限，指定负责人和复审日期；不要默认采用无限期保留。
- 常规事件：在数月内逐渐衰减。
用户主动遗忘
用户可以要求删除特定记忆：
- 特定事实。
- 特定时间段。
- 特定主题。
实现方式：删除工作流应删除原始记录以及所有衍生的片段、嵌入、摘要、索引、缓存、导出和排队任务。墓碑标记可能防止重新摄入，但仅仅隐藏记录并不等于删除。应定义备份的过期方式，并测试删除数据在恢复后是否不会重新出现。
合规要求触发的删除
法律要求可能规定必须删除或保留数据。《通用数据保护条例》第17条定义了删除权并规定了例外情况；法律顾问应将该条款及其他适用规则映射到产品、司法管辖区和数据角色上。
- 用户账户删除请求 → 在所有适用的存储系统中启动已经审核的删除或限制处理流程，并披露例外情况或备份到期信息。
- 按请求删除数据 → 定位相关记录及其衍生数据，然后验证结果。
- 保留期限 → 根据批准的计划自动使相关记录过期。
这些能力必须从一开始就内置，事后补加会非常痛苦。
隐私考量
记忆数据十分敏感，因为智能体掌握了大量用户信息。需要考虑以下方面：
静态加密
对存储中的记忆数据进行加密，这是标准做法。
访问控制
谁能查看用户的记忆？只有用户本人、只有系统，还是支持人员可以在特定条件下查看？必须明确规定，并审计所有访问。
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提取信息；用户可以审阅系统学到了什么。
- 后台任务：每周归并一次，将相关情景合并，并让过时内容衰减。
用户控制：
- 记忆仪表板，显示已记住的内容。
- 编辑或删除单个条目。
- “忘记过去一小时”按钮。
- 完整账户删除工作流程，包含已验证的覆盖范围、记录的例外情况以及备份过期行为。
在将其称为成功之前所需的确凿证据：
- 在固定评估集上，使用和不使用检索记忆的任务完成情况，
- 存储事实和检索记忆的精确性，包括矛盾处理，
- 跨租户和跨用户的隔离测试，
- 更正和删除是否会传播到记录、嵌入、缓存、导出和任务，以及备份是否会按期过期，
- 来自实际追踪的令牌、存储、延迟和操作成本，
- 用户理解与控制测试，而非假设的置信度。
已应对的故障模式：
- 幻觉记忆案例已包含在提取和检索测试中。
- 置信度评分已校准；它们本身并不能使一个事实成立。
- 在检索之前和展示之前均强制执行授权。
- 保留和巩固任务具有审计日志、故障处理和删除测试。
这是一个设计检查清单，而非生产就绪性的证明。生产状态需要实施证据和安全/隐私审查。
专用工具
下面简要介绍提供记忆即服务的方案：
Mem0。 一个开源的记忆层。请根据你的持久性、隔离性和删除需求，评估其当前的文档和代码。
Letta (MemGPT)。 一个以工具为导向的记忆设计。请审查其当前的文档和操作边界。
Zep。 一种托管的记忆和上下文服务。验证其当前的文档、数据边界和删除协议。
Cognee。 一种面向知识图谱的选项。在采用之前，验证其当前文档和代码库中的成熟度和适用性。
这些工具可能会减少实现工作，但会引入供应商、安全、迁移和数据生命周期的依赖。使用相同的验收测试将其与内部设计进行比较。
构建最小且有充分依据的记忆系统
长期记忆让智能体能够在会话之间保持连续，而不是每次都像失忆一样。这也是最难做好的能力之一。
整体架构分为以下层次：
- 工作记忆（上下文内）。
- 会话记忆（近期会话）。
- 情景记忆（具体事件）。
- 语义记忆（稳定事实）。
- 程序性记忆（偏好和工作流）。
每一层都有各自的存储、检索和衰减逻辑，也都能让智能体在长期使用中发挥更大价值。
真正重要的模式包括：
- 保守提取（不要虚构事实）。
- 基于置信度学习（不要把随口一说当成事实）。
- 主动遗忘（衰减和清理）。
- 用户控制（透明且可编辑）。
- 强制保护隐私（覆盖每一层）。
当它通过评估和生命周期测试后，记忆可以减少重复的简报，并使确认的偏好在会话之间可用。
对于需要跨会话连续性的智能体，持久化是一项明确的产品选择。只构建有充分用途依据的最小记忆系统，并纳入来源、授权、用户控制和经过测试的生命周期终止路径。
