AI 记忆架构的三维进化：从管道到网络
三个月前我画了一个「热→温→冷」的线性管道。跑下来发现，纵向晋升是必要条件，但不是充分条件。知识不是沿管道流动的液体，它是根系——向下扎根的同时，横向蔓延、交叉嫁接。管道负责把信息从对话层送到知识层，但知识到达目的地之后的关联、腐化、可发现性，是另一组问题。
起点：一条管道
最初的想法很简单：对话中的信息，提炼后存下来，需要时拿出来。
对话（热）→ 提炼（温）→ 沉淀（冷）
这个模型没有错。context-infrastructure 的 Observer→Reflector→GC Pipeline 证明了纵向晋升是可行的。温记忆压缩到 100 行，任何平台秒加载，这个设计确实好用。
但跑了三个月，三个管道解决不了的问题冒出来了。
问题一：知识孤岛
wiki 里建了 40 个页面。AI 可观测性和 Agent 护栏各自写得很好，但没人发现它们说的是同一件事——LLM 系统的可信度防御。一个管输出质量评估，一个管行为约束，底层逻辑是同构的。
纵向管道不负责这个——它的职责是把信息从热送到冷，不是让冷知识之间互相认识。这就像图书馆买了很多书，每本都分类入库了，但没有目录卡，也没有「相关推荐」。信息到了终点，但终点之间没有路。
解法：横向关联
wikilinks（双向链接）
页面 A 引用页面 B，B 的反向链接自动显示 A
→ 不需要主动维护，写的时候随手一链就行
标签聚类
同标签的页面自动归类
`agent` 标签下：agent-architecture, agent-memory, agent-guardrails, harness-engineering
→ 浏览一个标签就能看到整个领域地图
横向扫描（LINT 检查项之一）
同周创建 + 共享 2+ 标签 + 未互链 → 自动报告
→ 发现隐性关联，人脑记不住所有页面的创建时间和标签组合
跨域桥接
科技洞察 → 投资判断（如 AI 推理成本归因 → 算力股估值逻辑）
哲学思考 → 决策框架（如 Goodhart's Law → TDD 失效 → 管理指标陷阱）
→ 这是 wiki 最核心的价值，靠标签交叉和 wikilinks 实现
知识不是一棵树，是一张网。纵向管道处理深度，横向关联处理广度。两者不矛盾——管道把书买进来，关联让书和书之间产生对话。
需要说明的是，横向关联和活性维护之间有交叉。比如 LINT 的「横向链接缺失」检查项——它既是横向关联的发现工具（找到应该连接但没连接的页面对），也是活性维护的一部分（定期巡检）。这不是设计缺陷，是两个维度在边界处自然重叠，就像城市里「修路」（横向）和「市政巡检」（活性）本来就有交叉。
问题二：知识腐化
40 个页面，如果不维护，三个月后：
- 有些过时了（工具版本、API 变化）
- 有些互相矛盾（三月的认知和五月的新信息冲突）
- 有些变成孤岛（创建后没人再链接过）
- 标签体系漂移（随手加了不在分类法里的标签）
纵向管道只管往里灌，不管清淤。
解法：活性维护
Wiki LINT（每周自动运行，7 项检查）
1. 矛盾检测 — frontmatter contradictions 字段 + 内容冲突扫描
2. 孤立页面 — 入站链接 = 0
3. 缺失概念页 — 被引用 2+ 次但不存在的 wikilink
4. 过时内容 — updated 超过 60 天
5. 标签一致性 — 不在分类法中的标签
6. 横向链接缺失 — 同周 + 共享标签但未互链
7. Index 同步 — 实际文件 vs index.md 条目差异
→ 只报告不修改，人确认后才执行
公理反馈回路
应用记录追踪：每次公理被引用/用于决策，记一行
→ 日期 / 场景 / 触发 / 结果
→ 应用次数 ≥ 5 → 升级候选
→ 周报推送提醒评审
→ 确认升级 → 进入公理正式序列
→ 否决 → 重置计数，记录理由
→ 知识库不是博物馆，是活的系统
纵向管道的 GC 只管”这条记忆过不过期”。活性维护管的是”整个知识库健不健康”。
但不是所有冷知识都需要同等强度的维护。有些知识是稳定态——数学定理、经典文献、思维模型（比如二阶效应），写完基本不用动。有些是快速变化态——工具版本、API 变化、市场数据，一两个月就过时。LINT 检查的「过时内容」项（updated 超过 60 天）是一个粗粒度的过滤，实际操作中我会看内容性质决定是否更新，而不是机械地刷日期。
问题三：找不到
冷知识存在 Obsidian wiki 里，40 个页面，几千行内容。你说”之前讨论过 Agent 文件系统的三代演化”，我需要能找到它。
两个问题：
- 精确回忆 — 你提到了具体关键词，FTS5 全文搜索能搞定
- 模糊关联 — 你说”那个关于知识怎么长的模型”，关键词匹配失效，需要语义检索
解法：多层检索
MEMORY.md（Prompt Memory）
每轮注入，~2K 字符，最紧急的信息
→ 不需要搜索，永远在眼前
Session Search（FTS5）
历史对话全文检索
→ 精确回忆：关键词、人名、项目名
→ 跨 session 回忆：两个月前讨论过什么
ObsidianRAG（向量检索）
287 notes → 2120 chunks
all-MiniLM-L6-v2 本地 embedding
→ 语义搜索：描述性查询、模糊关联
→ 不依赖精确关键词
Wiki Index + Wikilinks（导航）
index.md → 领域地图
wikilinks → 页面间跳转
→ 浏览式探索：不知道要找什么时用
四层检索各有边界。不是谁替代谁，是不同场景用不同工具。
三维模型
把三个问题的解法合在一起：
graph TD subgraph 纵向晋升 H[热记忆<br/>对话采集] --> W[温记忆<br/>核心画像] W --> C[冷知识<br/>Wiki 页面] end subgraph 横向关联 WL[wikilinks<br/>双向链接] TAG[标签聚类<br/>同标签发现] LAT[横向扫描<br/>隐性关联] end subgraph 活性维护 LINT[LINT 巡检<br/>7 项检查] AX[公理反馈<br/>应用追踪] RET[RAG + FTS5<br/>语义+精确检索] end C --- WL C --- TAG C --- LAT C --- LINT C --- AX C --- RET LAT -.->|边界交叉| LINT
- 纵向晋升（热→温→冷）：信息的密度递减、持久性递增
- 横向关联（链接/标签/扫描）：知识节点之间的语义连接
- 活性维护（LINT/反馈/检索）：保持整个系统的健康和可发现性
原文的「热→温→冷」没有错，但它只描述了一个维度。就像只说”树要扎根”——没错，但根系也会横向蔓延，土壤也需要定期松土施肥。
实际数据
跑了三个月的 Obsidian wiki：
| 指标 | 数值 | 说明 |
|---|---|---|
| Wiki 页面总数 | 40 | entity + concept + comparison + query |
| 实体页 | 6 | 公司/产品实体 |
| 概念页 | 27 | 技术/思维模型概念 |
| 跨域 wikilinks | ~120 条出站链接 | 平均每页 3 个出站链接 |
| 公理条目 | 25 条 | 三轮审计后从 43 条合并，去重+精简 |
| LINT 检查项 | 7 项 | 每周一自动运行 |
| RAG 索引 | 287 notes → 2120 chunks | 全库（wiki 40 页 + 日记/剪藏/非wiki笔记 247 篇） |
| Session Search | 全量历史对话 FTS5 索引 | 跨 session 精确回忆 |
说明几个数据点：
287 vs 40：wiki 页面只有 40 个，是经过提炼的结构化知识。RAG 索引覆盖整个 Obsidian vault（287 篇），包括日记、剪藏、非 wiki 笔记——这些是原始素材，还没消化进 wiki。两个数字不矛盾，正好对应了三层模型中的「冷知识（wiki）」和「收集层（全库）」。
公理从 43 到 25：不是简单去重。三轮审计做了三件事：合并语义重叠的条目（比如「做减法」和「简单优先」合并成一条）、淘汰实践中反复不被引用的条目、升级从实践经验中涌现的新条目。审计过程记录在 公理审计报告。
效果层面：横向关联最具体的例子是「AI 是品位的放大器」这条公理——它链接到投资领域的复利职业策略，又链接到哲学层的认知框架。三个领域的页面因为 wikilinks 形成了三角连接。这不是规划出来的，是写的时候自然发生的。但坦诚说，目前只有一个这样的跨域三角连接案例，大部分 wikilinks 还是在同领域内（AI 页面链 AI 页面）。横向关联的潜力已经能看到，但密度还不够。
和原文的关系
本文是对 跨平台AI人格与记忆架构设计 中「第二层：记忆」的实战演进。原文定义了纵向晋升模型，本文补上了横向关联和活性维护两个维度。
如果把记忆架构比作图书馆：
- 纵向晋升是入库流程 — 新书从采购（热）到编目（温）到上架（冷）
- 横向关联是目录卡和推荐架 — 让读者发现「借了这本的人也借了那本」
- 活性维护是馆员巡检 — 定期清查过时书籍、修复断裂的目录引用、补充缺失的交叉推荐
只有入库没有目录，书在架子上但找不到。只有入库和目录没有巡检，几年后目录卡和实际书籍对不上了。
至于这套体系值不值得——40 个页面的 wiki，LINT 每周运行一次，确认时间大概 5 分钟。公理反馈回路是自动追踪，只在周报时才需要人看。RAG 索引构建一次，后续增量更新。目前这个规模下，维护成本可以接受。如果 wiki 涨到 400 页，可能需要重新评估 LINT 的噪声水平和人工确认的负担。