MemPalace 深度解析：一个让 AI 拥有"永久记忆"的本地开源系统，到底怎么用？

快速摘要： MemPalace 是一个完全本地运行的开源 AI 记忆系统，它采用"记忆宫殿"分层架构，将你与 AI 的所有对话内容按原文逐字存储，再通过语义检索快速定位信息。 在 LongMemEval 基准测试中，其 raw 模式召回率达到 96.6%（无需任何 API 调用），是目前公开测试中表现最出色的方案之一。它基于 Python 3.9+，底层依赖 ChromaDB 和 SQLite，整个系统只有 21 个 Python 文件，约 300 MB 磁盘占用，却提供了 19 个 MCP 工具用于与主流 AI 工具集成。往下看，莫潇羽@源码七号站 将为你详细拆解它的设计原理、技术架构、安装配置到实际使用的全流程。

一、为什么我们需要一个"AI 记忆系统"？

如果你是一个重度 AI 使用者，大概率遇到过这样的困境：你和 AI 花了一个下午讨论某个技术方案的选型，反复权衡了 GraphQL 和 REST 的优劣，甚至调试了一段很复杂的代码。当你满意地关掉对话窗口，第二天再打开同一个 AI 工具时——它什么都不记得了。你的思考过程、调试记录、决策依据，统统消失在了那个被关闭的会话里。

这不是某一个 AI 工具的问题，而是几乎所有主流大语言模型面临的通病。大模型的上下文窗口是有限的，一次对话结束后，之前的内容就不再被保留。有些工具提供了"记忆"功能，但它们通常的做法是让 AI 自行判断哪些内容"值得记住"，然后提取一些关键事实（比如"用户偏好 Postgres"），丢弃掉整段讨论的上下文。

这种做法的问题在于：AI 选择记住的，未必是你真正需要的。那些调试时的灵光一现、架构讨论中的反复权衡、以及"我们试了 X 方案但因为 Y 原因失败了"这样的关键推理过程，往往在 AI 的"筛选"中被丢掉了。

MemPalace 正是为解决这个问题而生的。它的核心理念非常直接：不做任何筛选，不做总结，不做改写——原封不动地保存所有对话原文，然后通过高效的语义检索让你随时找到需要的信息。

你可以把它想象成一个专门为 AI 对话设计的"搜索引擎"——它不评判什么信息重要、什么信息不重要，而是把所有信息都保留下来，当你需要的时候用最快的方式帮你找到。这种设计看似"笨"，但恰恰避免了"聪明过头"带来的信息丢失风险。

根据项目文档的估算，一个每天使用 AI 的重度用户，六个月下来大约会产生 1950 万个 token 的对话量。这个数字听起来很惊人，但想想看——每天几小时的编程讨论、需求分析、问题排查，积少成多就是这个量级。如果没有一个有效的记忆系统，这些宝贵的知识积累就像沙子一样从指缝间流走了。更要命的是，你甚至不知道自己丢失了什么，因为你根本不记得三个月前讨论过的那个技术方案细节。

二、MemPalace 的诞生背景

MemPalace 项目于 2026 年 4 月初在 GitHub 上线，发布后迅速获得了大量关注。截至莫潇羽@源码七号站发稿时，该项目已经斩获超过 4 万颗 Star，成为近期 GitHub 上最热门的开源项目之一。

该项目采用 MIT 开源协议，由 Milla Jovovich 和开发者 Ben Sigman 共同创建。据公开信息显示，Jovovich 在 2025 年底开始密集使用 AI 工具，在使用过程中深感现有 AI 记忆方案的不足——尤其是那些由 AI 自行判断"什么值得记住"的系统，经常丢失她真正需要的推理上下文和决策过程。于是，她拉上 Sigman，花了几个月时间用 Claude Code 从零开始构建了 MemPalace。

项目的 GitHub 地址为：https://github.com/MemPalace/mempalace

官方文档托管在：https://mempalaceofficial.com

需要特别提醒的是，MemPalace 官方在 README 中明确声明：唯一的官方来源是 GitHub 仓库、PyPI 包和 mempalaceofficial.com 文档站点。 其他任何域名（包括 mempalace.tech 等）都不是官方渠道，下载时请注意辨别，以免遭遇安全风险。

三、"记忆宫殿"架构：灵感来自古希腊的记忆术

MemPalace 这个名字并不是随便取的。它借鉴了古希腊修辞学家使用的一种经典记忆技巧——"记忆宫殿"（Method of Loci）。这种方法的原理是：在脑海中构建一座虚拟的建筑，把需要记忆的内容按照空间位置摆放在建筑的不同房间里。当你需要回忆时，只需要在脑海中"走过"这座建筑，就能按顺序找到对应的信息。

MemPalace 把这种空间化的记忆组织方式映射到了一个具体的数据结构中，形成了清晰的五层层级体系：

Wings（翼楼） 是最顶级的分类维度。每一个项目、每一个协作对象、或者每一个主题领域，都对应宫殿中的一座翼楼。比如你同时在做一个电商项目和一个博客系统，那它们就分别拥有各自的翼楼。所有关于这个项目的记忆，都存放在对应翼楼的空间内。

Halls（大厅） 是翼楼内部按记忆类型划分的走廊。每座翼楼都有相同类型的大厅，包括事实（facts）、事件（events）、建议（advice）、情感上下文（emotional context）等。这样的设计意味着，无论你在讨论哪个项目，同一类型的记忆总是被存放在结构上相同的位置。

Rooms（房间） 是大厅内部按具体子主题划分的空间。比如在一个 Web 项目的翼楼中，可能存在 auth（认证）、billing（计费）、deployment（部署）等不同的房间。每个房间聚焦一个特定的子议题。

Drawers（抽屉） 是存放原始内容的最终容器。你与 AI 的对话原文、代码片段、决策记录，都以逐字逐句的方式保存在抽屉中。这是 MemPalace 最核心的存储单元——不做任何总结和提取，保存的就是真实的原始文本。

Closets（壁橱）和 Tunnels（隧道） 是辅助结构。壁橱存放压缩后的 AAAK 格式摘要，指向原始抽屉内容，可以在搜索时作为加速索引使用。隧道则是跨房间的交叉引用，连接不同上下文中的相关记忆。

这种层级结构的核心价值在于：它让检索不再是对着一个巨大的扁平索引做全量搜索，而是可以逐层缩小范围——先定位到翼楼，再定位到大厅和房间，最后在特定的抽屉集合中做精准的语义匹配。 根据项目方公布的基准测试数据，仅靠这种结构化的层级约束，就能将检索准确率从 60.9% 提升到 94.8%，提升幅度达到 34 个百分点。

莫潇羽@源码七号站觉得这种设计思路非常值得借鉴——它不依赖复杂的算法，只是通过合理的信息组织方式就获得了显著的效果提升。

四、核心设计原则：逐字存储 + 零 LLM 写入路径

MemPalace 的技术架构有一个非常鲜明的特点：整个写入路径中不涉及任何大语言模型调用。

这意味着什么？当你把对话内容、项目文件、聊天记录导入到 MemPalace 时，所有的文本切分、分类、标签分配、元数据提取，全部是通过确定性的规则完成的——正则表达式匹配、关键词频率统计、路径名推断、启发式评分。没有一步需要调用 GPT、Claude 或任何其他大模型的 API。

这带来了几个实际好处：

零成本运行。 不需要 API Key，不会产生任何 token 费用。对于长期大量使用 AI 的用户来说，这一点非常重要。根据项目文档的估算，一个重度 AI 用户六个月的对话量大约为 1950 万个 token。如果用传统的需要 LLM 参与的记忆系统来处理这个量级的数据，API 调用开销会非常可观。

确定性和可预测性。 因为不涉及 LLM，写入过程是完全确定的——同样的输入永远产生同样的输出。不会出现"AI 今天觉得这段对话重要、明天觉得不重要"的情况。

离线可用。 整个系统可以在完全断网的环境下运行，对网络没有任何依赖。

具体来说，MemPalace 的写入流程是这样工作的：

当你使用 mempalace mine 命令导入内容时，系统首先会对文本进行切分（默认每个 chunk 800 字符，100 字符重叠）。然后，对于项目文件，它使用一个包含约 60 个关键词到房间映射的规则表来判断每段内容应该归入哪个房间——先检查文件的目录路径（比如 /auth/ 目录下的文件自动归入 auth 房间），再检查文件名，最后根据内容中的关键词进行评分。对于对话记录，系统会用 5 组关键词集对每段内容的前 2000 个字符进行匹配（比如"技术类"关键词集包含 code、python、api、bug 等 13 个关键词），得分最高的类别决定该内容的归属房间。

分类完成后，文本被转化为向量嵌入，存储到 ChromaDB 中的统一集合（mempalace_drawers）里，同时附带 wing、room、hall、date 等元数据标签。这些元数据就是后续检索时用于缩小搜索范围的"坐标"。

五、检索机制：语义搜索 + 元数据过滤

存得好只是第一步，找得到才是关键。MemPalace 的检索策略可以分为几个层次：

5.1 基础 Raw 模式

最基本的检索方式是直接在 ChromaDB 上做向量近邻搜索。你输入一个查询（比如"为什么我们改用了 GraphQL"），系统把查询转换为向量，然后在所有抽屉的嵌入向量中找到语义最接近的 Top-K 条结果。

这个模式在 LongMemEval 基准测试上的召回率（R@5）达到了 96.6%。需要强调的是，这个分数是在零 API 调用的条件下取得的——完全依靠本地的向量检索，没有用到任何 LLM 重排或增强。

5.2 结构化过滤

得益于记忆宫殿的层级结构，你可以在搜索时指定翼楼、房间等元数据来缩小范围。比如：

# 在所有记忆中搜索
mempalace search "为什么我们改用了 GraphQL"

# 只在 driftwood 项目的记忆中搜索
mempalace search "auth 相关决策" --wing driftwood

# 进一步限定到 auth-migration 房间
mempalace search "Clerk vs Auth0" --room auth-migration

这种逐层收窄的搜索方式，本质上是在向量搜索之前先做了一次元数据过滤。虽然在技术层面上这并不是什么全新的发明（任何向量数据库都支持元数据过滤），但 MemPalace 通过记忆宫殿的隐喻，给这种技术提供了一套直观、易理解的使用范式。

5.3 混合搜索模式（Hybrid v4）

在 MemPalace 的较新版本中，检索系统引入了混合搜索模式，将向量相似度搜索（权重 60%）和 BM25 关键词匹配（权重 40%）结合起来。这种组合的好处是：向量搜索擅长捕捉语义相似性，而 BM25 擅长精确匹配特定的名称、项目代号和错误信息等关键词。两者互补，能够覆盖更多的检索场景。

在混合模式下，召回率可以进一步提升到 98.4%。如果再叠加 LLM 重排（比如使用 Haiku 模型对检索结果做二次排序），理论上可以达到更高的水平——不过这就需要 API 调用了，不再是完全本地化的流程。

5.4 关于基准测试分数的客观说明

这里莫潇羽@源码七号站需要做一些补充说明。MemPalace 的基准测试数据在社区中曾引发过一些讨论。最初项目方声称在 LongMemEval 上取得了 100% 的分数，但后来社区分析发现，其中有 3 个问题是在发现系统回答错误后专门做了针对性修复再重测的，存在"过拟合测试集"的嫌疑。经过社区反馈后，项目方将主打分数修正为调优前的 96.6%。

此外，在 LoCoMo 基准测试上的 100% 得分也被指出存在方法论问题：LoCoMo 的会话内容只有 19-32 个条目，而 MemPalace 使用了 top_k=50 的检索窗口——当检索窗口大于候选池时，自然能检索到所有内容。

不过，即便考虑这些争议，96.6% 的 raw 模式分数（无 API 调用、纯本地向量检索）在同类系统中仍然是非常有竞争力的。作为对比，Mem0 等需要云服务和 API 的方案大约在 85% 左右。

六、AAAK 压缩：一种 AI 可读的文本缩写方言

MemPalace 还包含一个颇具创意的实验性功能：AAAK 压缩方言。

AAAK 的设计目标是把冗长的对话文本压缩到原来体积的约 1/30，同时保证压缩后的内容仍然可以被任何大语言模型直接阅读理解——不需要专门的解码器。它本质上是一种结构化的英文缩写体系，而不是二进制编码。

一条 AAAK 记录的格式大致如下：

# 头部
FILE_NUM|PRIMARY_ENTITY|DATE|TITLE

# 内容卡片（Zettel）
ZID:ENTITIES|topic_keywords|"key_quote"|WEIGHT|EMOTIONS|FLAGS

# 交叉引用（Tunnel）
T:ZID<->ZID|label

# 情感弧线（Arc）
ARC:emotion->emotion->emotion

其中，实体名称会被压缩为三字母大写代码（比如 Alice→ALC，Kai→KAI）。举个具体的例子：

原始对话：

"我们决定用 GraphQL 替代 REST，因为前端团队需要灵活的查询能力。Kai 在调研了两种方案后推荐的。团队对 schema-first 的方式很兴奋。"

压缩后的 AAAK 表示：

0:KAI|graphql_rest_decided|"decided to use GraphQL instead of REST"|determ+excite|DECISION+TECHNICAL

这种压缩的实际价值在于：对于积累了数月甚至数年对话历史的重度用户，原始文本量可能达到数百万甚至上千万 token。AAAK 可以将这些内容大幅压缩，使得在有限的上下文窗口中能加载更多的历史信息。

具体到 AAAK 的压缩机制，它是完全基于规则的处理流程，主要包含以下几个步骤：首先是实体识别，通过正则表达式匹配对话中出现的人名、项目名等实体，为每个实体分配一个三字母大写缩写码。然后是关键词频率统计，从对话内容中提取最具代表性的主题关键词。接着是句子评分，根据包含决策动词、技术术语、情感词汇等特征，对每个句子的重要性进行打分，选出最关键的引用。最后是情感和标签分类，通过预定义的情感词典和标签词典，为每段内容标注情感状态（如 excited、frustrated、determined 等）和分类标签（如 DECISION、TECHNICAL、EMOTIONAL 等）。

整个过程不涉及任何 LLM 调用，每一步都是确定性的规则匹配和模板填充。这保证了压缩过程的高速和零成本，但也意味着压缩的"智能"程度有限——它无法像 LLM 那样理解深层语义并做出高质量的摘要。

AAAK 的一个有趣特性是它的"壁橱（Closet）"机制。压缩后的 AAAK 内容被存放在壁橱中，每个壁橱都包含指向原始抽屉的引用指针。在检索时，壁橱作为一个加速索引层来使用——系统先在壁橱中进行快速匹配，找到相关的压缩摘要，然后通过指针"展开"到对应的原始抽屉内容。这种设计让壁橱成为一个可选的"增强信号"，即使壁橱的匹配不够准确，直接在抽屉层面的搜索仍然会正常运行，保证了系统的稳健性。

不过，必须坦率地指出：AAAK 是有代价的。 使用 AAAK 压缩模式后，在 LongMemEval 上的检索准确率会从 96.6% 下降到 84.2%，有约 12.4 个百分点的损失。这是因为压缩后的文本改变了向量嵌入的分布，影响了语义搜索的精度。因此，AAAK 是一个可选的折中方案——它用检索质量换取存储效率，在大规模场景下可能值得考虑，但在对准确率要求较高的场景中，使用默认的 raw 模式更为稳妥。

AAAK 压缩也是完全基于规则的（正则表达式 + 字典查找 + 模板），不涉及 LLM 调用。

七、四层渐进式加载：170 token 就能唤醒记忆

MemPalace 在上下文管理上有一个很精巧的分层加载设计。它将记忆分为四个层级，按需递进加载：

L0 层（身份层）：大约 50 个 token。包含最基本的身份信息——你是谁、当前在做什么项目。这些信息保存在 identity.txt 文件中，每次启动时都会加载。

L1 层（关键事实层）：大约 120 个 token。包含当前项目最重要的 15 条信息——技术栈、团队成员、关键决策等。系统通过遍历所有元数据并按重要性排序，自动筛选出最关键的条目。

L2 层（按需检索层）：不主动加载，只在 AI 需要回答特定问题时通过语义搜索按需拉取。

L3 层（完整存档层）：所有原始的抽屉内容，是最完整的数据层级。

这意味着 MemPalace 的启动成本极低——只需要加载 L0 + L1，总共大约 170 个 token，就能为 AI 提供足够的上下文基础。剩余 95% 以上的上下文窗口都可以留给当前对话使用。作为对比，如果你用传统的 CLAUDE.md 文件来管理记忆，随着内容增长，这个文件可能膨胀到数千行，每次启动都要全量加载，大量吞噬宝贵的上下文空间。

使用 mempalace wake-up 命令即可完成唤醒：

# 生成唤醒上下文
mempalace wake-up

# 或者输出到文件，供本地模型使用
mempalace wake-up > context.txt

八、知识图谱：带时间窗口的事实管理

除了向量化的对话存储，MemPalace 还内置了一个基于 SQLite 的实体关系知识图谱。这个图谱的特别之处在于：每条事实都有时间有效期。

在实际使用中，信息是会随时间变化的。比如"小明负责认证模块"可能在三个月后变成"小明转去了支付团队，认证模块交给了小红"。传统的平面文本记忆（如 CLAUDE.md）面临的一个常见问题就是陈旧信息——没人去清理过时的数据，导致 AI 基于错误的旧信息做出判断。

MemPalace 的知识图谱通过以下方式解决这个问题：

# 添加一个事实（实体关系三元组）
# 比如：小明 -> 负责 -> 认证模块（从 2026-01-01 起）

# 当事实发生变化时，标记旧事实失效
# 小明 -> 负责 -> 认证模块（2026-01-01 至 2026-04-01 失效）

# 添加新事实
# 小红 -> 负责 -> 认证模块（从 2026-04-01 起）

# 查询特定时间点的状态
# "2026 年 3 月谁负责认证模块？" -> 小明
# "现在谁负责认证模块？" -> 小红

你可以查看完整的时间线，追踪任何实体的历史变化。这个功能完全用 SQLite 本地实现，不需要额外的数据库服务。

通过 MCP 工具，AI 可以直接对知识图谱进行查询和更新：

• mempalace_kg_query：查询知识图谱中的事实
• mempalace_kg_add：添加新的事实三元组
• mempalace_kg_invalidate：标记事实失效
• mempalace_kg_timeline：查看实体的完整时间线

九、完整安装与配置教程

下面莫潇羽@源码七号站手把手带你走一遍 MemPalace 的安装和配置流程。

9.1 环境要求

在开始之前，请确认你的系统满足以下条件：

• Python 3.9 或更高版本（推荐 3.11+ 以获得最佳性能），通过 python --version 确认
• pip 包管理器（随 Python 自带），通过 pip --version 确认
• 约 300 MB 的磁盘空间（用于默认的嵌入模型）
• 一个 MCP 兼容的 AI 客户端（如 Claude Code、ChatGPT、Cursor 等）——如果你打算通过 AI 工具直接交互的话

9.2 安装 MemPalace

安装过程非常简单，一行命令搞定：

pip install mempalace

安装完成后，通过以下命令验证：

mempalace --version
# 应该输出类似 3.x.x 的版本号

9.3 初始化记忆宫殿

安装完成后，需要为你的项目初始化一座记忆宫殿：

mempalace init ~/projects/myapp

这个命令会完成以下操作：

• 自动检测你目录中的人物和项目结构
• 在 ~/.mempalace/ 下创建配置文件（config.json 全局配置、wing_config.json 翼楼映射、identity.txt 身份层）
• 生成 AAAK 引导文件
• 建立初始的翼楼结构

初始化过程中，你可以交互式地确认或调整自动推断的分类结果。

9.4 导入内容（挖掘）

MemPalace 使用 mine 命令将现有内容导入到记忆宫殿中。支持三种模式：

项目文件挖掘——将代码和文档导入：

mempalace mine ~/projects/myapp

对话记录挖掘——将 AI 对话的导出文件导入：

mempalace mine ~/chats/ --mode convos

MemPalace 支持导入 Claude 对话记录、ChatGPT 导出文件和 Slack 导出等格式。如果你的导出文件是多次对话合并在一起的大文件，可以先用 split 命令拆分：

mempalace split ~/chats/all_conversations.json

通用模式——自动分类到 decisions（决策）、preferences（偏好）、milestones（里程碑）、problems（问题）、emotional（情感上下文）五个类别：

mempalace mine ~/notes/ --mode general

在挖掘过程中，系统会对内容进行切分（800 字符/段，100 字符重叠）、关键词分类、向量化嵌入，然后存入 ChromaDB。整个过程不调用任何外部 API，完全在本地完成。

9.5 连接 Claude Code（推荐方式）

MemPalace 与 Claude Code 的集成是最成熟的。有两种配置方式：

方式一：通过 Claude Code 插件（推荐）

claude plugin marketplace add milla-jovovich/mempalace
claude plugin install --scope user mempalace

安装后重启 Claude Code，输入 /skills 确认 mempalace 已出现在可用技能列表中。这种方式会自动配置好 MCP 服务器和自动保存钩子。

方式二：手动添加 MCP 服务器

claude mcp add mempalace -- python -m mempalace.mcp_server

如果选择手动方式，你还需要单独配置自动保存钩子（下文会介绍）。

配置完成后，Claude Code 就拥有了 19 个 MemPalace MCP 工具，可以在对话中直接读写你的记忆宫殿。

9.6 连接其他 AI 客户端

MemPalace 同样支持其他 MCP 兼容的 AI 工具：

ChatGPT：进入 Settings → MCP，添加新服务器，command 填 mempalace，argument 填 mcp。ChatGPT 会自动检测可用工具。

Cursor：进入 Settings → MCP，添加与 Claude Code 相同的配置。Cursor 原生支持 MCP，MemPalace 工具会自动出现在 Composer 和 Agent 面板中。

本地模型（Llama 等）：生成唤醒上下文后手动注入：

mempalace wake-up > context.txt
# 将 context.txt 的内容粘贴到本地模型的 system prompt 中

也可以通过 Python API 直接调用：

from mempalace.searcher import search_memories

results = search_memories(
    "auth 相关的决策",
    palace_path="~/.mempalace/palace"
)

9.7 配置自动保存钩子（Claude Code）

如果你使用 Claude Code 并且是通过插件方式安装的，钩子已经自动配置好了。如果是手动安装，则需要配置两个钩子：

Save Hook（保存钩子）：每隔 15 条消息自动触发一次结构化保存，将当前对话中的主题、决策、引用、代码变更等内容存入记忆宫殿，同时刷新关键事实层（L1）。

PreCompact Hook（预压缩钩子）：在 Claude Code 进行上下文压缩之前触发，执行紧急保存，确保在上下文窗口缩小前不丢失任何重要信息。

这两个钩子的配置信息需要添加到 settings.local.json 中。具体的配置格式可以参考项目仓库中 hooks/ 目录下的说明文档。

值得一提的是，新版本的钩子脚本已经从 Bash 改写为 Python，修复了早期版本中存在的 Shell 注入风险（旧版本中来自 JSON 输入的 SESSION_ID 被直接用在文件路径中，可能导致路径遍历攻击）。

十、日常使用：搜索、查看和管理

安装配置完成后，你的日常工作流程可以大致概括为以下几个环节。

10.1 搜索记忆

搜索是你最常用的操作。MemPalace 提供了灵活的命令行搜索接口：

# 基础全局搜索
mempalace search "为什么选了 GraphQL"

# 按翼楼限定范围
mempalace search "部署配置" --wing ecommerce-app

# 按房间进一步限定
mempalace search "JWT 过期策略" --room auth

# 查看宫殿状态
mempalace status

如果你是通过 MCP 与 AI 工具集成的，搜索会更加自然。你只需要在对话中问问题，AI 会自动调用 mempalace_search 工具去记忆宫殿中检索相关内容，然后基于检索到的原始对话来回答你。

10.2 "先查再答"协议

MemPalace 内置了一个巧妙的行为引导机制。每次 AI 调用 mempalace_status 工具时，系统会在返回结果中注入一段"Memory Protocol"指令，教导 AI 遵循以下行为模式：

• 启动时调用 mempalace_status 加载宫殿概览
• 在回答任何关于人物、项目或历史事件的问题之前，先搜索记忆，不要凭猜测回答
• 如果不确定，说"让我查查"然后查询宫殿
• 每次会话结束后，写日记记录会话中发生的事情
• 当事实发生变化时，失效旧事实并添加新事实

这种设计本质上是一种 prompt engineering 技巧——通过工具返回值中嵌入的协议文本来引导 AI 的行为。虽然不是强制性的（AI 可能不总是严格遵循），但在实践中效果良好，能显著减少 AI "凭空捏造"回答的情况。

10.3 Agent 日记

MemPalace 为每个 AI Agent 提供了独立的日记功能。Agent 可以在对话结束时记录一段日记，概述本次会话的要点、做了什么决策、遇到了什么问题。这些日记保存在对应 Agent 的翼楼中，为后续回顾提供了方便的时间线记录。

通过 mempalace_diary_write 和 mempalace_diary_read 两个 MCP 工具即可完成日记的读写。

10.4 查看宫殿结构

想了解当前记忆宫殿的整体状态，可以使用：

# 查看宫殿统计
mempalace status

# 列出所有翼楼
mempalace list-wings

# 查看特定翼楼下的房间
mempalace list-rooms --wing myapp

# 查看完整的分类体系
mempalace taxonomy

十一、技术栈与项目结构一览

MemPalace 的技术栈刻意保持了轻量：

整个项目只有 21 个 Python 文件，代码规模非常精简。莫潇羽@源码七号站在查看项目结构时，注意到核心模块的分工还是比较清晰的：

• mempalace/backends/base.py：定义了向量存储后端的接口规范
• mempalace/backends/ 目录：存放具体的后端实现（默认为 ChromaDB）
• mempalace/mcp_server.py：MCP 服务器入口
• mempalace/searcher.py：检索逻辑
• mempalace/room_detector_local.py：基于规则的房间分类器（处理项目文件）
• mempalace/convo_miner.py：对话记录挖掘器
• mempalace/palace_graph.py：宫殿导航图构建
• hooks/ 目录：Claude Code 的自动保存钩子脚本
• benchmarks/ 目录：基准测试用例和运行器

可插拔的后端架构

MemPalace 的检索后端是完全可替换的。默认使用 ChromaDB，但如果你有其他向量数据库的偏好（比如 Milvus、Qdrant、Weaviate 等），只需要实现 mempalace/backends/base.py 中定义的接口就行——包括文档的增删改查和向量搜索方法。替换后端不需要修改系统的其他部分，这种设计给了项目很好的扩展空间。

关于默认后端 ChromaDB，这里莫潇羽@源码七号站多说几句。ChromaDB 是一个用 Python 编写的开源嵌入式向量数据库，它的最大特点是可以直接在你的 Python 进程内运行，不需要单独启动一个数据库服务。这使得 MemPalace 的部署变得异常简单——安装完 pip 包之后就能直接使用，不需要额外安装和配置数据库服务。

在 MemPalace 的实现中，所有的记忆（包括抽屉内容和 Agent 日记）都存储在 ChromaDB 的同一个集合 mempalace_drawers 中。每条记录包含原始文本、向量嵌入、以及 wing、room、hall、date、importance 等元数据字段。检索时，系统先根据你指定的元数据条件（翼楼、房间等）进行过滤，再在过滤后的结果集中做向量近邻搜索。这种"先过滤后搜索"的策略，就是层级结构带来检索提升的技术本质。

不过，所有数据集中在一个 ChromaDB 集合中也带来了一些潜在的扩展性问题。根据社区的分析，当抽屉数量达到 22K 级别时基准测试表现良好，但对于更大规模的数据（比如十万级甚至百万级的记录），ChromaDB 的内嵌模式可能面临内存和查询延迟方面的挑战。目前还没有大规模使用场景下的公开测试数据，这也是为什么 MemPalace 提供了可插拔后端接口——如果你的数据规模足够大，可以考虑切换到更适合大规模部署的向量数据库。

十二、19 个 MCP 工具详解

MCP（Model Context Protocol）是一种让 AI 工具连接外部能力的标准协议。MemPalace 提供了 19 个 MCP 工具（部分文档中提到 29 个，这与版本迭代有关），覆盖了记忆系统的各个操作维度。按功能可以分为以下几组：

读取类（约 11 个）——用于查询和导航记忆宫殿：

• mempalace_status：查看宫殿状态，返回翼楼数量、房间数量、抽屉总数等统计信息，同时注入 Memory Protocol
• mempalace_search：语义搜索，支持按翼楼/房间过滤
• mempalace_list_wings：列出所有翼楼
• mempalace_list_rooms：列出指定翼楼下的所有房间
• mempalace_taxonomy：查看完整的分类体系
• mempalace_duplicate_check：检查内容是否已存在，避免重复存储
• mempalace_tunnel_finder：查找跨房间的交叉引用
• mempalace_graph_stats：宫殿导航图统计
• mempalace_kg_query：查询知识图谱
• mempalace_aaak_spec：获取 AAAK 压缩规范
• mempalace_list_agents：列出所有注册的 Agent

写入类（约 3 个）——用于向宫殿添加内容：

• mempalace_add_drawer：添加新抽屉（自动去重）
• mempalace_delete_drawer：删除抽屉
• mempalace_kg_add：添加知识图谱三元组

知识图谱管理（约 3 个）：

• mempalace_kg_invalidate：标记知识图谱事实失效
• mempalace_kg_timeline：查看实体时间线
• mempalace_kg_stats：知识图谱统计

日记工具（2 个）：

• mempalace_diary_write：写入 Agent 日记
• mempalace_diary_read：读取 Agent 日记

当 AI 首次调用 mempalace_status 时，系统返回的信息中包含了 AAAK 方言的说明，AI 可以自动学习如何解读压缩格式，不需要用户做额外配置。

十三、多语言支持与国际化

在较新的版本中，MemPalace 已经加入了多语言支持。CLI 输出、AAAK 压缩指令和正则匹配模式都进行了本地化适配，目前支持的语言包括：英语、法语、韩语、日语、西班牙语、德语、简体中文和繁体中文。

如果你需要添加对其他语言的支持，只需翻译一个 JSON 配置文件即可。同时，项目在 GitHub 上也有专门的中文社区讨论帖（Issue #37），方便中文用户交流使用经验和问题排查。

十四、适用场景与局限性

适合哪些人使用？

开发者是 MemPalace 最直接的受益群体。如果你每天都和 AI 结对编程、讨论架构、调试问题，MemPalace 能帮你保留完