夜雨聆风本文目标：用第一性原理拆解 Agent 记忆问题，横向评测主流方案，给出可操作的选型框架。
预计阅读时间：12 分钟
一、问题定义：Agent 记忆到底在解决什么？
你有没有过这种感觉？
昨天和 OpenClaw 花了两个小时梳理需求，今天打开新 session，它一脸茫然：「你好，我是 你的AI 助手」
不是你的需求太复杂。是 Agent 的记忆系统，从根子上就没设计对。
在选方案之前，必须先回答一个问题：Agent 记忆系统的本质是什么？
多数人以为答案是「让 AI 记住更多东西」。这是表象，不是本质。
Agent 记忆系统解决的是两个正交的问题：
┌─────────────────────────────────────────────────────────┐│ ││ 问题一: 上下文工程 (Context Engineering) ││ ───────────────────────────────────── ││ 如何在正确的时机把正确的内容送进 context window ││ 核心矛盾: context window 有上限，记忆没有 ││ │├─────────────────────────────────────────────────────────┤│ ││ 问题二: 知识生命周期 (Knowledge Lifecycle) ││ ───────────────────────────────────── ││ 如何保持记忆的准确性、时效性、一致性 ││ 核心矛盾: 信息会过时、会矛盾，却不能简单覆盖 ││ │└─────────────────────────────────────────────────────────┘两个问题的解决难度不在同一量级。 Context engineering 是工程问题，有成熟解法。Knowledge lifecycle 是信息论问题，复杂度高得多。
为什么？
任何压缩都有损失。当 OpenClaw 把对话压缩成摘要，它在做有损压缩。而有损压缩的必然结果是：高频小细节丢失，低频关键约束也可能被当作噪音过滤掉。
这就是为什么「用户说不要用 A 库」会被压缩成「用户有偏好」——精确约束在压缩过程中被当作不确定的噪音丢掉了。
记忆系统要解决的，不是「记住更多」，而是「丢失更少」。
二、OpenClaw 原生记忆的问题
2.1 OpenClaw 记忆机制是怎么工作的
OpenClaw 默认的记忆机制：
1. Session memory: 滑窗内的对话历史 2. Workspace files: MEMORY.md、每日笔记等 Markdown 文件3. Compaction: context 满了就 summarization（摘要压缩）
2.2 原生机制的三个致命缺陷
作为 Agent 开发者，我们最怕的不是技术难，而是——明明调教好的 Agent，一夜回到解放前。
这不只是个技术问题。这是我们这群「想让 AI 更懂自己」的人的共同困境。
OpenClaw 原生机制有三个致命缺陷，是每一个重视记忆能力的开发者迟早会踩的坑：
缺陷一: Compaction 是有损的──────────────────────────────────────────当 context window 满了，OpenClaw 把旧消息压缩成摘要。摘要丢失细节，精确约束被忽略。"用户说不要用 A 库" → "用户有偏好"→ 未来可能推荐 A 库缺陷二: 文件记忆依赖人工程度──────────────────────────────────────────MEMORY.md 需要人手动维护。实际场景:- 开发者忘记更新- 更新了 MEMORY.md 但没更新 AGENTS.md- 多个文件之间的信息不一致缺陷三: 跨会话记忆完全丢失──────────────────────────────────────────每次新 session，Agent 对用户一无所知。昨天讨论的架构决策、用户偏好、技术栈全部归零。这三个问题叠加的结果：OpenClaw 是一个每次对话都从零开始的 Agent。
三、QMD 为何不是答案
3.1 QMD 是什么（名字起了很大的误导）
QMD = Query, Markdown Document
这名字起得真有迷惑性。
它让你以为这是记忆系统。实际上？它只是一个更智能的搜索引擎。
QMD 实际做的事:✓ 索引 workspace 里的文件 (Markdown, 代码, 各种文档)✓ BM25 关键词精确匹配✓ 向量语义相似度搜索✓ 结合 recency、file type、collection 权重做评分QMD 不做的事:✗ 从对话中提取结构化事实✗ 管理记忆的生命周期✗ 检测矛盾信息并处理✗ 跨会话持久化用户偏好✗ 生成压缩摘要3.2 QMD 的真实问题（GitHub Issues 证实）
memory_search | ||
memory_search | ||
系统性缺陷这个词是 OpenClaw 官方 issue 里用的。这意味着不是偶发 bug，是架构层面的问题。
3.3 QMD 的能力边界
QMD 最适合的场景：在一个已经有良好维护的知识库中做智能检索。
如果你有一个完美维护的 MEMORY.md、AGENTS.md、架构文档，QMD 能帮你更聪明地找到它们。
但这恰恰是问题所在——如果用户会主动维护这些文件，Agent 记忆问题本就不存在。记忆系统的价值恰好是在用户不主动维护时，系统自动接管这个过程。
QMD 的本质: 更智能的搜索引擎QMD 不能替代: 结构化事实提取 + 记忆生命周期管理四、知识分层：理解记忆系统的关键框架
在评测具体方案之前，需要一个统一的心智模型。
4.1 四类记忆，两种生命周期
Agent 的记忆可以分成四类，每类的处理策略完全不同：
┌────────────────────────────────────────────────────────────────┐│ 第一类: Durable Facts (持久事实) ││ ─────────────────────────────────────── ││ 内容: 用户偏好、技术栈、架构决策、项目约束 ││ 生命周期: 永久保留，更新时 supersede 而非覆盖 ││ 例子: "用户用 TypeScript，不用 Python" ││ 要求: 可追溯（能看到历史版本） │├────────────────────────────────────────────────────────────────┤│ 第二类: Execution State (执行状态) ││ ─────────────────────────────────────── ││ 内容: 当前任务进度、已完成步骤、待处理项 ││ 生命周期: 单任务周期，任务结束可丢弃，中断需能恢复 ││ 例子: "完成了 API 设计，正在写数据库迁移" │├────────────────────────────────────────────────────────────────┤│ 第三类: Session Context (会话上下文) ││ ─────────────────────────────────────── ││ 内容: 最近几轮对话的原始内容 ││ 生命周期: 会话内可见，compaction 后从可见范围移除但原文存档 ││ 例子: "这轮对话中用户问了三个问题" │├────────────────────────────────────────────────────────────────┤│ 第四类: Distilled Knowledge (蒸馏知识) ││ ─────────────────────────────────────── ││ 内容: 从多次交互中提取的高层模式、归纳总结 ││ 生命周期: 异步积累，低频更新 ││ 例子: "用户讨论需求时总是先问性能影响" │└────────────────────────────────────────────────────────────────┘多数记忆插件只处理第一类和第三类，忽略第二类和第四类。 这是它们实际效果不如预期的根本原因。
记忆分层不是为了炫技。是为了让 Agent 在正确的时机，调用正确的记忆。
四类记忆处理策略完全不同——这是 Engram 和 QMD 的根本区别。
4.2 提取的三层架构
记忆提取不应该全交给 LLM。正确的三层架构：
层一: 规则匹配 (覆盖 60-70%)──────────────────────────────────────────确定性模式，速度快，结果稳定例如: "用户偏好..."、"决定..."、"正在做..."不需要语义理解，正则+关键词即可层二: LLM 提取 (覆盖 20-30%)──────────────────────────────────────────语义模糊的场景，需要理解上下文批量处理，不要每条消息单独调用层三: Fallback 规则 (兜底)──────────────────────────────────────────前两层都没匹配时，低置信度存储检索时降权，不干扰高质量记忆全用 LLM 提取的问题是：成本线性增长 + 结果不稳定（同样内容两次提取可能不同）。
五、主流方案横向评测
5.1 评测维度与权重
| 记忆提取能力 | ||
| 生命周期管理 | ||
| 检索质量 | ||
| 工程复杂度 | ||
| 扩展性 |
5.2 参评方案一览
5.3 核心功能对比
| 记忆分层 | |||||
| 提取架构 | |||||
| Supersede | |||||
| DAG 摘要 | |||||
| 实体追踪 | |||||
| Agent 工具数 | |||||
| Obsidian 同步 | |||||
| Compaction 接管 |
5.4 详细评测
Engram ⭐⭐⭐⭐⭐
最推荐：功能最全，架构最严谨
给追求完美的开发者：如果你对记忆系统有洁癖，想要完全掌控每一类记忆的处理逻辑，Engram 是你唯一的选择。
优点:+ 完整的 4 类记忆分层+ DAG 摘要系统，层层浓缩不丢细节+ 预 compaction 事实提取（关键差异）+ 周期 harvest 异步积累知识+ Obsidian 双向同步+ 激活度模型 + 强化学习排序+ 详细的记忆质量控制（junk detection）+ 15+ 工具，Agent 可自主查询记忆缺点:- 配置项多（59+ 配置项）- 学习曲线陡- 8400+ 测试用例，复杂度高- SQLite 存储，并发有限适用场景: 需要最强功能、愿意投入配置时间核心架构亮点：Engram 在 compaction 发生之前执行事实提取。
这意味着什么？
即使消息被压缩成摘要，原始的「用户说不要用 A 库」这样的具体事实已经被永久保存了。
═══════════════════════════
好的记忆系统，不是记住更多，而是丢失更少。═══════════════════════════
你之前踩过「记忆丢失」的坑吗？
// Engram 的关键设计: pre-compaction extractionasync compact({ sessionId, force }) { // 1. 扫描即将被压缩的消息 // 2. 用规则快速提取确定性信号（无需 LLM） // 3. 用 LLM 批量提取复杂事实 // 4. 存入永久记忆库 // 5. 再执行压缩}Mem0 ⭐⭐⭐⭐
次推荐：最简单，开箱即用
给刚入门的开发者：如果你还在实验阶段，想快速验证记忆系统有没有用，今晚就能跑起来。
优点:+ 一行命令安装+ 支持云端和自部署+ auto-recall + auto-capture 全自动+ 官方维护，有 SLA+ 5 个常用工具够用缺点:- 无 supersede 机制（信息过时不处理）- 只有 2 类记忆（session / long-term）- 云端版本数据需出墙- 自部署版本依赖外部向量数据库适用场景: 想最快跑起来、不想折腾配置重要提示：Mem0 的 memory 分成 session（会话级）和 long-term（用户级），但没有 durable facts vs execution state 的区分。
这意味着什么？当前任务的中间状态和用户偏好会混在一起。
后果很直接：你让 Agent 记住「用户在做一个电商项目」，但它可能分不清这是持久偏好还是当前任务上下文。结果就是——建议可能偏离上下文，或者直接覆盖用户的真实偏好。
db0 ⭐⭐⭐⭐
本地优先首选：知识图谱 + supersede
优点:+ 知识图谱结构存储实体关系+ 完整的 supersede 机制+ SQLite 本地存储，无外部依赖+ supersede 设计专门解决"知识过时"问题+ benchmark: 76.9% (LoCoMo), 80% (LongMemEval)缺点:- 相对较新 (2026-03-22)- 工具数较少- 社区生态还在建立适用场景: 数据必须本地、需要知识图谱推理db0 的 benchmark 数据值得关注：
LoCoMo (199 queries): db0: 76.9% vs Mem0: 66.9%LongMemEval (50 questions): db0: 80.0% vs Mem0: 29%差距最大的是「知识更新」类问题——这正是 supersede 机制发挥作用的地方。
══════════════════════════════════════════════
有意思的是：差距不是来自检索能力，而是来自「忘记」的能力。══════════════════════════════════════════════
supersede 和覆盖，差别真的这么大吗？
Hindsight ⭐⭐⭐⭐
SOTA 检索质量：独立记忆服务器
优点:+ LongMemEval SOTA 性能+ 4 路并行检索（语义+关键词+图谱+时序）+ reflect 操作支持深度推理+ 记忆分层：World / Experiences / Mental Models+ 支持 Python/Node.js/CLI/ REST缺点:- 无 OpenClaw 官方插件（需自建）- 作为 Python 服务器运行，有运维成本- reflect 操作有延迟（深度推理）适用场景: 需要最强检索质量、愿意自建集成Hindsight vs db0：Hindsight 检索更强，db0 生命周期管理更强。可以考虑组合使用。
LUCID ⭐⭐
不推荐：QMD 的包装，不是真正的记忆系统
优点:+ 混合搜索质量不错+ salience 评分考虑 recency缺点:- 依赖 QMD daemon- 不管理记忆生命周期- 不是记忆提取系统- QMD 本身有系统性 bug适用场景: 仅作为 Engram/db0 的搜索增强层QMD ⭐
不推荐：被过度营销的搜索工具
问题汇总:✗ 不是记忆系统，是文件搜索引擎✗ memory_search 有系统性 bug（官方 issue 确认）✗ 无法提取结构化事实✗ 无法管理记忆生命周期✗ 无 supersede/矛盾检测✗ 跨会话记忆完全丢失唯一适合的场景:已有完美维护的知识库文件，想更智能地搜索但这本身就是矛盾的前提六、决策框架
6.1 选择树
┌─────────────────────────────────────────────────────────┐│ 你的首要目标？ │└─────────────────────────────────────────────────────────┘ │ ┌─────────────────┼─────────────────┐ ▼ ▼ ▼ 最快跑起来 最强功能 本地优先 │ │ │ ▼ ▼ ▼ Mem0 Engram db0 (5分钟) (1-2小时) (1-2小时) ┌─────────────────────────────────────────────┐ │ 需要 SOTA 检索精度 + 深度推理？ │ │ → Hindsight 作为 Engram/db0 的后端 │ └─────────────────────────────────────────────┘6.2 场景化推荐
今晚就能做的
先问你一个扎心的问题：
你上次被 Agent「失忆」坑到是什么时候？
是不是调了两个小时的 prompt，新 session 一开，全忘了？
不管你现在用什么方案，先做这个1 分钟自检：
记忆系统选型检查清单
• [ ] 我的记忆是被动存储的，还是主动提取的？ • [ ] 信息过时后，系统会怎么处理？（覆盖 vs supersede） • [ ] 我的约束条件（比如「用户不用 Python」）能精确回溯吗？ • [ ] 新 session 启动时，Agent 对我的了解程度是多少？
如果你有任何 一个 ❌——你已经被记忆问题困住了。
6.3 不推荐的方案
QMD：不适合作为 Primary 记忆系统。它能解决「文件搜到了」的问题，但解决不了「Agent 自己知道」的问题。
单独的 QMD：没有 extraction、没有 lifecycle、memory_search 有 bug。用它等于用搜索引擎代替数据库——能查到已知的，但不知道该记什么。
七、最佳实践：记忆系统设计的五条铁律
基于对上述所有方案的分析，总结出构建/配置记忆系统的核心原则：
铁律一：提取分层，不要全交给 LLM
60-70% 的记忆用规则快速提取（"用户偏好..."、"决定..."）20-30% 用批量 LLM 提取（语义复杂的场景）兜底用 fallback 规则，低置信度降权检索铁律二：Supersede 而非覆盖
当用户说"我换工作了":❌ 错误: 直接修改"在 A 公司" → "在 B 公司"✅ 正确: 保留"A 公司"记录，标记 superseded，检索时跳过价值: 可追溯、可回答"之前在哪工作"铁律三：assemble 前过检索 3x，重排截断
❌ 错误: 直接取 top-K 结果✅ 正确: 取 topK × 3 → cross-encoder 重排 → 按 token budget 截断原因: 早期检索质量不够好，过检索能捕捉更多相关内容铁律四：afterTurn 三层分离
同步层: 提取下一轮可能用到的结构化事实异步层: 批量 LLM 提取（降低 LLM 调用成本）周期层: 记忆合并、去重、激活度衰减铁律五：Compaction 前保护信息，但不要接管截断
❌ 错误: plugin 完全接管 truncation✅ 正确: 1. compaction 触发时，先快照到记忆库 2. 执行自己的提取逻辑 3. 调用 delegateCompactionToRuntime() 4. 让 OpenClaw 原生机制处理实际截断八、总结
一句话结论
OpenClaw 原生记忆不够用，但 QMD 也不是答案。真正的解决方案需要: 1. 自动提取结构化事实（不是靠人维护文件） 2. 管理记忆生命周期（supersede / 矛盾检测） 3. 智能检索 + 重排（不是简单向量搜索）首选: Engram (功能最强) 或 Mem0 (最快上手)进阶: Engram + Hindsight (两者结合)本地: db0 (数据不出墙)为什么这套方法有效？
因为它解决了记忆系统的本质问题：不是让 Agent 记住更多，而是让它在正确的时机调用正确的记忆。
作为 Agent 开发者，你真正需要的是什么？
不是更贵的模型，不是更多的 context window。是从今天开始，把记忆当作一等公民来设计。
═══════════════════════════════════════════════════════
记忆是 Agent 的「经历」，不只是数据。
═══════════════════════════════════════════════════════
当你花两个小时调教一个 Agent，你不是在配置一个工具——你在和它建立一段「共同经历」。
这段经历值得被记住。
💡 觉得有收获？
• 收藏：方便随时回看选型检查清单 • 转发：让更多同行少走弯路 • 关注：我会持续追踪 Agent 记忆系统的最新进展
下周我会发布Engram 完整配置教程，从 0 到生产级部署。点关注，第一时间收到。
关键路径
@mem0/openclaw-mem0 | |
github.com/lucassynnott/openclaw-engram | |
db0.ai/integrations/openclaw | |
github.com/vectorize-io/hindsight |
你在用哪个记忆方案？踩过什么坑？ 留言区聊聊。
写完这篇文章，我特意去翻了一下 QMD 的最新 issue——好家伙，系统性缺陷还在，closed 了三年没修。
记忆问题真的很难。不是难在技术，是难在这个问题本身就无解。
但我们还是在做。
因为每次 Agent「认识」我们的那一刻，所有的折腾都值了。
