MemPalace 深度解析：当 AI 终于学会"记住一切"

背景：AI 的致命缺陷——记忆的虚无

我们正在经历一场前所未有的变革：程序员做架构决策在 AI 对话窗口里完成，设计师和 AI 讨论配色方案，产品经理在 ChatGPT 里推演功能优先级。AI 已经深度介入了人类最核心的知识工作。

但问题是：对话结束后，一切都消失了。

你上周和 Claude 讨论的那套鉴权方案，当时论证了 20 分钟、否决了 3 种方案、最终选定了 JWT+Refresh Token——Session 结束后，这段思考彻底消失。下次遇到类似问题，AI 从零开始，你重新解释上下文，浪费 10 分钟。

这不是个例。MemPalace 团队做了一个测算：一个每天使用 AI 1 小时的程序员，6 个月积累的对话量是 1950 万 tokens。但没有任何上下文窗口能容纳这个量级，而 LLM 总结会丢失关键的"为什么"——那才是最有价值的部分。

1950万 tokens → 约 $507/年（纯总结方案） vs MemPalace 约 $10/年

这就是 MemPalace 要解决的问题。2026 年 4 月 5 日开源，48 小时内斩获 2 万+ stars，LongMemEval 基准测试 96.6% R@5，史上最高分——且完全免费、本地运行、零 API 调用。

一、问题本质：为什么现有 AI 记忆方案都失败了

在拆解 MemPalace 之前，有必要先理解现有方案的失败原因。

1.1 LLM 摘要法——以牺牲"为什么"为代价

主流 AI 记忆方案（比如让 AI 自己总结对话）是这个思路：对话结束后，用 LLM 把对话压缩成摘要，下次开新 Session 时把摘要塞进上下文。

问题在哪里？

LLM 摘要会丢失推理过程。原始对话里有：

• 为什么要否决方案 A？→ 因为它无法处理分布式 session 同步
• 方案 B 为什么最终放弃？→ 因为它在高并发下会产生惊群效应
• 最终选定的方案 C 有什么前置条件？→ 需要 Redis Cluster，且版本 ≥ 7.0

这些"为什么"才是上下文的核心。LLM 总结把它们压缩成"最终选定 JWT 方案"，下次遇到新问题，AI 根本不知道你之前否决过哪些路径、为什么否决。

1.2 纯向量检索——大海捞针

另一种方案：把历史对话全部向量化存进向量数据库（ChromaDB / Pinecone / Qdrant），下次用语义搜索找回相关段落。

这比摘要强，但问题也很明显：

1. 平铺式存储 —— 所有对话无差别地堆在一起。搜索"鉴权方案"，可能同时命中 5 个不相关的讨论
2. 无结构信息 —— 缺少"这是哪个项目的决策""这是哪个时间段的讨论"这类元信息
3. 搜索质量依赖 Query 质量 —— 你得想清楚怎么问，AI 才能找到对应的记忆

MemPalace 的做法不同：不信任 AI 自己决定什么值得记住，而是让你记住一切，然后给结构。

二、宫殿记忆法：3000 年前的修辞术，遇上 AI

MemPalace 的核心设计哲学来自一个你可能听过但未必了解细节的概念：记忆宫殿（Method of Loci）。

这是古希腊演说家西塞罗（Cicero）和古罗马学者阿美尼亚人（Method of Loci，又译轨迹记忆法）使用的记忆术。具体方法是：

1. 在脑海里构建一座虚拟建筑（宫殿）
2. 把要记忆的内容"放进"不同的房间
3. 回忆时在脑海里"走进"这些房间，内容自然浮现

这套方法的神奇之处在于：人类对空间位置的记忆极其强大。你可以轻松记住某个东西放在哪个抽屉、哪个房间，但要记住一段无结构的文字列表就困难得多。

MemPalace 把这个原理应用到了 AI 记忆系统。

2.1 核心数据结构：六层嵌套结构

MemPalace 的存储结构分为六层：

Wing（翅膀/区域）→ 对应一个独立主体（项目/人物/话题）
  └─ Hall（走廊）→ 连接同一 Wing 内的不同房间
       └─ Room（房间）→ 具体主题（auth、数据库、设计稿）
            └─ Closet（衣柜）→ 存放原始内容
                 └─ Drawer（抽屉）→ 具体文件或对话片段
                      └─ Tunnel（隧道）→ 跨 Wing 关联

关键理解：

• Wing（区域）：你做的每个项目、涉及的每个人物，都有自己独立的 Wing。Claude Code 的 Wing 里存放的是关于 Claude Code 的一切。
• Room（房间）：每个 Wing 内部再按主题分成房间。"Wing: 我的电商项目" 里面有 Room:订单系统、Room:支付流程、Room:搜索优化……
• Closet（衣柜）和 Drawer（抽屉）：实际存储原始内容的地方。Drawer 里放的是真实文件（代码文件、文档）或对话片段，Closet 是索引层。
• Hall（走廊）和 Tunnel（隧道）：Hall 连接同一 Wing 内的房间（跨主题关联），Tunnel 连接不同 Wing（跨项目关联）。

这套结构的价值在于：把平铺的记忆变成了有导航系统的地图。AI 不再需要在大海里捞针，而是知道"先进入哪个 Wing，再进哪个 Room"，精确定位。

2.2 Raw Verbatim 存储：不压缩，不摘要

这是 MemPalace 最重要的设计决策之一。

主流 AI 记忆方案都在做"压缩"——用 LLM 提取关键信息、压缩 token 数量。MemPalace 的理念相反：原始verbatim存储，一个字都不丢。

背后的逻辑很清晰：

LongMemEval 96.6% 的成绩来自 raw verbatim 模式。AAAK 压缩模式（实验性）得分是 84.2%——Lossy 压缩在这个场景下反而损害了召回率。

简单说：当你的存储目标是"以后能找到任何讨论过的细节"，不压缩比压缩效果好。因为 LLM 在提取"关键信息"时，必然会遗漏那些"当时看起来不关键但后来发现很关键"的细节。

三、AAAK：面向 AI 的缩写语言

AAAK（念作 "Ah-ah-ah-k"）是 MemPalace 自研的 AI 专用缩写语言，这是整个项目里最有趣也最具争议的设计。

3.1 为什么 AI 需要专门的缩写语言？

MemPalace 的 README 里提到了一个测算：一个典型程序员 6 个月内有 1950 万 tokens 的对话积累。即使 verbatim 存储，每次开新 Session 都读一遍是不可能的。

但 AAAK 的核心目标不是"省 tokens"（在小规模下，README 里也承认 AAAK 实际上比原文 token 更多），而是：

在超大规模重复实体场景下压缩——当你的记忆里有 1000 次提到同一个函数 processPayment()，AAAK 可以把它压缩成代码 P()，让上下文更紧凑。

3.2 AAAK 的设计原则

AAAK 的核心思路是实体代码化：

# AAAK 示例
# 原始文本：
# "我们在 processPayment() 函数中调用了 validateToken()，
#  然后通过 sendNotification() 发送 webhook，
#  processPayment() 位于 payment_service.py"

# AAAK 压缩后：
# "我们在 P() 中调用了 VT()
#  然后通过 SN() 发送 webhook
#  P() 位于 PSP"

processPayment → P()
validateToken → VT()
sendNotification → SN()
payment_service.py → PSP

AI 能理解这套缩写规则（因为它由 LLM 学习），同时每次遇到重复实体时都使用缩写，累计节省的 token 量相当可观。

3.3 诚实面对争议

必须指出：MemPalace 团队在 README 发出后 48 小时内就发了一份详细的勘误（就是文章开头那段"A Note from Milla & Ben"）。其中最重要的一条是：

AAAK 在小规模场景下不会节省 token（英文实测 66 tokens → 73 tokens，反而多了）。它设计用于大规模重复实体场景，在那个场景下才有压缩价值。

这种开源社区 48 小时内公开承认错误并详细解释的态度，本身就值得尊敬。

四、MCP 集成：让 AI 自己管理记忆

MemPalace 最优雅的设计是它不是给人用的工具，而是给 AI 用的工具。

4.1 一次配置，永久生效

传统记忆系统需要你（人类）主动去写入、检索。MemPalace 的目标是让 AI 自己完成这一切。

# 一次性配置（用户操作）
claude mcp add mempalace -- python -m mempalace.mcp_server

# 之后，用户只需说话：
# "Claude，帮我看看上周和你的那次讨论，当时你建议我用 xx 方案，
#  现在遇到新问题想参考一下"

# Claude 自动调用 mempalace_search
# → 找到对应 Wing/Room
# → 返回 verbatim 对话内容
# → 在此基础上继续推理

用户完全不需要记住"我在哪里讨论了什么"。AI 来管理记忆，用户只管提问题。

4.2 MCP Server 提供的 19 个工具

通过 MCP 协议，MemPalace 向 AI 暴露了 19 个工具，核心包括：

mempalace_mine()        # 挖掘新数据（对话、代码、文档）
mempalace_search()      # 语义搜索记忆
mempalace_save()        # 保存当前上下文到指定 Wing/Room
mempalace_wake_up()     # 生成 170 tokens 的核心上下文摘要
mempalace_classify()    # 对新内容进行分类（决策/问题/偏好/里程碑）
mempalace_fact_check()  # 矛盾检测

4.3 本地模型支持：Llama、Mistral 也能用

对于不想用云端 LLM 的用户，MemPalace 也支持本地模型：

# 方式一：wake-up 命令（给本地模型注入上下文）
mempalace wake-up > context.txt
# 把 context.txt 粘贴进本地模型的 system prompt

# 方式二：Python API
from mempalace.searcher import search_memories
results = search_memories("鉴权方案选型", palace_path="~/.mempalace/palace")
# results 是最相关的 verbatim 记忆片段列表

整个系统不依赖任何外部 API：ChromaDB 在本地运行，AAAK 解码不需要调用 LLM（它是纯规则），$0/年，100% 隐私。

五、LongMemEval 基准测试：96.6% 背后的真相

5.1 基准测试说明

LongMemEval 是专门测试 AI 长程记忆能力的基准，包含 500 道问题，考察 AI 能否准确回忆历史对话中的细节。

• 测试方式：先让 AI 阅读 500 条对话（模拟多个月的使用积累），然后问 500 道关于这些对话的问题
• R@5：返回 Top-5 结果中包含正确答案的比例
• 测试环境：M2 Ultra，零 API 调用，完全本地运行

96.6% R@5 raw verbatim 模式意味着：AI 问任何关于历史对话的问题，Top-5 结果里有 96.6% 的概率包含正确答案。

5.2 数据对比

5.3 基准测试局限性

README 中团队也坦诚说明了局限性：

1. AAA K实验阶段：fact_checker.py（矛盾检测）尚未集成到主 KG 操作流中（正在做）
2. Chrom eDB 版本：v0.4.x 有 shell 注入风险，macOS ARM64 有 segfault（正在修）
3. LongMemEval 的代表性：测试集可能不完全代表真实使用场景

这份坦诚在开源世界里极为罕见——大多数项目会藏着掖着，直到社区发现再被动应对。

六、架构解析：核心模块一览

MemPalace 的代码库结构相对扁平，核心模块如下：

mempalace/
├── __init__.py
├── cli.py              # 命令行入口（init/mine/search/status）
├── miner.py            # 数据挖掘器（convos/projects/general）
├── searcher.py         # 语义搜索（ChromaDB 查询）
├── wakeup.py           # 上下文生成器
├── classifier.py       # 内容分类器（决策/偏好/里程碑/问题）
├── storage.py          # ChromaDB 底层操作
├── palace.py           # Palace 结构管理（Wing/Room/Closet/Drawer）
├── aaak.py             # AAAK 编解码器
├── fact_checker.py     # 矛盾检测工具（待集成）
└── mcp_server.py       # MCP 协议服务（暴露 19 个工具）

6.1 Miner 模块：三种挖掘模式

# 模式一：项目挖掘（代码+文档）
mempalace mine ~/projects/myapp

# 模式二：对话挖掘（原始）
mempalace mine ~/chats/ --mode convos

# 模式三：对话挖掘（自动分类）
mempalace mine ~/chats/ --mode convos --extract general
# 自动分类为：decisions / preferences / milestones / problems / emotional_context

6.2 Storage 模块：ChromaDB 配置

# mempalace 使用 ChromaDB 作为向量存储后端
# 默认路径：~/.mempalace/chromadb/

# 核心配置参数：
collection_name = "mempalace_raw"
embedding_model = "sentence-transformers/all-MiniLM-L6-v2"  # 本地模型
distance_metric = "cosine"

# 关键设计：所有 embedding 在本地完成，无 API 调用

七、与其他方案的横向对比

7.1 vs Anthropic Memory / OpenAI Memory

7.2 vs Continue / Cody 等代码记忆工具

Continue（GitHub Copilot 的开源竞品）和 Sourcegraph Cody 都有"记忆代码库上下文"的能力，但它们专注的是代码结构记忆，而非决策和讨论记忆。

MemPalace 的野心更大：记住你用 AI 做过的所有事情——代码、文档、Slack 讨论、架构辩论、会议决策。

八、实际使用场景

场景一：跨项目的架构知识复用

用户：新项目要用微服务架构，之前你帮我分析过哪些坑来着？
Claude：[调用 mempalace_search("微服务架构 坑 讨论")]
       → 找到 Wing: 旧电商重构项目，Room: 微服务选型
       → 返回 verbatim 讨论：
         "当时否决单体优先的原因：高并发下扩展困难，
          调研结论：Netflix OSS + Spring Cloud 方案
          建议：先按领域拆分，不做过度设计"
Claude：找到了，当时我们讨论过三个主要坑...

场景二：AI 协作的项目启动加速

# 新 Session 开始
用户：继续上次的工作
Claude：[调用 mempalace_wake_up]
       → 生成 170 tokens 上下文：
         Wing: 电商项目 | 当前阶段: 搜索模块重构
         关键人物: 张三（后端）、李四（前端）
         当前痛点: 搜索延迟 800ms，需优化到 200ms
         决策记录: 已选定 Meilisearch 方案
Claude：我记得我们上周确定用 Meilisearch，目标是把搜索延迟从 800ms 压到 200ms...

场景三：团队知识传承

# 新成员加入
用户：给新人介绍一下项目背景
Claude：[调用 mempalace_search("项目背景 架构决策 关键人物")]
       → 聚合多个 Wing 的关键信息
       → 生成项目概览，包含：
         为什么选这个技术栈（历史决策）
         哪些坑踩过（教训总结）
         团队工作流和偏好

九、局限性与挑战

9.1 当前已知问题

从 GitHub Issues 来看，以下问题值得关注：

1. Shell 注入风险（Issue #110）：hooks 逻辑存在 shell injection，已被社区发现，修复中
2. macOS ARM64 segfault（Issue #74）：ChromaDB 在 Apple Silicon 上有崩溃问题
3. ChromaDB 版本锁定：v0.4.x 有兼容性问题，需等维护者确认稳定版本
4. AAA K性能争议：README 发布时数据有误，团队已主动承认并修正

9.2 规模化挑战

MemPalace 当前设计面向个人用户。对于团队场景：

• Wing 归属：谁创建的 Wing？谁可以写入？
• 冲突解决：多人同时修改同一 Wing 下的内容怎么处理？
• 权限控制：某些敏感对话能否标记为"私有 Wing"？

这些问题目前没有成熟的解决方案，是 MemPalace 往企业化方向发展的主要障碍。

十、安装与快速上手

# 安装
pip install mempalace

# 初始化（指定工作目录）
mempalace init ~/projects/myapp

# 挖掘已有数据
mempalace mine ~/projects/myapp                    # 代码和文档
mempalace mine ~/chats/claude/ --mode convos       # 对话记录

# 连接 MCP（以 Claude Code 为例）
claude mcp add mempalace -- python -m mempalace.mcp_server

# 验证状态
mempalace status
# 输出：
# Wing: myapp (项目)
#   Room: auth (2 drawers)
#   Room: database (5 drawers)
#   Room: api (3 drawers)
# Wing: 张三 (人物)
#   Room: 工作偏好 (1 drawer)
# Total drawers: 11 | Last mined: 2026-04-08

结语：记忆系统的范式转移

MemPalace 带来的启示，远超它本身作为一个工具的价值。

过去十年，我们学会了把文档存进 Confluence、把代码存进 GitHub、把需求存进 Jira。但知识工作最重要的产物——AI 对话中的推理过程、决策依据、失败教训——从来没有被系统性地保留下来。

MemPalace 第一次认真地说：这些对话本身就值得被记住，而且应该用原始形态记住，不应该被 LLM 预先筛选。

把宫殿记忆法（Metho d of Loci）——这套古罗马演说家用来背诵整场演讲的技术——应用到 AI 记忆系统上，是一个意外但深刻的类比。人类的记忆从来不是随机访问存储器，而是有空间线索的联想网络。MemPalace 承认这一点，并把这个洞见变成了工程实现。

当然，它还远未成熟。ChromaDB 的稳定性问题、AAAK 的规模化验证、团队知识共享的场景缺失……都是真实的工程挑战。

但 96.6% 的基准成绩、开源 48 小时内主动承认错误的坦诚、以及"Raw verbatim 不压缩"这个违反直觉但数据验证的设计决策——都说明这是一个认真对待问题的团队。

如果你每天使用 AI 工作超过 2 小时，MemPalace 值得认真一试。

你的下一个 AI 对话，不应该从零开始。

参考链接

• GitHub: milla-jovovich/mempalace
• LongMemEval 基准: benchmarks/BENCHMARKS.md
• MCP Server: python -m mempalace.mcp_server