22 年以前，“LLM 应用"基本等同于"调一次 ChatComplete”。从 22 年底 ChatGPT 出来到 26 年这三年里，行业发现真正决定智能体上限的不是模型本身，而是模型周围那一圈用来承载历史、外部知识与可更新偏好的记忆系统。这篇综述沿着一条主线展开：以"信息来源"为轴的四层记忆世界观，把过去三年的代表性工作放进这四层里，并且回答一个 26 年才浮出水面的反向问题——为什么大家又在把向量数据库塞回到一个 markdown 仓库或一份 SQLite 单文件里。

一、把整片版图压成三句话

如果把过去三年关于智能体记忆的所有论文、产品和工程实践压成三句话，大致是这样：

第一，Agent 的记忆按"信息源"切是一个稳定的四层结构：训练数据（L1）、对话内数据（L2）、会话间数据（L3）、外部世界但与本会话无关的数据（L4）。每一层的写入主体不同，分别是训练管线、当前交互、Agent 自己、世界本身。围绕"是不是要再切出第五层"在 25-26 年有一些讨论，本文的判断是：Titans / MemoryLLM 这类"推理时可学习的参数化记忆"是 L1 内部的分化，不是新增的 L5。

第二，短时记忆与长时记忆的二元结构横切这四层。注意力扮演短时记忆，参数与外部存储扮演长时记忆。这条二分最早在认知科学里成熟（Atkinson-Shiffrin 1968），在 Titans（Google Research, 2024-12）那篇论文里被直接搬进了 Transformer 架构。

第三，26 年正在发生一场"向量数据库回归文件系统"的反向运动。Karpathy 的 LLM Wiki（2026-04）、Garry Tan 的 GBrain（2026-04-10）、tobi 的 QMD（2026-03）三件事指向同一个方向：当知识库是一个人或一个小团队的规模时，与其起一套 Pinecone/Weaviate/Qdrant sidecar，不如把全文检索、向量检索和结构化查询全部塞进一份 brain.db 或一棵 markdown 树里。

二、骨架：按"信息源"切的四层世界观

2.1 四层的定义与写入主体

把记忆按"信息从哪条路径进入 Agent 视野"切开，得到四层。这个分法的好处是每一层的写入主体互不重叠，可以直接往下接产品形态。

层	名称	进入路径	写入主体	典型容量	认知科学对位
L1	训练数据	预训练吃下去的语料	训练管线	万亿 token 级	程序性 + 内化的语义
L2	对话内数据	当前会话的上下文窗口	当下交互	几十 K~百万 token	工作记忆
L3	会话间数据	同一 Agent 跨会话的积累	Agent 自己	GB 级 markdown / 数据库	情景记忆 + 个性化语义
L4	外部世界	第三方事实（数据库、网页、文档）	世界本身	互联网级	客观语义记忆

L1 的"写入主体是训练管线"意味着一旦权重冻住，Agent 自己改不动。L2 的"写入主体是当下交互"意味着会话结束就消失，下次开会话又是空的。L3 的"写入主体是 Agent 自己"意味着上次会话学到的偏好可以被 Agent 主动写到一份外部存储里，下次会话再读回来。L4 的"写入主体是世界本身"意味着 MySQL 表里的数据是业务系统写的、维基百科的内容是别人写的，Agent 只是去查。

四个写入主体决定了四个不同的工程问题：训练管线的问题是数据配比和算力；上下文窗口的问题是 attention 退化和 token 成本；会话间存储的问题是新鲜度治理和检索精度；外部世界的问题是接入协议和实时性。这四个问题按写入主体分开谈更顺手。

2.2 短时记忆与长时记忆：贯穿四层的二元结构

认知科学里关于记忆的最早系统模型是 Atkinson-Shiffrin 1968 年提出的多储存模型：感觉记忆 → 短时记忆 → 长时记忆。后来又分化出工作记忆、情景记忆、语义记忆、程序性记忆等更细的分类，但短时 / 长时这条最粗的二分一直没被推翻。

把这条二元结构投影到 Agent 的四层里：

短时记忆（STM）：L2 是纯粹的短时，会话结束即消失。L1 中"当前 forward pass 期间的 KV cache"也属于短时。
长时记忆（LTM）：L1 的模型权重、L3 的跨会话存储、L4 的外部世界都属于长时。差别在于写入成本：L1 写入要重训，L3 写入是 Agent 一次 write() 调用，L4 几乎不由 Agent 写入。

Google Research 2024-12 的 Titans 论文把这条二分直接搬进 Transformer 架构。它的核心论断在摘要里写得很克制：注意力机制因其精确但有限的上下文窗口扮演短时记忆，神经记忆模块因其能够持久化历史信息扮演长时记忆。这个映射不只是修辞——Titans 在 needle-in-haystack 任务上把上下文扩展到 200 万 token 以上，靠的就是让短时记忆负责精确依赖、让长时记忆模块负责跨窗口的持久信息。

2.3 其他正交分类视角

四层不是唯一的分法。其他几种常见分类沿着不同的轴心切，给出不同的层数：

分法来源	切分轴心	层数	典型层
本文（信息源）	信息源 / 写入主体	4	训练 / 对话 / 跨会话 / 外部世界
CoALA（Sumers et al. 2023）	认知功能	4	工作 / 情景 / 语义 / 程序
MemGPT（Packer et al. 2023）	访问速度 / OS 类比	3	core / recall / archival
LangGraph	持久性	2	thread / cross-thread
Memory³（鄂维南团队 2024）	是否可外化	3	隐式参数 / 工作记忆 / 显式记忆
Agentic Memory 综述路线	形式	2	参数化 / 文本

层数从来不取决于现实，取决于轴心。本文以"信息源"为骨架，因为它的每一层都对应一个清晰的工程问题。

2.4 四层 vs 五层：一个被高估的争论

24-25 年随着 Titans / MemoryLLM / Memory³ 这类工作的出现，业内一度讨论是否应该在 L1（训练数据 / 静态参数）之外再划一层 L_{1.5}（推理时可更新的参数化记忆）。这个讨论后来沉下去了，原因有三。

一是"可更新参数化记忆"目前还没有大规模工业落地。Titans 是论文工作，MemoryLLM 是研究原型，主流推理引擎（vLLM、SGLang、TGI）还没有把"可更新参数"作为一等公民暴露出来。

二是 Titans 这类工作的本质是 L1 内部的分化，不是新出现的层。它做的事情是让短时记忆能渗透回模型架构内部，模糊了 L1 和 L2 的边界。把它当成 L1 的新趋势比单独分出 L5 更稳。

三是 26 年真正在发生的事不是"再分一层"，而是 L3 和 L4 在工程上往一起合并。QMD / LLM Wiki / GBrain 这条线就是把"Agent 自己积累的会话间记忆"和"外部世界事实"塞进同一份 brain.db 里，方向上的影响远比再分一层 L5 要大。

所以本文以四层为定盘星，在第四节单独讨论 L1 内部分化，把第七节让给 L3+L4 的合流趋势。

三、时间轴：22-26 年的四个阶段

把记忆世界过去三年多的代表性工作铺在时间轴上，大致是四个阶段。每个阶段都有一个核心问题，回答它的代表性工作通常会引出下一阶段的核心问题。

3.1 阶段一（2022下-2023上）：朴素 RAG 与 kNN-LM 余晖

ChatGPT 2022-11 发布的时候，业界对"如何让大模型用上外部知识"的主流答案是两个：参数化（继续 fine-tune）和检索增强。当时还没人专门提"Agent 记忆"这个词。

工业界的主线是朴素 RAG。LangChain 在 2022-10 发布第一版，把 retriever + LLM + prompt 这条管线模板化。配合 Pinecone（2019 创立但 22-23 起飞）、Weaviate、Chroma（2023 出现）这一批向量数据库，整个行业用半年时间把"建索引 → 查 Top-K → 拼 prompt"这条路趟成默认范式。

学术界的主线是 kNN-LM 谱系。Khandelwal et al. 在 ICLR 2020 提出 kNN-LM，第一次系统证明 nearest-neighbor 检索可以拉升语言模型的泛化。后来 Atlas（Izacard et al., JMLR 2023）、REPLUG（Shi et al., NAACL 2024）沿这条线把检索增强从"工程技巧"做成"训练范式"。

这个阶段的核心问题是"如何让模型用上窗口外的知识"，答案是 RAG。但 RAG 解决不了一个更深的问题：Agent 跨会话的记忆怎么办？这个问题在 23 年下半年被 MemGPT 第一次正面回答。

3.2 阶段二（2023下-2024）：服务化与认知架构兴起

23-24 年是"Agent 记忆"作为独立工程领域成型的两年。四股力量同时在动。

学术上是认知架构的回归。Packer et al. 在 2023-10 发布 MemGPT，把操作系统的虚拟内存类比搬到 LLM 上：核心记忆（始终在上下文）/ 回忆记忆（可搜索的对话历史）/ 归档记忆（容量无限的外部知识）。Sumers et al. 2023 提出的 CoALA 框架则把认知科学的工作 / 情景 / 语义 / 程序四分法明确移植到 LLM Agent 上。这两个工作奠定了后续所有"分层记忆"产品的语言。

社区层面是斯坦福小镇和 NVIDIA Voyager。Park et al. 2023 的 Generative Agents（斯坦福 Smallville）用"记忆流 + 反思 + 规划"让 25 个 NPC 在虚拟小镇里持续生活。同年 NVIDIA 的 Voyager 在 Minecraft 里通过持续积累的 skill library 实现终身学习。两个工作把"Agent 记忆等于检索"的认知刷新成"Agent 记忆等于一个可读可写可演化的状态系统"。

产品层面是第一代专用记忆服务。Mem0、Zep、Cognee 在 23-24 年陆续出现，都是独立于框架的记忆中间件，上层不管你用 LangChain、LangGraph、CrewAI 还是裸 SDK，下层都通过 API 写入 / 检索同一份记忆库。Mem0 后来在 24-25 年完成了一次重要的工程务实主义转向（移除约 4000 行图记忆代码，改用 spaCy 实体链接），这件事本身就是这个阶段成熟度的标志，市场已经能容忍"减法"。

协议层面是 MCP。Anthropic 在 2024-11 推出 Model Context Protocol，第一次把"Agent 怎么调外部工具 / 怎么读外部记忆"标准化。MCP Memory Server 是它附带的参考实现，用 JSONL 文件存知识图谱，10 个工具接口覆盖完整 CRUD。

这个阶段的核心问题是"Agent 怎么记住跨会话的事"，答案是分层 + 服务化 + 标准化。但它解决不了下一个问题：当上下文窗口推到 128K、1M 之后，注意力本身在退化怎么办？这个问题在 24 年下半年开始被参数化记忆增强的复兴正面回答。

3.3 阶段三（2024-2025）：参数化记忆复兴 + 外部记忆工程化

24-25 年这一年半在两条线上同时推进。

参数化记忆增强这条线进入复兴期。Google 2024-04 发布 Infini-attention，在单个 Transformer 块内集成压缩记忆，让有界资源能处理无限长输入。同年 12 月发布 Titans，引入"神经长期记忆模块"在推理时学习历史。中间还有鄂维南团队 2024-07 的 Memory³（显式记忆作为参数化记忆和 KV cache 之外的第三种形式）、MemoryLLM（2024-02）、SILO（ICLR 2024 Spotlight）。这一波工作的共同点是承认参数化记忆不应该是冻死的，应该有一个推理时仍可写入的子层，也就是前面说的"L1 内部分化"。

外部记忆这条线进入工程化精细化。Anthropic 2024-09 发布 Contextual Retrieval，证明给每个 chunk 在索引阶段补上语境能把检索失败率降低 35-67%。Jina AI 2024-09 的 Late Chunking 反过来，先用长上下文模型对整篇文档做 token 级编码，再在 token 序列上池化形成 chunk 向量。25 年 Bowen Jin 等发布 Search-R1，用 RL 把"什么时候搜、搜什么、搜完怎么办"训进模型权重。同年 OpenAI、Google、Perplexity 前后推出"Deep Research"，把多 Agent 长程检索做成产品。

索引层面 A-MEM 和 xMemory 各推一步。Xu et al. 2025 在 NeurIPS 发的 A-MEM 受 Zettelkasten 卡片盒笔记法启发，提出"动态链接的原子化知识网络"：记忆不再用静态层次组织，而是节点之间通过语义关联动态链接，新记忆的加入会触发对历史记忆的属性更新。26 年 ICML 的 xMemory 走得更远，明确指出 RAG 在 Agent 记忆场景的不匹配（RAG 面向异构语料，Agent 记忆是高度相关的连贯流），提出四层分层（原始消息 → Episode → Semantic → Theme）+ 自顶向下检索。

工程标准化层面 Anthropic Skills 是 25 年的里程碑。Anthropic 2025-10 推出的 Skills 把"Agent 能力"做成可独立分发的目录，配合 frontmatter 元数据 / SKILL.md 正文 / references/ scripts/ 三层渐进式披露，是 24-25 年最重要的"L3 记忆工程化"成果之一。它和 AGENTS.md 一起回答了"工程化的 L3 应该长什么样"。

这个阶段的核心问题是"如何让记忆系统在工程上可治理、在架构上可演化"，答案是参数化复兴 + 索引精细化 + 工程标准化。但它没有回答下一个问题：当一个个人或小团队的知识库规模到 GB 级、文件数到万级，是不是真的需要 Pinecone + Neo4j + ChromaDB 这套全家桶？26 年的回答是"不需要"。

3.4 阶段四（2026）：从向量库回归文件系统

26 年到现在最有标志性的一组工作不是新的论文，是三个不到 100KB 的项目：

QMD（tobi, 2026-03）：本地优先的 markdown 智能搜索引擎，BM25 + 向量 + LLM rerank 全部塞进一份 SQLite。
LLM Wiki（Karpathy, 2026-04）：一份 markdown idea file，提出"摄入时合成 wiki、查询时直接读 wiki"范式，不写代码不发包。
GBrain（Garry Tan, 2026-04-10）：把 1 万份 markdown + 3000 人物档案 + 13 年日历 + 5800 条 Apple Notes 收成一份 brain.db，单文件 SQLite + FTS5 + vector embeddings。

这三件事共享一个反直觉的判断：对一个人或一个小团队规模的知识库，向量数据库 sidecar 是过度工程。它们指向同一条工程主张——把全文检索、向量检索、结构化查询全部收在同一个连接、同一份文件里。

这个阶段的核心问题就是本文标题里那句"向量数据库回归文件系统"，第七节会展开。

四个阶段串起来是这样：从"如何用外部知识"（朴素 RAG）走到"如何跨会话记忆"（服务化与认知架构），再走到"如何工程化治理记忆"（参数化复兴与索引精细化），最后走到 26 年的"如何用一份文件做完所有事"（向量库回归文件系统）。每一阶段的代表性工作都在为下一阶段挖问题。

四、L1 训练数据：参数化记忆的内部分化

L1 这一层在 22-23 年是最稳定的："训练完就冻死"是行业默认。24 年下半年开始这条默认假设被三组工作正面挑战。

4.1 Titans：注意力是短时，神经记忆是长时

Titans（Google Research, 2024-12）的核心架构是在 Transformer 旁边并行挂一个神经长期记忆模块。这个模块在推理时（test time）学习如何记忆历史上下文，与注意力并行：注意力处理当前窗口内的精确依赖，神经记忆维持对更长历史的持久感知。论文给出三种集成方式（Memory as Context / Memory as Gate / Memory as Layer）和它们各自的实验对比。

关键的工程意义不在"上下文变长"，而在参数化记忆不再是一次性写完的——神经记忆模块的权重在推理时持续更新。这一刀切下去之后，L1 内部其实就分化成了两块：

L1a 静态参数：预训练 + fine-tune 写完之后冻住的权重
L1b 推理时可写参数：Titans 的神经记忆模块、MemoryLLM 的记忆池、Infini-attention 的压缩记忆

实验上 Titans 在 needle-in-haystack 任务上把上下文推到 200 万以上，覆盖语言建模、常识推理、基因组学和时间序列。

4.2 Infini-attention：在标准注意力内部集成压缩记忆

Infini-attention（Google, 2024-04）走的是"不增加新模块，在标准注意力内部做改造"的路线。它在单个 Transformer 块中同时运行掩码局部注意力和长程线性注意力：局部注意力负责当前窗口的精确计算，线性注意力维护一个不断更新的压缩记忆，吸收历史信息、在需要时提供远程上下文。

它的优雅之处在于资源有界。处理无限长输入序列时内存和计算资源是固定的，模型只需要"最小的有界内存参数"就能流式推理。实验在 1B 和 8B 上验证，覆盖了 100 万长度的密钥检索和 50 万长度的书籍摘要。

4.3 MemoryLLM 与 Memory³：可写参数 + 显式记忆

MemoryLLM（2024-02）直接挑战"部署后模型是静态的"这个假设。它在 Transformer 的潜在空间嵌入了一个固定大小的记忆池，使模型能够在运行时吸收新的文本知识并记住之前注入的信息。实验显示，即使在近百万次记忆更新后，模型仍保持运行完整性，没有性能退化。

Memory³（鄂维南团队，2024-07）从一个更基础的角度切入，提出语言模型应该有"第三种记忆形式"：

隐式记忆：模型参数（≈ L1a）
工作记忆：KV cache 与上下文（≈ L2）
显式记忆：可被检索的外部稀疏记忆（≈ 一种新形态的 L3+L4）

论文从零训练了一个 2.4B 的 LLM 作为概念验证，摘要声称在测试中同时优于"更大规模的 LLM 和 RAG 模型"且解码速度高于 RAG。它的贡献不只是模型本身，更在于把"参数 / 上下文 / 外部"这条三分法从工程直觉升格成可被设计的架构维度。

4.4 为什么这是 L1 内部分化而不是新 L5

很容易把"推理时可写的参数化记忆"独立成 L5。本文不采用这个分法，理由有三。

一是写入边界仍在模型内部。Titans 的神经记忆模块物理上是模型架构的一部分，更新的是模块内的权重 / 隐状态，不是文件系统里的字节。这条边界是 L1 的边界。

二是这种"可写"目前还在研究阶段。截至 26 年 5 月，主流推理引擎没有把"用户可控的参数化记忆写入"暴露成 API。等到 vLLM / SGLang / TGI 开始原生支持"推理时可写参数"作为一等公民时，再考虑给它独立的层号也不迟。

三是 Skill 自动沉淀这件事在工程上更像 L3 而不是 L1b。有人会反驳说 Hermes / Superpowers 的 skill 自动学习不就是推理时可学习的参数化记忆吗？但 skill 的物理形式是 markdown 文件 + frontmatter，写入路径是 Agent 调 Write 工具，存储介质是文件系统。它不在模型架构内部，而是在 L3。把 skill 算到 L1b 会模糊掉"是否在模型内部"这条最重要的工程边界。

所以本文的判断是：L1 在 24 年之后正在内部分化为 L1a（静态参数）和 L1b（推理时可写参数），但作为独立的层来组织世界观，依然是四层稳。

4.5 外部记忆可以 shadow 权重，但不能替代权重

Hermes、OpenClaw、Superpowers 这类系统把一个问题推到了台前：如果 agent 能把运行时经验写成 MEMORY.md、USER.md、SKILL.md、daily notes、Dreaming 结果和 session 索引，再在下一次任务里检索并注入这些内容，它是不是已经等价于"模型自己学会了"？

答案要分层说。在 L3/L4 行为层，外部记忆确实可以 shadow L1 权重。模型内部可能带着旧 API、旧框架习惯、旧项目结构的先验；当前任务启动时注入的 spec、测试结果、官方文档、项目记忆和历史失败记录，可以把这些先验压下去，让模型在这个任务场域里表现得像"已经学过"。这就是外部状态对权重先验的覆盖。

但 shadow 不是替代。外部记忆不会创造新的模型表征，也不会让底层权重拥有新的泛化能力。把 ~/.hermes/skills/、~/.openclaw/workspace/MEMORY.md 或项目 AGENTS.md 拿走，能力就会随之消失。它更像一层可审计、可 diff、可回滚的行为覆写层，而不是参数层里的新知识。

外部记忆要真正 shadow 权重，至少要满足五个条件：可发现、可精确换入、有优先级、可失效、可验证。只把所有资料堆进一个大文件，不会产生稳定能力，只会制造召回噪声和上下文稀释。真正起作用的是 selector、压缩、检索、注入、测试和回滚组成的闭环。这个边界在《Self-Improving Agent 的边界：外部记忆能不能 shadow 模型权重？》里单独展开。

五、L2 对话内数据：上下文工程的崛起

L2 是最直观的一层——就是当前 forward pass 里那个 prompt。它的容量从 22 年 GPT-3.5 的 4K 一路推到 25 年 Claude 4 / Gemini 3 的 1M-2M。但容量推高之后行业很快发现一个反直觉的事实。

5.1 Context Rot：上下文不是越大越好

Lost in the Middle（Liu et al., TACL 2024）给出过一个反直觉的数据点：20 篇文档的多文档问答任务中，把答案放在中间位置，准确率比放在首尾下降超过 30%。这条 U 形曲线在所有主流长上下文模型上都能复现，包括 100K+ 上下文版本。

26 年的工程实测把这个结论推得更远。Anthropic 在 Context Engineering 文档中把这种现象正式命名为 Context Rot：

“As the number of tokens in the context window increases, the model’s ability to accurately recall information from that context decreases.”

这意味着 L2 的有效容量远小于其名义容量。一份 100K token 的上下文里塞 100 条规则，每条规则的被注意到概率可能比塞 10 条的版本里还低。这个观察直接催生了 25-26 年的 Context Engineering 范式。

5.2 Context Engineering 的四大策略

LangChain 把上下文工程的设计空间总结为四个动词：

策略	含义	代表手段
Write	把信息写出 L2，进入 L3 或外部存储	便签 / 跨会话记忆 / 进度日志
Select	在 L3/L4 里挑出当前需要的部分注入 L2	向量检索 / 知识图谱 / 工具描述 RAG
Compress	在 L2 内部做压缩，减少 token 占用	递归 / 分层摘要 / 上下文修剪
Isolate	用多 Agent 架构隔离上下文	sub-agent / orchestrator-worker

Anthropic 推荐的 Just-in-Time Retrieval 策略本质上是 Write + Select 的组合：使用轻量级标识符（文件路径、存储查询、Web 链接）在运行时动态加载数据。AGENTS.md 的"地图而非手册"原则（OpenAI Codex 团队）也是同一思路的具体化，让 L2 只装地图（≈ 200 行），数据页放在 L3 的 docs/ 子树按需加载。

换成操作系统的比喻，这四个动词就是 context paging：当前窗口是工作集，外部记忆是磁盘，检索和摘要是 page in，压缩、归档和主动遗忘是 page out。Compact 的价值也不只是给长对话续命，而是丢弃已经完成的任务，把未完成目标、关键约束和下一步动作留给下一轮。这个视角在《上下文换入换出：下一代 scaling》里单独展开。

5.3 工程实测里的两个数字

26 年比较扎实的两个公开数字：

一篇 26 年的 monitor 性能评测显示，Claude Opus 4.6（开 thinking）在 100K token 转录中插入对抗指令，靠近开头的 recall 是 99.7%，移到深处之后掉到 69%。
Gemini 3 标称 2M、Claude 4 标称 1M、GPT-5 标称 400K，但在 needle-in-a-haystack 测试里，几乎所有前沿模型在大约 32K 之后都会快速劣化。

这两个数字解释了为什么"四层架构"实际是 200 行 AGENTS.md + GB 级 L3 的组合，而不是把 GB 级知识全塞进 L2。有效上下文不等于名义上下文，这是 25-26 年 L2 工程的第一性约束。

六、L3 会话间数据：从进度日志到记忆文件

L3 是 22-26 年工程化进展最大的一层。它解决的核心问题是"上次会话学到的东西，下次会话怎么读回来"。

6.1 文件标准：从混沌到事实约定

L3 的物理载体最初是没有标准的——每个工具、每个团队自己发明。23-25 年这两年逐渐收敛出几个事实约定。

AGENTS.md / CLAUDE.md 的收敛

AGENTS.md 是目前最接近"标准"的 L3 文件形式。23 年最初分为 CLAUDE.md（Anthropic Claude Code）、.cursorrules（Cursor）、AGENTS.md（OpenAI Codex 等）三派。25 年 OpenAI 主导下三派在 AGENTS.md 上收敛，由 Linux Foundation 旗下的 Agentic AI Foundation（AAIF）作为标准 steward。截至 26 年 5 月，agents.md 主页统计 GitHub 上已有超过 6 万个开源项目使用这一格式。

这类文件的特征是稳定的背景知识，回答"一个刚进入这个项目的 AI 智能体，需要知道什么才能有效工作"。典型内容是项目概述、技术栈、代码规范、架构原则、运行 / 测试 / 部署命令。

Claude Code 自 v2.107（2025-05-09）支持 @path/to/file.md 引用语法之后，CLAUDE.md 里只需一行 @AGENTS.md 就能完成桥接，迁移成本接近零。这条 import 是 L3 工程化进入"乐高化"阶段的标志：AGENTS.md 不再是一份文件，而是一棵可组合的文档树。

进度日志：写给下一个 Agent 实例读

Anthropic Harness 方案中使用 claude-progress.txt，OpenAI Codex 团队使用 docs/exec-plans/ 目录下的执行计划文件。这类文件记录动态的任务状态：

## 2026-05-15 会话记录
- 完成了用户认证模块（JWT + refresh token）
- 发现了一个 CORS 配置问题，已修复
- 下一步：实现消息列表的分页功能
- 已知问题：WebSocket 连接在移动端偶发断开，待排查

这类文件没有统一格式，但有一个共同原则：写给下一个 Agent 实例读，不是写给人读。它需要足够结构化，让 Agent 能快速定位关键信息。

功能清单：可机器验证的任务状态

Anthropic 在工程实践中发现一个微妙但重要的细节：模型对 JSON 文件的"不当修改"概率显著低于 Markdown 文件。所以他们推荐用 JSON 格式的功能清单管理可验证的任务进度：

{
  "category": "functional",
  "description": "新建对话按钮能创建一个新的会话",
  "steps": [
    "导航到主界面",
    "点击「新建对话」按钮",
    "验证新会话已创建"
  ],
  "passes": false
}

初始化 Agent 在第一次运行时生成完整功能清单（所有 passes: false），后续 Agent 每次选最高优先级的未完成项实现，完成后标记为 passes: true。这让任务进度变得可量化、可追踪、可验证。

Git 历史作为时间维度的 L3

Git 本身就是一种 L3。每次提交都是一个检查点，记录"这个时间点代码处于什么状态"。Anthropic 明确要求编码 Agent 在每次会话结束时提交代码并写清楚提交信息，这样下一个实例可以通过 git log --oneline -20 快速了解最近发生了什么。Git 历史作为 L3 的独特价值在于它不只记录"当前状态是什么"，还记录"如何一步步走到这里"，这种时间维度的信息对理解设计决策和排查问题至关重要。

结构化知识库

Codex 团队走得更远，建立了一个完整的 docs/ 目录结构作为 L3 知识库：

docs/
├── design-docs/          # 设计文档，含验证状态
├── exec-plans/
│   ├── active/           # 活跃的执行计划
│   ├── completed/        # 已完成的计划
│   └── tech-debt-tracker.md
├── generated/
│   └── db-schema.md      # 自动生成的数据库模式
├── product-specs/        # 产品规格
├── references/           # 外部库的 llms.txt 格式文档
├── DESIGN.md
├── FRONTEND.md
└── QUALITY_SCORE.md      # 各模块的质量评分

AGENTS.md 作为目录，指向这套知识库的各个部分。这就是后来 OpenAI 总结成"地图而非手册"（Map, not Manual）的设计原则的具体形态。

llms.txt 与 MCP Memory：跨工具的协议层

llms.txt 是一个新兴提案，设计思路类似 robots.txt——给 LLM 提供一个专门的简化版文档入口。Codex 团队在 docs/references/ 下存放 nixpacks-llms.txt、uv-llms.txt 等文件，作为外部库的 LLM 友好版文档。

Anthropic 2024-11 推出的 MCP 在跨工具层面给了 L3 一个标准协议。MCP Memory Server 用本地 JSONL 文件存储知识图谱，围绕三个原语构建：实体（节点）、关系（有向边）、观察（附着在实体上的原子化事实），暴露 10 个工具接口覆盖完整 CRUD。

MCP Memory 的意义在于打通了不同工具之间的 L3 壁垒。无论 Claude Desktop、VS Code 还是其他 MCP 兼容客户端，都可以通过同一个 Memory Server 读写记忆。Mem0 等第三方服务也开始提供 MCP 接口。

6.2 框架内置记忆：三种路线

L3 在框架层面也催生了三条不同的实现路线。

LangGraph：Store API + 命名空间

LangGraph 的记忆架构围绕 Store API 构建，核心抽象是 BaseStore 接口。它将记忆的组织权交给开发者，通过命名空间实现灵活的多租户隔离：

按用户：("user", user_id, "memories")
按 Agent：("agent", agent_id, "learned_patterns")
按项目：("project", project_id, "decisions")

Store 的设计哲学是跨线程共享：不同对话线程可以读写同一个 Store 中的同一个命名空间。这使得"用户 A 在对话 1 中教会 Agent 的偏好，在对话 2 中自动生效"成为可能；而对话历史（checkpointer）则是线程私有的。

CrewAI：统一记忆 + 复合评分

CrewAI 用一个统一的 Memory 类替代了此前分立的短期、长期、实体和外部记忆类型。设计决策背后的洞察是：记忆的"类型"不应由开发者预先指定，而应由 LLM 在存储时自动推断。

当一条新记忆被存入时，LLM 会分析其内容自动推断三个维度：层级作用域（如 /project/alpha）、分类标签、重要性评分。检索时采用复合评分：

1	`score = 0.5 × semantic_similarity + 0.3 × recency_decay + 0.2 × importance`

其中 recency_decay 是指数衰减函数，可配置半衰期。一条高度相似但两个月前存入的记忆，可能排在一条中等相似但昨天存入的记忆后面。

另一个关键机制是记忆整合：新记忆与已有记忆的余弦相似度超过 0.85 时，系统调用 LLM 决定保留、合并还是替换；批量写入时在 0.98 阈值上做纯向量去重，无需 LLM 参与。默认存储后端是 LanceDB，数据持久化在 .crewai/memory 目录下。

Letta（MemGPT）：操作系统式虚拟记忆管理

Letta 是 MemGPT 论文的工业化产品。它把记忆划分为三个层级，对应操作系统的存储层次：

MemGPT 层级	OS 类比	容量	内容
核心记忆	寄存器 / L1 缓存	小（始终在上下文）	关键人设、用户画像、当前任务
回忆记忆	主存 / RAM	中等	对话历史的可搜索索引
归档记忆	磁盘 / SSD	大	长期知识、文档、历史数据

关键创新是 Agent 可以自主修改自己的核心记忆。当 Agent 发现用户偏好变化时，它主动调用 core_memory_replace 将旧信息替换为新信息，这种"自编辑记忆"是传统 RAG 系统没有的。

三种路线的对比

维度	CrewAI	LangGraph	Letta
记忆分类	LLM 自动推断	开发者定义命名空间	三层固定层级
检索策略	复合评分	向量 + 元数据过滤	按层级检索 + 全文搜索
去重 / 整合	自动整合（0.85 阈值）	无内建	Agent 自主编辑
持久化	LanceDB 本地文件	可插拔 Store 后端	服务端数据库
独特价值	开箱即用、零配置	灵活可编程	自编辑记忆、OS 式管理

6.3 治理：外部记忆也会腐烂

L3 不是写好就万事大吉的，它本身也会腐烂。OpenAI Codex 团队在实践中总结了一个深刻教训：他们最初尝试用一个大型 AGENTS.md 文件存储所有知识，结果发现四个严重问题：

上下文是稀缺资源：巨大的指令文件挤占任务、代码和相关文档的空间
过多指导反而失效：当一切都"重要"时，一切都不重要了
它会立即腐烂：随着代码库演进，文档跟不上，Agent 开始基于过时信息做决策
难以验证：单一大文件无法做机械化的覆盖率检查和新鲜度验证

他们的解决方案是把 AGENTS.md 从百科全书变成目录：一份约 100 行的 AGENTS.md 作为地图，指向 docs/ 下结构化的知识库。专门的 linter 和 CI 验证更新状况，定期运行的"文档园丁"Agent 扫描过时文档并发起修复 PR。

这套实践揭示了 L3 工程化的核心挑战：外部记忆本身需要被设计、维护和治理。它不是一次性配置，而是一个需要持续投入的基础设施。

七、L4 外部世界：从 RAG 到向量库回归文件系统

L4 是工程上最热闹的一层。22-25 年它的主旋律是"向量数据库百花齐放"，26 年的主旋律是反向——把向量库塞回文件系统。

7.1 第一波：专用记忆服务的三种哲学

在框架内置记忆之外，L4 还有一批独立于框架的专用记忆服务。这些服务的设计哲学差异，揭示了"语义检索 + 时序推理 + 本体组织"三个维度的不同侧重。

Mem0：从图记忆到实体链接的工程务实主义

Mem0 是目前最广泛使用的开源记忆服务之一。它的核心架构是向量存储 + 实体链接 + 重排序器的三层栈，通过统一的 API 管理用户 / Agent / 会话三种作用域的记忆。

Mem0 一个值得关注的演进：它在最新版本中移除了约 4000 行图记忆代码，将 Neo4j / Memgraph 等图数据库依赖替换为内建的实体链接机制。新方案用 spaCy 从记忆文本中提取实体（专有名词、引用文本、复合名词短语），存在向量库的平行集合中。检索时查询中的实体与实体集合匹配后，作为信号之一注入到三信号混合搜索（语义相似性、BM25 关键词、实体关联度）共同决定排序。

这个转向揭示了一个工程现实：图数据库在记忆场景中的维护成本往往高于其带来的检索增益，尤其是当实体关系可以通过更轻量方式近似表达时。这是 26 年"回归简单"的早期信号。

Zep：时序上下文图谱与事实失效

Zep 不在检索上做优化，而在数据模型上做文章，构建一个时序上下文图谱。Zep 的三阶段管线是：

摄入：接收聊天消息、JSON 业务数据、文档等异构输入，自动提取实体、关系和事实
图谱构建：将提取的信息组织为时序知识图谱，每个事实带有有效时间范围（如 2024-09-15 ~ present）。当事实变化时旧事实被标记为失效而非删除
上下文组装：根据查询从图谱检索相关上下文，格式化为 token 高效的提示注入

Zep 的核心差异化是事实失效机制。用户说"我换了工作"时，Zep 不会简单添加新记忆，而是把旧工作信息标记为失效并记录状态变迁的时间线。这种时序感知使 Agent 能够回答"他之前在哪里工作"这类需要历史上下文的问题。

性能方面，Zep 声称 P95 检索延迟 < 200ms，在 LoCoMo 基准上以单次检索达到 80.32% 的准确率。其底层时序图谱库 Graphiti 已开源。

Cognee：本体驱动的记忆基础设施

Cognee 走第三条路：用自动抽取的本体论（Ontology）来组织记忆，而不依赖向量相似性或手工图谱。它的三阶段管线是：

摄入：28+ 数据源连接器，覆盖数据仓库、向量存储、文件、API、Slack 等
推理：自动提取本体结构、构建"世界模型"
行动：Agent 跨会话从世界模型中召回记忆

Cognee 的独特之处在于它是自改进的，每次运行都会"压实"已有的知识结构，使记忆随使用变得更精准。它也提供 MCP 服务器接口。

三种哲学

维度	Mem0	Zep	Cognee
核心数据结构	向量 + 实体链接	时序知识图谱	本体驱动的世界模型
检索策略	三信号混合搜索	图谱遍历 + 上下文组装	本体引导的召回
时序感知	无内建	事实失效 + 时间范围	版本化的知识压实
图谱能力	已移除（改为实体链接）	核心能力（Graphiti）	本体自动抽取
适用场景	通用记忆管理	需要时序推理	企业知识密集型

Mem0 信"统计信号混合"，Zep 信"结构化时序推理"，Cognee 信"本体论组织力量"。目前没有一种被证明在所有场景下最优。

7.2 向量数据库的春秋战国

向量数据库是这一批专用记忆服务的底层依赖，也是 22-25 年 L4 工程化的中流砥柱。但它本身也是一个分化剧烈的市场。

维度	Chroma	Pinecone	Weaviate	Qdrant	FAISS	Milvus
定位	轻量嵌入式	全托管云服务	混合搜索平台	高性能向量引擎	底层算法库	分布式向量系统
部署模式	进程内 / 本地服务	Serverless 云端	自托管 / 云端	自托管 / 云端	库	分布式集群
混合搜索	仅向量	向量 + 元数据	向量 + BM25	向量 + 丰富过滤	仅向量	向量 + 标量过滤
多租户	集合级别	命名空间	原生多租户	集合 + 载荷过滤	无	分区键
典型用户	原型 / 个人	生产级 SaaS	企业搜索	高性能检索	研究	大规模生产

Agent 记忆场景下使用向量数据库有三个与传统 RAG 不同的需求。

第一是高频小批量写入。Agent 记忆是"边对话边写"的，每轮交互可能产生新条目。Chroma 和 Qdrant 表现较好，前者进程内模式几乎零延迟写入，后者 WAL 设计保证写入不影响查询。Pinecone Serverless 在小批量写入时存在冷启动延迟。

第二是时序感知检索。Agent 记忆不只要"最相似的"，还要"最近的"。Weaviate 和 Qdrant 的丰富过滤能力有优势；FAISS 和 Chroma 需要在应用层自行实现。

第三是记忆隔离。多用户场景下用户 A 的记忆不应出现在用户 B 的检索结果中。Weaviate 的原生多租户最完善；Pinecone 通过命名空间；Qdrant 通过载荷过滤模拟；Chroma 需要为每个用户创建独立集合。

7.3 反向运动：QMD / LLM Wiki / GBrain 三件套

26 年发生了一件"非典型"的事：三个不到 100KB 的项目在三个月内连续出现，共同指向"向量数据库 sidecar 是过度工程"的反向判断。

QMD：本地优先的 markdown 智能搜索

QMD（tobi, 2026-03）是一个开源的 CLI 工具 + Node.js / Bun 库，专为 markdown 文档设计。核心特性：

完全本地：所有数据和模型本地运行，无需联网
混合搜索：BM25 关键词 + 向量语义 + LLM 重排序
智能分块：自动将长文档切为约 900 token 的语义完整片段，15% 重叠
MCP 集成：提供 Model Context Protocol 服务器，可与 Claude 等 AI 工具集成

它的物理形态非常激进，所有索引数据存在一份 SQLite 文件里：~/.cache/qmd/index.sqlite。FTS5 表负责全文检索，sqlite-vec 扩展负责向量检索，普通表负责元数据。首次运行下载约 2GB 的本地 GGUF 模型（embeddinggemma-300M 嵌入 / qwen3-reranker-0.6b 重排序 / qmd-query-expansion-1.7B 查询扩展），之后整套检索栈不再依赖任何外部服务。

工程上它的查询管线是这样的：

用户查询 "project timeline"
    ↓
查询扩展（LLM 生成 2 个变体）
    ↓
并行检索（BM25 × 3 路 + 向量 × 3 路）
    ↓
RRF 融合（k=60）+ Top 排名奖励
    ↓
LLM 重排序（qwen3-reranker，Yes/No + logprobs）
    ↓
位置感知融合（Rank 1-3 用 75%RRF+25%Rerank；Rank 11+ 倒过来）
    ↓
最终结果

QMD 在个人 / 团队规模的 markdown 知识库上的吸引力很直接：你不需要起 Docker，不需要管 Pinecone 账单，不需要维护连接字符串。一个 qmd query "认证流程" 命令就拿到结果。

LLM Wiki：摄入预合成的范式宣言

LLM Wiki（Karpathy, 2026-04）的物理形态比 QMD 还激进：它不是代码，是一份 GitHub Gist，副标题 A pattern for building personal knowledge bases using LLMs。Karpathy 在文件开头写得很克制：这不是一个可运行的代码仓库，是一个 idea file，目的是让读者贴给自己的 coding agent（Claude Code、Codex 等），由 agent 根据这份理念给每个用户搭一套自己的实现。

核心设计哲学只有一句话：不要在每次查询时做 RAG，把 LLM 当作一个持续维护 markdown wiki 的 agent，让它在摄入阶段把原始文档合成成交叉引用的 wiki 页面，查询时直接读 wiki。

维度	传统 RAG	LLM Wiki
知识处理时机	每次查询时	摄入时一次
知识形态	原始文档 chunk	结构化、交叉引用的 wiki 页面
矛盾检测	查询时可能才发现	摄入时就标记
查询开销	向量检索 + 拼接 + LLM	读 wiki（或 wiki + 少量检索）
可审计性	检索结果难以持久追溯	wiki 本身就是版本可控的 markdown
人类角色	上传与查询	策划、编辑、提问

把成本从"每次查询都跑一遍检索 + 生成"搬到"摄入时合成一次 wiki"，节省体现在三点。重复查询不再重复做检索：同一份文档被问 100 次，RAG 要跑 100 次向量检索，LLM Wiki 只在摄入时合成一次，之后所有问题都落在已经消化过的 wiki 上。预合成减少了 query 到 chunk 的错配：RAG 失败的典型模式是问题措辞和 chunk 原文差异太大，wiki 页面因为已经做过跨文档整合覆盖了更多提问角度。矛盾和重复在摄入阶段被消除：等价于在索引阶段做了一次数据清洗，查询时不再需要模型临时判断"这两段哪个才对"。

LLM Wiki 的副作用也很明显：合成错误会被固化，摄入成本不低。它只适合"会被问很多次的知识库"，例如个人知识库、技术文档、研究领域综述。

GBrain：brain.db 单文件 + Compiled Truth / Timeline

GBrain（Garry Tan, 2026-04-10）是 LLM Wiki 哲学最完整的工程落地。Garry Tan 是 Y Combinator CEO + Initialized Capital 联合创始人，开源后三天内就拿到 6500+ GitHub Star，MIT 授权。

它解决的是 Garry Tan 自己的实际问题——他的个人知识库已经包含：1222 份人物档案、7471 个 markdown 文件、约 2.3GB 总量、3000+ 人物档案、13 年日历数据（21000+ 事件）、5800 条 Apple Notes（追溯到 2009 年）。这个规模下，Git 目录管理已经吃力，grep 已经失效。

GBrain 的两个核心架构选择。

底层用 SQLite，不用 Postgres。Gist 里讲得很直接：单文件、没有 server、没有 connection string、没有 Docker、没有 managed database。最后得到一份可以 scp、可以 rsync、可以备份到 S3、可以拷进 U 盘的 brain.db。判断依据是：这是一个人的知识库，不是高并发写入系统，不是多租户数据库，不需要 replication，不需要 row-level security。这套选型面对的是"一个人的长期知识脑"这类场景。

全文、向量、结构化查询收在同一层。GBrain 把 FTS5 + vector embeddings 都塞进同一个 SQLite。原话：“不要 Pinecone、不要 Chroma sidecar、不要再起一个 Qdrant container。全文搜索和语义搜索，最好在同一个连接、同一份库、同一套命令里完成。”

知识模型层面，GBrain 提出 Compiled Truth + Timeline 结构：

每个实体（人、公司、项目）一份 markdown 页面

页面上半部分（Compiled Truth）：
  - 结论性信息
  - 代表当前对该实体的最佳理解
  - 新证据出现时被重写或更新
  - 提供经过提炼的最终判断

页面下半部分（Timeline）：
  - 只追加的证据轨迹
  - 永远不编辑历史记录
  - 保存原始事实与数据来源

这套设计直接对应 Zep 的"事实失效"机制，但用更简单的方式实现：上半部分允许覆盖，下半部分只追加。GBrain 在此之上构建了一层轻量级的 CLI 和 MCP 层，专门针对 OpenClaw / Hermes 这类持续运行的 Agent 优化，支持增量索引更新。

GBrain 提出的三层记忆架构（与 Agent 自身记忆互补）：

层	内容	定位
GBrain	人物、公司、交易、会议、观点、原创思考等客观事实	长期世界知识库（≈ L3 + L4）
Agent Memory	偏好、决策、运行配置、行为规则	Agent 行为状态（≈ L3）
Session Context	当前对话的上下文	实时上下文（≈ L2）

GBrain 的灵感来源声明得也很明确——Vannevar Bush 1945 年论文 As We May Think 中的 Memex 设想。Memex 是"按人的联想方式组织知识"的概念机器，GBrain 把它做成了一份 brain.db。

三件套的共同主张

QMD、LLM Wiki、GBrain 这三件事虽然抽象层次不同（QMD 是工具、LLM Wiki 是范式、GBrain 是落地），它们共享同一组工程主张：

数据载体最小化：能 SQLite 不上 Postgres，能 markdown 不上数据库
依赖最小化：能本地跑不上云服务，能内嵌不起 sidecar
检索栈一体化：全文 + 向量 + 结构化全部收在同一连接里
可审计可迁移：知识库本身是可 diff、可 backup、可 scp 的文件
AI 友好：所有这些设计的最终目标是让 Agent 能高效读写

这一波运动有一个值得记的标志：发起人不是数据库公司，不是 vector DB 厂商，是程序员社区里的"个人知识库重度用户"。Karpathy 是 OpenAI 联合创始人，Garry Tan 是 YC 总裁，两个人都不是数据库背景，但他们的判断已经传染到了工程界。

7.4 为什么向量数据库正在被收编

22-25 年向量数据库赛道的繁荣本质上是一个特定阶段的产物。当时的主流场景是"企业级 RAG"：海量异构文档、多租户、高 QPS、需要 SLA。这个场景下 Pinecone / Weaviate / Milvus 是合理选择。

26 年浮出水面的另一类场景是"个人或小团队 brain"：

数据规模 GB 级，不是 TB 级
写入主要是 Agent 自己，不是数据管道
查询主要是单个用户或单个 Agent 上下文，不是高并发
知识需要被人审计、修改、版本控制

在这一类场景里，SQLite + FTS5 + sqlite-vec 比 Pinecone 划算得多。不是性能更好，而是心智负担、运维成本、可移植性、隐私边界都更优。

更准确的说法不是"向量数据库被淘汰了"，而是"向量数据库正在被分化"：

企业级：仍然是 Pinecone / Weaviate / Milvus 的舞台
个人 / 小团队：SQLite vec、LanceDB、DuckDB vec、brain.db 这类嵌入式方案在快速吃份额
极简场景：MCP Memory Server 那种 JSONL + 关键词匹配在千条记忆级别完全够用

这场分化的最终格局尚未稳定，但 26 年的方向是明确的：向量数据库不再是 L3+L4 的必选项，而是其中一类场景的可选项。

八、横切问题一：语义索引难题

L1 到 L4 的所有讨论本质上都在回答同一个问题：如何让 Agent 在正确的时间找到正确的知识？这个问题在工程上极像数据库索引设计，但又有一个根本差异。

8.1 一个深刻的类比：外部记忆 ≈ 数据库索引

数据库索引的设计哲学是构建一个足够小、可以长期驻留在内存中的数据结构（如 B-tree），使查询只需要对数复杂度就能定位到完整的数据页。索引不存全部数据，它只存"钩子"，足够让查询引擎判断"下一步该往哪走"的最小信息。

Codex 团队把 AGENTS.md 从百科全书变成目录，正是这个思路的直觉应用：AGENTS.md 是索引，docs/ 是数据页。Anthropic 的 Just-in-Time Retrieval 也是同一思路，用轻量级标识符（文件路径、存储查询）在运行时动态加载。学术界 24-25 年的 MemTree、H-MEM、SHIMI 算法直接把这个类比形式化：MemTree 用动态树状结构组织记忆，H-MEM 通过多层记忆 + 位置索引实现高效长期推理，SHIMI 把知识建模为动态结构化层次（几乎就是语义版 B-tree）。

工业实践中 3 层记忆架构已被验证可以将 token 使用减少 35-45%，同时保持 87% 的语义召回准确率。这个数字背后的逻辑与 CPU 缓存层级（L1/L2/L3）如出一辙：越热的数据离处理器越近，越冷的数据可以容忍更高的访问延迟。

8.2 但语义钩子 ≠ θ-连接

类比到这里遇到根本性困难。

传统数据库中索引的工作原理是 θ-连接：查询表达式 WHERE age > 25 与索引值之间存在精确的、可计算的匹配关系。B-tree 的每个内部节点都知道"大于这个值往右走，小于往左走"——这个判断是确定性的、无歧义的。

但在语义时代，Agent 的"查询"不是 WHERE column = value，而是"我正在实现一个分布式锁，需要了解项目中关于并发控制的约定"。这个查询与外部记忆中的知识之间不存在精确的 θ-连接，它们之间的关系是语义相似性：模糊的、概率性的、依赖上下文的。

这带来两个被学术界和工业界越来越清晰识别出的难题。

8.3 难题一：我们不知道怎么设计知识的结构

数据库中数据的结构（schema）是预先定义的。索引设计可以基于查询模式优化——大部分查询按时间范围过滤，就在时间列上建索引。

但对于 Agent 记忆里的工程知识，我们不知道最优组织结构是什么。目前主流做法是"总分总"式的层次化拆解，顶层目录文件指向若干子文档。这种做法简单直觉，但隐含了一个强假设：知识的语义关系是树状的。

现实中知识关系往往是图状的。一条关于"数据库连接池配置"的知识，可能同时与"性能优化"、“资源管理”、“部署配置”、"故障排查"四个主题相关。

NeurIPS 2025 的 A-MEM 受 Zettelkasten 启发提出突破性思路：不再用静态层次结构组织记忆，而是用动态链接的原子化知识网络。每条记忆是独立节点，通过语义关联动态链接。更关键的是 A-MEM 支持记忆演化，新记忆被整合时可以触发对历史记忆的上下文表征和属性更新。

ICML 2026 的 xMemory 走得更远，明确指出 RAG 范式在 Agent 记忆场景的不匹配：

“RAG targets large, heterogeneous corpora where retrieved passages are diverse, whereas agent memory is a bounded, coherent dialogue stream with highly correlated spans that are often duplicates.”

xMemory 提出"解耦到聚合"方法论：先将记忆解耦为语义组件，组织成四层层次结构（原始消息 → Episode → Semantic → Theme），用"稀疏性-语义"目标函数动态指导记忆的拆分与合并。检索时采用自顶向下策略，仅在能降低读者不确定性时才扩展到更细粒度的证据。

8.4 难题二：我们不知道模型需要什么知识

数据库中查询优化器可以分析查询日志了解"用户通常怎么查"，据此优化索引。但对于 LLM Agent，我们不知道模型在执行到足够深、足够复杂的场景时，它"看到"的世界是什么样的，它最需要的知识是什么。

这是认知科学问题不是工程问题。模型的"意图"是在推理过程中动态涌现的，它自己可能都不知道下一步需要什么知识，直到它遇到了一个它无法解决的子问题。

Context Rot 是这个问题的具体表现：把所有可能相关的知识都塞进上下文，模型也不一定能找到它需要的那条。xMemory 论文对此给出目前最系统的回应：传统 top-k 相似性检索在 Agent 记忆场景中会"塌陷"。Agent 对话历史是高度相关的连贯流，相似性检索会反复返回冗余的、重复的内容，真正需要的前置知识可能因为"不够相似"而被遗漏。它的解决方案是检索应该超越相似性匹配，转而在潜在语义组件上操作。

26 年的 Anatomy of Agentic Memory 综述从更宏观视角识别了这个问题的系统性根源：现有评估基准存在饱和效应，评估指标与语义效用错位，性能高度依赖底层模型。我们甚至还没有一个好的方法来衡量"模型是否找到了它需要的知识"。

8.5 三条前沿路径

面对这两个难题，学术和工业界沿三条路径探索。

第一条路径是从树到图的知识图谱增强。GraphRAG 的基准数据显示，多跳推理场景下知识图谱的准确率比纯向量检索高 3.4 倍。Mem0 和 Zep 已经开始将图结构与向量检索混合使用：向量负责"广度"（找到语义相关的内容），图遍历负责"深度"（沿关系链找到间接相关但关键的知识）。

第二条路径是从被动检索到主动组装的 Context Engineering。Anthropic 和 LangChain 都在推动从"被动检索"到"主动上下文工程"的范式转变。Write / Select / Compress / Isolate 四大策略不再是"查索引-取数据"，而是完整的上下文生命周期管理。

第三条路径是从静态结构到动态演化的自组织记忆。A-MEM 和 xMemory 代表的方向是让记忆结构本身成为可学习、可演化的系统。不再由人类预先设计知识的分类和层次，而是让 Agent 在使用过程中自主发现最优组织方式。这类似于数据库领域的"自适应索引"思想：索引不是预先建好的，而是在查询过程中逐步构建和优化。

一个仍然开放的根本问题是语义空间中的"排序"是否可能。B-tree 之所以能实现对数复杂度查找，是因为它操作的值空间存在全序关系。但在语义空间中，“分布式锁"和"数据库连接池"之间没有"大于"或"小于”，只有"相似度 0.73"这种模糊度量。我们可能永远无法在语义空间中构建出像 B-tree 那样优雅的对数复杂度索引：语义检索的本质可能更接近高维空间中的近似最近邻搜索（ANN），它可以很快，但永远不是精确的。

九、横切问题二：记忆的生命周期

L3 和 L4 的记忆不是只增不减的。无限积累会导致检索噪声增大、存储成本失控、陈旧信息误导决策。成熟的记忆系统需要完整的生命周期管理：创建 → 压缩 → 整合 → 遗忘。

9.1 压缩：从冗余到精炼

递归摘要是最简单的方法：对话历史超过阈值时，用 LLM 把旧消息总结为摘要、替换原文。问题是信息的不可逆丢失，一旦原始细节被摘要替代就无法恢复。

分层压缩是 xMemory 提出的更精细方案：将记忆组织为四层结构（原始消息 → Episode → Semantic → Theme），检索时自顶向下展开，仅在能降低读者不确定性时才扩展到更细粒度。这避免了"要么全量加载、要么只看摘要"的二元困境。

上下文修剪走选择性路线：不压缩所有内容，而是基于相关性分数剔除当前任务不需要的上下文片段。Anthropic 推荐的策略（用轻量级标识符替代完整内容，在需要时动态加载）正是这个方向。

9.2 整合：从碎片到统一

记忆整合解决的是重复和冲突问题。CrewAI 的实现提供了一个清晰的参考：

实时整合：每条新记忆写入时检查与已有记忆的余弦相似度。超过 0.85 时触发 LLM 决策——保留原文、用新记忆替换、或合并为更完整的一条
批量去重：remember_many() 在批次内部以 0.98 的余弦阈值做纯向量去重，不调用 LLM，保证高吞吐
冲突解决：新旧事实相矛盾时（“用户偏好 PostgreSQL” vs “用户偏好 MongoDB”），Zep 的方案是将旧事实标记为失效而非删除，保留决策变迁的历史脉络

A-MEM 的记忆演化机制更进一步：新记忆被整合时不仅影响自身存储位置，还会触发对关联历史记忆的上下文表征更新。记忆网络是活的，新知识的加入会改变旧知识的被理解方式。

GBrain 的 Compiled Truth + Timeline 是同一思路的极简版：上半部分允许覆盖（整合 Compiled Truth），下半部分只追加（Timeline 保留全部证据）。

9.3 主动遗忘：从积累到筛选

主动遗忘可能是最反直觉的环节，通常认为"记住更多"是好事。但在 Agent 场景中过时的记忆比没有记忆更危险，因为它会以高置信度提供错误的上下文。

当前主动遗忘机制有三种路线。

基于时间衰减：CrewAI 的 recency_decay 使用指数衰减函数，使旧记忆的检索权重随时间自然降低。配合可配置半衰期，这种方法能让近期记忆自然浮现，不需要显式删除旧记忆。

基于作用域清理：CrewAI 的 memory.reset() 支持按作用域子树清理记忆，可以遗忘某个项目的所有记忆而保留其他项目，实现精准的选择性遗忘。

基于事实失效：Zep 的时序图谱不"遗忘"任何信息，而是将过时事实标记为失效。严格说这不是遗忘而是"降权"，失效事实仍然可查但不会被默认注入上下文。这种方法在需要历史审计的场景（金融、医疗）中尤为有价值。

一个仍然开放的问题是谁来决定什么应该被遗忘。人类的遗忘很大程度上是无意识的神经过程，而 Agent 的遗忘必须是显式决策。目前的方案要么依赖启发式规则（时间衰减），要么依赖 LLM 判断（整合时的保留 / 删除决策），还没有出现一个被广泛验证的最优策略。

十、横切问题三：MCP 与跨工具互操作

L3 和 L4 都面临一个共同的工程问题：同一份记忆能不能被多个工具读写？MCP 在 24-26 年逐步成为这个问题的事实标准答案。

Anthropic 2024-11 推出的 MCP 把 Agent 和外部工具 / 资源 / 记忆之间的协议标准化。在记忆维度上，MCP Memory Server 用本地 JSONL 文件存储知识图谱，三个核心原语：

实体：图谱节点，包含名称、类型和一组观察记录
关系：节点之间的有向边，主动语态描述
观察：附着在实体上的原子化事实

10 个工具接口覆盖完整 CRUD。Agent 在每次对话开始时调用 read_graph 加载已有记忆，识别到新信息时调用写入接口更新图谱。

MCP 记忆的工程意义有三个。第一是打通了工具壁垒。无论 Claude Desktop、VS Code、Cursor、Codex 还是其他 MCP 兼容客户端，都可以通过同一个 Memory Server 读写记忆。Mem0、Cognee、QMD、GBrain 等服务都已经提供 MCP 接口，意味着同一份记忆可以被任意一个 MCP 客户端访问。第二是降低了切换成本。换工具的时候记忆不丢，只要新工具支持 MCP，把 Memory Server 配上就行。第三是催生了"记忆即服务"的中间件市场。原来记忆能力是绑定在框架里的（LangGraph Store 只能给 LangGraph 用），有了 MCP 之后记忆服务可以独立分发、按使用付费。

当前 MCP 记忆方案的局限仍然明显：JSONL 文件不支持向量检索，search_nodes 只能关键词匹配；缺乏多用户隔离；没有记忆的自动过期和整合能力。这些问题需要下一代 MCP 记忆规范来回答。Anthropic 也意识到了这一点，25-26 年陆续有 RFC 在讨论 MCP Memory 的演进方向。

十一、四层之上：智能体记忆的更广泛用途

Harness Engineering 是 L3 最直接的应用场景，但远不是唯一。把整个四层架构当成基础设施看，外部记忆还有五个更宽的用途。

一是多智能体协作的共享状态。多个专业化 Agent 协同工作时，外部记忆是它们之间传递状态的唯一可靠方式。一个软件开发流水线里，需求分析 Agent 写 product-specs/、架构 Agent 写 design-docs/、编码 Agent 更新 feature_list.json、测试 Agent 更新测试状态、文档 Agent 扫描过时文档发起修复 PR，每个 Agent 独立运行，通过共享的文件系统"通信"。这种角色类似微服务架构中的消息队列：解耦、异步、持久化。Codex 团队的"文档园丁"Agent 和"质量评分"Agent 正是这个用法。

二是跨会话的个性化与用户记忆。这是面向用户 AI 产品中的核心应用。AI 需要记住用户偏好（“我喜欢简洁的代码”）、用户背景（“我是 Java 开发者”）、历史决策（“上次决定用 PostgreSQL”）、进行中的项目状态。这类记忆如果只存在于单次对话上下文中，每次新对话都要重新建立，体验极差。Mem0、Zep、GBrain 正在这个方向快速发展。

三是知识库管理与 RAG 的进化。传统 RAG 是被动的：用户提问 → 检索 → 注入上下文 → 生成。随着 Agent 能力增强，外部记忆正在从"被动检索"进化为"主动维护"——Agent 可以主动写入新发现的重要信息；定期运行的"记忆整理"Agent 可以合并重复、删除过时、建立索引；记忆可以是有层次、有关联的知识图谱而不是扁平文档列表。LLM Wiki 和 GBrain 是这个方向最纯粹的体现。

四是 Agent 行为的约束与治理。外部记忆不只存储"做了什么"，还可以存储"应该怎么做"和"不应该做什么"。Codex 团队的"黄金原则"直接编码到代码仓库：

我们更倾向于使用共享的实用程序包，而不是手工编写的辅助工具
我们不会使用"YOLO 式"探测数据——我们会验证边界，或依赖类型化的 SDK

通过自定义 linter 和 CI 机械强制执行。当 Agent 生成的代码违反这些原则时，CI 失败，Agent 收到带修复指令的错误信息。这是把人类的品味和判断编码为可执行约束。

五是科学研究与长期项目的知识积累。研究项目可能持续数月数年，涉及大量实验、假设、验证和推翻。外部记忆可以记录：已验证的假设和实验结论；已尝试但失败的方向（避免重复踩坑）；当前研究进展和下一步计划；相关文献摘要和关键引用。Anthropic 在 Harness 工程博客中提到，他们相信这些经验"可以应用到科学研究或金融建模等领域所需的长期智能体任务类型"。

十二、未来：记忆即代码 + 自进化

12.1 记忆即代码

Codex 团队提出过一个深刻的洞察：

从智能体的角度来看，它在运行时无法在情境中访问的任何内容都是不存在的。存储在 Google Docs、聊天记录或人们头脑中的知识都无法被系统访问。代码仓库本地的、已版本化的工件就是它所能看到的全部。

这意味着将知识写入外部记忆文件本质上是在为 Agent “立法”。写下的每一条规则、每一个约束、每一份设计文档，都会成为 Agent 行为的一部分。这与"基础设施即代码"高度相似：与其依赖口头约定和隐性知识，不如将一切显式化、版本化、可审计。

记忆即代码在工程上落地的几个具体动作：

外部记忆文件和代码一起被版本控制
外部记忆的质量和新鲜度被 CI 自动验证
外部记忆的更新由专门的"记忆维护"Agent 负责
人类的品味和判断通过外部记忆持续注入系统

26 年 GBrain 和 LLM Wiki 把这一范式推到极致，整个 brain.db 本身就是可 scp、可 git 化、可 backup 的工程产物。

12.2 Brain-Agent 循环：自进化的雏形

GBrain 在 README 里把整个系统的核心思路概括为"Agent 经历读取 → 对话 → 写入的闭环"。每当有新信号进入系统（一封邮件、一段会议录音、一条推文、一个行程变动），Agent 先查询已有知识库（读取），充分理解上下文后作出回应（对话），然后将这次交互产生的新知识写回知识库（写入），供下一次查询使用。

Garry Tan 称这为"大脑-Agent 循环"：每走一圈，Agent 就比上一圈更懂你。这个循环把 26 年所有相关工作的方向都串起来：

LLM Wiki 把"写入"做成"摄入时的预合成"
GBrain 把"读取 + 写入"收在同一份 brain.db 里
A-MEM 让"写入"会触发对历史记忆的属性更新
Anthropic Skills 让"程序性记忆"也能跟着循环成长
Search-R1 把"如何读取"训进模型权重

每个 Agent 都有自己的脑库，每个脑库都在和自己的主人一起持续演化，这是 26 年记忆世界最值得跟踪的方向。

12.3 三个仍然开放的问题

第一是语义索引的理论上限。B-tree 的对数复杂度在语义空间不成立。目前所有方案（向量检索、知识图谱、本体抽取、A-MEM 演化、xMemory 解耦）都是工程层的逼近。是否存在一个语义检索版的"对数复杂度定理"，目前没有定论。

第二是什么应该被遗忘。现有的遗忘机制要么是启发式（时间衰减），要么是 LLM 判断，没有一个在大规模实证上被广泛验证。这个问题的最终答案可能来自神经科学而不是工程。

第三是参数化记忆能不能按需写入。Titans 证明了"可写"的可行性，但要走到"Agent 自己决定写哪部分参数"还有很远。这一步走完，L1 和 L3 的边界会被彻底重画。

小结：把综述压成一张表

问题	26 年的答案
Agent 记忆怎么分层？	四层骨架（按写入主体）：L1 训练 / L2 对话 / L3 跨会话 / L4 外部世界。L1 内部正在分化为静态参数和推理时可写参数。
短时 / 长时怎么对应？	L2 + L1 当前 KV cache = STM；L1 权重 + L3 + L4 = LTM。Titans 直接把这条二分搬进 Transformer。
外部记忆有统一文件标准吗？	没有强标准，但 `AGENTS.md` / `CLAUDE.md` 已经收敛成事实约定，MCP 在协议层提供互操作。
框架内置记忆有哪些路线？	三条：CrewAI 统一 + 复合评分、LangGraph Store + 命名空间、Letta MemGPT 的 OS 式虚拟记忆。
专用记忆服务的差异在哪？	Mem0 信统计信号混合，Zep 信时序知识图谱，Cognee 信本体论组织。Mem0 已放弃图数据库转向实体链接。
参数化记忆增强是什么？	Titans / Infini-attention / MemoryLLM / Memory³ 让"部署后学习"成为可能，是 L1 内部分化，不是新增 L5。
记忆会过期吗？	会。生命周期管理三支柱：压缩（分层摘要）/ 整合（去重 + 冲突解决）/ 主动遗忘（衰减 + 失效）。
26 年最重要的反向运动是什么？	向量数据库回归文件系统。QMD / LLM Wiki / GBrain 三件套指向同一个工程主张：个人 / 小团队规模下用 SQLite + markdown 取代 vector DB sidecar。
未来的核心形态是什么？	记忆即代码 + Brain-Agent 循环：每个 Agent 都有自己的脑库，脑库随使用自我演化。