情景记忆——Agent 如何记住自己做过什么

一、为什么情景记忆是"断片"的重灾区

前两篇我们把工作记忆和语义知识都覆盖了。但你感受最深的"断片"——新会话一切归零——根源是情景记忆缺失。

场景 1：早上调试字段映射 → 中午修好 → 下午开新会话继续
        问题：下午的 Agent 不知道早上发生了什么

场景 2：上周确定了数据库设计方案 → 这周开始编码
        问题：Agent 不记得设计决策的上下文

场景 3：排查一个复杂 bug → 试了 3 种方案 → 第 2 种方案不行
        问题：Agent 不记得"方案 B 已经试过了"

这些场景的共同模式是：信息产生于会话 A，需要在会话 B 中被使用。 没有情景记忆，每个新会话都是一张白纸。

二、核心设计：存什么、怎么存、怎么取

1. 存什么

原则：不要存全部，存结构化的关键信息。

一个结构化的情景记忆条目：

{
  "id": "mem_abc123",
  "session": "sess_xyz",
  "timestamp": "2026-07-07T10:30:00",
  "type": "decision",
  "domain": "sync_engine",
  "subject": "字段映射",
  "context": "上游 API 返回的字段名变了",
  "decision": "从 field_mapping 表动态读取",
  "alternatives": ["hardcode 新字段名"],
  "rationale": "配置化更灵活",
  "status": "resolved"
}

2. 怎么存

推荐方案： 用关系表（或 SQLite）存结构化的字段（时间/类型/领域/状态），再加上关键词标签做简单匹配。先不要上向量库——复杂度高、收益不确定，等检索质量成为瓶颈再升级。

3. 怎么取

三、与你现有工具的对接

Hermes 已经有了两个与情景记忆相关的工具：memory（持久化事实）和 session_search（历史会话检索）。但问题在于：需要用户主动触发，不是自动的。

建议的第一步改进

1. 在系统提示词中增加情景记忆指令。 告诉 Agent：新会话启动时，自动检索相关情景记忆。
2. 建立关键决策的记录机制。 在对话过程中，当 Agent 识别到关键决策被做出时，自动调用 memory 工具记录。
3. 会话结束时自动转存。 每次会话结束前，Agent 生成一个"上下文转存包"，包含关键决策、待办事项和当前状态。

一个简单的实施方案

不需要写复杂的后端代码。可以用一个 JSON 文件来实现最简版本的情景记忆：

// ~/.hermes/memory-bank.json
[
  {
    "session_date": "2026-07-07",
    "domain": "sync_engine",
    "decisions": ["字段映射改为配置化读取"],
    "pending": ["API 限流策略未定"],
    "entities": ["sync_engine", "field_mapping"],
    "summary": "修复了字段映射问题"
  }
]

Agent 在新会话启动时，读取这个文件，自动筛选出 pending 不为空或与当前工作域相关的条目。

四、与工作记忆和语义知识的衔接

工作记忆（当前会话）→ 自动转存 → 情景记忆（历史记录）
                                              ↓
                                   重复模式 → 手动提炼 → 语义知识（固化技能）

衔接规则：

1. 从工作记忆到情景记忆：自动转存。 每次会话结束自动生成结构化摘要，设计在 Agent 的会话结束流程中。
2. 从情景记忆到语义知识：手动提炼。 同一个模式的决策反复出现时，才人工判断是否固化为语义知识。
3. 从情景记忆到工作记忆：自动加载。 新会话启动时，加载相关的情景记忆到"关键事实区"。

五、实践建议

见效最快的改进——只改系统提示词，不写代码：

1. 会话启动时自动检索： 加一句"在开始回答前，先搜索与当前问题相关的历史会话。"
2. 决策时自动记录： 出现"我们决定…"、"选方案 X 不选 Y 因为…"、"这个方向试过了"时，Agent 自动调 memory 记录。
3. 会话结束时生成摘要： "给这个会话生成一个摘要——关键决策、待办事项、涉及实体。"