AI 的记忆到底怎么存的？聊聊 KV Cache、向量库和外部记忆的区别

凌晨 2 点，我的 Agent 又「忘」了我说过的话

上个月有一个深夜，我在跟 SFD Lab 的主力 Agent 小火龙聊一件事，前面说了很多背景，结果对话开头的内容它就忘了。不是因为它笨，是因为上下文窗口装不下了——超出的部分被截掉了。

从那以后我开始认真想一个问题：AI 的「记忆」到底存在哪里？怎么存的？为什么有时候记得住，有时候记不住？这篇文章就是我把这些搞清楚之后的笔记，尽量说人话。

首先搞清楚：AI 有三种「记忆」

你可以把 AI 的记忆系统想成三个抽屉：

第一个抽屉：参数记忆（训练进去的知识）
这是最底层的记忆，烧在模型权重里的。GPT-4 知道「牛顿发现了万有引力」不是因为你告诉它，是训练时见过几千万次这句话，编码进了 700 亿个参数里。这种记忆几乎不会消失，但也不能更新——模型一旦发布，这部分就冻住了。

第二个抽屉：上下文记忆（当次对话的 KV Cache）
这是最常见的「短期记忆」。你跟 AI 说的每一句话，都会被编码成一组 Key-Value 向量，存在 KV Cache 里。模型生成下一个 token 时，会拿当前 query 去和所有历史 KV 做 attention，把相关的内容拉出来参考。

这就是为什么「上下文长度」是个硬指标——128k tokens 的窗口，就是 128k 个位置的 KV 存储上限。超了就必须截掉，没有例外。

第三个抽屉：外部记忆（向量库、文档库）
这是最灵活的一层，也是 RAG 架构的核心。你把文档、笔记、历史对话拆成 chunk，向量化后存到 Qdrant、Pinecone 这类向量数据库里。每次对话时，先检索最相关的几条，塞进 prompt 上下文，模型就「知道」了。

KV Cache 的工作原理（不怕跑）

KV Cache 是理解 LLM 性能的关键，但很多人只知道「缓存」两个字，不知道里面存的是啥。

每一层 Transformer 的 attention 计算，都需要把每个 token 的 Key 和 Value 向量算出来。如果你对话里有 1000 个 token，就有 1000 组 KV 向量，每次生成新 token 都得用到它们。

不用缓存的话，每次生成都要重算所有历史 token 的 KV——计算量随长度平方增长，完全不可用。KV Cache 的做法是：算过一次就存起来，下次生成直接读。这就是为什么长上下文对显存要求高——你的 128k 上下文，每层 Transformer 都要存一份 KV，32 层就是 32 份，乘以每个 KV 向量的维度，轻松干到 40GB+。

我们在 MS01 跑本地模型的时候踩过这个坑。Qwen3.5 35B 在 128k 上下文下，光 KV Cache 就能把 96GB 显存吃掉一大半，剩下给计算的内存反而不够。后来把上下文缩到 32k，稳多了。

向量检索怎么工作？和 KV Cache 有什么区别？

很多人把「向量库」和「KV Cache」搞混，其实是两件完全不同的事。

KV Cache 存的是 transformer 内部的中间状态，是模型推理的基础设施，不暴露给外部。

向量库存的是语义向量——一段文字通过 embedding 模型（比如 BGE、text-embedding-3-small）变成一个 768 维或 1536 维的向量，这个向量代表这段文字的「语义位置」。检索时，把 query 也向量化，找最近邻，就找到了语义最相关的内容。

这两件事的分工很清楚：KV Cache 让模型「记得住当次对话」，向量库让模型「有能力检索历史信息」。一个是短期记忆，一个是长期记忆的检索入口。

SFD 实验室怎么用的？

我们目前 15 个 Agent 的记忆架构大概是这样的：

每个 Agent 的工作上下文保持在 32k 以内（够用，不浪费显存）。超出工作上下文的历史，通过 MEMORY.md 文件持久化——这是一种最朴素的「外部记忆」方案，胜在可靠。

我们还在 Memos 里做了一个共享记忆池，所有 Agent 可以写入和读取。这不是向量检索，是纯文本检索，适合结构化的记录。在我们的场景里，14 个 Agent 的协作日志、老板的指令历史，都沉淀在这里。

下一步想接 Qdrant——把老的对话日志向量化，给 Agent 做语义检索。现在还没做，因为觉得 MEMORY.md 够用了。

总结一下，不整那些废话

三种记忆，三个层次：参数记忆是「学过的知识」，KV Cache 是「当次对话的临时脑子」，向量库是「可以随时查的外挂笔记本」。搞清楚这三层，你就能理解为什么大窗口模型贵、为什么 RAG 必要、为什么 Agent 要做持久化记忆。

没什么神秘的，就是工程问题。

SFD 编者注：我们自己踩过最深的坑是以为「上下文够长就不用做记忆管理了」——结果发现 128k 窗口的推理成本是 8k 的 16 倍，Agent 变贵变慢。现在的原则是：控制上下文长度，靠 MEMORY.md 和向量检索补不够的部分。