记忆系统系列

三层记忆模型——工作记忆、情景记忆、语义知识

一、为什么是三层的

上一篇我们诊断了"断片"的三种表现，提出用三层记忆模型来归因。这篇深入每一层，看它们各自解决什么问题、用什么技术实现、有什么取舍。

但先回答一个问题：为什么是三层的，不是两层的、也不是四层的？

这个框架来自认知科学。心理学家 Atkinson 和 Shiffrin 在 1968 年提出了记忆的多重存储模型，后来 Tulving 区分了情景记忆和语义记忆。这个三分法在神经科学和心理学中经过了几十年的验证。

但这不是照搬心理学。三层的合理性来自工程实践的需求分析：

层	管理对象	生命周期	核心矛盾
工作记忆	当前会话的内容	秒-分钟级	上下文窗口到底够不够大
情景记忆	历史会话的记录	天-周级	存什么、怎么找、什么时候忘
语义知识	长期沉淀的技能	月-年级	如何从经验中提炼可用的模式

三层对应三个不同的生命周期，意味着三种不同的存储方案、检索策略和更新策略。混在一起会同时降低三个维度的质量。

二、工作记忆（Working Memory）

它解决什么问题

问题： 在一个长对话中，Agent 记不住前面说过什么、做过什么决策。

核心机制

工作记忆的本质是当前会话的上下文窗口管理。它不是"存储系统"，而是"注意力管理系统"——在有限的 Token 预算内，决定什么信息应该保留、什么可以压缩、什么必须丢弃。

原始对话流：
  [Round 1] 用户说 A → Agent 说 A1
  [Round 2] 用户说 B → Agent 说 B1（基于 A+A1+B）
  [Round 3] 用户说 C → Agent 说 C1（基于 A+A1+B+B1+C）
  ...

问题：Round 10 时，Round 1 的信息已经被稀释

解决工作记忆的五种策略

策略	做法	优点	缺点
全文保留	把整个对话历史塞进上下文	信息完整	Token 消耗巨大，很快达到上限
滑动窗口	只保留最近 N 轮对话	简单可控	早期信息完全丢失
摘要压缩	定期把前面的内容压缩成摘要	节省 Token，保留关键信息	有信息损失，摘要质量不稳定
优先级保留	标记重要信息强制保留	关键信息不丢	需要判断"什么重要"
分层上下文	系统指令+关键事实+近期对话+当前轮	结构化管理	实现复杂

在实践中，摘要压缩 + 优先级保留的组合是最实用的：定期用 LLM 自己把前面的对话压缩成结构化摘要，同时标记关键决策和参数为"永久保留"。

工程要点

• Token 预算是硬约束。 给工作记忆分配多少 Token 直接影响 Agent 的质量和成本。建议为关键信息保留 20-30% 的上下文窗口。
• 摘要不是万能的。 LLM 生成的摘要可能丢失细节或引入错误。建议定期让用户或验证机制检查摘要质量。
• 工作记忆是"易失性"的。 会话结束后，工作记忆应该被清空或转存为情景记忆——不要试图在下一个会话中复用原始的工作记忆内容。

三、情景记忆（Episodic Memory）

它解决什么问题

问题： 每次开启新会话，Agent 都不记得之前讨论过什么、做过什么决策。

这是"断片"最频繁的领域，也是记忆系统中最需要工程投入的部分。

核心机制

情景记忆的本质是跨会话的状态持久化和检索。它把过去会话中的关键信息保存下来，在新的会话中提供给 Agent 使用。

会话 1：用户调试字段映射问题 → 定位到 bug → 修复 → 部署
                    ↓
              关键决策被持久化
                    ↓
会话 2：用户开始新任务 → Agent 自动检索相关情景记忆
        → "提醒：你上次处理了字段映射问题，结论是..."

存储什么

不是存储整个会话（那是日志），而是存储结构化的事件：

存储字段	说明	示例
时间戳	事件发生时间	2026-07-06T14:30:00
类型	事件分类	bug_fix / decision / investigation
实体	涉及的核心对象	sync_engine / field_mapping
上下文	事件描述	"字段 X 映射错误，hardcode 导致"
结论	最终决策/结果	"改为从 field_mapping 表动态读取"

检索策略

模式	触发条件	做法	适用场景
主动检索	新会话启动时	自动加载最近 N 条相关记忆	日常开发，连续工作
按需检索	Agent 发现和当前问题相关	语义搜索匹配	跨越较长时间的问题
时间线检索	用户指定时间范围	按时间范围查询	回溯排查

工程要点

• 检索质量 > 存储量。 存了 10000 条记忆但找不到需要的，等于没存。
• 需要遗忘策略。 不是所有历史都值得保留。过期的、已经覆盖的、不相关的记忆应该被清理或降权。
• 情景记忆和日志不是一回事。 日志是全量记录，给开发者看的；情景记忆是精选摘要，给 Agent 看的。
• 这是 Harness 没有覆盖的缺口。 跨会话的记忆需要独立设计。

四、语义知识（Semantic Knowledge）

它解决什么问题

问题： 同类型的问题反复出现，Agent 每次都要从头推理，不会复用已有的经验。

核心机制

语义知识的本质是从经验中提取可复用的模式。它把过去成功的操作路径固化为标准的技能/规则/模板，让 Agent 在面对类似问题时直接调用。

原始经验：
  "上次扩字段的时候，先改了数据库，然后改了 Go struct，
   然后改了 INSERT SQL，然后改了 handler..."

↓ 提炼后

语义知识（可复用技能）：
  标题：数据库字段扩展的标准流程
  步骤：
  1. ALTER TABLE ADD COLUMN
  2. 更新 Go struct（+ JSON tag）
  3. 更新 INSERT/UPDATE SQL
  4. 更新 SELECT 查询（+ Scan 参数）
  5. 更新 routeTable.orderedFields

存储形式

形式	适合存储	检索方式
技能模板	标准操作流程	按意图匹配
规则	IF-THEN 逻辑	条件匹配
知识图谱	实体关系	图遍历

与工作记忆、情景记忆的关系

情景记忆（原始经验）→ 模式提取 → 语义知识（固化的技能）
                                          ↓
                             在类似场景中被调用 → 工作记忆（当前使用）

工程要点

• 抽象层次要适中。 太具体的知识适用面窄，太抽象的知识难以实际使用。
• 需要验证。 从情景记忆中提取的模式不一定每次都正确，需要在实际使用中验证和修正。
• 这是 Harness·知识沉淀已经覆盖的领域。 知识沉淀方法论的核心就是语义知识的生成和固化流程。

五、三层之间的关系

三个层次不是独立工作的，而是形成一个完整的记忆流水线：

工作记忆（当前会话）→ 转存 → 情景记忆（历史会话）
                                          ↓
                               重复模式提取 → 语义知识（长期技能）
                                                   ↓
                                    新会话自动加载 → 工作记忆（新的会话）

三条重要原则：

1. 下行是自动的，上行是有选择的。 工作记忆到情景记忆的转存应该自动发生，但情景记忆到语义知识的提升需要验证。
2. 不能跳层。 别指望工作记忆直接承载语义知识，也别希望情景记忆替代工作记忆。三层各自解决不同时间尺度的问题。
3. 遗忘策略和存储策略同等重要。 没有遗忘的记忆系统就像没有整理的仓库——东西越堆越多，找东西越来越难。

六、为什么情景记忆是当前最大的缺口

回头看我们现有的积累：

层	Harness 覆盖	需要补充
工作记忆	✅ 上下文管理	把经验体系化
情景记忆	❌ 未覆盖	这是核心缺口
语义知识	✅ 知识沉淀	扩展固化机制

情景记忆是你目前最需要填补的。下一篇我们聚焦第三篇——工作记忆管理，深入 Token 预算和上下文优化策略。

---