你的Agent需要记忆系统
   │
   ├─ [Step 1] 先分类 → 该扔的/该缓存的/该存的
   │   跳过后果：MEMORY.md 从 200行涨到 800行，关键信息被淹没
   │
   ├─ [Step 2] 选存储 → 上 SQLite FTS5，不上向量库
   │   跳过后果：装了向量库但 90% 查询不需要语义搜索，多花运维成本
   │
   ├─ [Step 3] 加时效 → 每条记忆 created_at + valid_until + superseded_by
   │   跳过后果：3个月前的错误配置参数仍然被检索到，制造回归bug
   │
   ├─ [Step 4] 对齐缓存 → Frozen Snapshot：稳定前置，动态后置
   │   跳过后果：API 成本高出 25-75%，prefix cache 从未命中
   │
   ├─ [Step 5] 加归纳 → 每日 Auto-Dream：去重、冲突检测、时效淘汰
   │   跳过后果：搜索噪音——5条"渲染崩溃"记录来自不同期，Agent 合成错误答案
   │
   ├─ [Step 6] 按需升配 → 模糊查询用向量库、时序管理用知识图谱
   │   跳过后果：不跳过也没损失——但前置条件不完备就上是更精致的垃圾场
   │
   └─ [Step 7] 验证 → 3个指标 + 5个测试用例
       跳过后果：不知道系统在变好还是变坏，盲目迭代

类比：搬家 → 卖旧报纸(扔) + 随身带牙刷(缓存) + 锁好房产证(存)

何时重新分类：每季度一次，或在以下事件发生时：

1. 项目框架变更
2. Agent 工具集增减
3. 发现某类信息持续未被检索

黄金法则：FTS5 廉价宽召回 → LLM 昂贵精排。解耦搜索和理解。

何时升级到向量库：

1. 你的搜索词中“像上次”类查询占比 > 30%
2. FTS5 Top-5 召回率连续 3 天 < 80%
3. 跨话题语义发现成为日常需求

每条记忆：
├─ created_at    → 什么时候产生的
├─ valid_until   → 什么时候到期（NULL = 永不过期）
└─ superseded_by → 被哪条新记忆替代（NULL = 仍是权威）

永不删除旧记录 — 只标记 superseded。支持“当时 vs 现在”的时间旅行查询。

两个立刻可用的修复： 1. System Prompt 拆两段：头部冻结 + 尾部动态 2. 必须注入动态信息？放在整个 Prompt 的最末尾

检查方法：

看你的 API 用量报表：
Cache Read Tokens ÷ Total Input Tokens > 80% 才算合格
低于 60% = 你正在烧钱

触发时机：

1. `session` 结束时（低频率使用场景）
2. 每日凌晨 cron（高频使用场景）
3. 任意时刻手动 `consolidate`

不做的代价：搜索噪音。相似片段互相干扰，Agent 合成错误答案。

前置条件：Step 1-5 全部跑通且验证通过，才考虑升级。

不要做的事：

1. 前置条件不完备就上向量库 → 更精致的垃圾场
2. 把知识图谱当全量关系模型 → 只做事实时序管理

5 个测试用例：

1. “上次 bug 怎么修的？” → 精确召回

2. “项目现在用什么框架？” → 时效性

3. “删除 /tmp 临时文件” → 信噪比（记忆不应干扰）

4. “3 个月前决策还适用吗？” → 时间旅行

5. 100 次请求后 Cache 命中率 → 经济账

该扔的 = 能重新推导的
该缓存的 = 短期高价值、跟着 session 走
该存的 = 不可推导的、丢了就没了

每一行是否只归了一类？（不重复、不遗漏）

“该存”列里，有没有东西是能重新推导的？（有→移到“该扔”）

“该缓存”列里，有没有超过 session 生命周期的？（有→移到“该存”）

“该扔”列里，有没有丢了就无法恢复的？（有→移到“该存”）

本文转载自 https://github.com/LesterYu0/feynman-build-workshop