知识图谱 on Kalend's Blog

AI Agent的'遗忘症'怎么治？三层方案从金鱼脑到长期记忆

Fri, 24 Jul 2026 08:30:00 +0800

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

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

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

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

先搞清楚病因。

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

限制	表现
物理上限	128K窗口大约装10万字中文，一个复杂项目的完整上下文轻松超限
成本线性增长	token越多越贵，1M窗口一次调用可能几块钱
信息衰减	“Lost in the Middle"效应——中间的信息被遗忘，首尾偏好
跨会话断连	关掉对话窗口，一切归零

那向量检索（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"。

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

怎么写、怎么更新

写热记忆的原则：

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

更新方式：手动编辑文件，或者在对话中告诉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里找，不会被无关信息干扰。

容量和性能

当前实际运行数据：

指标	数值
总Drawer数	21,986
Wing数	14
底层存储	ChromaDB（本地SQLite）
单次查询延迟	<100ms
存储成本	零（纯本地）

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

适用场景

场景	是否适合语义搜索
查找历史对话	✅ 语义匹配，模糊查询
技术记录检索	✅ 按wing/room分类存储
项目详情	✅ 长文本切块后存储
精确关系查询	❌ “谁负责后端"这种结构化问题
时间序列分析	❌ 需要专门的时间窗口支持

语义搜索解决了"跨会话的深度记忆"问题，但它的底层还是文本匹配。当你需要查询结构化的关系信息——“项目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/全文检索）

决策逻辑很简单：

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

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

遗忘机制

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

三种遗忘机制：

机制	触发方式	作用
kg_invalidate	手动标记	知识图谱中的事实失效，设valid_to=今天
热记忆清理	定期审计	删除过时的高频信息，释放context空间
sync清理	文件删除后同步	删除源文件时自动清理对应的存储条目

避坑指南

坑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

记忆系统设计：从短期记忆到持久化知识图谱

Thu, 18 Jun 2026 08:40:06 +0800

记忆系统设计：从短期记忆到持久化知识图谱

开篇结论：为什么大多数 Agent 都是"金鱼脑"

先用一句话下结论：2026 年所有主流 Agent Memory 方案本质仍是"高级结构化笔记本"——能存能查能更新，但不会主动学习/总结规律/主动适配。

这不是贬义，是现实。我上周用代码助手写了一周代码，关掉终端重开就全忘：项目架构、代码风格偏好、调试进度、踩过的坑——这些上下文全丢了。这不是工具的错，是记忆系统的设计难题。

先别管"AI 时代来了"这种废话。用"失忆症"这个真实痛点切入：当你用 Claude Code/OpenClaw 写代码，每次重开都要从头解释项目背景，这不是技术能解决的问题，是记忆系统的本质缺陷。

第一层：工作记忆（短期）—— 上下文窗口就是它的全部

短期记忆 = 当前对话/任务的上下文，受限于模型 context window。

怎么管：滑动窗口、摘要压缩、关键信息锚定。

局限：ephemeral（易失），窗口满了就丢。

这是所有 Agent 的起点，也是上限。无论你后面加多少层记忆层，能直接访问的还是窗口里的内容。这也是为什么大部分 Agent 都是"金鱼脑"——窗口一滚，前段对话就没了。

第二层：情景记忆（会话级）—— 对话历史的压缩与检索

跨会话记住发生了什么。

这层在 2023-2024 年是主流：向量记忆技术。做法是把对话历史转 embedding 存向量库，下次检索最相似片段塞回上下文。

但问题来了：vibes-based retrieval（基于模糊联想的检索）在需要精确段落时完全失效。向量检索擅长模糊联想，但找不到精确段落；不理解时间因结果、不区分新旧事实。

典型场景：你的项目从 React 迁移到 Vue，两条记录都有"框架迁移"的语义相似度，向量检索两条都返回。但一个是历史事实（已无效），一个是当前事实。向量库分不清。

第三层：长期记忆（持久化）—— 向量库 vs 结构化存储

这层的核心问题是：什么场景用向量（模糊联想、相似度），什么场景用结构化（精确事实、可更新）。

2024-2025 年出现了三条路线：

OS 启发路线

UC Berkeley MemGPT 论文——上下文窗口=内存，外部存储=硬盘，Agent 像操作系统管理虚拟内存。三层：Core Memory（主存）、Archival Memory（归档可搜索）、Recall Memory（回忆机制）。这条路线催生了 Letta 公司，GitHub 35k stars。

知识图谱路线

Graphiti/Zep ——时序知识图谱，每条事实带 valid_at/invalid_at 时间戳，新信息到来时旧事实被自动废止而非删除，保留变化轨迹。Graphiti GitHub 32k stars，2026 年仍活跃更新。

认知科学路线

斯坦福 Generative Agents（小镇模拟）——观察→反思→规划三层，能从日常观察合成高层反思。

写入时智能 vs 读取时智能的工程权衡：

路线	代表	策略	适合
写入时智能	Mem0	存储时提取分类	高频检索
读取时智能	Engram	广泛存储，检索时计算	信息丰富场景

Mem0 这条路线在 2025 年底拿了 4200 万美元 B 轮融资，GitHub 68k stars，证明写入时智能有市场。

第四层：知识图谱（关系网络）—— 何时该上，何时不该

知识图谱不是终点，是特定场景的解决方案。

Graphiti 的图谱路线：实体+关系+时间，时序知识图谱，新事实自动废止旧事实而非删除（valid_at/invalid_at）。

关键警告：过早引入知识图谱是经典坑——需求没验证就建复杂系统。什么规模/复杂度才值得上图谱？

知识图谱 vs 向量库不是二选一，是混合。2025-2026 年的趋势是混合存储架构：向量+图+全文+结构化。

关键设计决策（实战核心）

遗忘机制：记忆不该只增不减

艾宾浩斯遗忘曲线、衰减策略，学会遗忘和学会记忆一样重要。

2026 年新出现的"做梦"机制：仿生记忆整合。OpenClaw Auto-Dream（三阶段睡眠循环+90天衰减遗忘曲线）、MemoryBank（艾宾浩斯遗忘曲线）。这是从认知科学借来的理念。

记忆分级：热/温/冷存储分层（类比 CPU 缓存 L1/L2/L3）

这是多快好省的工程实践：高频访问的信息放热层（工作记忆+情景记忆），低频访问的放冷层（长期记忆+知识图谱）。

写入时 vs 读取时智能的工程权衡

没有绝对的对错，看场景。高频检索用写入时智能（存的时候多花点 CPU，查的时候快）；信息丰富场景用读取时智能（存的时候少花点 CPU，查的时候多算）。

四层模型一句话总结

工作记忆=寄存器，情景记忆=L1 缓存，长期记忆=内存，知识图谱=关系型数据库。这个比喻不完美，但能帮你快速理解分层逻辑。

避坑指南

记忆污染/安全：Zombie Agents（记忆注入攻击）、跨用户污染

SSGM 治理框架开始出现，企业级需要审计追踪/角色隔离/GDPR 遗忘权。这不是危言耸听，是真实的生产事故。

“上下文泡沫”：记忆越多越受限，过度拟合历史偏好不再探索新方案

记忆系统容易把历史偏好固化：用过 React 就一直推 React，哪怕项目早该换技术栈。这是"记得太多"反而限制了探索新方案。

“记忆到认知的鸿沟”：能记 50 个 bug 但总结不出模式——存事实≠理解模式

HN 上有个帖子吐槽 Mem0：“stores memories, but doesn’t learn user patterns”——存事实≠理解模式。能记 50 个 bug，但总结不出"70% 是异步调用顺序问题"。数据湖 vs 数据挖掘的区别：存储事实很简单，从事实中提取洞察很难。

三种典型场景下的选型

场景	推荐方案
高频检索（实时对话）	写入时智能（Mem0）
复杂关系追踪（代码库、社交网络）	知识图谱（Graphiti）
极低延迟（实时交互）	数据库式（Mnemora）
编码 Agent	文件系统式（memU、ReMe）

一个最小可用架构建议：工作记忆（L1）+ 情景记忆（向量检索）+ 长期记忆（结构化存储）。先跑起来，再根据实际需求扩展。

结语

记忆系统的终点不是"记住"，而是"学会"。这不是哲学，是工程现实。

2026 年的技术路线尚未收敛，类似 2010 年 NoSQL 百花齐放阶段。五种架构路线——写入时智能、读取时智能、文件系统式、数据库式、图式——各有优劣，没有银弹。

大厂的态度也很有趣：OpenAI 做平台锁定，Anthropic 坚持无状态，Google 依托生态，Apple 强本地。这更证明没有统一答案。

中国生态有个独特特征：重 RAG 轻 Memory。这可能是因为 RAG 更直接，记忆系统更复杂。

我的建议：别急着上知识图谱，先搞清楚你的真实需求是什么。高频检索？复杂关系？极低延迟？编码场景？每个场景都有对应的优化方向。

记忆系统的设计不是技术问题，是产品设计问题。你想让 Agent 记什么、怎么记、什么时候用——这些问题比选什么框架更重要。

2026 年的记忆系统仍处于早期阶段，没有成熟方案——但这也是为什么值得自己动手设计的原因。

参考资料：

Mem0 GitHub（68k stars）
Letta（前身 MemGPT）（35k stars）
Graphiti（32k stars）
UC Berkeley MemGPT 论文
斯坦福 Generative Agents
学术界 2026 上半年 40+ 篇相关论文
HN 帖子：“Mem0 stores memories, but doesn’t learn user patterns”
社区吐槽：“embedding similarity is great for vibes-based retrieval but terrible when you need a specific paragraph”
MCP 记忆协议、MemSearch（Zilliz）
Zilliz SOC2、$24M 融资（2025）
OpenClaw Auto-Dream、MemoryBank
SSGM 治理框架