第七话｜记忆：模型从不记得任何事，是我们每次把该记住的塞回给它

Tue, 19 May 2026 00:00:00 +0000

第六话结尾，留下了一个没解决的问题。

那一篇我们让循环「断了能接回来」：进度落盘、崩溃恢复、幂等防重做。但回头想，我们忙活的始终是「这一笔订单 O-1001」从头到尾的进度。真实世界里，Agent 不会只处理一笔订单——它今天处理一百笔、明天再处理一百笔。于是问题冒出来了：

处理第 1 笔订单时，Agent 学到「这个 SKU 经常缺货，得先查库存」；到第 100 笔，它还记得吗？还是每一笔都像第一次那样，从头摸索一遍？

「记住这一次任务走到哪了」，和「记住过去做过的那些事、攒下的那些经验」，是两码事。前者第六话解决了；后者——让 Agent 跨任务、跨会话，还记得以前的事——正是这一篇要讲的：记忆。

先立住全文的锚，一句话：

模型从不记得任何事，是我们每次把该记住的东西检索出来、塞回给它的。

一、先看清：模型到底「记得」什么

要讲记忆，得先拆穿一个最常见的误解——以为模型有记忆。

模型没有记忆。每一次调用都是独立的：你发给它的，只有当前这一批 messages。它不记得上一轮说过什么，不记得昨天聊过什么，更不记得半年前你喜欢喝什么。它「看起来记得」，是因为你每次把历史原样塞回去了。

把这一点说透，用一张表：

你以为的	实际发生的
模型记得上一轮	你把上一轮对话塞回了 messages
模型记得你的名字	你把「用户叫张三」这条事实塞回了几轮
模型记得你爱喝茶	你把「偏好：喝茶」塞回了 prompt

所以「记忆」这件事，责任从来不在模型，而在运行它的那层代码。模型只是个无状态的文本补全器；「记不记得住」，取决于你用什么方式、存到哪里、什么时候检索出来喂给它。

这不是杞人忧天。MemGPT 那篇论文（arXiv 2310.08560）做过一个「Deep Memory Retrieval」实验：问一个五个会话之前讨论过的话题，裸的 GPT-4 只有 32.1% 答对——因为相关历史早被截断了；而 MemGPT 靠「把该记住的换进上下文」这套机制，做到了 92.5%。同样的模型，差距全在有没有一层可靠的记忆系统。

这一篇要做的，就是把「你每次塞回去」这件事，从临时的、随手的、手忙脚乱的，变成分层的、持久的、可检索的——这才是「记忆系统」四个字的真正含义。

二、四层记忆，各管一段

人的记忆不是一坨，是分层的。这个分层不是拍脑袋——在 Agent 领域，有一篇被广泛引用的论文把它正式化了：CoALA（Cognitive Architectures for Language Agents，arXiv 2309.02427）。它借鉴经典的认知架构（Soar 等），把语言 Agent 的记忆拆成一层工作记忆 + 三种长期记忆，正好对应四个名字：工作、情节、语义、程序。

层	是什么	存哪	什么时候失效
工作记忆 Working	窗口内的完整对话	内存 `messages`	窗口满、进程重启
情节记忆 Episodic	会话内发生过的关键事实	SQLite	需主动写、主动读
语义记忆 Semantic	跨会话的事实、偏好、知识	向量库（检索）	不检索等于不存在
程序记忆 Procedural	怎么做事的方法、流程	代码 / Skill	本篇不展开

分清楚每层管什么、存哪、怎么失效，是设计记忆系统的第一步。

层	是什么	存哪	什么时候失效
工作记忆 Working	窗口内的完整对话	内存 `messages`	窗口满、进程重启
情节记忆 Episodic	会话内发生过的关键事实	SQLite	需主动写、主动读
语义记忆 Semantic	跨会话的事实、偏好、知识	向量库（检索）	不检索等于不存在
程序记忆 Procedural	怎么做事的方法、流程	代码 / Skill	本篇不展开

四层各存各的，但最终殊途同归——都要在模型需要时，被检索出来、塞回给模型：

flowchart LR
 A[工作记忆
内存 messages] --> E[拼进 prompt]
 B[情节记忆
SQLite 事实表] --> E
 C[语义记忆
向量库检索] --> E
 D[程序记忆
代码/Skill] --> E
 E --> F[无状态的模型
记不记得住全靠这次喂进去]

逐层说。

工作记忆就是第四、五话里那个 messages 列表——模型现在「正在看」的东西。它最直接，也最脆弱：窗口一满，最早的东西被挤掉；进程一重启，全没了。

情节记忆是「这条对话里发生过什么」：用户说他叫张三、说他爱喝茶。把关键事实显式提取出来，存成结构化条目。它的价值不是「存了」，而是比全量历史更省 token、更抗干扰，而且落盘后能活过重启。

语义记忆是「跨会话你还知道什么」：不管哪一任会话，Agent 都「知道」这个用户是 Java 后端、爱喝茶。它靠向量检索——写入时把知识向量化，检索时算相似度召回。

程序记忆是「怎么做一件事」：不是「记住了什么事实」，而是「记住了怎么做」。它和前三层有本质区别——前三层记的是可遗忘的、会过期的事实，程序记忆记的是可复用、经过验证的方法。这是第九话 Skill 系统的引子，这里只点一句。

关键洞察：分层不是为了显得高级，而是因为不同记忆的失效方式不同——窗口会满、会话会结束、进程会重启。分不清层，就不知道该把什么存进哪一层，也不知道什么时候该去检索什么。

三、情节记忆：把关键事实提取出来，落进 SQLite

先从最容易落地的一层下手：情节记忆。

第六话我们已经建立了一个认知——进度要显式化，不和消息耦合。情节记忆同理：与其每次把整段对话塞回去，不如把它缩成几条结构化事实。

class EpisodicMemory:
 def __init__(self, db_path: str):
 self.conn = sqlite3.connect(db_path)
 self.conn.execute(
 """CREATE TABLE IF NOT EXISTS facts (
 id INTEGER PRIMARY KEY AUTOINCREMENT,
 subject TEXT NOT NULL, -- 事实主体
 fact TEXT NOT NULL, -- 事实内容
 session_id TEXT NOT NULL, -- 产生于哪个会话
 created_at TEXT NOT NULL
 )"""
 )

 def add(self, subject, fact, session_id):
 self.conn.execute(
 "INSERT INTO facts(subject, fact, session_id, created_at) VALUES (?,?,?,?)",
 (subject, fact, session_id, datetime.now(TZ).isoformat()),
 )
 self.conn.commit()

注意这里多了一个字段 session_id。它记录「这条事实产生于哪一场会话」，让每一条事实都可追溯归属。至于「情节记忆里的哪些事实，该升格为跨会话的语义记忆」——那是另一道工序，本篇 demo 还没做，但 session_id 是它将来成立的地基：没有归属，就谈不上「把某个会话学到的、沉淀成全局长效的」。

跑起来，你会看到最想看到的那一幕——进程重启后，事实还在：

[1] 情节记忆：关键事实落 SQLite，重启读回
情节记忆已写入 SQLite（3 条）：
 - 用户名: 张三
 - 偏好: 喝茶，尤其是龙井
 - 职业: Java 后端工程师

（模拟进程重启：新开连接，读回）
重启后读回的事实：
 - 用户名: 张三 (session=session-A)
 - 偏好: 喝茶，尤其是龙井 (session=session-A)
 - 职业: Java 后端工程师 (session=session-A)

「进程重启」这一下，正是第六话「断点恢复」的自然延伸：第六话让这一次任务的进度活过崩溃，这一篇让过去会话的事实活过重启。同样是「落盘」，落的东西不一样。

但情节记忆有个天花板：它只能原样读回。你知道「用户爱喝茶」这条事实存在，可当用户问出一句你从没存过原句的话——比如「我平时喜欢喝什么呀？」——你怎么知道该把「喝茶」这一条翻出来？能存，还得能找。 这就引出下一层。

四、语义记忆：不检索，等于不存在

语义记忆要解决的，是「从哪里找」的问题。

存了一万条事实，用户问一句新的话，你不可能把一万条全塞给模型（塞不下，也污染）。你得按语义相似度，挑最相关的几条。这就是「检索」，也是语义记忆和情节记忆的分水岭：

情节记忆回答「发生过什么」，语义记忆回答「和这个问题最相关的是什么」。

检索靠的是向量：把每段文字映射成一个高维向量，语义相近的文字，向量在空间里挨得近。这里的关键，是用真实 Embedding 模型（bge-m3，1024 维）把文字变向量，而不是手动分词去凑：

def embed_one(text: str) -> list[float]:
 payload = {"model": "bge-m3", "prompt": text}
 req = urllib.request.Request(
 f"{EMBEDDING_URL}/api/embeddings",
 data=json.dumps(payload).encode(),
 headers={"Content-Type": "application/json"},
 )
 with urllib.request.urlopen(req, timeout=60) as resp:
 return json.loads(resp.read())["embedding"]

然后存入 Qdrant 向量库，检索时算余弦相似度召回。跑起来看真实的检索结果：

[2] 语义记忆：bge-m3 + Qdrant，跨会话召回（含同义改写）
 问「用户喜欢喝什么？」→ 命中 [用户喜欢喝茶，尤其是龙井] score=0.753
 问「用户爱喝什么饮料？」→ 命中 [用户喜欢喝茶，尤其是龙井] score=0.705
 问「用户职业是什么？」→ 命中 [用户职业是 Java 后端工程师，擅长并发编程] score=0.704
 问「博客写什么？」→ 命中 [用户的博客主题是 AI Agent 开发] score=0.604

盯住第二行。问的是「爱喝什么饮料」，命中的是「喜欢喝茶」——两个词字面上完全不同，但向量空间里挨得很近。

这就是真实 Embedding 的价值，也是它区别于「土法分词」的地方。用纯 bigram 分词做检索，「爱喝」和「喜欢喝」一个字都对不上，匹配为零；而 bge-m3 把同义改写投影到相近向量，「爱喝」和「喜欢喝」照样能对上。语义检索的「语义」二字，靠的就是这一步。

五、这一层真正的坑：上下文的位置

语义检索把最相关的东西找出来了，但故事还没完——找出来之后，塞回给模型时，放在哪个位置，也决定它「记不记得住」。

2023 年一篇论文《Lost in the Middle》（arXiv 2307.03172）量了这个位置效应，结论很扎心：模型是「U 形」阅读者——最关注上下文的两头，几乎忽略中间。在「键值检索」任务里，答案 key 放开头或结尾时准确率约 95%，放中间时跌到约 40%；换成多文档问答，从最好位置到最差位置的落差约 25–30%，而且连明确标榜「长上下文」的模型也躲不掉——这不是窗口不够大，是注意力模式本身的限制。

这对记忆系统的启示一句话就够了：

检索回来之后，别随手一塞。 最重要的几条放到上下文两头，中间留给次要信息。检索只是第一步，排序和摆放同样决定模型「用没用上」你找到的记忆。

这一篇的 demo 检索结果只有几条、短文不触发这个效应，所以这里只作一句提醒——真正做长上下文记忆时，位置问题会和检索问题一起蹦出来。

六、程序记忆：怎么做事，是另一类记忆

四层讲了三层，最后一层只点一句，因为它是独立的一篇。

前三层记的都是事实：你叫什么、爱喝什么、是做什么的。但有一类「记忆」被漏掉了——怎么把事情做对的方法。

「这个 SKU 常缺货，得先查库存」是事实。「处理订单要先查库存、再扣库存、扣完发通知、全程落盘」是方法。方法不存成事实，方法要存成可重复调用的流程——这就是第九话要讲的 Skill。

程序记忆和前三层的本质区别：事实会过期，方法可复用。把「经过验证的做法」固化成资产，Agent 才不是每次都从零摸索。

这里先埋下这个钩子，到此为止。

七、动手实验 + 失败路径

看完原理，跑一遍真的。任务是「让 Agent 跨会话认得你」：先自报姓名与偏好，落盘；再模拟重启、换新会话；最后问一个需要召回的开放式问题。

配套代码在 GYA 仓库（Python）与 GYA-Java 仓库（Java 21），两条命令：

# 离线回归：不依赖 Embedding/Qdrant/LLM（5 项测试）
python3 -m unittest test_memory -v

# 完整演示：真实 bge-m3 + Qdrant + SQLite
export QDRANT_API_KEY=你的key
python3 memory_demo.py

最想让你看到的三段输出，已经贴在第三、四节了。这里补它最有意思的失败路径——也就是「无记忆」时的样子。同样的问法，不给任何上下文：

[3] 无记忆对照：模型没有上下文时，答不上'我是谁'
 模型: 我不知道你是谁，也不知道你叫什么名字。

有记忆时它能答「你是张三，爱喝茶」；没记忆时它只能老实说「我不知道」。这一对照，把「模型从不记得任何事」这句话坐实了——差别不在模型，全在我们有没有把该记住的塞回去。

跑不通时，最常见的三个坑：

Embedding/Qdrant 没起：语义部分会自动降级到离线 TF-IDF（会打 ⚠️）。真实检索需要 Ollama bge-m3 在线、Qdrant 可访问、QDRANT_API_KEY 正确。
Qdrant 写入报 400「not a valid point ID」：Qdrant 的 point id 只认无符号整数或 UUID，不认数字字符串。demo 里已用整数。
Java 版报 SQLITE_IOERR_DELETE：受限沙箱环境（CI/容器化 shell）会拦 SQLite 默认 journal 的 unlink 调用。Java 版 newDb() 里已用 PRAGMA journal_mode=OFF 绕过；正常本地终端可去掉这两行，恢复崩溃安全。

八、总结和下一篇

四层记忆到这里立住了：工作记忆管「现在看什么」，情节记忆管「这次发生过什么」，语义记忆管「跨会话知道什么」，程序记忆管「怎么做」。它们的共同病根只有一个——模型无状态，记不记得住全靠我们把该记住的东西，从持久化存储里检索出来、塞回去。

这一篇让 Agent 记住了「你是谁、你要什么」。但有个更根本的能力还没碰：它怎么接上外部世界——查天气、查库存、调别人家的服务，谁来定接口、谁来负责发现和调用？这是第八话要讲的：MCP。

演示代码：Python 版在 GYA 仓库 c07-memory，Java 21 等价实现在 GYA-Java 仓库 c07-memory。按各自 README 的命令跑，不要复制这篇文章里零散的代码块。参考：Sumers 等, CoALA: Cognitive Architectures for Language Agents（工作/情节/语义/程序四层记忆的出处）；Packer 等, MemGPT: Towards LLMs as Operating Systems（分层记忆与 Deep Memory Retrieval 数据）；Liu 等, Lost in the Middle（上下文位置的 U 形效应）；Embedding 模型 BAAI bge-m3（1024 维）。检索与无记忆对照 Trace 为 2026-09 本机实测（Python 与 Java 双跑，分数一致）。

Qdrant on Renxin's Blog