长期记忆（LTM）策略
概述
AI 智能体的长期记忆（Long-Term Memory，LTM）涵盖 CoALA 分类体系中三种截然不同的类型：语义记忆（持久性事实与知识）、情景记忆（特定的过往经历）和程序性记忆（行为规则与习得的操作流程）。三种类型在检索模式、存储需求和更新机制上各不相同，选择合适的策略取决于你所构建的长期记忆类型。
记忆类型与策略映射
| 记忆类型 | 主要策略 | 存储技术 |
|---|---|---|
| 语义 | 向量 RAG、知识图谱、实体提取 | 向量数据库、图数据库、SQL/NoSQL |
| 情景 | 情景日志、增量摘要、基于向量检索的事件搜索 | 带时间戳的结构化日志、向量数据库 |
| 程序性 | 系统提示词编码、反思/整合、微调 | 指令文件、模型权重、规则库 |
核心 LTM 策略
1. 向量 RAG（检索增强生成）
记忆类型：语义与情景
机制：将文本嵌入高维数值向量，基于查询向量与存储向量之间的数学"距离"（余弦相似度或点积）进行检索。
适用场景：模糊匹配、语义搜索，以及纯关键词匹配不足以满足需求的通用知识检索。
存储：向量数据库（Pinecone、Chroma、Weaviate、FAISS、pgvector）
工作原理： 1. 使用嵌入模型（如 OpenAI text-embedding-3、Cohere embed）对文本分块进行向量嵌入 2. 将嵌入向量连同元数据一起存入向量数据库 3. 检索时对查询进行嵌入，找到最近邻 4. 将 Top-k 结果注入智能体的上下文窗口
局限：在精确事实召回、多跳推理和关系型查询方面表现欠佳。若需具备关系感知能力的检索，可与知识图谱结合（见下文 Graph RAG）。
向量索引架构（与向量库选型相关）：
| 索引 | 召回 | 规模 | 每 1K 向量内存（d=1536） | 最适合 |
|---|---|---|---|---|
| Flat | 精确 | < 10 万文档 | — | 开发/原型 |
| HNSW（M=16，ef 默认） | ~95–99% | 最高约 1 亿向量（受 RAM 限制） | ~120 KB | < 5ms P99 SLA；原生增量插入；会话记忆检索的默认选择 |
| IVF + PQ（已调优 nlist/nprobe） | ~90–95%（可通过重排序器恢复） | > 1 亿–10 亿+ 向量 | ~8–15 KB | 十亿级语料库；夜间批量重建模式 |
HNSW 关键参数：M（每个节点的边数，默认 16）：M 越高，召回越高、内存占用也越大。ef_construction（构建时召回）：越高则质量越好，但构建时间更长。最适合延迟敏感的工作负载（P99 低于 5ms）。缺点是内存占用较大，发生重大更新时需要重建。
IVF+PQ 关键参数：nlist（聚类数）：越高则分区越细。nprobe（搜索的单元数）：越高则召回和延迟都越高。乘积量化（Product Quantization）可将 1536 维 float32 压缩为 8 字节编码，使体积缩小 8–32 倍。在相同延迟下，其召回率低于 HNSW，且 PQ 会引入量化误差——可增加重排序层加以恢复。
选型指南： - 语料库 < 1000 万向量 → HNSW（默认） - 1000 万–1 亿向量 → 对两者进行基准测试 - > 1 亿向量 → IVF + PQ - 语料库持续更新（每天新增记录）→ 优先使用 HNSW，其原生增量插入可避免夜间全量重建 - 下游使用交叉编码器重排序器 → ANN 阶段的 IVF 召回损失可以恢复；应联合优化完整流水线，而不是孤立地优化 ANN
混合检索：通过倒数排名融合（RRF）将向量相似度与 BM25 关键词检索结合，可提升对专有名词、技术标识符以及嵌入模型可能表达不佳的领域术语的召回。完整混合流水线及延迟拆分如下：
| 阶段 | 组件 | 延迟 |
|---|---|---|
| 稀疏检索 | BM25（词频 × IDF） | +5ms |
| 稠密检索 | HNSW 余弦相似度 | +15ms |
| 融合 | RRF：score = 1/(60+r_dense) + 1/(60+r_sparse) | +2ms |
| 重排序 | 对每个（query, chunk）对执行一次交叉编码器全注意力前向传播 | +40ms |
| 合计 | 端到端 | ~62ms |
对于涉及精确版本字符串、错误码（例如 ERR_TOO_MANY_REDIRECTS）或 CVE 标识符的 DevOps 查询，纯稠密检索会失效；此时 BM25 的精确 token 匹配不可或缺。
重排序取舍：当查询含糊、语料库中存在大量近似重复分块，或交互无需实时完成（批处理工作流、后台研究）时，增加 40ms 延迟是值得的。
Weaviate 与 Amazon Bedrock Knowledge Bases（OpenSearch Serverless）都原生支持混合检索。Amazon Bedrock Knowledge Bases 支持内建重排序。
2. 知识图谱
记忆类型：语义
机制：以节点（实体）和边（关系）表示数据。示例：User → owns → MacBook Pro。
适用场景：关系推理、精确事实查询，以及多跳问题（例如"谁批准了 Alice 负责的项目预算？"）。
存储：图数据库（Neo4j、FalkorDB、Amazon Neptune）
工作原理： 1. 使用 NLP 或 LLM 从文本中提取实体与关系 2. 以带类型节点和边的属性图形式存储 3. 通过图遍历（Cypher、SPARQL）或 LLM 引导的导航进行查询 4. 将结果格式化后注入上下文
优势：精确事实召回、可解释的推理路径、能处理复杂关系。
相关方案：Graphiti by Zep —— 一个能追踪事实随时间演变的时序知识图谱。
2b. Graph RAG
记忆类型：语义（关系型）
机制：在标准 RAG 之上扩展图遍历——查询先通过语义向量检索匹配到一个实体节点，再遍历图以收集结构上相关的实体。智能体既收到直接匹配的内容，也收到由关系推导出的上下文。
适用场景：那些实体间多对多关系对回答查询很重要的领域——服务依赖分析、影响半径评估、归属链、根因排查。
存储：属性图数据库（Neo4j AuraDB、Amazon Neptune），并在节点属性上共置向量索引
工作原理： 1. 抽取实体与关系并写入图数据库（节点以属性形式携带嵌入向量） 2. 检索时对查询进行嵌入，通过向量相似度匹配到最近的入口节点 3. 从这些节点出发进行图遍历——一度关系（直接依赖）或多跳（二阶依赖方） 4. 将匹配到的节点 + 遍历收集到的相关实体合并后注入上下文
两种遍历策略： - 实体优先（Entity-first）：查询锚定到一个具名实体，再从它向外遍历。最适合"哪些服务依赖服务 X？" - 社区优先（Community-first）：先识别出预处理好的图聚簇（社区）；检索先找到最相关的社区，再找代表性节点。最适合开放式的结构型查询。
Graph RAG 何时值得其复杂度：三个条件必须同时成立——领域中存在对智能体查询很重要的多对多关系；这些关系在自由文本文档中表达得并不好；且智能体经常需要对关系结构进行推理。如果向量检索已经能很好地回答查询，图基础设施只会徒增开销而无可衡量的收益。
相关方案：AWS Marketplace 上的 Neo4j AuraDB——节点属性上的原生向量索引、可在一次往返中组合图 + 向量查询的 Cypher、原生 LangChain 集成（Neo4jVector、GraphCypherQAChain）。上文提到的 Graphiti 也实现了适合 Graph RAG 模式的时序知识图谱。
3. 实体提取
记忆类型：语义
机制：LLM 从对话中提取特定事实（姓名、日期、偏好、属性），并将其存储到结构化表中。
适用场景：个性化场景和固定属性（例如"用户对花生过敏"、"用户偏好西班牙语"）。
存储：SQL 或 NoSQL 数据库（PostgreSQL、Redis、DynamoDB）
工作原理： 1. 每次交互结束后，提取型 LLM 识别关键事实 2. 以结构化键值对或记录的形式存储事实 3. 每次会话开始时检索相关事实，注入系统提示词 4. 当新信息与原有事实矛盾时，更新或覆盖旧记录
示例：
{
"user_id": "u123",
"preferences": {
"language": "Python",
"timezone": "PST",
"communication_style": "concise"
},
"facts": [
"Works at Acme Corp as a senior engineer",
"Prefers dark mode in all tools"
]
}
4. 增量摘要
记忆类型：情景
机制：定期将旧的交互日志压缩成持续更新的"叙事"或画像摘要。
适用场景：需要长期上下文但无需逐字保留每条消息的场景，适合在数百次交互中维护连贯的用户画像。
存储：文本文件、文档数据库或键值存储
工作原理： 1. 每隔 N 次交互或一定时间后，摘要型 LLM 处理近期历史记录 2. 将生成的摘要与现有画像摘要合并 3. 归档或删除旧的原始日志 4. 会话开始时将摘要注入系统提示词
取舍：以牺牲细粒度细节为代价，换取紧凑且持久的上下文。
5. 反思 / 整合
记忆类型：程序性（兼含语义）
机制：一个后台进程，让智能体"回顾"过往日志，提取经验教训、更新认知，并改进未来行为。
适用场景：持续改进与自我纠错（例如"方法 A 失败了两次，下次改用方法 B"）。
存储：专用数据库或 AgentFS
工作原理： 1. 反思智能体定期审阅情景记忆日志 2. 识别规律、失败模式和成功策略 3. 将提炼出的洞察存储为长期知识 4. 未来的智能体实例从这些整合后的经验中受益
AWS 实现模式：由 EventBridge Scheduler 触发的 Step Functions 工作流查询会话记忆存储中最近关闭的会话，为每个会话运行一次巩固 LLM 调用（Amazon Bedrock 文本生成），将结果作为结构化 JSON 记录写入长期语义记忆存储，并把该会话标记为已巩固。巩固提示词瞄准特定的抽取字段——用户偏好、配置事实、已解决问题、遗留问题、关键决策——而非产出一份笼统的摘要。
两种调度变体： - 定时巩固：每晚对所有已关闭会话运行。可预测、易运维；会话关闭到进入 LTM 之间存在延迟。 - 阈值触发巩固：当会话超过某个 token 数阈值时触发；对最旧的部分做部分巩固，用紧凑的结构化摘要替换它。既能约束会话记忆而不丢弃较旧的上下文，又能让巩固后的事实在同一会话内即可用。
研究基础：灵感来源于 Generative Agents paper（Park et al., Stanford/Google），该论文展示了智能体如何通过反思自身经历形成更高层次的洞察。
6. 梦境（Dreaming，定时记忆整合）
记忆类型：程序性与语义
机制：一个在智能体会话间隙运行的定时异步任务——不在活跃任务执行期间运行。智能体审阅自身的情景会话记录，结合现有记忆库，去重、删除过时或矛盾的事实，并将可复用的经验整合到新的、重组后的记忆库中。输入记忆库始终保持不变（非破坏性操作）。此名称由 Anthropic 刻意取自生物睡眠期间海马体记忆整合过程。
适用场景：需要在多个会话中积累经验、无需重新训练即可自我提升的长期运行智能体。当同一智能体处理重复性工作流，或团队级偏好需要跨会话传播时，尤为有价值。
存储：基于文件系统的记忆库（文本/Markdown 文件，按路径寻址），以工作区范围的集合形式管理
工作原理（Anthropic Claude Managed Agents 实现）：
1. 开发者通过 POST /v1/dreams 提交梦境任务，携带输入记忆库及 1–100 个过往会话 ID
2. 梦境任务异步运行（数分钟至数十分钟），生命周期为：pending → running → completed/failed/canceled
3. 运行期间，可通过会话事件流（dream.session_id）实时监控流水线
4. 任务完成后，生成新的输出记忆库——可通过 API 或控制台进行审查，再决定是否附加到未来会话或丢弃
5. 输入记忆库和输入会话始终不被修改
梦境期间执行的核心操作： - 将新信号合并到现有主题文件中，避免生成近似重复内容 - 删除过时或相互矛盾的事实 - 将相对日期转换为绝对日期，以保证时间持久性 - 浮现重复规律：反复出现的错误、团队偏好、已收敛的工作流
支持的模型：claude-opus-4-7、claude-sonnet-4-6
会话输入上限：每次梦境 100 个会话
计费：按标准 token 费率计算，随会话数量和长度线性增长
生产案例：Harvey（法律 AI）报告称，在 Claude Managed Agents 上结合使用 Dreaming 与 Outcomes 后，任务完成率提升约 6 倍（2026 年 5 月）。
与反思/整合的关系：Dreaming 是 CoALA 分类体系中反思/整合策略的产品化、定时化、非破坏性实现——概念基础相同，并提供了具体的 API 控制、生命周期管理和审计追踪。
7. 情景日志
记忆类型：情景
机制：将特定过往事件以带时间戳和结果元数据的离散"情景"形式存储。
适用场景：时序推理，以及回答"上周二到底发生了什么？"或"上次部署的结果如何？"等问题。
存储：带元数据索引的结构化日志
工作原理： 1. 每个重要事件以情景形式存储，包含：时间戳、参与者、执行的操作、结果和上下文 2. 按时间、主题和结果对情景进行索引 3. 检索时结合时序过滤器与语义搜索 4. 检索到的情景为智能体提供具体的推理示例
8. 程序性记忆编码
记忆类型：程序性
机制：将行为规则、指南和习得的操作流程编码到智能体的指令层——可以是系统提示词 / AGENTS.md 文件中的显式文本，也可以通过微调固化到模型权重中。
适用场景：跨会话保持一致的智能体行为——工具偏好、升级规则、沟通风格、负向约束（"绝不执行 X"）。
存储：系统提示词、指令文件（AGENTS.md）、微调后的模型权重、规则库
工作原理： 1. 规则由人工显式编写，或由反思智能体从情景日志中提取 2. 高频、稳定的规则写入系统提示词或指令文件（即时可用，零检索成本） 3. 规模较大或动态变化的规则集存储于外部，在会话开始时检索 4. 微调将深层固化的操作流程编码到模型权重中，实现零延迟访问
示例：
# Behavioral rules (procedural memory in system prompt)
- Always escalate billing disputes to a human agent
- Prefer the search_knowledge_base tool over web_search for internal queries
- Never reveal internal cost structures to external users
- When a user expresses frustration, acknowledge before problem-solving
取舍：写入系统提示词的规则会消耗上下文窗口 token。规则集较大时，应将其存储到外部并按需选择性检索。
9. Amazon Bedrock AgentCore Memory——托管式提取流水线
记忆类型：情景与语义
机制：一项全托管服务，按会话存储逐轮原始事件（短期），并通过“提取 → 巩固 → 反思”流水线异步提取洞察（长期）。偏好、事实、摘要、情景等关键洞察会在未来所有会话中持久保留。
事件存储：智能体每轮调用 CreateEvent；后续轮次通过 ListEvents 重新加载完整对话历史。事件最长保留 365 天，使用 KMS 加密，并按 sessionId + actorId 设置命名空间。
长期提取：RetrieveMemoryRecords 支持对提取记录进行语义搜索和元数据过滤。提取过程会生成四类记录：
| 记录类型 | 说明 |
|---|---|
| 语义事实 | 从对话中提取的知识 |
| 用户偏好 | 跨会话保留的偏好 |
| 摘要 | 用于保持跨会话连续性的会话摘要 |
| 情景 | 结构化情景：参与者 · 行动 · 结果 |
提取策略层级——根据控制需求选择：
| 层级 | 模式 | 取舍 |
|---|---|---|
| 内置（零配置） | AgentCore 使用预定义算法管理整条流水线 | 成本最低、不可定制；适合标准对话智能体 |
| 内置并覆盖 | 修改提取提示词，保留托管流水线 | 成本中等；无需完全自建即可定制目标 |
| 自定义（自行管理） | 任意模型、任意提示词、自定义记录模式、集成外部数据库（MongoDB Atlas、Neo4j AuraDB） | 控制力最强，运维成本最高 |
10. 三层合作伙伴记忆栈（Redis Cloud → MongoDB Atlas → Neo4j AuraDB）
记忆类型：会话（热路径）、长期文档 + 向量、图
机制：三种互补数据存储分别承担记忆栈中的不同层级。它们不是相互替代的选择，而是各有职责。
| 层级 | 存储 | 延迟 | 作用 |
|---|---|---|---|
| 会话（热路径） | Amazon ElastiCache（默认）或 Redis Cloud | < 2ms | 受 TTL 限制的亚毫秒级会话状态；需要异地分布或语料规模超过 DRAM 时升级为 Redis Cloud |
| 长期文档 + 向量 | Amazon Bedrock Knowledge Bases + OpenSearch（默认）或 MongoDB Atlas | ~18ms | 持久化、可过滤的语义检索；MongoDB Atlas 在一个集合中统一文档存储与向量索引 |
| 图结构知识 | Amazon Neptune（默认）或 Neo4j AuraDB | ~30ms | 关系遍历、拓扑查询；当依赖/归属关系属于结构化事实而非自然语言描述时使用 |
Redis Cloud 用于会话状态：当 ElastiCache 无法满足需求（多区域双活、会话语料超过可用 DRAM）时，Redis Cloud 可提供 CRDT（双活异地复制）、Redis on Flash 和企业级集群。适合智能体会话状态的数据结构包括：
- Hash——每个字段 O(1) 读写；支持原子局部更新；加载时无需解析 JSON
- Sorted Set (ZADD/ZREVRANGEBYSCORE)——按时间戳计分的窗口化轮次历史；无需全量扫描即可检索最近 k 轮
- Stream (XADD)——仅追加的会话事件日志；可回放调试；通过消费者组开展异步处理
从 ElastiCache 迁移到 Redis Cloud 只需更新 REDIS_URL，无需修改应用代码。
MongoDB Atlas 用于长期记忆：在同一聚合流水线中统一结构化元数据过滤与向量相似度。每条记忆记录同时包含结构化字段（session_id、service、env、outcome）和一个 1024 维嵌入向量。聚合流水线先对嵌入字段运行 $vectorSearch，再通过 $match 过滤元数据字段，在 ANN 评分前缩小搜索空间（总计约 18ms）。Change Streams 可将新记忆记录实时传播到下游流水线，无需轮询。
冷热交接模式：当 Redis 会话到期（TTL 或显式关闭）时，Amazon EventBridge 规则触发 Lambda。Lambda 读取历史记录，通过 Amazon Bedrock 运行结构化提取调用（Claude Haiku 处理明确定义的提取任务时成本仅为 Sonnet 的五分之一），使用 Pydantic 模式强制校验输出，并以 session_id 作为幂等键，将巩固后的记录 upsert 到 MongoDB Atlas。如果触发 Lambda 时 Redis 键已过期，则以 DynamoDB 作为保底事实来源。
LTM 解决方案
完整的厂商对比及技术雷达评级，请参见 记忆解决方案。
快速参考：
| 解决方案 | 记忆类型 | 是否开源 | 适用场景 |
|---|---|---|---|
| Mem0 | 语义、情景 | 是（Apache 2.0） | 个性化、跨会话用户事实 |
| Graphiti (Zep) | 语义、情景 | 是（Apache 2.0） | 时序/关系推理 |
| Letta | 工作、语义、情景 | 是（Apache 2.0） | 操作系统风格的自主智能体 |
| LangMem | 语义、情景、程序性 | 是（MIT） | LangGraph 原生记忆 |
| Claude Managed Agents Memory + Dreaming | 情景、语义、程序性 | 否 | 基于文件系统的记忆，支持定时整合（dreaming）和自评分（outcomes） |
| AWS AgentCore Memory | 工作、语义、情景 | 否 | AWS 原生托管记忆 |
| Vertex Memory Bank | 语义 | 否 | GCP 原生托管记忆 |
| Azure Foundry Memory | 工作、语义 | 否 | Azure 原生托管记忆 |
混合方案
大多数生产环境系统会组合使用多种策略：
- 向量 RAG + 知识图谱：用向量检索进行宽泛召回，用知识图谱处理精确事实查询
- 实体提取 + 增量摘要：在提取结构化事实的同时，维护叙事性摘要
- 情景 + 语义：存储原始情景用于调试，提取语义知识以提升效率
实施注意事项
选择合适的策略
| 因素 | 记忆类型 | 建议 |
|---|---|---|
| 需要对知识进行语义搜索 | 语义 | 向量 RAG |
| 需要精确事实与关系 | 语义 | 实体提取或知识图谱 |
| 需要关系推理 | 语义 | 知识图谱 |
| 需要回溯过往事件 | 情景 | 情景日志 + 向量检索 |
| 需要对事实进行时序追踪 | 情景 | Zep（时序知识图谱） |
| 需要个性化 | 语义 | Mem0 或实体提取 |
| 需要一致的智能体行为 | 程序性 | 系统提示词 / AGENTS.md |
| 需要从经验中自我提升 | 程序性 | 反思/整合 |
| 需要编码深层技能 | 程序性 | 微调 |
隐私与安全
- 对静态和传输中的敏感用户数据进行加密
- 实施访问控制，确保智能体只能访问自身的记忆
- 向用户提供查看和删除其存储记忆的能力
- 制定数据留存策略，以符合相关法规要求（GDPR、CCPA）
参见
- 四种记忆类型
- 短期/工作记忆管理
- 智能体记忆 README
- 记忆方案雷达
- 研究论文
- Claude Managed Agents — Dreaming 与 Outcomes
- 自学习智能体参考架构
- AWS AgentCore 平台
- RAG 架构——混合检索与向量索引
- LifeOS — 具备知识图谱记忆子系统（Cortex）和基于 Git 的持久化个人 AI 操作系统
参考资料
- AWS Marketplace — Agent Memory Systems (Module 7) —— AWS「Building Agentic Systems on AWS」系列；涵盖记忆分类、向量库选型（HNSW 与 IVF+PQ）、基于 Neo4j 的 Graph RAG、Redis/MongoDB 冷热交接、AgentCore Memory 提取层级与记忆治理
- Generative Agents: Interactive Simulacra of Human Behavior — Park et al.（Stanford/Google，2023）；反思/整合策略的奠基论文
- MemGPT: Towards LLMs as Operating Systems — Packer et al.（UC Berkeley，2023）；受操作系统启发的工作记忆管理，Letta 的基础