MemPalace 是 Milla Jovovich 开源的本地AI长期记忆系统，支持语义搜索与四层记忆栈，在 LongMemEval 基准上纯本地检索召回率达96.6%。适合 AI 重度用户与开发者，完全本地运行、无需 API Key。需注意宫殿架构可能对检索性能有负面影响，早期宣传存在过度争议，建议尝鲜而非生产环境使用。
Tags:
生化危机里的女主爱丽丝，第五元素里的莉露，好莱坞硬核动作女星。
但 2026 年 4 月，她刷屏的方式不太一样：她在 GitHub 上发了一个叫 MemPalace 的开源项目，48 小时拿了 7000 Star，一周破 19000。
现在已经 4 万多了。
一个动作女星搞开源 AI 项目，这个反差本身就够聊的。
这个项目本身到底怎样，坦率讲，有亮点，也有挺明显的硬伤。
01
她为什么要做这个
Milla 自己在 MISSION.md 里写了她做这个项目的起因。
她长期用一个叫 Lumi 的 AI 助手协作开发项目，遇到一个所有 AI 重度用户都头疼的问题：上下文压缩之后，AI 就失忆了。
她形容 Lumi 每次醒来都跟新同事一样问今天我们要干嘛，而她明明之前已经跟它聊了好几个小时。
她试了市面上各种记忆系统，觉得都差点意思。
她的原话大概是：这些东西就像空仓库，你往里面堆了很多信息，但真要找的时候搜半天也搜不到。
她特别想要一种模糊回忆的能力：就是那种"我们之前聊过类似的东西吧？"的感觉，普通关键词搜索根本做不到。
所以她和工程师 @bensig 一起，从自己的真实痛点出发，用 Claude Code 搞了这么一个东西出来。
这个出发点是实在的，不是为了蹭 AI 热度瞎搞。
02
MemPalace 是什么
一句话概括：MemPalace 是一个本地运行的 AI 长期记忆系统。
它把你的对话和项目文件逐字存下来，然后用语义搜索来检索。
注意关键词：逐字存储，不做摘要，不做改写。
这个设计选择挺有意思的。
大部分记忆系统会对内容做压缩或者摘要来节省空间，但 MemPalace 坚持存原文。
好处是信息不丢失，坏处是存储成本高。
不过对于个人使用来说，磁盘空间不是问题，信息保真才是。
它的存储结构借用了记忆宫殿的概念：
Wing（翼）是顶层单位，一个项目或者一个人就是一个翼。
Room（房间）是具体话题，比如 auth-migration、deploy-process 这种。
Closet（壁橱）是压缩索引，指向原始内容的位置。
Drawer（抽屉）是逐字保存的原始对话文本。
另外还有 Tunnel（隧道）做跨翼关联，如果不同项目里聊了同一个话题，graph 层可以自动把它们连起来。
灵感来自两套老东西：
古希腊演说家把演讲内容放在想象建筑的各个房间里的记忆宫殿技法，还有德国社会学家卢曼的卡片盒笔记法。
用互相引用的小卡片管理了几万条笔记。
听起来很优雅。
但优雅的理念不等于好的效果，后面会说实测数据。
开源地址：github.com/MemPalace/mempalace03
四层记忆栈
这是整个项目里工程上最有价值的部分。
MemPalace 设计了一个 4 层渐进式加载的记忆栈：
L0 是身份层，大概 50 个 token，告诉 AI 它是谁、服务谁。
L1 是关键故事层，大概 500-800 token，系统自动从所有记忆里挑出最重要的 15 个时刻，按房间分组，作为每次 AI 唤醒时的核心上下文。
L2 是按需回忆层，只有聊到某个具体话题的时候才加载对应的房间内容，大概 200-500 token。
L3 是深度搜索层，对整个记忆宫殿做全量语义检索。
核心思路是：不需要把所有记忆一股脑塞进 prompt，按需加载就好。一个典型的 AI 唤醒大概只需要 600-900 token，比把全部历史塞进去要省很多。
另外它还有个叫 AAAK 的压缩方式，Milla 自己说这个名字没什么含义，就是她跟 Lumi 之间的内部笑话。
它把人名、重复概念、关键时刻压缩成极简速记，存在 Closet 里作为索引，指向 Drawer 里的原始内容。
有点像图书馆的目录卡：先查卡片知道在哪，再去书架上拿书。
04
实打实的性能数据
先说好的一面。
MemPalace 的纯语义搜索确实挺能打。
在 LongMemEval 基准上，Raw 模式拿到了 96.6% 的 R@5 召回率。
这个数字不需要任何 API 调用，不需要 LLM，纯靠 ChromaDB 向量检索，完全本地跑。
Hybrid v4 模式在 held-out 集上拿了 98.4%，这个数字也是诚实的。用 50 条调参，450 条没见过，不是拿训练集跑出来的。
LoCoMo、ConvoMem、MemBench 等多个基准都有公开可复现的结果。
96.6% 的纯本地检索，这个成绩本身是硬的。
但接下来要说的，就是这篇文章最该聊的部分了。
硬伤：宫殿结构反而是负增益
这是 MemPalace 最大的问题，也是很多人不知道的。
项目自己的 BENCHMARKS.md 里记录了一组数据：
Raw 模式（纯语义搜索，不加任何宫殿特性）：96.6%
启用 Rooms（元数据过滤）：89.4%，掉了 7.2 个百分点
启用 AAAK 压缩：84.2%，掉了 12.4 个百分点
也就是说，MemPalace 最核心的卖点：那个精心设计的宫殿架构、结构化的 Wing/Room/Closet 层级，在检索性能上非但没有帮忙，反而拖了后腿。
96.6% 的好成绩靠的是底层 ChromaDB 向量检索本身，跟宫殿架构没关系。
这不是我说的，是项目自己测出来的数据。
这并不意味着宫殿结构毫无价值。
从信息组织的角度看，Wing 和 Room 的划分对于多项目、多人的场景确实有帮助，它能让你按范围检索而不是在整个库里大海捞针。
但如果你追求的是纯粹的检索准确率，这套结构目前没有带来正面的数据支撑。
可能的原因是结构化检索本身就比纯语义搜索更难做对：加了一层过滤条件，就有可能过滤掉本该命中的结果。
但这只是一个猜测，具体原因可能需要更深入的分析。
用户在决定是否用之前，应该知道这个事实。
05
生态整合做得还不错
抛开争议，MemPalace 在生态整合这一层做的是不错的。
它提供了 MCP Server，有 29 个工具，覆盖检索、知识图谱、跨翼导航这些操作。
Claude Code、Gemini CLI、各种 MCP 兼容工具都能直接接入。
后台 Hooks 可以自动存档对话内容，不需要你在聊天窗口里手动触发。Milla 说她实测这个功能把每轮对话省了大概 1.13 美元的重复传输成本。
Agent 日记功能让不同的专业 Agent 各自有独立的 wing 和 diary，互不干扰。
一个 reviewer agent 记 bug 模式，一个 architect agent 记架构决策，不会混在一起。
支持 8 种语言包括简繁体中文。
后端可插拔，默认 ChromaDB，接口开放可以换。
隐私方面，全部本地运行，数据不上传，不需要 API Key 就能用核心功能。
SQLite 存知识图谱，ChromaDB 存向量。在 AI 工具普遍要你交数据的今天，这点确实值得肯定。
最后说说这个项目绕不开的争议。
4 月 5 日项目公开之后，很快在社区引发了讨论，而且讨论的方向挺激烈。
早期宣传里有两个大问题。
一个是声称 Palace 架构能带来 +34% 的性能提升，实际上恰恰相反，前面说了，实测是负的。
另一个是 LoCoMo 基准上宣传的 100% 召回率，后来发现那个结果绕过了检索环节，本质上不算数。
然后发生了一系列事：
先是否认和辩解。然后是承认数据有问题。
接着公开撤回了 +34% 和 100% 的宣传。
重写了 README 和文档网站。把所有 benchmark 方法和原始数据公开。补了 42 个回归测试防止类似问题再出现。
整个纠错过程大概花了 10 天。
有趣的实验，谨慎地用
聊聊整体判断，亮点是有的。
四层记忆栈的按需加载思路确实有工程价值。
96.6% 的纯本地检索召回率是实打实的好成绩。本地优先、隐私保护的立场在 AI 工具里算稀缺的。
Milla 的真实痛点驱动也让这个项目比很多跟风的 AI 项目更有说服力。
问题也很明显。
核心卖点宫殿架构在检索性能上没有数据支撑，甚至有负面影响。
早期宣传过度已经是不争的事实。项目的长期维护能力也存疑，毕竟核心团队就那么几个人。
目前的 MemPalace 更像是一个有趣的实验，而不是一个可以在生产环境里放心用的工具。
如果你是 AI 协作的重度用户，愿意尝鲜，能接受一些边界情况，可以试试。但如果你要的是稳定可靠的企业级记忆方案，建议再观望。
上手很简单：
pip install mempalacemempalace init ~/projects/myappmempalace mine ~/projects/myapp06
点击下方卡片，关注逛逛 GitHub
这个公众号历史发布过很多有趣的开源项目，如果你懒得翻文章一个个找，你直接关注微信公众号：逛逛 GitHub ，后台对话聊天就行了：
