跳转至

AI Agent Memory Systems

📊 Level ⭐⭐⭐⭐ | 16.1KB

来源：原文存档

How AI Agent Memory Works

Language models forget the moment they finish replying. Memory is everything the system around them does to make that not matter. This essay walks through the ideas one at a time, with something to touch in every section. Source: raw article | Review: value=8 confidence=7

核心要点

  • AI agent memory 是一个循环系统：接收消息 → 编码 → 检索相似记忆 → 组装 prompt → 生成响应 → 决定是否记住新信息
  • 四种记忆类型：Episodic（事件）、Semantic（事实）、Procedural（技能）、Working（当前工作区）
  • 向量检索是语义搜索的基础，通过 cosine similarity 找到最相关的记忆片段
  • 记忆 governance（PII 过滤、时间有效性、超额标记）是区分 demo 与生产系统的关键
  • Multi-agent memory 是权限拓扑问题，而非简单的存储扩展
  • 生产系统需要分离读写路径、背景 worker 处理慢操作、多租户隔离、延迟预算管理 → 原文存档

相关实体

主题导航

深度分析

记忆的本质是循环，而非存储

Cobanov 的核心论点是"Language models forget the moment they finish replying"——这一定义将记忆问题从"存储"重新框架为"循环"。传统开发者倾向于将 memory 理解为 database（一种持久化存储），但实际上 memory 是一个持续运转的处理管道：每个用户消息触发一次完整的检索-组装-生成-写入循环。 这一框架的重要推论是：记忆系统的性能不仅取决于存储层（vector DB 的查询速度），还取决于整个循环中每一个环节的效率——查询重写是否准确、embedding 模型是否适配领域、reranker 是否能平衡相关性与新鲜度。任何一个环节的瓶颈都会成为整个记忆系统的瓶颈。Memory is a lifecycle problem: write, age, supersede, redact, forget，而非简单的 CRUD 操作。

四种记忆类型的认知科学映射

Episodic / Semantic / Procedural / Working 的四分法直接借鉴自认知科学，每种类型对应不同的认知功能：

  • Episodic memory：时间有序的事件日志，回答"我们上次谈了什么"。检索策略以时间 recency 为主，但也可以按日期范围或主题查询。实现上，每轮对话结束后生成一个短摘要并写入 vector DB，下一轮对话时通过 embedding 相似度召回 top-3~5 条。
  • Semantic memory：结构化的事实和关系，回答"用户知道什么"。通常通过知识图谱实现，支持多跳推理（如"用户工作的公司位于哪个城市"）。图谱的边代表关系类型（works_at、lives_in、prefers），节点代表实体。
  • Procedural memory：学会的技能和工具使用，回答"agent 能做什么"。这决定了 agent 的工具调用模式和错误处理策略，而非关于用户的事实。实现上通常是 prompt 或 policy 文件中的规则集。
  • Working memory：当前的 scratchpad，回答"现在正在处理什么"。这决定了模型的"注意力焦点"，是唯一完全位于 in-prompt 的记忆类型。其容量受限于 context window 大小。 四者的协同工作机制是：访客走到博物馆 agent 说"Tell me more about that Refik piece you mentioned earlier"时，episodic 找到之前聊过 Refik 的记录 → semantic 从 catalog 拉取该作品的完整描述 → procedural 触发 artwork_detail 工具获取实时数据 → working 将所有检索结果和当前消息一并放入 context，LLM 在此基础上作答。四个 store 对用户是"无感"的，但每个 store 有不同的读写规则和检索策略。

向量检索的几何直觉与局限

Embedding 将文本映射到高维向量空间（通常 1536-3072 维），相似语义的内容在该空间中距离较近。Cosine similarity 是衡量相似度的标准方法，因为它对向量长度不敏感。HyDE（Hypothetical Document Embeddings）的核心洞察是：问题和答案往往是不同"形状"的——直接 embedding 问题可能找不到包含答案的文档，因为答案的表述方式与问题不同。HyDE 先让 LLM 生成一个假设性答案，再 embedding 那个答案，找到形状相似的文档。这一技巧在实践中能将检索召回率提升显著。 然而，embedding 模型的选择直接影响检索质量——通用 embedding 在垂直领域（如医疗、法律）可能表现不佳，需要 fine-tuned domain-specific embedding。此外，embedding 模型一旦更换，旧存储的所有向量都需要重新计算，这是一个被经常低估的运维成本。

读写分离与治理门

Memory governance 是将 demo 级记忆系统推向生产的关键。"Naive append"会导致 PII 泄露（credit card number 进入记忆存储）和矛盾（用户搬家后，新旧两个地址都存在，agent 不知道哪个是当前的）。"Naive overwrite"丢失时间上下文，无法回答"用户以前住在哪里"的问题。Governed 写入则维护了完整的时间线：标记旧事实为 superseded，保留用于时序推理，同时通过 PII filter 阻止敏感信息进入存储。 这一设计的实现要求是：写入路径必须经过一个 governance gate，该 gate 负责 PII 检测（正则或模型）、时间有效性标注（valid_from / valid_until）和矛盾检测（发现新事实与旧事实冲突时，标记旧事实为 superseded 而非删除）。读取路径则需要在组装 prompt 之前应用时间过滤器（如"只返回当前有效的事实"）。

Multi-agent Memory：权限拓扑而非存储扩展

当记忆从单个 agent 扩展到多个 agent 时，问题从"如何存储"变成"谁能看到什么"。Shared memory 不再是单一向量数据库，而是变成了一个权限图：Researcher agent 的研究笔记默认是 private（不需要广播到项目频道），Planner 的决策记录可能需要 shared（因为其他 agent 需要知道计划上下文），而用户偏好（如饮食禁忌）应该是 User-profile scoped（只对当前用户可见）。 六种失败模式揭示了 shared memory 的核心风险：Cross-user leakage（研究笔记中的用户偏好泄露给其他租户）、Over-sharing（过多共享导致噪声）、Poition propagation（错误信息通过共享记忆扩散）、Conflicting decisions（不同 agent 基于不同版本的记忆做出矛盾决策）、Stale playbook（共享的决策规则过时但未被更新）、Attribution loss（无法追溯某条记忆是谁在什么上下文中写入的）。

生产系统架构：读写路径分离与延迟预算

Reference architecture 将系统分为两条路径：Agent runtime 在 request path 上（必须低延迟），Memory service 作为 side-quest（允许异步处理）。背景 worker 负责慢操作：embedding 计算、摘要生成、re-embedding 过时记忆、decay 策略执行。这些操作如果放在 request path 上，会直接增加用户感知延迟。 Latency budget 分析显示 p95 目标 800ms 中，retrieval 占用约 495ms（Query rewrite 80ms + Dense search 60ms + BM25 30ms + Graph walk 50ms + Reranker 250ms + Pack+send 25ms）。Reranker 是最大的单一瓶颈（250ms），这解释了为什么许多系统在 production 中跳过 reranker 或使用轻量级 reranker——用一点点相关性损失换取显著延迟改善。

实践启示

对 AI 应用开发者

  1. 从四种记忆类型出发设计架构：在设计新的 agent memory 时，先明确需要支持哪种记忆类型。简单的个人助手只需要 episodic + semantic；复杂的 multi-agent 系统需要额外考虑 procedural（工具策略）和共享 memory 的权限拓扑。
  2. Embedding 模型选型决定检索质量上限：不要默认使用 OpenAI 的 ada-002 或 text-embedding-3-large。花时间在具体垂直领域评估 embedding 质量——医疗场景用 PubMedBERT，法律场景用 LegalBERT，可能比通用 embedding 好很多。同时建立 embedding 模型版本管理策略，以便在未来模型升级时重新计算所有历史向量。
  3. HyDE + RRF 是 production retrieval 的标配组合：HyDE 处理 query/answer shape mismatch 问题，RRF（Reciprocal Rank Fusion）融合 dense/sparse/graph 三种检索结果。这两者一起使用可以将召回率提升 20-30%，而实现成本相对可控。
  4. 永远不要跳过"是否需要检索"的判断：对于"Can you translate hello to Japanese"这类不需要记忆的请求，调用 vector search 是纯粹的浪费。在 retrieval pipeline 入口增加"need detection"步骤（简单的分类模型或规则），可以显著降低无用检索的延迟和成本。

对安全与隐私工程师

  1. PII governance 必须在写入路径而非读取路径：在读取时过滤 PII 意味着敏感信息已经进入了存储，风险暴露面已经形成。正确的做法是在写入路径上用正则匹配（如 \b\d{4}-\d{4}-\d{4}-\d{4}\b 匹配信用卡号）和/或专用 PII 检测模型（如 Microsoft Presidio）拦截敏感信息。
  2. 多租户隔离是 multi-agent memory 的生死线：每个租户的记忆必须严格隔离。实现上建议在 namespace per tenant 和 single collection + payload filter 之间做出选择——前者隔离严格但成本高，后者成本低但存在隔离失效的风险。对于高价值客户或有合规要求的场景，namespace per tenant 是值得的。
  3. Deletion lineage 是审计合规的基础：GDPR 的"被遗忘权"要求系统能够删除特定用户的所有记忆。但简单的物理删除（从 vector DB 中移除对应向量）可能不够——该记忆可能已经被用于生成 response 或写入其他 agent 的 shared memory。因此 deletion 操作本身应该是一个 audit event，触发 propagate 流程到所有衍生索引和共享存储。
  4. Cross-user leakage 的测试用例：在 memory 系统上线前，必须设计覆盖以下场景的测试：租户 A 的研究笔记中的用户偏好信息，是否会出现在租户 B 的 agent 响应中？这是最常见的 memory 相关安全漏洞，也是最难通过单元测试发现的——需要专门的 integration test 环境。

对平台工程师

  1. 热/温/冷三层存储是 cost-efficiency 的关键：并非所有记忆都需要 vector search 的计算成本。Top facts（活跃用户/项目的核心信息）放在 Redis 或内存 KV 中，每轮都读取；Recent episodes（近期对话）放在 vector DB 中，按需检索；Archived sessions（历史日志）放在 S3 中，仅用于回填或审计。三层架构可以将热数据的检索延迟降低一个数量级，同时将存储成本降低 70-80%。
  2. Memory API 的最小表面设计：生产系统的 memory API 只需要三个端点：POST/memory/events（追加原始事件）、POST/memory/search（混合检索，服务器端强制 scope 过滤）、DELETE/memory/{id}（遗忘，propagate 到衍生索引）。不要在 API 层面暴露过多的内部实现细节（如"更新某条记忆的 embedding"），这会破坏封装性并增加安全风险。
  3. Embedding 模型更换的运维流程：每当 embedding 模型更换时，所有历史存储的向量都需要重新计算。这不是简单的 batch job——它需要在重新计算期间暂停写入（否则新模型生成的向量和旧向量混在一起无法检索），或者采用双写策略（新旧向量并行写入，切换完成后清理旧向量）。提前设计好这个流程，避免在凌晨 3 点手忙脚乱。
  4. Background worker 的优先级队列设计：embedding 计算、摘要生成和 re-embedding 是不同的作业类型，应该使用不同的优先级队列。高优先级队列处理用户等待的同步检索，中优先级处理需要尽快完成的写入后任务（如 summary），低优先级队列处理非紧急的维护作业（如过时记忆的 re-embedding）。

对产品经理

  1. "记住一切"是错误的产品假设：用户并不总是希望 agent 记住所有对话历史。有些对话是临时性的（"帮我查一下这个航班"），有些是敏感但不相关的（医疗信息不应与产品偏好混淆）。产品设计应该让用户能够选择性地"标记重要记忆"和"遗忘临时对话"，而不是默认将所有内容都写入长期记忆。
  2. Memory 的"忘记"功能是信任建立的关键：在用户界面中明确显示"agent 记得什么"并允许用户删除特定记忆，能够显著提高用户对 AI 产品的信任度。这不仅是隐私合规的要求（GDPR 等），也是产品竞争力的体现——用户更愿意使用一个他们能够控制的记忆系统。
  3. Multi-agent memory 的 shared/private 默认为 private：如果 agent 之间需要共享记忆，那应该是一个有意识的显式操作（类似"发布到项目"），而不是默认行为。默认共享会导致信息噪音和隐私泄露，而默认私有则要求开发者主动考虑共享场景——这是一个更安全的默认选择。
  4. Memory 系统的可观测性指标：上线 memory 系统前，必须建立以下 metrics：检索召回率（通过用户反馈或 ground truth 数据集评估）、PII 泄露次数（每次 governance gate 拦截都是一次告警）、平均检索延迟（p50/p95/p99）、记忆更新成功率（写入路径的 SLA）。这些指标应该在 dashboard 上实时展示，并在异常时触发告警。