MemPalace 深度拆解报告

> *"记忆宫殿"不是噱头——它是一组关于 AI 记忆系统设计哲学的真实实验，只不过有些部分比其他部分更真实。* > > *参考：一篇独立 arxiv 论文（2604.21284）对 MemPalace 的批判性分析，以及费曼"命名不等于理解"的原则。*

---

一、一句话定位

MemPalace 是一个本地优先、零 API 调用的 AI 记忆系统，核心赌注是"存储一切原文，不总结不提取，把检索问题单独解决"。

它用认知科学中的"记忆宫殿"（Method of Loci）作为隐喻，把记忆组织成 Wings→Rooms→Drawers（翅膀→房间→抽屉）的层级结构。但别被这个华丽的名字骗了——真正让它与众不同的是 verbatim 存储哲学，而不是宫殿本身。

---

二、核心哲学：Verbatim 存储

2.1 行业共识 vs MemPalace 的逆向赌注

当前几乎所有 AI 记忆系统都走同一条路：

系统	方法	写入成本
Mem0	LLM 提取和总结关键事实	每次写入都要调用 LLM，按 token 付费
Zep/Graphiti	LLM 构建时序知识图谱	每次写入都要调用 LLM，按 token 付费
LangMem	LLM 提取结构化记忆	每次写入都要调用 LLM，按 token 付费
Supermemory	多 agent 架构，语义+时序+实体搜索	每次操作都涉及 LLM 推理

MemPalace 说："我不信这套。让我试试把所有东西原封不动存进去，看看能不能只靠检索解决问题。"

结果是：

LongMemEval R@5: 96.6%（纯语义搜索，零 LLM 调用）
LongMemEval R@5: 98.4%（Hybrid v4，50q 调参 + 450q hold-out，仍零 LLM 调用）
LongMemEval R@5: ≥99%（Hybrid v4 + LLM rerank，此时才调用 LLM）

对比：Mem0 最初的成绩是 ~49%。也就是说，MemPalace 用零 API 成本的方法，大幅领先了当时最强的提取式系统。

2.2 为什么 Verbatim 能赢？

提取式方法有一个根本性问题：你不知道现在提取什么会在未来被用到。

假设用户今天说："我下周二要去见张医生。"提取式系统会提取"用户有医生预约"这个事实。但如果三个月后用户问"我上次见张医生是什么时候？"，系统可能已经从记忆中清除了"张医生"这个实体（因为不常用），只保留了模糊的"有医疗预约"记录。

Verbatim 存储保留了完整的原文："我下周二要去见张医生。"检索时，"张医生"三个字仍然能被语义搜索找到。

这不是魔法。这只是一个信息论的基本事实：提取是信息有损操作。如果你承受得起存储成本，原文永远比摘要更可靠。

2.3 但 Verbatim 不是银弹

一篇独立 arxiv 论文（2604.21284）对 MemPalace 做了深度批判性分析，结论是：MemPalace 的 headline 性能主要归功于 verbatim 存储 + ChromaDB 的 all-MiniLM-L6-v2 嵌入模型，而不是宫殿隐喻本身。

论文的核心发现： 1. 宫殿层级只是元数据过滤——Wings→Rooms→Drawers 在代码层面就是 ChromaDB 的 metadata filtering，这是标准向量数据库功能，不是 MemPalace 发明的 2. 96.6% 是在 L2 距离下测的——v3.3.0 修复了一个 bug（未设置 hnsw:space=cosine），但 all-MiniLM-L6-v2 的嵌入是归一化的，所以 L2 和 cosine 排序等价 3. v3.3.0 的自纠正值得称赞——维护者主动把 headline 从 100% 改为 98.4%（held-out 数据），移除了含有类别错误的跨系统对比表

论文的结论是 nuanced（细微的）：MemPalace 代表了"被过度宣传的真实架构洞察"——verbatim 确实有价值，但宫殿隐喻的营销速度超过了科学严谨性。

---

三、架构拆解：四层记忆栈

3.1 宫殿隐喻 vs 代码实现

层级	隐喻	代码实现	功能
L0: Wings	宫殿的侧翼	顶层分类（people / projects）	粗粒度路由
L1: Rooms	房间	Topics 分类	中粒度过滤
L2: Drawers	抽屉	Verbatim 文本块存储	原始内容存储
L3: Knowledge Graph	关联图谱	带 validity windows 的时序实体关系图	结构化关系

唤醒成本（wake-up cost）——每次会话开始时加载记忆所需的 token 数：

L0（Wings map）：~170 tokens
L0+L1（Wings + Rooms）：~350 tokens
L0+L1+L2（到 Drawers）：~900 tokens
L0+L1+L2+L3（完整 KG）：~2000 tokens

这意味着：你可以根据任务复杂度选择唤醒深度。 简单对话只需要 170 tokens 的 palace map，复杂分析才加载完整的 verbatim 内容和知识图谱。

3.2 检索层：可插拔设计

默认后端是 ChromaDB，但 v3.2.0 引入了抽象接口（backends/base.py），支持：

ChromaDB（默认）
LanceDB
PostgreSQL + pgvector
社区后端

v3.3.0 新增的 Closet 层：在 Rooms 和 Drawers 之间增加了一个紧凑的可搜索索引，指向 verbatim drawers 的指针。BM25 关键词搜索被整合进来，Closet 负责提升排序，Drawers 仍然是 truth source。

3.3 零 LLM 写入路径

MemPalace 的写入流程： 1. 文本分块（固定策略，不调用 LLM） 2. 嵌入模型编码（all-MiniLM-L6-v2，本地运行） 3. 存入 ChromaDB 4. 可选：提取实体关系存入 SQLite 知识图谱（用轻量级 NLP，不是 LLM）

整个过程不需要任何 LLM API 调用。 这意味着：

零 API 成本
完全离线可用
确定性行为（同一输入总是产生同一输出）
无速率限制
无厂商锁定

在竞品每次记忆写入都要花几分钱的世界里，这是一个真实的竞争优势。

---

四、竞争格局：七系统对比

根据独立分析论文和多个来源的对比数据：

系统	Stars	类型	写入方式	LongMemEval R@5
MemPalace	~48k	Verbatim + 时序 KG	零 LLM	96.6% / 98.4%
Supermemory	~22k	多 agent 架构	全 LLM	~99%（自报）
Mem0	~53k	提取式事实	LLM 提取	~93.4%（2026.4 新算法）
Mastra	~20k	GPT-5-mini 观察模式	持续 LLM	~94.87%
Hindsight	~15k	Retain→Recall→Reflect	多 LLM pass	~91.4%
Zep/Graphiti	~25k	时序知识图谱	LLM 提取	~85%
Letta	~22k	有状态 agent + 记忆块	LLM 管理	未专注 benchmark

关键变化：Mem0 的追赶

Mem0 在 2026 年 4 月发布了"token-efficient memory algorithm"，用单次分层提取 + 多信号检索，把 LongMemEval 从 ~49% 提升到 93.4%。这个提升极为显著，直接挑战了"verbatim 必然优于提取"的叙事。

现在的情况：

零成本场景：MemPalace 仍领先（96.6% vs Mem0 的 93.4%，但差距缩小到"统计噪声"级别）
成本不敏感场景：Supermemory 和 Mastra 可以达到 ~99%
关系密集型查询：Zep/Graphiti 的 Neo4j 知识图谱更强大

结论：verbatim 不是绝对胜利，而是一种 trade-off 选择。

---

五、MCP Server 和 Agent 生态

5.1 MCP Server：29 个工具

MemPalace 提供完整的 MCP（Model Context Protocol）server，暴露 29 个工具：

记忆读写（store_memory, get_context, search_memories）
知识图谱操作（add_knowledge, query_knowledge）
会话管理（open_session, close_session）
元数据操作（list_wings, list_rooms, list_drawers）

这使得 MemPalace 可以与任何支持 MCP 的客户端集成——Claude Code、Cursor、Continue.dev 等。

5.2 多 Agent 支持

每个 specialist agent 有自己的 wing 和 diary：

独立的记忆空间
跨 session 的日记累积
轻量级实现，与宫殿结构深度集成

这与 OpenClaw 的 workspace + AGENTS.md 有相似之处，但 MemPalace 更强调"每个 agent 有自己的 wing"的隔离。

5.3 Auto-save Hooks

MemPalace 提供自动保存 hook 与 Claude Code 集成：

定期保存（会话中定期触发）
压缩前保存（在 Claude Code 压缩上下文前触发，防止丢失关键信息）

这是一个务实的工程考量——Claude Code 的上下文压缩策略可能会丢弃早期内容，auto-save 确保重要信息先存进记忆系统。

---

六、批判性评估：什么真实，什么营销

6.1 真实的贡献

1. Verbatim-first 哲学：挑战了提取式共识，证明了"存储一切原文"在检索场景下可以达到顶尖性能 2. 零 LLM 写入路径：在 everyone-charges-per-token 的市场中，零成本是真实的差异化优势 3. 最小唤醒成本：170-900 tokens 的唤醒开销是行业最低水平之一 4. 四层渐进式加载：允许根据任务复杂度选择记忆深度，节省上下文窗口 5. 自纠正的维护文化：v3.3.0 主动修正 headline 和对比表，展示了对科学严谨性的尊重

6.2 被高估的部分

1. 宫殿隐喻的检索增益：论文证明宫殿层级只是 metadata filtering，对语义搜索的数学性能没有实质提升。隐喻的价值在 HCI（人机交互）层面，不在算法层面。 2. 100% → 98.4% 的 headline 修正：最初的数据有 overfitting 嫌疑（100% 是在训练集上），后来的 held-out 数据修正为 98.4% 更符合实际。 3. GitHub stars 的解读：48k stars 不等于 48k 用户。大量 stars 来自社区对"AI 记忆"概念的兴趣，不等于生产部署规模。

6.3 真实的局限

1. 存储膨胀：verbatim 存储意味着无限增长的存储需求（虽然文本本身很小，但嵌入向量是 384 维 × n） 2. 检索延迟：大量 verbatim 内容意味着更长的检索时间（虽然 v3.3.0 的 Closet 层有所改善） 3. 关系推理弱：相比 Zep 的 Neo4j 知识图谱，MemPalace 的 SQLite 三元组存储在复杂关系查询上能力不足 4. 多模态缺失：目前只支持文本，不支持图像/音频/视频的记忆 5. 单次写入瓶颈：虽然零 LLM 成本，但嵌入模型（all-MiniLM-L6-v2）的吞吐量在大规模场景可能成为瓶颈

---

七、费曼视角：MemPalace 在赌什么？

费曼会问："你是因为这个方案有效才相信它，还是因为你给它起了个漂亮名字才相信它？"

MemPalace 的情况恰好是两者的混合：

名字（宫殿隐喻）很漂亮，但它对检索性能的贡献 ≈ 0。宫殿是 metadata filtering，ChromaDB 本身就支持。
方案（verbatim 存储）确实有效，而且在一个关键维度上赢了：零成本。

费曼会说：

> "存储一切原文然后靠检索来解决问题，这个想法在信息论上是对的——你不确定未来会问什么，所以保留一切是保守策略。但你要诚实：这不是宫殿的功劳，这是'不扔东西'的功劳。宫殿只是个好看的文件夹结构。"

真正的 insight 是：在 LLM API 按 token 收费的世界里，把写入成本和推理成本解耦，是一个被低估的工程选择。 MemPalace 把昂贵的 LLM 调用从"每次记忆写入"转移到了"可选的 rerank 阶段"，这是一个架构层面的成本优化。

---

八、适合谁用？

不适合：
需要复杂关系推理的场景（选 Zep/Graphiti）
对检索准确率要求极高且预算充足的场景（选 Supermemory）
需要多模态记忆的场景（暂无理想方案）
适合：
隐私敏感、需要完全离线运行的场景
API 预算有限、希望零成本记忆写入的场景
喜欢本地优先、文件级控制的用户
已经在使用 Claude Code / Cursor 等 MCP 客户端的开发者
想要一个"不完美但诚实"的记忆系统的人

---

参考

仓库: https://github.com/milla-jovovich/mempalace
独立批判论文: arXiv:2604.21284 — "Spatial Metaphors for LLM Memory: A Critical Analysis of the MemPalace Architecture"
竞品对比: https://adityaarsharma.com/ai-memory-tools-compared/
Mem0 新算法: 2026 年 4 月 "token-efficient memory algorithm"
协议: MIT
系统要求: Python 3.9+, ~300MB 磁盘, 无需 API key