AI Agent 记忆设计模式目录

从 7 个开源项目 + 5 个生产级 Agent + 3 个框架的源码中提炼出 8 种可复用的记忆设计模式。每种模式包含问题域、核心机制、代表实现、适用场景和局限性。

调研元信息

模式总览

模式 1: Pre-compaction Flush

问题域

LLM 的上下文窗口有限，当对话 token 接近上限时会触发 context compaction（压缩/截断）。压缩会丢失未被保存的对话信息。如何在压缩前”抢救”重要记忆？

核心机制

嵌入一个静默的记忆 Agent 到主对话流中。该 Agent 监控 token 使用量，当接近 compaction 阈值时自动触发，从当前上下文中提取重要信息并持久化到外部存储（数据库/文件）。

[对话进行中] → [token 接近阈值] → [flush Agent 激活]
    → [提取关键信息] → [写入持久存储] → [compaction 安全执行]

代表实现

OpenClaw 的 memory_flush 工具。嵌入式 Agent 在 system prompt 中声明自己存在，监控对话流，在 compaction 前调用 memory_flush 将记忆写入数据库。Dreaming 机制在 flush 后做异步整合（去重、关联、更新）。

适用场景

长对话场景（Coding Agent 编码 session 常超过数万 token）、用户不主动保存的场景。

局限性

flush Agent 本身消耗 token，可能加速 compaction 触发；compaction 时机依赖 token 计数精度；flush 质量取决于嵌入式 Agent 的提取能力。

详细分析

见 OpenClaw Memory Flush 精读。

模式 2: Index + Retrieval

问题域

记忆存储为多个文件时，如何让 Agent 快速找到最相关的文件？全量注入所有文件会超出上下文预算。

核心机制

维护一个索引文件（目录 + 每个文件的摘要），启动时用 LLM 从索引中选出最相关的 N 个文件加载。索引文件本身足够小以全量注入。

[会话开始] → [加载索引文件（MEMORY.md）]
    → [LLM 根据用户消息选择最相关的 ≤5 个记忆文件]
    → [加载选中文件] → [注入上下文]

代表实现

Claude Code 的 memdir 模块。MEMORY.md 是索引文件（200 行 / 25KB 硬顶），子目录下按项目/用户分层存储。sideQuery 用独立 Sonnet 调用做语义检索。extractMemories 在会话结束后用 Agent 提取新记忆并更新文件。

适用场景

记忆总量可控的场景（个人开发者项目级记忆）；需要人机协作编辑的场景（用户可直接编辑 MEMORY.md）。

局限性

索引文件有硬顶限制，记忆量增长后摘要必须越来越精简；LLM 选择的质量受索引摘要信息密度影响；不支持结构化查询。

详细分析

见 Claude Code 记忆深度剖析。

模式 3: Two-phase Pipeline

问题域

实时提取容易产生碎片化记忆（每次对话提取的零散事实），需要跨会话全局视角来整合、去重、合并。

核心机制

Phase1（实时）：每次任务完成后并行提取候选记忆条目，存入 staging 区。Phase2（离线）：独立整合 Agent 以冷却期触发，读取所有 staging 条目 + 现有记忆文件，用 git-diff 格式做增量更新。

Session 1: [对话] → Phase1 提取 → staging 表
Session 2: [对话] → Phase1 提取 → staging 表
...
[冷却期到] → Phase2 整合 Agent:
    读取 staging + 现有 memories.md → 增量 diff → 更新 memories.md

代表实现

Codex 的 memories 模块。Phase1 concurrency=8 并行提取，Phase2 有 6 小时冷却期（CONSOLIDATION_COOLDOWN_SECS = 21600）。整合 Agent 在沙箱中运行，输出是 unified diff 格式。usage_count 跟踪每条记忆被引用次数，未被引用的可被淘汰。

适用场景

高频使用场景（一天多个 session）；需要高质量整合（去重、合并矛盾）；可以容忍记忆生效延迟。

局限性

6 小时冷却期导致新鲜度延迟；Phase2 整合质量不透明（用户无法预知哪些记忆被保留/删除）；staging 表无限增长需要清理策略。

详细分析

见 Codex 记忆深度剖析。

模式 4: Semantic Pyramid

问题域

不同查询需要不同粒度的记忆——有时需要原始对话细节，有时只需要用户画像。单一粒度的存储无法满足多层次查询。

核心机制

将记忆组织为金字塔结构，逐层蒸馏：L0（原始对话）→ L1（原子事实）→ L2（场景块 / 主题聚合）→ L3（用户画像）。每层保留溯源链接。查询时根据需求选择从哪层检索。注入时用 MMD（Memory Meta-Document）格式，稳定层在前（Cache 友好）、动态层在后。

L0: "我昨天在北京见了老王，聊了新项目"
  ↓ LLM 提取
L1: [用户在北京] [用户见了老王] [老王是朋友] [新项目存在]
  ↓ 主题聚合
L2: [社交-老王: 关系/见面记录] [项目: 新项目讨论]
  ↓ 画像提炼
L3: [用户基础: 常在北京活动, 有活跃社交圈]

代表实现

DB-Agent-Memory 的 4 层语义金字塔。SQLite + sqlite-vec 存储，BM25 + 向量混合检索。零外部依赖。

适用场景

需要多粒度查询的场景；重视 Prompt Cache 友好性（稳定区/动态区分离）；零依赖部署环境。

局限性

LLM 提取错误逐层放大；提炼管道的 LLM 成本随对话量线性增长；L1→L2→L3 的聚合规则需要调优。

详细分析

见 DB-Agent-Memory 精读。

模式 5: Virtual Memory

问题域

Agent 的上下文窗口类似 CPU 寄存器——容量有限但访问极快。如何让 Agent 管理远超上下文容量的记忆？

核心机制

借鉴操作系统虚拟内存：core memory（常驻内存，类似 RAM）+ archival memory（归档存储，类似硬盘）+ recall memory（检索缓存）。Agent 通过工具调用自主决定 page in（从 archival 加载到 core）和 page out（从 core 归档到 archival）。

Core Memory (≈2000 tokens):
  [persona]: Agent 自我定义
  [human]:   用户核心信息
  
Archival Memory (无限):
  [向量化的历史记忆条目]

Recall Memory (最近对话缓存):
  [可搜索的对话历史]

Agent 工具:
  core_memory_append / core_memory_replace
  archival_memory_insert / archival_memory_search
  conversation_search

代表实现

Letta (MemGPT)。Agent 拥有 7 个记忆管理工具，完全自主决定何时读写。core memory 有字符限制（类似物理内存容量），满时 Agent 必须决定删什么。

适用场景

需要 Agent 深度推理记忆管理策略的研究场景；模型能力强（GPT-4 级别）的场景。

局限性

Agent 自主管理的可靠性完全取决于模型能力——弱模型经常忘记保存或检索；每次记忆操作都是完整工具调用周期（2-5 秒延迟）；core memory 容量太小时频繁 page fault。

详细分析

见 Letta 精读 和 框架内建记忆横评。

模式 6: Temporal Graph

问题域

事实随时间变化——用户的住址、工作、偏好都会改变。如何记录事实的完整演变历史，同时支持”当前状态”查询？

核心机制

将事实存储为知识图谱的节点和边，每条边带双时间轴：valid_at（事实何时有效）和 expired_at（事实何时过期）。新事实与旧事实冲突时，旧边标记过期，新边创建——两条都保留。查询时用时间过滤获取最新状态。

[2024-01] 用户 --住在--> 北京  (valid_at=2024-01, expired_at=2025-03)
[2025-03] 用户 --住在--> 上海  (valid_at=2025-03, expired_at=NULL)

查询 "用户现在住哪" → expired_at IS NULL → 上海
查询 "用户2024年住哪" → valid_at ≤ 2024 AND expired_at > 2024 → 北京

代表实现

Graphiti (Zep)。Neo4j 存储，向量 + 图遍历 + cross-encoder 重排三阶段检索。

适用场景

事实频繁变化的领域（客服、医疗、金融）；需要历史追溯的场景。

局限性

图谱只增不减（每次变更创建新边），长期运行后图谱膨胀影响查询性能；依赖 Neo4j 等重量级图数据库；cross-encoder 重排增加检索延迟。

详细分析

见 Graphiti 精读。

模式 7: MCP Memory Service

问题域

不同 Agent 有不同的（或没有）内建记忆能力。如何让任何 Agent 都能接入统一的记忆服务，且无需修改 Agent 源码？

核心机制

通过 MCP（Model Context Protocol）协议暴露记忆操作为标准工具（add_memory / search_memory / list_memories 等）。Agent 作为 MCP Client 连接记忆 MCP Server，记忆服务对 Agent 是透明的外挂。

三种部署拓扑：

拓扑 1: Host-Adapter（DB-Agent-Memory）
  Agent → MCP Adapter → DB-Agent-Memory 核心库
  - Adapter 薄、核心厚；支持嵌入使用

拓扑 2: Pure Server（supermemory）
  Agent → MCP Server (supermemory)
  - 所有逻辑在 Server 侧；多 Agent 共享

拓扑 3: 混合（mem0）
  Agent → MCP Adapter → mem0 SDK → 后端服务
  - 三层间接；灵活但复杂

代表实现

supermemory MCP Server（Pure Server 模式）、DB-Agent-Memory MCP Adapter（Host-Adapter 模式）、mem0 MCP adapter（混合模式）。

适用场景

无内建记忆的 Agent（Cline、Continue）需要记忆能力；多 Agent 需要共享记忆；已有记忆基础设施需要接入新 Agent。

局限性

MCP 不定义记忆数据模型和事务语义——写入冲突和一致性需要记忆后端自行处理；网络延迟（MCP 通常是 stdio/SSE 通信）；Tool description 的质量直接影响 Agent 的使用效果。

详细分析

见 MCP 记忆拓扑精读 和 MCP 记忆桥接层。

模式 8: Rules-as-Memory-Bank

问题域

Agent 没有内建记忆功能，也没有 MCP 支持。如何用现有的 Profile/Rules 机制模拟持久记忆？

核心机制

将记忆组织为一组固定结构的 Markdown 文件，Agent 在每次会话开始时加载（全量注入 system prompt），在会话结束时更新。文件结构模拟记忆层次：projectbrief.md（项目概述）、techContext.md（技术栈）、progress.md（进展）等。

Memory Bank 文件结构:
  projectbrief.md     ← 项目基础（类似 L3 画像）
  techContext.md      ← 技术上下文
  systemPatterns.md   ← 架构模式
  activeContext.md    ← 当前工作焦点（类似 L1 当前事实）
  progress.md         ← 进展记录

Custom Instructions (.clinerules):
  "每次会话开始时读取所有 Memory Bank 文件"
  "每次会话结束时更新 activeContext.md 和 progress.md"

代表实现

Cline 社区的 Memory Bank 模式。通过 .clinerules 自定义指令驱动 Agent 在会话边界读写 Profile 文件。

适用场景

Agent 无内建记忆且不支持 MCP 的过渡阶段；小型项目（记忆量有限，全量注入不超预算）。

局限性

继承 Profile 的全部缺陷——无语义检索（全量注入）、无冲突合并（人工解决）、无遗忘机制（只增不减）。Token 成本随文件量线性增长。Agent 必须被指令”驱动”读写，遗忘指令则记忆中断。

详细分析

见 Profile 与 User Memory 边界。

模式选择指南

按 Agent 类型

按约束条件

模式组合

实践中这些模式常组合使用：

• Pyramid + MCP (DB-Agent-Memory)：金字塔存储 + MCP 暴露 → 任何 Agent 都能用分层记忆
• Flush + Pyramid (OpenClaw 方向)：compaction 前抢救 + 后台蒸馏 → 长对话不丢失
• Index + Pipeline (Claude Code + Codex 融合)：索引检索 + 批量整合 → 实时 + 离线双保障
• Bank → MCP (Cline 升级路径)：从 Profile 模拟迁移到 MCP 外挂 → 渐进式增强

演进趋势

短期（2026 下半年）

MCP 记忆服务（模式 7）将成为事实标准接入方式。DB-Agent-Memory 的 Host-Adapter 模式在这个趋势中位置有利——既可以嵌入使用，又可以通过 MCP 暴露。

中期（2027）

模式融合加速。生产级 Agent 可能同时拥有内建记忆（模式 2/3）和 MCP 外挂记忆（模式 7），两者通过统一接口协调。Flush（模式 1）可能被更多 Agent 采纳作为防丢失机制。

长期

Memory 和 RAG 的边界将进一步模糊。记忆系统可能演变为”个性化知识库”——既有从交互中学到的经验（Memory），也有从文档中检索到的知识（RAG），统一由一个分层存储 + 多模态检索系统管理。

交叉引用

• 模式 1 详细分析：OpenClaw Memory Flush 精读
• 模式 2 详细分析：Claude Code 记忆深度剖析
• 模式 3 详细分析：Codex 记忆深度剖析
• 模式 4 详细分析：DB-Agent-Memory 精读
• 模式 5、6 详细分析：各项目精读 + 框架内建记忆横评
• 模式 7 详细分析：MCP 记忆拓扑精读
• 模式 8 详细分析：Profile 与 User Memory 边界
• Memory vs RAG 边界：Memory 与 RAG 边界
• 12 维度大矩阵：生产级 vs 开源记忆对比