MemPalace ：本地全量存储的 AI 记忆系统，96.6% 长记忆召回率的实现逻辑

做了这么多年大模型应用开发，最头疼的问题从来不是模型效果不够，而是记忆留不住。和AI聊过的架构方案、踩过的坑、拍板的决策，会话一关就彻底消失。半年下来，几百次调试、几十场技术评审，全变成了聊天记录里的死数据，真要复盘的时候，翻都翻不到。

市面上的记忆方案不是没有，但要么走摘要路线，把上下文压缩成几句干巴巴的结论，推理过程和权衡逻辑全丢了；要么走云服务路线，数据全传上去，隐私没保障不说，一年下来成本大几千。更关键的是，大多数记忆系统都是让AI来判断“什么值得记”，本质上还是在做信息过滤，你永远不知道它丢了什么。

直到刷到MemPalace这个项目，第一反应是“终于有人做对了方向”——不做摘要、不做筛选、全量存储，靠结构化的“宫殿”架构来组织信息，纯本地运行，零API调用，LongMemEval基准测试拿下96.6%的R@5召回率。

先算一笔账：AI记忆到底有多贵

很多人没算过，日常用AI的记忆成本其实高得离谱。按每天和AI工作对话来算，六个月大概会产生1950万token的对话数据，这里面有决策、有调试过程、有架构权衡，全是知识资产。

不同的处理方案，成本天差地别：

这不是百分比的差距，是数量级的差距。更重要的是，摘要式记忆丢了上下文，你只知道“我们选了Postgres”，但不知道为什么选、当时否决了什么方案、踩过什么坑。而MemPalace存的是逐字原文，所有推理过程都在。

MemPalace到底是什么

不是又一个RAG框架，也不是云记忆服务，是一个完全运行在本地机器上的AI记忆系统。核心逻辑来自古老的“记忆宫殿”记忆法——古希腊演说家把知识点放在想象的建筑里，回忆的时候走一遍建筑就能想起来。MemPalace把这个思路工程化了，把所有对话、文档、代码都组织成“翼-厅-房-壁橱-抽屉”的层级结构，语义检索的时候先定位到具体区域，再查内容，召回率比平库检索高34%。

整个项目完全开源，MIT协议，不需要账号，不需要订阅，不需要联网，安装之后所有数据都存在你自己的硬盘上，不会有任何数据流出本机。目前最新版本是v3.3.0，依赖只有Python 3.9+、ChromaDB和PyYAML，轻量到离谱。

核心架构：宫殿结构的工程化实现

整个宫殿的层级结构非常清晰，从大到小依次是翼、厅、房间、壁橱、抽屉，跨主题之间还有隧道连接。

翼（Wing）

最高层级单元，每个项目、每个人、每个大主题单独一个翼。比如你负责的电商项目是一个翼，团队里的核心成员是一个翼，技术选型专题是一个翼。系统会自动从内容里识别翼，也可以手动指定。

厅（Hall）

翼内部的一级分类，所有翼共用统一的厅类型，相当于记忆的维度：

• hall_facts：已经确定的决策、定版的选择、固化的事实
• hall_events：会话记录、项目里程碑、调试过程
• hall_discoveries：技术突破、新发现、新见解
• hall_preferences：个人习惯、技术偏好、观点倾向
• hall_advice：方案建议、问题解决方案、最佳实践

厅的设计非常巧妙，它不是按内容主题分，而是按信息类型分。这样不管在哪个项目翼里，所有的决策都归在facts厅，所有的问题都归在events厅，结构非常规整，AI检索的时候知道去哪个厅找对应类型的信息。

房间（Room）

具体的主题单元，比如auth-migration（认证迁移）、graphql-switch（GraphQL切换）、ci-pipeline（CI流水线）。同一个房间名称如果出现在不同的翼里，会自动生成隧道，跨翼关联同一个主题。

举个例子：

• 人物翼Kai / 事件厅 / 认证迁移房间 → “Kai调试了OAuth token刷新问题”
• 项目翼driftwood / 事实厅 / 认证迁移房间 → “团队决定把认证迁移到Clerk”
• 人物翼Priya / 建议厅 / 认证迁移房间 → “Priya认可Clerk优于Auth0”

同一个主题，三个不同的翼，通过隧道自动关联。查“认证迁移”的时候，能同时看到人物、项目、建议三个维度的信息，不会漏。

壁橱（Closet）

房间里的摘要索引层，存放指向原始内容的摘要和索引。当前版本是纯文本摘要，后续版本会接入AAAK压缩。壁橱的作用是快速过滤，让AI先看摘要判断有没有用，有用再打开抽屉看原文，不用每次都加载全量内容。

抽屉（Drawer）

最底层的存储单元，存放原始的逐字内容，一点都不修改，一点都不摘要。这是整个系统高召回率的核心——你永远不会丢失原始信息，检索的时候可以精准定位到原文的某一句话。

隧道（Tunnel）

跨翼的连接通道。当同一个房间名出现在不同翼里的时候，系统会自动创建隧道，把不同维度的同一主题关联起来。也可以手动创建隧道，建立自定义的关联。

这个结构不是拍脑袋想出来的，是经过22000+真实对话记忆测试验证的：

这里必须说明白，这个34%的提升本质是元数据过滤带来的，是ChromaDB本身就支持的功能，不是什么革命性的新检索算法。官方自己也澄清了这一点，没必要吹成黑科技，但实用性确实很强——就像你找文件，知道在哪个文件夹哪个子目录，肯定比全盘搜索快得多、准得多。

四层内存栈：让AI“睡醒就记得你”

很多记忆系统是每次提问都全量检索，慢还费token。MemPalace做了分层加载，不同场景加载不同层级的记忆，平时只带最少的token，需要的时候再深度搜索，非常符合人类的记忆模式。

L0 身份层

约50 token，永远加载。内容就是identity.txt里的纯文本，告诉AI“你是谁，你的角色是什么”。相当于人的自我认知，永远不会忘。

L1 关键事实层

约120 token（AAAK压缩后），永远加载。包含核心团队信息、主要项目、核心偏好，相当于AI的“常识”。不用每次都问你叫什么、做什么项目、喜欢什么技术栈，一上来就知道。

L2 房间回忆层

按需加载。当对话聊到某个已知主题的时候，自动加载对应房间的相关记忆，比如聊到认证，就把认证相关的决策、问题、方案都拉出来。数据量不大，刚好够支撑当前话题的上下文。

L3 深度搜索层

按需加载。只有当用户明确问历史问题，或者AI判断需要查久远历史的时候，才会触发全库语义搜索，从抽屉里拉原始内容。

平时AI醒着的时候，只加载L0+L1，总共600-900 token，几乎不占上下文空间。聊到具体话题，自动拉L2的内容进来。真要查历史久远的事，再走L3全库搜。

做Agent开发的都知道，上下文窗口是最宝贵的资源。很多方案一上来就塞几千字的记忆，直接把一半窗口占了，后面推理效果直接下降。MemPalace这个分层思路非常务实，把记忆按使用频率和重要性分级，热数据常驻，冷数据按需加载，既不浪费token，又保证了记忆的完整性。

AAAK压缩方言：理想和现实的差距

AAAK是MemPalace里最有话题性的功能，也是争议最大的。刚发布的时候宣传“30倍无损压缩”，后来官方自己出来认错，说夸大了。这里把事实说清楚，不吹不黑。

AAAK本质是一种有损缩写系统，通过实体编码、结构标记、句子截断，把重复出现的实体和关系打包成更少的token。它不需要专门的解码器，任何能读英文的LLM都能看懂，Claude、GPT、Gemini、Llama、Mistral都可以直接用。

目前的真实状态

1. 是有损，不是无损。基于正则替换实现，不是可逆压缩，会丢失部分信息，不是什么“无损压缩”。
2. 小体量下反而费token。官方之前举的短文本例子，用真实的OpenAI tokenizer计算，原文66 token，AAK压缩后是73 token，反而更多。因为编码、分隔符有固定开销，短文本本身token效率就高，压缩的收益覆盖不了开销。
3. 大体量下才有收益。当同一个实体被提到几百次、同一个项目横跨几千个会话，实体编码的成本被摊薄，才能真正节省token。它是为大规模重复场景设计的，不是给几段话压缩用的。
4. 召回率低于原始模式。LongMemEval测试中，raw原始模式96.6% R@5，AAAK模式只有84.2%，差了12.4个百分点。压缩率和召回率的trade-off客观存在。
5. 不是默认存储格式。默认存在ChromaDB里的还是原始逐字文本，AAAK只是上下文加载的时候可选的压缩层，不是存的时候就压。存储用raw，加载的时候可选AAK，这个定位很清晰。

官方现在也在迭代，换了真实的tokenizer来统计，优化断点逻辑。我的判断是，AAAK的思路是对的，针对“记忆里大量重复实体”这个场景做定向压缩，比通用压缩效率高，但现在还在实验阶段，生产环境优先用raw模式就好，AAAK可以尝鲜，别抱太高预期。

带时间维度的知识图谱：不是只有静态三元组

很多记忆系统都带知识图谱，但大多数是静态的，事实变了还要手动改，时间长了全是错误信息。MemPalace的知识图谱做了时间有效性窗口，每个三元组都有生效时间和失效时间，查的时候可以指定时间点，看当时的事实是什么样的。

核心API和用法

from mempalace.knowledge_graph import KnowledgeGraph

kg = KnowledgeGraph()

# 添加三元组，带生效时间
kg.add_triple("Kai", "works_on", "Orion", valid_from="2025-06-01")
kg.add_triple("Maya", "assigned_to", "auth-migration", valid_from="2026-01-15")
kg.add_triple("Maya", "completed", "auth-migration", valid_from="2026-02-01")

# 查询实体当前状态
kg.query_entity("Kai")
# 返回：[Kai → works_on → Orion (current), Kai → recommended → Clerk (2026-01)]

# 查询指定时间点的状态
kg.query_entity("Maya", as_of="2026-01-20")
# 返回：[Maya → assigned_to → auth-migration (active)]

# 查询项目时间线
kg.timeline("Orion")
# 返回按时间排序的完整项目事件链

# 标记一个事实失效
kg.invalidate("Kai", "works_on", "Orion", ended="2026-03-01")


失效之后，查询当前状态不会再返回这条，但查询历史时间点仍然可以查到。人员变动、方案调整、项目结项，都可以用失效来处理，不会污染当前的知识，又能保留历史记录。

做项目管理的都懂，静态知识图谱很快就过时了，全是错误信息。带时间维度的话，历史数据和当前数据能分开，不会出现“人已经走了还说他负责这个项目”的尴尬情况。

和主流方案的对比

我之前做企业知识图谱的时候，用Neo4j部署一套成本很高，还要专门维护服务器。MemPalace直接用SQLite存，轻量到离谱，个人开发者或者小团队用完全够用，而且数据全在自己手里，对于涉密项目或者敏感对话，这是刚需。

矛盾检测（实验中）

项目里还有个fact_checker.py工具，可以检查输入的断言和知识图谱里的事实是否矛盾，比如：

• 输入“Soren完成了认证迁移” → 检测到归属冲突：负责的是Maya，不是Soren
• 输入“Kai来这里2年了” → 检测到任期错误：记录显示3年，2023年4月入职
• 输入“这周五冲刺结束” → 检测到日期过期：当前冲刺周四结束，两天前刚更新

目前这个功能还是单独的工具，还没集成到知识图谱的主流程里，不能自动触发。官方说正在接进去，后续版本会上线。

29个MCP工具：和AI原生集成

MemPalace不是让你手动敲命令搜记忆，而是通过MCP协议直接接进AI里，AI自己会调用工具搜记忆，你根本感觉不到它的存在。

MCP全称Model Context Protocol，是Anthropic推出的标准协议，现在Claude、ChatGPT、Cursor、Gemini都支持。MemPalace实现了完整的MCP服务器，一共29个工具，分成七大类：

宫殿读取类

• mempalace_status：宫殿整体概览 + AAAK规范 + 记忆协议
• mempalace_list_wings：列出所有翼及对应数量
• mempalace_list_rooms：列出指定翼下的所有房间
• mempalace_get_taxonomy：完整的翼→厅→房间层级树
• mempalace_search：带翼/房间过滤的语义搜索
• mempalace_check_duplicate：存入前检查重复
• mempalace_get_aaak_spec：AAAK方言完整规范

宫殿写入类

• mempalace_add_drawer：存入文件逐字内容
• mempalace_delete_drawer：按ID删除抽屉

知识图谱类

• mempalace_kg_query：带时间过滤的实体关系查询
• mempalace_kg_add：添加三元组事实
• mempalace_kg_invalidate：标记事实失效
• mempalace_kg_timeline：实体时间线
• mempalace_kg_stats：图谱统计概览

导航类

• mempalace_traverse：从一个房间出发跨翼遍历图谱
• mempalace_find_tunnels：查找连接两个翼的房间
• mempalace_graph_stats：图谱连接性统计
• mempalace_create_tunnel：手动创建跨翼隧道
• mempalace_list_tunnels：列出所有隧道，可按翼过滤
• mempalace_delete_tunnel：按ID删除隧道
• mempalace_follow_tunnels：从房间出发追踪所有关联隧道

抽屉管理类

• mempalace_get_drawer：按ID获取单个抽屉
• mempalace_list_drawers：分页列出抽屉
• mempalace_update_drawer：更新抽屉内容或元数据

Agent日记类

• mempalace_diary_write：写AAAK格式的日记条目
• mempalace_diary_read：读取最近的日记条目

系统类

• mempalace_hook_settings：获取/设置钩子行为
• mempalace_memories_filed_away：检查最近是否保存成功
• mempalace_reconnect：外部写入后强制重连数据库

AI会自动从mempalace_status的返回里学习AAAK方言和记忆协议，不需要手动配置。装完之后直接用就行，AI自己知道什么时候该调用什么工具。

自动保存钩子

针对Claude Code，还有两个自动保存钩子，不用手动存：

• 保存钩子：每15条消息触发一次结构化保存，提取话题、决策、引用、代码变更，同时更新L1关键事实层
• 预压缩钩子：上下文压缩之前触发，紧急保存，防止窗口收缩丢失内容

配置也很简单，在Claude的钩子配置里加两行就行。还可以设置MEMPAL_DIR环境变量，钩子会自动对指定目录执行mine操作，后台自动挖掘新的对话和文件。

三种使用场景：从开箱即用到深度定制

场景一：Claude Code用户，直接装插件

这是最简单的方式，官方推荐，适合大多数人。

# 从市场安装插件
claude plugin marketplace add milla-jovovich/mempalace
# 安装到用户作用域
claude plugin install --scope user mempalace


装完重启Claude Code，输入/skills验证有没有mempalace，有就成功了。之后正常聊天就行，记忆会自动保存，问题会自动搜索，你完全感觉不到它的存在。

场景二：MCP兼容工具，通用方案

ChatGPT、Cursor、Gemini CLI这些支持MCP的工具，都可以用这种方式接入。

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


接完之后AI就能调用所有29个工具，体验和Claude插件差不多。Gemini CLI还支持自动处理服务器和保存钩子，更省心。

场景三：本地模型，完全离线

Llama、Mistral这些本地模型，大多还不支持MCP，有两种用法：

1. 唤醒命令：把核心事实导出来，放到系统提示里

mempalace wake-up > context.txt


把context.txt的内容粘到模型的系统提示里，大概600-900 token，AI一上来就知道你的基本情况、项目背景、核心偏好。

2. CLI搜索 + Python API：按需搜索，把结果拼到prompt里

mempalace search "auth decisions" > results.txt


或者用Python API灵活调用：

from mempalace.searcher import search_memories

results = search_memories(
   "auth decisions",
   palace_path="~/.mempalace/palace",
   wing="orion"
)


拿到结果之后拼到prompt里发给模型就行，全程离线，数据不出本地机器。

我自己用本地Llama 3测试过，wake-up模式的效果超出预期，几百个token就能把项目的核心决策、人员分工、技术栈都讲清楚，比自己写系统提示全面多了。做离线Agent开发的话，这个方案非常合适，完全不用依赖云服务。

从零到一完整上手流程

1. 安装

要求Python 3.9+，直接pip安装：

pip install mempalace


依赖只有chromadb>=0.4.0和pyyaml>=6.0，没有其他乱七八糟的东西，装起来很快。

2. 初始化宫殿

找一个你要管理的项目目录，执行init：

mempalace init ~/projects/myapp


会走引导流程，生成配置文件、AAAK引导，自动识别项目里的人和主题，生成翼配置。

3. 挖掘数据

三种挖掘模式，对应不同数据源：

• projects模式：挖掘代码、文档、笔记，适合项目目录

mempalace mine ~/projects/myapp


• convos模式：挖掘对话导出，Claude、ChatGPT、Slack的导出都支持

mempalace mine ~/chats/ --mode convos


• general模式：自动分类，把内容分成决策、里程碑、问题、情感上下文

mempalace mine ~/chats/ --mode convos --extract general


建议挖的时候指定翼标签，把数据归到对应的翼里，后面检索效率高很多：

mempalace mine ~/chats/orion/ --mode convos --wing orion


我一开始踩过坑，直接把整个聊天目录丢进去，没指定翼，结果所有内容都归到了默认翼里，后面没法按项目过滤。大家注意这点，按项目或者按人分类挖掘，结构会清晰很多。

4. 大文件拆分

有些对话导出会把很多会话拼成一个大文件，直接挖掘效果不好，可以先用split命令拆成单个会话文件：

# 拆分
mempalace split ~/chats/

# 预览拆分结果
mempalace split ~/chats/ --dry-run

# 只拆分包含3个以上会话的文件
mempalace split ~/chats/ --min-sessions 3


拆完再挖，分类会准确很多。

5. 搜索验证

挖完之后搜一下试试：

mempalace search "why did we switch to GraphQL"


返回的是原始的对话内容，不是摘要，是逐字的原文，连当时的代码片段、表情符号都在。

6. 查看状态

mempalace status


能看到宫殿的整体情况、翼的数量、房间数量、AAAK规范、记忆协议。

官方亲自澄清的几个问题：

MemPalace刚发布的时候宣传有点激进，结果社区几个小时就找出了问题，官方直接发了长文认错，这点挺难得的。把几个关键澄清说清楚，避免大家踩坑：

1. AAAK的token数例子错误。之前用len(text)//3这种粗略方式估算token，实际用OpenAI的tokenizer算，短文本AAAK反而更费token。官方已经在重写例子，找能真正体现压缩优势的场景。
2. “30倍无损压缩”夸大了。AAAK是有损缩写系统，不是无损压缩，有信息丢失，召回率比raw模式低12.4个百分点。96.6%的头部分数是raw模式的，不是AAAK的。
3. “+34%宫殿提升”有误导性。这个对比的是无过滤搜索和翼+房间元数据过滤，元数据过滤是ChromaDB的标准功能，不是什么新的检索机制，有用但不是技术护城河。
4. “矛盾检测”还没集成。现在只是个单独的工具，不能自动运行，官方正在接到知识图谱主流程里。
5. “Haiku重排序100%”是真的，但没开源。重排序管道没放到公开的基准脚本里，官方正在补充进去。而且100%是混合模式，需要调用API，不是纯本地。

我很欣赏这种态度。开源项目就该这样，有问题直接认，不藏着掖着。比起那些吹得天花乱坠、实际用起来全是坑的项目，MemPalace至少诚实，你清楚地知道它能做什么、不能做什么。

专项Agent：每个领域自己的专属记忆

很多人做Agent都是一个大脑记所有事，结果什么都记不深。MemPalace支持做专项Agent，每个Agent有自己的翼和日记，专注一个领域，知识越积累越专业。

你可以建多个专项Agent，比如：

• 评审员Agent：专门记代码质量、bug模式、最佳实践
• 架构师Agent：专门记设计决策、技术选型、权衡逻辑
• 运维Agent：专门记部署方案、故障案例、基础设施问题

每个Agent的配置文件都在~/.mempalace/agents/目录下，JSON格式。你的CLAUDE.md里只需要加一行：

You have MemPalace agents. Run mempalace_list_agents to see them.


AI运行的时候会自动发现这些Agent，每个Agent自己写日记，用AAAK压缩，跨会话持久化。评审员见过的bug模式越多，下次评审越准；架构师记得的决策越多，下次给方案越贴合你的习惯。

对比一下，Letta做Agent托管记忆要20-200美元一个月，MemPalace用一个翼就实现了，免费，纯本地。

基准测试：数据说话

所有测试结果都是可复现的，基准脚本都在项目的benchmarks目录里，自己就能跑。

几个关键事实：

• 96.6%的raw分数，是目前公开的、不需要API密钥、不需要云端、全程不用LLM的LongMemEval最高分。
• 这个分数是可复现的，有开发者在M2 Ultra上不到5分钟就跑完了，结果一致。
• 加Haiku重排序能到100%，但需要调用API，就不是纯本地了，相当于用额外的LLM做精排。
• 测试用了500道题，覆盖各种记忆场景。

和其他主流系统的对比：

纯本地零调用的场景下，MemPalace是第一梯队的。如果愿意调用API加重排序，还能更高，但那就失去本地的意义了。

Java开发者怎么玩

我自己做Java开发这么多年，拿到一个Python项目第一反应就是怎么和Java生态结合。MemPalace虽然是Python写的，但有几种方式可以无缝集成到Java项目里。

方式一：命令行调用

最直接的方式，Java里用ProcessBuilder执行mempalace命令，拿输出结果。适合简单的搜索场景，不用写太多代码。

/**
* Java调用MemPalace搜索示例
*/
public class MemPalaceClient {
   public List<String> search(String query, String wing) throws IOException {
       ProcessBuilder pb = new ProcessBuilder(
           "mempalace", "search", query, "--wing", wing
       );
       pb.redirectErrorStream(true);
       Process process = pb.start();
       
       List<String> results = new ArrayList<>();
       try (BufferedReader reader = new BufferedReader(
               new InputStreamReader(process.getInputStream()))) {
           String line;
           while ((line = reader.readLine()) != null) {
               results.add(line);
           }
       }
       return results;
   }
}


优点是简单，不用额外部署；缺点是每次都要启进程，频繁调用的话性能一般。

方式二：Python API + 本地HTTP服务

把MemPalace的Python API包装成一个本地HTTP服务，Java用RestTemplate或者Feign调用。适合频繁调用的场景，性能比每次启进程好很多。

用FastAPI写个简单的包装，几十行代码：

from fastapi import FastAPI
from mempalace.searcher import search_memories
from mempalace.knowledge_graph import KnowledgeGraph

app = FastAPI(title="MemPalace Local Service")

@app.get("/api/search")
def search(query: str, wing: str = None, room: str = None):
   results = search_memories(query, wing=wing, room=room)
   return {"code": 0, "data": results}

@app.get("/api/kg/{entity}")
def query_kg(entity: str, as_of: str = None):
   kg = KnowledgeGraph()
   result = kg.query_entity(entity, as_of=as_of)
   return {"code": 0, "data": result}


Java那边正常调接口就行，相当于一个本地的记忆服务，部署在开发机或者内网服务器上都可以。

方式三：集成到Spring AI

如果你在做Java版的AI Agent，比如Spring AI项目，可以把MemPalace作为记忆组件，替代掉默认的内存记忆或者向量记忆。

实现思路很简单：

1. 初始化的时候加载L0和L1层，注入到系统提示
2. 每次对话的时候，根据消息内容判断要不要加载L2房间记忆
3. 用户明确问历史问题的时候，触发L3深度搜索

我自己做了个简单的实现，测试下来比默认的InMemoryChatMemory好用太多，尤其是多轮对话多了之后，不会因为上下文窗口不够而丢前面的记忆，需要的时候能从MemPalace里捞出来。对于需要长期记忆的Agent场景，这个方案非常合适。

已知问题和注意事项

说优点也要说缺点，客观才可信。目前版本还有一些已知问题，大家心里有数：

1. AAAK还在实验阶段，召回率不如raw模式，生产环境优先用raw模式存储。
2. 矛盾检测功能还没集成到主流程，现在只能手动跑工具。
3. macOS ARM64有段错误的问题，官方在修（Issue #74）。
4. 钩子有shell注入风险，官方在修（Issue #110）。
5. ChromaDB版本还没固定，可能有兼容性问题，官方打算钉到测试过的版本范围（Issue #100）。
6. 没有官方网站。现在出现了很多假冒网站，有的带病毒、有的弹广告，别乱下。官方只有GitHub仓库和PyPI发布，其他都是假的。

我的判断和展望

做了这么多大模型应用，我越来越觉得，记忆才是AI的核心壁垒。模型可以换，接口可以换，但积累下来的记忆、决策、经验，是真正属于你的资产。

MemPalace最打动我的地方，是它的“本地优先”和“全量存储”。现在很多项目都在往云端走，把用户的数据都圈到自己服务器里，美其名曰“智能记忆”，实则是绑架用户数据。MemPalace反其道而行之，所有数据都在你本地，不需要账号，不需要订阅，不需要联网，完全开源。

全量存储更是反常识的思路。所有人都在说“信息太多要过滤”，但记忆这个东西，你永远不知道哪句话哪天会用到。摘要式记忆看似高效，实则把推理过程和上下文都丢了，真要复盘的时候，你只知道结论，不知道为什么得出这个结论，等于白记。MemPalace选择全量存，靠结构和检索来提效，虽然存储量大一点，但换来了100%的信息完整性，这个trade-off我认为是值得的。

未来这个项目还有很大的想象空间：AAAK成熟之后，上下文能装更多记忆；矛盾检测集成之后，能自动修正知识图谱里的错误；支持更多数据源接入，比如Notion、飞书、企业微信。如果能出Java版本就更好了，不过现在这样也够用了。

给大家一个建议：如果你天天和AI打交道，做项目、写代码、搞架构，一定要试试MemPalace。花半小时装一下，把历史对话导进去，用一周你就回不去了。AI的记忆，就该掌握在自己手里。