MemPalace：56K Star 的记忆系统，做得越少反而越强
MemPalace 是今年四月冒出来的一个项目。到七月初已经 56,906 个 Star，迭代了三十多个版本。一个 AI 记忆系统，MIT 协议，Python 写的。
我翻了一遍它的代码仓库、benchmark 报告和设计文档，发现这个项目的思路跟所有同行完全反着来。别人都在用 LLM 提取记忆，它偏不。别人都在做摘要压缩，它偏存储原文。而这种「做得更少」的策略，拿到了 LongMemEval 上 96.6% 的检索召回率——不需要任何 LLM，不需要 API key，不需要联网。
所有人都搞错了方向
先说说 AI 记忆这个赛道在干嘛。
你肯定遇到过这种事：跟 Claude 或者 ChatGPT 聊了一小时，把项目需求、技术选型、各种 tradeoff 都交代清楚了。第二天打开新对话，它什么都不记得。你得从头再说一遍。烦。
所以有了 AI 记忆系统。Mem0、Mastra、Supermemory、Zep、Hindsight——全是解决这个问题的。它们的做法基本一致：用 LLM 扫描你的对话，提取出「关键事实」存起来。比如你说「我们后端决定用 PostgreSQL，不要 MySQL」，它就存一条记忆：「用户偏好 PostgreSQL」。
听起来合理。但问题出在哪？
LLM 提取事实的时候，一定会做信息压缩。你的原话是「因为我们要做地理空间查询，MySQL 的 GIS 支持不够好，Go 的 pgx 驱动也更成熟」。提取成「偏好 PostgreSQL」之后，「GIS 支持」「pgx 驱动」「Go 生态」这些上下文全丢了。下次你问「为什么当时选了 PG」，记忆系统答不上来——它只记得结论，不记得原因。
而且 LLM 提取本身就不稳定。同一个对话跑两次，可能提取出略有不同的「事实」。有些事实它觉得不重要就不提了。谁来决定什么重要？一个统计模型，不是你。
MemPalace 的做法简单到让人怀疑：不提取。不摘要。不压缩。存原文，用 embedding 做语义搜索。
一座宫殿，三层结构
MemPalace 的数据模型用了一个空间隐喻，来自古希腊的记忆宫殿技术。你把记忆放进一座想象的建筑里，通过空间位置来组织回忆。
它把这座宫殿分成四层：
Wing（楼翼）——最粗的粒度。通常对应一个人、一个项目、一个主题。你和每个人的所有对话放在各自的 Wing 里，不同项目的记忆不会混在一起。
Room（房间）——按时间分组。每一天是一个 Room，或者每个对话 Session 是一个 Room。这就产生了一个自然的时效性维度：你昨天聊了什么、上周聊了什么、上个月聊了什么，在检索时可以被利用。
Drawer（抽屉）——最小的存储单元。一段原文，不加修改。你说过什么，它就存什么。一个 Drawer 可能是一次对话中的一句话，也可能是一个完整的消息。
Closet（储藏间）——这是索引层。用一种叫 AAAK 的压缩方言把 Drawer 的内容转成一个紧凑的符号格式，让 LLM 能快速扫过几千条条目，立刻知道该打开哪个抽屉。AAAK 不是让 LLM 读完整内容，而是让它看一眼摘要符号，判断这条记忆跟当前问题是否相关。
这个结构的妙处在于搜索可以分层缩小范围。不是在整个记忆库里暴力跑向量相似度，而是先定位到正确的 Wing → 定位到时间相关的 Room → 再在 Room 里做语义搜索。每一步都在收窄范围。你在问「上次那个 CI pipeline 的优化方案」时，系统不需要在所有 5 万条记忆中硬搜——它会先锁到「工作项目-Wing」→「上个月-Room」→ 然后只在那几十条 Drawer 里找。
96.6%，不要 LLM
MemPalace 最狠的数据在 benchmark 上。
LongMemEval 是目前 AI 记忆领域的标准基准，500 道题，评估系统能否从长对话历史中检索到正确答案所在的片段。指标是 R@5——前 5 个检索结果里包含正确答案的概率。
MemPalace 的裸跑成绩：96.6%。配置：ChromaDB 默认 embedding，不做任何 rerank，不调用任何 LLM。零 API 费用，纯本地。
加上一层 hybrid 策略（关键词增强 + 时间邻近性增强）但不加 LLM rerank：98.4%。这个数字是在 50 道 dev set 上做了参数调优，450 道 held-out 上验证的——不是过拟合。
加上 LLM rerank（用 Claude Haiku 或者 Sonnet 从前 20 个候选中挑出最相关的）：100%。500 道题全对。
注意这几个数字的层次：
- 96.6% 是完全免费的，可以跑在断网的笔记本上
- 98.4% 加了传统 IR 技巧，依然免费
- 100% 才需要 LLM，但可以用任何模型
其他 benchmark 呢？LoCoMo 上从 60.3% 拉到 88.9%（hybrid v5），ConvoMem 上 92.9%，MemBench ACL 2025 上 80.3%。这些都是不用 LLM 的数字。
为什么不用 LLM 反而效果好？MemPalace 在 benchmark 文档里说得很直白：其他系统在「应该记住什么」这一步就丢失了信息。LLM 提取出的「用户偏好 PostgreSQL」是一个正确但贫瘠的事实。原文里还包含了为什么选它、当时考虑过什么替代方案、有什么 tradeoff——这些在语义搜索时都是匹配信号。
存原文 = 保留更多信号 = 搜索更容易命中。逻辑就这么简单。
记忆系统不需要成为另一个 LLM 调用
MemPalace 有一个设计原则叫「verbatim always」——永远不摘要、不改写、不做有损压缩用户的原始文字。这在代码仓库的 CLAUDE.md 里被列为不可妥协的铁律。
这引出另一个对比：Mem0 等系统的工作流程是「对话 → LLM 提取 → 存事实 → LLM 检索 → 返回」。链路里有两个 LLM 调用点。每次提取要对整个对话做推理，每次检索可能也要做推理。贵，慢，不稳定。
MemPalace 的链路是「对话 → 原文存储 → embedding 检索 → 返回原文」。链路上零 LLM 调用（除非你主动开 rerank）。快，便宜，可复现。
对于大多数场景——回想起上周讨论过的某个技术决策、找一个曾经提过的 API 端点、恢复某个项目的上下文——96.6% 够了。而且结果是你自己的原话。不是 LLM 帮你概括的二手信息。
隐私不是功能，是架构
MemPalace 的另一个设计决定是「local-first, zero external API by default」。所有东西跑在本地。embedding 模型跑在本地（默认 embeddinggemma-300m，多语言，100+ 语种）。向量数据库跑在本地（ChromaDB）。
它支持接入 Anthropic、OpenAI、Google 的 API——但这是显式 opt-in，用户必须手动配 key。系统永远不在你不知道的时候把你的对话内容发出去。
对于企业场景这一点很关键。很多公司的内部讨论、代码审查、架构决策是不能上云的。MemPalace 可以部署在完全离线的机器上，环境变量配好本地 Ollama 或者 LM Studio 就能跑完整流程。MCP server 通过 stdio 连接，不需要网络。
ChromaDB 是默认后端，但也可以切到 Qdrant、pgvector，甚至可以开一个纯 sqlite_exact 后端做精确向量比对。存储层是插件化的，接口定义在 mempalace/backends/base.py。
MCP 原生，35 个工具
MemPalace 暴露了 35 个 MCP tool。不只是「读写记忆」那类的 CRUD。
有跨 Wing 导航的 tool：从当前对话的 Wing 跳到关联的人/项目的 Wing。有知识图谱操作的 tool：添加实体关系、查询时间线、标记失效区间。有 Agent 日记的 tool：每个 Agent 可以在自己的 Wing 里写执行日志，后续可以被搜索召回。有抽屉管理的 tool：归档、拆分、合并。
一个细节很有意思：每个 Agent 在 MemPalace 里有一个独立的 Wing 和 Diary。Agent 执行任务时可以写执行记录，下次被唤醒时可以搜到上次做了什么、怎么做的、结果怎么样。这意味着 Agent 之间也可以通过共享的 Palace 来传递上下文。
对于用过 MCP 的人来说，接入方式很简单。装好 mempalace 之后，在 MCP 客户端配置里加一段 stdio server 配置就行。Claude Code、Codex CLI、Gemini CLI、Cursor IDE 都有现成的 hooks 和配置模板。
三个月，三十个版本
MemPalace 从 3.0 发布到 3.5，只用了不到三个月。Changelog 里能看到迭代节奏极快：
3.0（4 月 5 日）：架构搭好，Palace 四层模型、MCP server、AAAK 方言、benchmark 套件
3.1：加了 mine --mode convos，可以直接吞 Claude Code 的 JSONL 对话记录。Hooks 机制上线——Agent 每次对话结束自动存档
3.2：加了知识图谱，带时间窗的实体关系。sweep 命令上线，可以按消息粒度重建索引
3.3：支持多语言 embedding（embeddinggemma-300m），benchmark 扩展到 LoCoMo、ConvoMem、MemBench
3.4：后台服务模式 mempalace daemon。Closet 压缩从手动变自动。混合检索引擎重写
3.5（当前）：前后端分离架构（mempalace service + CLI），WAL 写入保护，Windows 全路径支持
节奏快得不正常。这种速度通常意味着要么代码质量在崩，要么团队对问题域的理解非常清晰。看测试覆盖率从 30% 拉到 85%，以及每个版本都带完整的 benchmark 复现脚本，我更倾向于后者。
跟你的 Agent 系统对接
回到实际问题。如果你在用 Hermes Agent 或者类似的 MCP Agent 框架，怎么把 MemPalace 接进来？
最直接的用法是 MCP server。在你的 mcp.json 或者 Hermes 的 MCP 配置里加上 mempalace 的 stdio server，Agent 就自动获得 35 个记忆工具。
然后是 hooks。如果你用 Claude Code 或者 Codex CLI，MemPalace 提供了现成的 hooks 脚本，每次对话结束自动触发 mempalace mine。对话记录变成可搜索的记忆，不依赖 Claude 或 Codex 自身的 session 管理。
再进一步，你可以给不同的 Agent 分配不同的 Wing。比如「代码审查 Agent」写在自己的 Wing 里，「部署 Agent」写在另一个 Wing。当审查 Agent 被唤醒时，它先搜自己的 Wing 看看昨天的审查记录，再跳到部署 Agent 的 Wing 看上次发布是否引入了新问题。跨 Wing 导航的 MCP tool 就是为这种场景设计的。
对于需要完全离线的企业部署，整个流程只需要 Python 3.9+ 和 300MB 磁盘装 embedding 模型。没有外部依赖，没有莫名其妙的 API 费用，没有数据出境的问题。
但也不是没缺点
先说一个架构上的取舍：MemPalace 不做增量更新。Drawer 是追加的，旧的 Drawer 不会自动过期或合并。如果你连续说了一周同一件事，Palace 里会有七份几乎相同的记录。虽然去重逻辑能处理一部分，但索引体积会持续增长。mempalace compress 可以手动触发压缩，但不是全自动的。
Changelog 里能看出稳定性还在爬坡。前几个版本有过 WAL 文件大小超标、Windows 编码问题、跨平台路径分隔符不一致等问题。修得很快，但毕竟是个三个月的项目，生产环境部署需要自己测一遍。
另外 benchmark 的数字虽然漂亮，但 LongMemEval 是一个学术基准——500 道选择题，不是真实的生产环境查询。MemBench ACL 2025 上的 80.3% 更接近现实。96.6% 是一个上限估计，实际使用感受可能低于这个数。
最后，MemPalace 的思路不适合所有场景。如果你的 Agent 需要主动「理解」用户偏好并做出推断（不只是召回原文），你还是需要 LLM 来做「从记忆中推理」。MemPalace 解决的是记忆检索问题，不是记忆推理问题。它找到原文，但不负责解释。
方向比实现重要
MemPalace 让我重新想的一件事是：AI 记忆到底该做多少？
过去两年大家都在往记忆系统里塞 LLM。提取用 LLM，摘要用 LLM，检索用 LLM，融合用 LLM。每个环节都想用 AI 做点什么。但 MemPalace 走到 96.6% 只用了一句话：「存原文，搜原文」。
这就是那种「做得越少反而越好」的项目。不是技术更先进，是假设更少。不做信息压缩就不丢信息。不丢信息，搜索命中率自然高。
对做 Agent 系统的人来说，这个教训可以迁移到很多地方。你的 Skill 是不是在过度设计？你的 prompt 链是不是太长了？你在用 LLM 做的那些事，有没有一个更简单的版本——不需要推理，只需要存和搜？
56K 个 Star 说了同一句话：有时候，最好的设计是知道自己不该做什么。
MemPalace — https://github.com/MemPalace/mempalace | 56,906 stars | MIT | Python 3.9+
当前版本 v3.5.0 | 发布周期：2026.04 – 2026.07