《记忆是底座》读书笔记

1. 主文章在讲什么（30 秒）

一句话主线：把记忆当”功能”撒上去，得到一个多了几步的 ChatGPT；把记忆当”底座”建出来，得到一个有护城河的产品。一个真实记忆层需要六件事，“向量库 + RAG”只覆盖其中一个半。

反对什么观点：

• 反对”我们有 RAG = 我们有记忆”
• 反对”向量库选 Pinecone vs Weaviate 是关键决策”——它们只解决六件事中的同一件
• 反对”AI 产品的护城河在模型选择上”——护城河在记忆层

如果只能记一句话：

AI 产品的智能上限不取决于模型，取决于记忆系统。

2. 关键概念词典

记忆的三种类型（认知科学借来的）

六个子层 vs 业界主流（容易混的）

Atomic Fact vs Document Chunk（容易混的）

3. 完整脉络（主文章每节展开）

为什么类型化存储是底层选择

把所有”用户说过的”放进同一个向量库，用相似度检索——这是业界默认。

问题：相似度检索不区分问题类型。

• 问 “我们决定了什么” → 应返回 decision 类记录
• 问 “上次失败的原因” → 应返回 failure-typed episodic
• 问 “用户希望我怎么回复” → 应返回 procedural

向量库会返回”和这个查询语义相似的”——可能是 decision 也可能是闲聊片段。

类型化存储的工程实现：每条记录有 type 字段，检索时先按 type 过滤再按相似度排序。这一个改动让 80% 的”问错了类型”问题消失。

为什么原子事实改变检索粒度

向量检索的最小单位是 chunk（文档片段）。问题：用户问”X 是什么”，期望的是一个命题级答案，向量库返回一个段落。用户得自己读。

原子事实的工程实现：

1. 写入时，从每份长文档中自动抽取 3-10 条原子事实
2. 每条事实是 JSON：{fact, source, type, tags}
3. 检索时，先检索 facts，找不到再 fallback 到 chunks

为什么情景记忆是”会学习”的关键

详见 情景记忆专文。这里只说接口：

type: roundtable | sprint | debug | ...
trigger: "..."
result: success | partial | failure
artifact: "..."
lesson: "..."

关键字段是 result。它强迫有人判断成功/失败，这把”系统记得发生了什么”升级为”系统从发生中学习”。

为什么温度模型让记忆”优雅衰减”

记忆不是二元的（保留 / 删除）。它有强度。

没有温度时的两种失败：

• 全部保留 → 三年前过时方案被反复推荐
• 按时间删 → 老但仍重要的决策（“我们的核心架构是 X”）丢失

温度模型：

• Hot：近期高频访问 → 检索时全权重
• Warm：近期访问过 → 检索时正常权重
• Cool：很久没访问 → 检索时降权
• Frozen：归档项目 → 默认不检索，用户主动要求时检索

这是个衰减曲线 + 用户控制的设计。比”全部保留”和”按时间删”都更接近真实记忆。

为什么图层不是 embedding 能替代的

Embedding 找语义相似。它找不到因果。

例子：

• 文档 A：“决定用 LangGraph 做编排”
• 文档 B：“因为 LangGraph 不解决 Memory，加了自己的 episodic 层”

Embedding 找不到 A → B 这条因果链——它们语义不相似（一个谈编排，一个谈记忆）。

但用户问”我们为什么有 episodic 层”时，需要这条链：因为 LangGraph 不解决，所以加。

图层的实现：每个 markdown 文件之间的 wikilink 物化成 links.jsonl 表。检索器可以从 A 的 wikilink 找到 B，遍历整条因果链。

我的茶会系统目前有 195 条 wikilink 边（从 wc -l vault/links.jsonl 看出）。

为什么概念层让系统”真的适应”

记人说过什么是数据。记这是什么样的人，他这样说话是概念。

我的实现：每个频繁合作者维护两个文件：

• behavioral.md：行为模式观察（“K 偏好独立思考的合作伙伴，反对纯执行”）
• current-state.md：当前状态（“今天在做副文章 review，紧迫度高”）

这些每次会话都加载，影响每个其他检索如何被使用。没有这层，系统能背事实但不会根据事实调整行为。

4. 真实代码 / 数据

Atomic Facts 的实际格式

vault/facts/facts.jsonl（截至 2026-05-04 共 324 行）：

{"fact": "Amber 选 Chat-as-Hub 而不是 tabs","source": "parties/product/roundtables/amber-architecture.md","tags": ["amber","ux"],"type": "decision","created_at": "2026-04-08"}
{"fact": "茶会从 2026-03-24 创世，到 2026-05-04 是 41 天","source": "git log","tags": ["meta"],"type": "metric","created_at": "2026-05-04"}
{"fact": "WebSocket 在长 AI 任务上失败率 14%（V0 数据）","source": "parties/tech/ideas/submit-poll-pattern.md","tags": ["pattern","tech"],"type": "metric","created_at": "2026-04-15"}

抽取由 rule 自动触发：每次写入 parties/*/roundtables/ 或 bazaar/patterns/ 时，rule 跑一次 LLM 抽取，追加到 jsonl。

Episodic 记录的实际格式

ateliers/dev/memory/cases/2026-04-22-amber-sprint-2.md：

---
type: sprint
trigger: "Amber Sprint 2 评分闭环部署"
result: partial
date: 2026-04-22
---

## 尝试
用 snapshot 弱点优先 + tool mandatory triggers 实现评分闭环

## 结果
评分功能可用，但多轮一致性不足（每轮分数偏离）

## 原因
没在 prompt 里强制"对照上一轮 snapshot"，模型重新评估

## 教训
评分类 agent 必须在 prompt 里 ground 在前序 snapshot 上，
否则方差会盖过信号

温度模型的实际计算（伪代码）

def temperature(record):
    days_since_last_access = now - record.last_accessed
    access_frequency = record.access_count / record.age_days

    if days_since_last_access < 7 and access_frequency > 0.5:
        return "hot"
    elif days_since_last_access < 30:
        return "warm"
    elif record.project_status == "archived":
        return "frozen"
    else:
        return "cool"

def retrieve(query):
    candidates = vector_search(query)
    return sorted(candidates, key=lambda r: r.score * weight(temperature(r)))

WEIGHTS = {"hot": 1.0, "warm": 0.7, "cool": 0.3, "frozen": 0.0}

知识图谱边的实际格式

vault/links.jsonl（截至 2026-05-04 共 195 条）：

{"source": "parties/career/ideas/insightforge.md","target": "bazaar/patterns/cloudflare-workers-stack.md","weight": "strong","type": "depends_on"}
{"source": "parties/product/roundtables/amber-architecture.md","target": "characters/architect.md","weight": "weak","type": "mentioned"}

每条边有：源、目标、权重（strong / weak）、类型（依赖、提及、反对、支持等）。

数据点：六周后的真实统计

截至 2026-05-04（自 2026-03-24，约 6 周）：

• 原子事实：324 条（自动抽取，每周约 50 条）
• 情景记录：84 条（按 sprint / roundtable / debug 类型分布）
• 知识图谱边：195 条（wikilink 物化）
• pattern 文件：28 个（从情景里手动 + 半自动提炼）
• 圆桌归档：158 场

这些数字本身不是论点，论点是每一类都不为零——证明六个子层都被实际使用，不是 PPT 上的方框。

5. 架构图

图 1：业界主流 vs 完整记忆架构

   业界主流                       完整架构

   ┌──────────────┐               ┌────────────────────┐
   │              │               │  概念层（用户状态）  │
   │              │               ├────────────────────┤
   │              │               │  图（关系 + 因果）   │
   │              │               ├────────────────────┤
   │              │               │  温度（衰减加权）    │
   │  RAG +       │               ├────────────────────┤
   │  向量库       │               │  情景（带结果）      │
   │              │               ├────────────────────┤
   │              │               │  原子事实（命题）    │
   │              │               ├────────────────────┤
   │              │               │  类型化（语义/情景/程序）│
   └──────────────┘               └────────────────────┘
        ↑                              ↑
    一个半子层                     六个子层

图 2：检索流程（业界 vs 我的）

用户问："我们当时为什么决定用 Chat-as-Hub？"

   业界路径                          我的路径

   query → vector search             query → 类型路由（决策类）
        → top-3 chunks                    → 检索 atomic facts
        → stuff into prompt                → 找到事实条目
        → LLM 生成                          → 检索图：找到决策的因果链
                                            → 检索情景：当时的讨论结果
                                            → 综合所有 → LLM 生成

   结果：用户得到上下文                结果：用户得到答案 + 来源
                                       + 因果链 + 当时的讨论

图 3：温度模型让记忆”优雅衰减”

   时间 →
   |
   |  ┌─────┐
   |  │ HOT │ 高频访问，最近写入
   |  └──┬──┘
   |     ↓ 时间过去
   |  ┌─────┐
   |  │WARM │ 仍有访问，权重略降
   |  └──┬──┘
   |     ↓ 时间过去
   |  ┌─────┐
   |  │COOL │ 久未访问，降权但仍可检索
   |  └──┬──┘
   |     ↓ 项目归档 OR 长期未访问
   |  ┌─────┐
   |  │FRZN │ 默认不检索，用户主动调出
   |  └─────┘

   每个状态有不同的检索权重：
   HOT 1.0  WARM 0.7  COOL 0.3  FRZN 0.0

图 4：图层的因果链

   用户问："为什么 Amber 有 episodic 层？"

   embedding 检索（找不到链）：
   - "决定用 LangGraph"    ← 和查询不相似
   - "加了 episodic 层"    ← 和查询稍相似
   - "Memory 子层架构"     ← 和查询稍相似
   返回：随便几个语义相关片段

   图检索（找到链）：
   决定用 LangGraph (X)
        │ wikilink: depends_on
        ↓
   LangGraph 不解决 Memory (Y)
        │ wikilink: causes
        ↓
   加了 episodic 层 (Z)

   遍历 X→Y→Z，返回完整因果链
   答案：因为 LangGraph 不解决 Memory，所以我们加了 episodic 层

图 5：六层记忆的完整数据流

                  写入路径

    长文档（圆桌归档）
         │
         ↓
    类型化存储（标 type）
         │
         ↓
    原子事实抽取（rule 触发）→ facts.jsonl
         │
         ↓
    wikilink 解析 → links.jsonl
         │
         ↓
    （存入向量库 + facts + graph）

                  检索路径

    用户查询
         │
         ↓
    类型路由（按问题类型选层）
         │
    ┌────┼────┬────────┬───────┐
    ↓    ↓    ↓        ↓       ↓
 facts vector graph episodic procedural
    └────┴────┴────────┴───────┘
         │
         ↓
    温度加权排序
         │
         ↓
    概念层（按用户状态调整呈现）
         │
         ↓
    LLM 生成 + 引用

6. 我的批注

我和我以前的想法的冲突

以前：我以为做 AI 产品的护城河是 “我有什么模型 + 什么 prompt”。 现在：模型是商品（每三个月一代），prompt 容易复制，只有记忆系统是不可复制的——它需要时间堆积，无法买无法抄。

以前：我把 “memory = 向量库” 当默认。 现在：向量库只是六个子层的最浅一片。我现在见到任何 AI 产品 pitch 说 “我们有记忆”，第一个问题是 “你的六层在哪里”。

以前：我以为 episodic memory 是研究阶段的玩具。 现在：它是工程上可上线的功能，一周内能加。没人加的原因不是技术难，是产品判断不到位。

反复想过的部分

为什么不直接抄人脑的记忆模型——人脑还有 working memory（短期工作记忆）我没列。LLM 的 context window 已经天然是 working memory。所以我跳过了它。如果未来 LLM 的 context 不再是问题，working memory 这个概念会消失。

MCP 在哪一层——MCP 是接口，不是架构。它标准化了 agent 怎么和记忆/工具说话，但不规定记忆架构。我的六层架构可以用 MCP 暴露给 agent，也可以不用 MCP。MCP 解决的是互操作性，不是记忆质量。

为什么概念层不是更高级的”用户画像”——传统”用户画像”是营销概念，预测用户行为。我的概念层是指导面团行为——根据用户状态调整怎么和用户对话。两者目标不同：画像服务公司，概念层服务用户。

下次会改的

• 温度计算的参数——目前 hot/warm/cool 的阈值是直觉拍的（7 天 / 30 天）。应该根据实际检索命中率反推阈值。
• 概念层的形态——目前是 markdown 文件，每次会话全文加载。规模大了会挤占 context。应该改成”按当前对话相关性”加载概念层片段。
• 图层的边类型——目前只有 strong / weak 两种权重。应该加 causes / depends_on / contradicts / supports 等关系类型，让因果链检索更准。

7. 面试话术（按时长背三档）

30 秒电梯版

2 分钟白板版

10 分钟深入版

8. 可能被问到的 5 个问题 + 回应

问题 1：六层听起来很复杂，小团队能负担吗？

回应：

不是从第一天做到极致。值得做的最小集合是前三层：类型化存储、原子事实抽取、情景记录。这三层一周能搭好。

后三层（温度、图、概念）是随系统运行时间自然需要的——你会因为遇到具体问题去加它们。比如 “三个月前过时建议反复出现” → 加温度模型；“用户问因果但找不到” → 加图层。

反过来如果一开始就跳过它们，第三个月你会发现自己在重新发明它们，而且发明得不好——因为前三层的设计没考虑后三层。所以最小集合做对，预留扩展点。

问题 2：用 MCP 不就解决了吗？

回应：

MCP 是接口，不是架构。它标准化了 agent 怎么和记忆说话，但不规定记忆架构。我的六层可以用 MCP 暴露给 agent，也可以不用。

类比：MCP 是 SQL 协议，记忆架构是数据库设计。SQL 不规定你怎么设计表。

用了 MCP 但只暴露一个向量库，这只是用了 MCP，没有解决记忆质量。

问题 3：温度模型听起来像缓存策略，有意义吗？

回应：

表面像，本质不是。缓存策略关心的是性能——访问快慢。温度模型关心的是相关性——这个记忆现在还重要吗。

一个具体差异：缓存里热点数据”不再热”是性能问题（变慢）。温度模型里 hot 变 cool 是预期行为（旧记忆不再相关）。

另一个差异：温度模型支持用户主动调出 frozen——“我要看 6 个月前归档项目的决策”。缓存没有这种主动性。

问题 4：你说”模型是商品”——但用户体验高度依赖模型质量啊？

回应：

在模型快速进步的时间窗口里这是对的——GPT-3 → GPT-4 跳过两个数量级，谁用 GPT-4 谁赢。

但 2026 年我们已经进入模型质量收敛期——前三家模型在大多数任务上差异已经很小。这时模型不再是差异化点，而是基础设施。

类比：2010 年用什么数据库（MySQL vs Postgres）有差异；2020 年这个差异基本没了，差异在应用层。AI 产品现在正在经历这个转折——差异化从模型层下移到应用层，而记忆是应用层最大的杠杆。

问题 5：你说”没人这么做”——但 LangChain / LlamaIndex 都在做记忆框架啊？

回应：

它们做的是记忆基础设施——VectorStoreMemory、ConversationBufferMemory、SummaryMemory 这种。这是工具，不是架构。

类比：这就像 ORM（SQLAlchemy 等）和数据库设计的关系。ORM 给你工具，但怎么设计你的表 schema 是你的事——不同应用需要不同的 schema。

我的六层是架构——告诉你应该有哪些层、每层解决什么、怎么互相关联。LangChain 等可以实现这个架构，但它们不规定它。

这就是为什么”用了 LangChain Memory” ≠ “有完整记忆架构”——大多数 LangChain 用户只用了它的 ConversationBufferMemory，那只是六层中的最浅一层。

9. 相关链接

内部（其他主文章）

• Five Layers of an Agent System — 记忆是第 1 层
• Episodic Memory — 第三个子层的展开
• The 2026 Agent Framework Landscape — 业界框架在记忆层各做什么

外部参考

• Reflexion (Shinn et al., 2023) — 情景记忆 + 反思的论文起源
• Generative Agents (Park et al., 2023) — 早期完整记忆架构
• MemGPT (Packer et al., 2023) — 长期记忆 + working memory 的尝试
• Anthropic: Building Effective Agents

相关概念

• Reflexion ≈ 情景记忆 + 模式提炼（学术起源）
• MemGPT ≈ 把记忆分层（OS-style）
• Letta（前 MemGPT） ≈ 记忆相关 SDK 的尝试
• MCP = 记忆/工具接口标准（不是架构）