先说结论：三层方案能治，且完全免费本地运行。

你一定经历过这种崩溃——跟AI说了一百遍"代码用TypeScript不要JavaScript"，换个对话窗口它又问你用什么语言。你跟它讲过的项目背景、踩过的坑、你的审美偏好，下次全部归零。

这不是模型的问题，是架构的问题。LLM天生没有状态，context window有物理上限，窗口关了记忆就没了。之前分析过记忆架构的理论框架，今天直接上手搭——三层方案，从热记忆到语义搜索到知识图谱，照着做就能跑通。

为什么大多数AI助手是"金鱼脑"

先搞清楚病因。

LLM是无状态函数——输入token，输出token，没有内部记忆寄存器。你的"对话历史"就是每次请求时把前面的内容重新塞进context window发给模型。这就是为什么窗口越来越大（从4K到128K到1M），但问题没有根本解决：

那向量检索（RAG）呢？它解决了"找不到"的问题，但没解决"记不准"的问题。向量检索的本质是模糊联想——你问"上次那个数据库迁移方案”，它能找到语义相近的段落，但找不到你说的那一个精确段落。而且它没有结构化能力：“张三负责后端、李四负责前端"这种关系型信息，向量检索搞不定。

所以需要多层方案。每一层解决不同的问题。

第一层：热记忆——每轮都带上你的核心信息

热记忆是最简单也最有效的一层。原理很直白：把最重要的信息写进一个固定文本段，每次对话开始时自动注入到system prompt里。

载体和格式

热记忆通常存在一个markdown文件里，比如这样：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

## 用户偏好
- 代码语言：TypeScript，禁止JavaScript
- 回复风格：先结论后细节，不要铺垫
- 禁止行为：不要用emoji，不要加"首先"/"其次"连接词

## 环境信息
- 操作系统：Debian 13，内核6.12
- 部署方式：Docker Compose，compose文件在~/infra/
- 数据库：PostgreSQL 16，连接串在.env

## 高频踩坑
- Hugo日期必须RFC3339格式，否则日期变0001-01-01
- 又拍云API只支持HMAC-SHA1签名，不支持Basic Auth

工作原理

每轮对话开始时，系统把这段内容注入到system prompt中。模型看到的不是"你是一个通用助手”，而是"你是一个帮忞写代码的助手，用TypeScript，先给结论，不要emoji"。

这就是热记忆的核心——每轮都带上的上下文常量。

怎么写、怎么更新

写热记忆的原则：

1. 只放高频信息。你的项目结构、技术栈、编码习惯——每次对话都需要的
2. 控制在2000字符以内。热记忆占用context window，太长浪费token
3. 用结构化格式。分块（用户偏好/环境/踩坑），用列表不用段落
4. 定期清理。过时的信息及时删除，否则会"污染"新对话

更新方式：手动编辑文件，或者在对话中告诉AI"记住XXX"，它会自动更新热记忆段。

适用场景

热记忆是第一道防线，解决80%的"又忘了"问题。但它的容量有限，跨会话的深度信息需要更深的存储。

第二层：语义搜索——跨会话的"长期记忆"

当信息量超过热记忆的容量限制，或者你需要查找历史对话中的某个细节时，就需要语义搜索层。

这一层的核心是向量数据库——把文本切块、转成向量、存入数据库，查询时用语义相似度匹配。

为什么不用传统搜索

传统搜索（grep、全文检索）是精确匹配。你搜"数据库迁移"，它只找包含这几个字的段落。但用户可能说的是"把MySQL换成PostgreSQL那件事"——语义一样，措辞完全不同。

向量搜索解决的就是这个问题。它把文本编码成高维向量，语义相近的文本在向量空间中距离更近。

实际工具怎么用

以MemPalace为例（57.6k stars，本地免费，ChromaDB底层）：

存储信息：

1
2
3
4
5

mempalace_store(
    wing="devops",           # 域/分类
    room="hugo-blog",        # 主题/子分类
    content="Hugo日期必须用RFC3339格式(2026-05-14T10:00:00+08:00)，否则日期变0001-01-01"
)

语义搜索：

1
2
3
4
5

mempalace_recall(
    query="Hugo日期格式问题",
    wing="devops",           # 可选，限定搜索范围
    top_k=5                  # 返回最相关的5条
)

搜索结果包含文本内容、相似度分数、来源wing/room，可以按相关性排序后注入到当前对话中。

组织结构：Wing-Room-Drawer

MemPalace用三层结构组织信息：

1
2
3
4
5
6
7
8

Wing（域）→ Room（主题）→ Drawer（条目）
───────────────────────────────────────
devops/     hugo-blog/     Hugo日期格式踩坑
                         又拍云API签名问题
            docker/        Compose网络配置
user/       preferences/   编码风格偏好
            background/    技术背景
conversation/ general/     历史对话摘要

这种结构的好处是搜索时可以限定范围——搜Hugo相关的问题只在devops/hugo-blog里找，不会被无关信息干扰。

容量和性能

当前实际运行数据：

2万多个drawer，查询依然在100毫秒内完成。这就是向量数据库的优势——检索时间不随数据量线性增长。

适用场景

语义搜索解决了"跨会话的深度记忆"问题，但它的底层还是文本匹配。当你需要查询结构化的关系信息——“项目A现在的状态是什么”、“张三和李四什么关系”——就需要知识图谱。

第三层：知识图谱——结构化的"关系网络”

向量搜索是模糊匹配，知识图谱是精确查询。

知识图谱的核心是三元组：Subject → Predicate → Object。比如：

1
2
3
4

忞 → 负责 → 博客系统
博客系统 → 使用 → Hugo + Stack主题
博客系统 → 部署到 → 又拍云CDN
忞 → 偏好 → TypeScript

这种结构让查询变得精确——“忞负责什么？“直接返回"博客系统”，不需要语义匹配。

时间窗口：自动废止旧事实

知识图谱最容易出的问题是信息过时。“张三负责后端”，三个月后张三离职了，旧事实还在图谱里，查出来就是错的。

解决方案是时间窗口——每条三元组都有valid_from和valid_to字段：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

# 添加事实
mempalace_kg_add(
    subject="张三",
    predicate="负责",
    object="后端服务",
    valid_from="2026-01"
)

# 后来张三离职了，废止旧事实
mempalace_kg_invalidate(
    subject="张三",
    predicate="负责",
    object="后端服务"
)
# valid_to 自动设为今天

查询时只返回当前有效的事实（valid_to为空或大于今天），过时的信息自动过滤。

实际使用场景

场景1：追踪人物关系

1
2
3
4
5
6
7
8

# 记录团队分工
mempalace_kg_add(subject="张三", predicate="负责", object="后端API")
mempalace_kg_add(subject="李四", predicate="负责", object="前端React")
mempalace_kg_add(subject="项目Alpha", predicate="后端负责人", object="张三")

# 查询：谁负责后端？
mempalace_knowledge(entity="后端API")
# → 张三 → 负责 → 后端API

场景2：追踪项目状态变化

1
2
3
4
5

# 项目状态随时间变化
mempalace_kg_add(subject="项目Alpha", predicate="状态", object="开发中", valid_from="2026-01")
mempalace_kg_invalidate(subject="项目Alpha", predicate="状态", object="开发中")

mempalace_kg_add(subject="项目Alpha", predicate="状态", object="测试中", valid_from="2026-04")

场景3：技术栈关系

1
2
3
4
5
6
7
8

mempalace_kg_add(subject="博客系统", predicate="使用框架", object="Hugo")
mempalace_kg_add(subject="博客系统", predicate="使用主题", object="Stack")
mempalace_kg_add(subject="博客系统", predicate="托管平台", object="又拍云")
mempalace_kg_add(subject="Stack主题", predicate="依赖", object="Hugo 0.144+")

# 查询：博客系统的依赖链是什么？
mempalace_knowledge(entity="博客系统")
# → 返回所有相关三元组

何时该用知识图谱，何时不该

简单判断：如果查询里有"谁/什么/关系/状态/版本"这种结构化关键词，用知识图谱。如果是"上次/记得/聊过/说过"这种模糊回忆，用语义搜索。

四级回忆链：怎么把三层串起来

三层不是独立工作的，它们形成一个级联回忆链：

1
2
3
4
5
6
7

热记忆（每轮自动注入）
    ↓ 没找到？
MemPalace语义搜索（按需查询）
    ↓ 还没找到？
session_search（跨会话精确搜索）
    ↓ 最后手段
结构化文件搜索（grep/全文检索）

决策逻辑很简单：

1. 热记忆：高频、稳定、短文本——每次自动带上，不需要主动查询
2. 语义搜索：中频、长文本、需要模糊匹配——用户提到某个话题时触发
3. session_search：低频、需要精确匹配某个历史对话——明确要求时触发
4. 文件搜索：兜底——其他方式都找不到时，直接grep源文件

这个级联的效率在于：热记忆零成本（已经注入了），语义搜索100ms内返回，session_search秒级，文件搜索最慢但最全。90%的需求在前两层就解决了。

遗忘机制

记忆系统不仅要能记，还要能忘。过时的信息如果不清理，会造成"记忆污染”——AI带着过期信息做决策，比没有记忆更糟糕。

三种遗忘机制：

避坑指南

坑1：过早上知识图谱

最常见的错误。需求还没验证就建复杂系统——三元组设计了一百个关系类型，实际只用到三个。

正确做法：先用热记忆+语义搜索跑一个月，确认确实有结构化查询需求，再加知识图谱。三层方案是渐进式的，不是一步到位的。

坑2：记忆污染

跨会话的过时信息混入当前对话。比如三个月前记录的"项目状态：开发中"，现在已经是"已上线"了，但没有及时更新。

正确做法：给信息打时间戳，定期审计，用kg_invalidate废止过时事实。热记忆更要频繁清理——它每轮都注入，过时信息的伤害最大。

坑3：热记忆膨胀

什么都往热记忆里塞，2000字符变成5000字符，再变成10000字符。结果context window被记忆占了大半，留给实际对话的空间不够了。

正确做法：热记忆只放"每轮都需要"的信息。“偶尔用到的"放语义搜索，“结构性的"放知识图谱。一个判断标准：如果这条信息连续5轮对话都没被用到，就不该在热记忆里。

坑4：向量检索的"记忆泡沫”

向量搜索返回的结果看着相关，但实际上是噪声。比如你问"数据库性能优化”，它返回了"数据库备份方案"——语义相近但不是你要的。

正确做法：用wing/room限定搜索范围，设置相似度阈值过滤低质量结果。语义搜索是召回，不是精确匹配，返回结果需要二次筛选。

落地建议：最小可用方案

不需要三层一步到位。推荐的渐进路线：

第一周：只用热记忆

把用户偏好、技术栈、高频踩坑写进热记忆段，2000字符以内。这一层零成本，立即见效。

第二周：加入语义搜索

安装MemPalace（本地ChromaDB，不需要API Key），开始把重要对话、技术记录存进去。配置wing/room分类结构。

第三周：按需加知识图谱

如果发现经常需要查询"谁负责什么"、“项目状态”、“依赖关系"这种结构化信息，再加知识图谱层。不需要就不加。

整个方案完全本地运行，不需要任何云服务、API Key或月费。MemPalace底层是ChromaDB（SQLite），数据存在本地磁盘，隐私完全可控。

记忆系统的终点不是"记住”，而是"学会"。

三层方案解决的是信息的存储和检索，但真正有价值的是从记忆中提取规律、变成行为。热记忆让你不用重复解释偏好，语义搜索让你不用重复查找历史，知识图谱让你不用重复梳理关系。

把这些省下来的时间和精力，用在真正需要创造力的地方。

— varkm