S21-B06 · 记忆与状态

适用读者：Agent "聊两句就忘"或记忆越存越乱的人。
前置：S21-B01、S20-J02。
覆盖旧文：709(2588) + 记忆 7 卡 = 3,583 点（最大基础篇）。
覆盖扩展：E-S21-007（源数据与索引分离）。
上一篇：S21-B05 · MCP：模型上下文协议
下一篇：S21-J01 · Harness 工程。

1. 一句话结论

记忆要分两层存：源数据（人类可读、可 git 管理）+ 索引（机器可检索）。混在一起，改不动也查不准。

实测可行的结构：

memory/
├── 2026-11-06-项目约定.md        ← 源数据（Markdown，可读可 diff）
├── 2026-11-05-用户偏好.md
└── index.sqlite                  ← 索引（向量/倒排，可重建）

层	特点	为什么分离
Markdown 源数据	可读、可版本控制、可人工修正	索引重建不丢内容
SQLite 索引	向量/BM25、快速检索	换模型只需重建索引（S20-B02）

2. 三种记忆（E-S21-007）

类型	内容	存储
工作记忆	当前任务状态	内存/上下文
情景记忆	发生过什么（会话记录）	追加日志
语义记忆	事实与偏好	结构化 + 检索

判据："这条信息下次会话还要用吗？" 要 → 落盘（语义记忆）；不要 → 只在上下文。

3. 写入策略：什么该记

该记	不该记
用户明确的偏好/约定	一次性闲聊
项目决策与原因	可从代码推导的事实
失败教训（避免重复踩坑）	敏感凭据（绝不）

"记太多会怎样"：检索噪声上升（S20-B03 的 topK 噪声）——记忆质量 > 记忆数量。

4. 检索策略：怎么取

① 关键词/向量混合召回（S20-B03）
② 按时间衰减重排（越近越相关）
③ 只取 top-N，控制上下文预算（S20-J02）

"为什么不把记忆全塞上下文"：token 成本 + 注意力稀释——预算只有那么多。

5. 五个误区

误区	真相
"记忆就是向量库"	源数据与索引要分离
"记得越多越聪明"	噪声会拖累检索
"记忆能自动更新"	要有写入规则与冲突处理
"可以把凭据记进去"	绝不能
"换模型不用管记忆"	索引要重建，源数据不用

6. 自检

两层存储各是什么、为什么分离？
三种记忆的边界？
什么该记、什么不该记？
检索的三步？
为什么"记忆质量>数量"？

7. 下一篇

S21-J01 · Harness 工程：运行时、Loop 与沙箱

记忆讲完，进阶层开始：Agent 的"外壳"到底管什么。

本篇属于系列《S21 · Agent 工程与 MCP》。旧文来源：A-709 + 记忆 7 卡；扩展点 E-S21-007。