给 AI 的记忆分个层：上下文数据库的设想

写在前面

用 AI 编程助手干了半年活之后，我最强烈的感受不是"它不够聪明"，而是它记不住该记的东西。

昨天说过的事今天要重说一遍；项目里某个模块的约定，换个会话就失忆；沉淀下来的技能和踩过的坑，躺在某个角落里等着被重新发现。而市面上的方案——向量数据库、RAG 管线、各种记忆插件——用下来总觉得隔靴搔痒：能检索到，但检索回来的东西常常不是"我想要的那个"，而是"字面上像的那个"。

这段时间我在整理一套自己的思路，暂且叫它上下文数据库。这篇把设想写下来——它还没有经过大规模验证，更像是把我踩过的痛点翻译成结构。如果你也在折腾 AI 的长期记忆，欢迎交换想法。

一、两个真实的问题

先说传统 RAG 在我场景里的两个毛病。

毛病一：扁平检索丢层级。 RAG 把知识切成片段、算向量、按相似度召回。但知识本身不是扁平的：一份设计文档有章节，章节下有小节，小节里的段落只有放在小节里才有意义。扁平检索命中一个片段时，它的邻居丢了——你拿回"第 3.2 节的半段话"，却不知道 3.1 和 3.3 说了什么。相似度算法只对"字面接近"负责，不对"结构完整"负责。

毛病二：三套系统互不相通。 一个 AI 助手实际需要的上下文至少有三类：跨会话的长期记忆（用户的偏好、历史决定）、项目知识（这个代码库的架构约定）、可复用的技能（怎么做某类任务）。它们通常散落在记忆插件、向量库、提示词模板三个地方，检索方式、更新时机、优先级规则各不相同。助手要"用上"它们，全凭各系统的运气。

这两个毛病指向同一个缺失：上下文缺一个统一的组织结构。

二、把上下文组织成虚拟文件系统

我的核心设想是：把所有上下文组织成一棵目录树，像文件系统一样。记忆、知识、技能不再分家，都是树上的节点——只是挂的目录不同：

viking://
├── memories/          # 长期记忆：偏好、决定、经验
│   ├── preferences/
│   └── experiences/
├── resources/         # 项目知识：文档、笔记、代码库摘要
│   └── projects/workforce-hub/
└── skills/            # 可复用技能：某类任务的做法

为什么是文件系统隐喻？因为它自带三个 RAG 缺失的性质：层级（目录就是知识的组织结构）、路径（每个节点有稳定的地址，可被引用和更新）、作用域（检索时可以限定在某个子树里）。

关键设计：每个语义目录生成两层摘要，和原文一起构成三级结构。 检索的粒度从"片段"变成"目录"，摘要负责让 AI 廉价地判断"这个目录值不值得深入"。

三、L0/L1/L2：让 AI 先花小钱再花大钱

三级结构里，token 成本逐级上升，用途逐级具体：

L0 Abstract——一句话概括。 “这是 workforce-hub 的消息模块设计，核心是 seq_no 游标和 outbox 投递。” 一行，几十个 token。用途：快速判断相关性。AI 扫一遍目录的 L0，就能把 99% 的无关目录排除掉。

L1 Overview——结构与要点。 目录里有什么、分几块、每块的结论。几百个 token。用途：规划检索路径。AI 看到 L1 就知道"我要的东西在子目录 A 还是 B"，不用打开每个文件。

L2 Details——完整原文。 只有确认相关后才读。几千到几万个 token。用途：真正干活。

这三级背后的经济学很简单：判断"要不要读"不该花"读完"的钱。 现在的 RAG 之所以费 token 还不准，是因为它跳过了判断环节，直接把一堆"可能相关"的原文塞进上下文——AI 用一大段昂贵 token 去发现其中只有一小段有用。分层之后，贵的原文只在精准确认后加载，廉价的摘要承担了全部的初筛。

有意思的是这套结构对人类也成立——我翻自己的笔记找东西，也是先看标题（L0）、再扫目录（L1）、最后才通读（L2）。AI 的记忆组织没有理由比人更笨。

四、目录感知检索：先找房间，再翻抽屉

有了层级结构，检索流程也应该改成分阶段的：

第一步：向量检索定位候选目录（不是片段！）
第二步：解析目录范围（确定候选目录覆盖了哪些子树）
第三步：在范围内部做精排，按 L0 → L1 → L2 逐级加载

第二步的"解析目录范围"值得单独说。候选目录之间有父子关系和邻居关系——两个候选可能同属一个父目录，意味着它们的兄弟目录大概率相关。用 Trie 树把目录路径解析成范围，就能把邻接上下文带回来：命中"消息存储"目录时，旁边的"消息投递"目录知道该跟着进来，因为它们在树上本来就长在一起。

相比全局扁平检索，这条路的好处是检索结果自带结构：AI 拿到的不适一袋散装片段，而是"这是目录 A 的概况、目录 B 的两个关键段落、它们之间的关系"。喂给模型的上下文不再需要它自己脑补结构。

五、现实问题：设想和落地之间的三道坎

如实说，这套设想离"拿来就用"还有距离，我自己卡在三道坎上：

摘要一致性。 目录内容更新后，L0/L1 摘要要跟着更新，否则摘要会撒谎——说好的"三步方案"，点进去已经变成五步。摘要更新需要再跑一次模型，成本和时机（每次写入都更？定时批量？）都得权衡。

分层粒度。 目录切太粗，L1 就退化成长文，失去初筛价值；切太细，树上几千个目录，扫一遍 L0 也是负担。粒度本质上是个"知识的颗粒度"问题，没有万能答案，只能按内容性质分治。

写入路径。 人写笔记有明确的"我要存个东西"动作，但 AI 会话里的知识是流动的——一段对话结束，哪些该沉淀成目录、挂在哪、和已有目录合并还是新建？没有好的自动化策略之前，写入靠人肉审核，规模上不去。

我的当前解法是笨办法：先在个人知识库的规模（几百个目录）上人工维护结构，让检索侧先跑通；写入自动化等检索的价值被验证之后再做。先把"读"做对，再优化"写"——顺序反过来容易两头都做不好。

六、小结

三点体会：

AI 记忆的问题不是"存不下"，是"组织不好"。 向量库解决了"存"和"算相似"，但没解决"结构"——而理解任何知识都需要结构。
分层的本质是 token 经济学。 判断相关性用 L0，规划路径用 L1，干活才用 L2——让贵的 token 只花在确认过的地方。
检索结果自带结构，好过让模型脑补结构。 目录感知的检索把邻居和层级一起带回来，模型拿到的不再是一袋碎片。

这套设想还在我自己知识库的小规模实验里。等它跑出些可信的结论，我再来更新这篇——就当这是 L0 层的锚点。