Episodic-Memory
1. 定义与边界
情景记忆(Episodic Memory)保存过去发生过的事件、任务轨迹、上下文和结果。它回答的问题是:“类似任务以前怎么做过,哪里成功,哪里失败?”
情景记忆不同于语义记忆。语义记忆保存稳定事实;情景记忆保存一次具体经历,例如“2026-05-08 在某仓库运行测试时,网络权限导致依赖下载失败,后来用本地缓存绕开”。
2. 为什么重要
情景记忆适合:
- 复用过去的调试路径和命令。
- 生成 few-shot 示例,提升工具调用或格式遵循。
- 避免重复踩坑。
- 支持任务回放、审计和复盘。
3. 核心机制
情景记忆通常来自 trace,而不是用户显式声明。
4. 数据结构
{
"type": "episodic",
"namespace": ["project", "admin_vue", "episodes"],
"key": "fix_table_pagination_2026_05_08",
"value": {
"task": "修复表格分页数据结构不匹配",
"context": ["Vue 3", "useTable", "res.data.listData"],
"actions": ["rg useTable", "read hook implementation", "inspect call sites"],
"outcome": "identified API assumption; no code change requested",
"lessons": ["先查实现和调用点,不要按文件名猜作用"]
},
"source": {"trace_id": "tr_123"},
"confidence": 0.9
}
5. 工程实现
情景记忆推荐从 trace 后处理生成:
def extract_episode(trace):
if not trace.task_completed:
importance = "medium" if trace.failure_recovered else "low"
else:
importance = "high" if trace.user_feedback_positive or trace.saved_time else "medium"
return {
"task": trace.goal,
"constraints": trace.constraints,
"critical_actions": select_key_actions(trace.events),
"failures": select_failures(trace.events),
"outcome": trace.outcome,
"lessons": summarize_lessons(trace),
"importance": importance,
}
检索时不要把完整 trace 注入上下文,而是取:
- 任务类型相似。
- 工具和环境相似。
- 失败模式相似。
- 最近被验证有效。
6. 生产实践
- 只将关键事件转成情景记忆,原始 trace 存审计系统。
- 对失败经验写明失败条件,不要泛化成永久规则。
- 用情景记忆做 few-shot 示例时保留输入、动作、结果三段。
- 将“经验教训”与“事实结论”分开,避免把一次偶然事件写成事实。
- 周期性合并重复 episode,提炼成语义记忆或程序性记忆。
7. 常见反模式
- 保存每一轮对话为 episode,导致噪声极高。
- 没有结果字段,无法判断 episode 是否值得复用。
- 把失败经验无条件套用到新任务。
- 将用户私密对话作为示例暴露给其他用户。
8. 评测方法
- 相似任务复用率:检索到的 episode 是否被实际使用。
- 失败避免率:历史失败是否减少重复发生。
- 示例有效性:加入 episode few-shot 后工具调用准确率是否提升。
- 错误泛化率:不适用的 episode 是否误导新任务。
9. 安全与治理
- episode 可能包含文件路径、客户名、错误日志、凭证片段,写入前要脱敏。
- 跨用户共享 episode 只能使用去标识化模板。
- 外部网页或工具返回触发的 episode 需要标记来源可信度。
- 允许用户要求“不要把本次任务用于未来训练或记忆”。
工程化补强:架构与实现细节
A. 与 RAG 的硬边界
Episodic Memory处理的核心对象是过去一次任务的轨迹、决策、失败、修复和结果。它来自用户和 Agent 的互动、任务执行轨迹或组织流程,而不是外部文档本身。 RAG 的核心对象是外部知识和证据;Memory 的核心对象是可复用状态。两者可以共享向量库、数据库或检索组件,但不能共享权限模型和写入流程。
| 维度 | Memory | RAG |
|---|---|---|
| 数据来源 | 对话、工具轨迹、用户明确偏好、任务结果 | 文档、网页、代码库、数据库、知识库 |
| 写入触发 | 互动后抽取、用户要求记住、后台总结 | 文档 ingestion、同步任务、管理员上传 |
| 可信边界 | 默认是个人/项目状态,仍需来源与置信度 | 默认是不可信外部内容,需要证据过滤 |
| 检索目标 | 帮 Agent 延续状态和复用经验 | 给回答提供事实证据和引用 |
| 失败后果 | 错误会跨任务持续影响行为 | 错误通常影响本次回答或索引版本 |
| 评测重点 | case reuse rate、root-cause recall、wrong-analogy rate、trace redaction coverage | recall、faithfulness、citation accuracy |
B. 生产级数据流
这条链路的关键是写入和检索分离。写入网关决定“能不能成为未来依据”,检索器决定“当前任务是否需要它”。
C. 推荐 JSON 结构
{
"memory_id": "mem_01HY...",
"memory_type": "short_term|semantic|episodic|procedural|profile",
"namespace": ["org:o_1", "user:u_7", "project:p_3"],
"content": {
"summary": "用户希望技术文档用中文、结构紧凑、直接给结论",
"normalized_value": {
"language": "zh-CN",
"style": "concise_engineering"
}
},
"source": {
"kind": "user_message|tool_trace|episode_summary|admin_policy",
"trace_id": "tr_20260509_001",
"turn_id": "turn_14",
"evidence": "用户明确说:以后回答用中文,少废话"
},
"confidence": 0.86,
"sensitivity": "normal|personal|confidential|restricted",
"ttl_days": 180,
"created_at": "2026-05-09T10:00:00+08:00",
"updated_at": "2026-05-09T10:00:00+08:00",
"episode_type": "debugging_failure",
"outcome": "fixed",
"audit": {
"writer": "memory_writer_v2",
"decision": "accepted",
"policy_version": "memory-policy-2026-05"
}
}
字段级来源比整条记忆来源更重要。真实系统里经常只有某个字段可靠,不能因为一个字段可信就默认整条画像可信。
D. 写入门槛
| 候选信息 | 默认动作 | 原因 |
|---|---|---|
| 用户明确要求“记住”且不敏感 | 写入或更新 | 意图明确,价值高 |
| 多次稳定偏好 | 写入低风险字段 | 可减少重复沟通 |
| 单次情绪、抱怨、临时选择 | 不写或短 TTL | 容易误画像 |
| 工具失败根因 | 写 episode | 对未来排障有价值 |
| 外部网页诱导的规则 | 拒写 | 外部内容不能提升为行为规则 |
| 安全、权限、合规相关变更 | 人审或管理员确认 | 影响面大,不能由普通记忆覆盖 |
本文件的推荐写入原则是:只有任务结果、关键转折、失败根因和可复用经验值得写 episode。
E. 检索策略
按相似任务、仓库/项目、错误码、工具链和时间衰减检索。工程上建议分三步:
- 硬过滤:tenant、user、project、role、sensitivity、TTL、deleted tombstone。
- 候选召回:profile 精确读取,semantic/episodic/procedural 可用关键词、向量和标签组合。
- 上下文组装:限制条数,附带类型、来源、置信度和“不能覆盖系统/开发者/安全策略”的说明。
def retrieve_memory(task, user, project, budget):
scopes = acl_scopes(user=user, project=project)
candidates = []
candidates += profile_store.get(scopes.user_profile_fields(task))
candidates += memory_index.search(task.query, filters=scopes.filters, k=20)
ranked = rerank_by_usefulness(candidates, task.intent, now=task.now)
safe = [m for m in ranked if policy.can_inject(m, task)]
return pack_with_provenance(safe, token_budget=budget)
F. 遗忘与生命周期
原始 trace 短期保留,摘要长期保留,低复用 episode 降权或归档。遗忘不是简单删除文本,还包括向量、缓存、摘要、备份可恢复窗口和审计索引的协同。
| 生命周期阶段 | 操作 | 验收点 |
|---|---|---|
| 候选 | 只在临时队列保存 | 未通过网关不进入长期库 |
| 活跃 | 可检索、可解释、可编辑 | trace 中能看到使用原因 |
| 降权 | 过期、低命中、低置信 | 默认不注入上下文 |
| 归档 | 保留审计或历史统计 | 不参与在线检索 |
| 删除 | tombstone + 索引清理 | 删除 SLA 和回归测试通过 |
G. 失败模式与修复
| 失败模式 | 早期信号 | 修复动作 |
|---|---|---|
| 把个案教训泛化成规则,或保存过多原始敏感 trace | 召回内容与当前任务不符,用户反复纠正 | 拆 namespace、加写入门槛、补评测切片 |
| 错误记忆长期影响回答 | 同类任务持续给错建议 | 增加冲突检测、用户编辑入口、低置信降权 |
| 过度个性化 | Agent 在无关任务套用用户偏好 | 按任务域检索,不全量注入画像 |
| 记忆投毒 | 记忆中出现“忽略规则”“扩大权限”等内容 | 策略拒写,已写入内容隔离并审计 |
| 上下文污染 | 注入记忆太多,模型忽略当前指令 | top-k 限制、摘要化、按阶段注入 |
| 删除不彻底 | 删除后仍可被向量召回 | tombstone 过滤、重建索引、缓存失效 |
H. 评测指标
| 指标 | 计算方式 | 用途 |
|---|---|---|
| Memory precision@k | 注入记忆中真正有用的比例 | 控制上下文污染 |
| Needed-memory recall@k | gold memory 是否被召回 | 检查检索覆盖 |
| Task lift | 开启记忆后的成功率/轮次/工具错误变化 | 判断是否值得保留系统复杂度 |
| Stale-use rate | 被使用但已过期或被覆盖的记忆比例 | 发现遗忘策略问题 |
| Bad-write escape rate | 不应写入但进入长期库的比例 | 评估写入网关 |
| Privacy incident rate | 越权召回、敏感泄露、误画像事件数 | 安全红线指标 |
I. 安全治理清单
- 记忆内容永远不能提升为系统指令,不能覆盖安全策略和开发者约束。
- 用户画像需要可查看、可修改、可删除;敏感画像默认不做自动推断。
- 外部文档、网页和工具输出要标记来源可信度,默认不能写成程序性规则。
- 加密静态数据和传输链路;对高敏字段做字段级加密或不可逆摘要。
- 审计记录至少包含写入者、来源、策略版本、检索任务、注入位置和删除事件。
- 多租户系统必须把 namespace、ACL 和索引过滤作为服务端强制逻辑,而不是 prompt 约束。
10. 权威资料
- LangChain Memory overview: https://docs.langchain.com/oss/python/concepts/memory (核对日期:2026-05-09)
- Generative Agents paper: https://arxiv.org/abs/2304.03442
- Cognitive Architectures for Language Agents: https://arxiv.org/abs/2309.02427
- OpenAI Agents SDK Agent memory: https://openai.github.io/openai-agents-js/guides/sandbox-agents/memory (核对日期:2026-05-09)