9.4.5 情景与程序记忆【选修】
- 理解情景记忆和程序记忆的区别
- 理解这两类记忆为什么对复杂任务特别重要
- 通过可运行示例看懂“从经历提炼流程”的最小闭环
- 学会判断一条信息更适合存成 episode 还是 工作流
可以把这张图当成判断工具：短期状态服务当前运行，长期记忆存稳定事实，情景记忆保留具体经历，程序记忆沉淀可复用的方法。
情景记忆到底是什么？
Section titled “情景记忆到底是什么？”它更像单次经历
Section titled “它更像单次经历”例如：
- 上周处理过一次退款争议，原因是学习进度超出阈值
- 某次生成周报时，数据库接口超时导致任务失败
这类记忆的特点是：
- 带时间和上下文
- 有具体事件经过
- 不一定总能直接复用
为什么 Agent 需要情景记忆？
Section titled “为什么 Agent 需要情景记忆？”因为复杂系统经常要参考过去发生过的事：
- 用户之前遇到过什么问题
- 上一次类似任务是怎么结束的
- 哪类情况容易失败
这类信息不是静态档案，但对决策很有帮助。
程序记忆又是什么？
Section titled “程序记忆又是什么？”它更像技能和流程
Section titled “它更像技能和流程”例如：
- 处理退款问题时，先查订单，再查政策，再判断资格
- 做竞品报告时，先收集数据，再分类，再总结
这类记忆的重点不在“过去具体哪次”， 而在“以后遇到类似任务时可以沿用这套做法”。
为什么程序记忆很重要？
Section titled “为什么程序记忆很重要？”因为它能让 Agent 避免每次都从零规划。 很多任务其实不是完全新问题，而是：
- 新实例 + 旧流程
这时程序记忆能显著降低推理负担。
两者最大的区别是什么？
Section titled “两者最大的区别是什么？”情景记忆回答“发生过什么”
Section titled “情景记忆回答“发生过什么””例子：
- “上次生成周报时，因为日志太多导致摘要质量下降”
程序记忆回答“类似问题通常怎么处理”
Section titled “程序记忆回答“类似问题通常怎么处理””例子：
- “生成周报的一般步骤是拉数据 -> 聚类 -> 生成摘要 -> 审核”
情景记忆像项目复盘。 程序记忆像 SOP 手册。
两者都重要，但用途不同。
先跑一个“经历 -> 流程”示例
Section titled “先跑一个“经历 -> 流程”示例”下面这个例子会做两件事：
- 记录几次具体 episode
- 从 episode 中提炼出一个可复用 工作流
from dataclasses import dataclass
@dataclassclass Episode: task_type: str context: str steps: list result: str
episodes = [ Episode( task_type="refund_case", context="用户询问未发货订单是否能退款", steps=["查订单状态", "查退款政策", "判断资格", "返回结论"], result="success", ), Episode( task_type="refund_case", context="用户询问学习进度超 20% 是否能退款", steps=["查订单状态", "查退款政策", "判断资格", "返回结论"], result="success", ), Episode( task_type="weekly_report", context="周报生成任务", steps=["拉数据", "聚类问题", "写总结"], result="partial_failure", ),]
def build_procedural_memory(episodes, min_support=2): grouped = {} for episode in episodes: key = (episode.task_type, tuple(episode.steps)) grouped[key] = grouped.get(key, 0) + 1
workflows = {} for (task_type, steps), count in grouped.items(): if count >= min_support: workflows[task_type] = list(steps) return workflows
procedural_memory = build_procedural_memory(episodes)print("procedural_memory:", procedural_memory)预期输出：
procedural_memory: {'refund_case': ['查订单状态', '查退款政策', '判断资格', '返回结论']}这段代码到底说明了什么？
Section titled “这段代码到底说明了什么？”它说明：
- 情景记忆可以积累“具体做过的事”
- 当重复 enough 次之后，可以抽象成程序记忆
也就是说，程序记忆往往不是凭空写出来的， 而是从反复成功的 episode 中沉淀出来。
为什么 weekly_report 没有进入程序记忆？
Section titled “为什么 weekly_report 没有进入程序记忆？”因为它只出现了一次， 还没有足够支持度。
这很符合现实：
- 一次偶然成功或失败，不一定值得立刻写成标准流程
为什么这比直接手写 工作流 更有启发？
Section titled “为什么这比直接手写 工作流 更有启发？”因为它展示了一个非常真实的知识沉淀过程：
- 先做
- 再复盘
- 最后抽象成流程
这恰恰是很多成熟 Agent 系统演进的路径。
情景记忆在系统里通常怎么用？
Section titled “情景记忆在系统里通常怎么用？”检索相似案例
Section titled “检索相似案例”当遇到当前问题时，可以先查：
- 以前有没有类似情况
- 当时是怎么处理的
- 最后结果如何
如果某类任务经常失败， 情景记忆会非常适合回答：
- 是在哪一步容易出错
- 哪类上下文容易触发失败
作为程序记忆的训练素材
Section titled “作为程序记忆的训练素材”它本身也可以成为后续流程抽象的原始数据。
程序记忆在系统里通常怎么用？
Section titled “程序记忆在系统里通常怎么用？”作为规划器的默认模板
Section titled “作为规划器的默认模板”当任务类型被识别后，系统可直接加载：
- 默认工作流
很多程序记忆本质上就像：
- 可复用技能
- 标准处理流程
- 任务模板
作为安全边界
Section titled “作为安全边界”程序记忆还能起到“别乱来”的作用。 例如对高风险任务，只允许系统沿用已经审核过的流程。
最容易踩的坑
Section titled “最容易踩的坑”误区一：把所有历史都叫情景记忆
Section titled “误区一：把所有历史都叫情景记忆”不是所有历史都值得保留为 episode。 episode 更适合：
- 有明确任务
- 有过程
- 有结果
的记录。
误区二：一有 episode 就自动变成程序记忆
Section titled “误区二：一有 episode 就自动变成程序记忆”程序记忆需要：
- 重复性
- 稳定性
- 可迁移性
误区三：程序记忆写死后永远不更新
Section titled “误区三：程序记忆写死后永远不更新”如果流程变化了，程序记忆也应该更新。 否则它会从“经验”变成“过期经验”。
学完这一页，至少保留这张证据卡：
- 记忆类型
- 短期、长期、情景或程序性
- 写入规则
- 在内存创建或更新时
- 检索规则
- 查询、相关性、时效性和权限检查
- 失败检查
- 过时记忆、隐私泄漏、矛盾或过度检索
- 清理动作
- 总结、合并、过期、删除或请求确认
这节最重要的是建立一条沉淀逻辑：
情景记忆负责保存具体经历，程序记忆负责把反复验证过的经历抽象成可复用流程。
一旦你把这条逻辑想清楚， 记忆系统就不再只是“存档”，而会开始真正帮助 Agent 学习。
- 给示例再增加两条
weekly_report的成功案例，让它也能沉淀出程序记忆。 - 想一想：哪些任务更适合查 episode，哪些任务更适合直接套 工作流？
- 为什么说程序记忆很像“技能库”，而不只是“历史记录”？
- 如果某条 工作流 已经过时，你会怎么设计更新机制？
参考实现与讲解
- 增加成功的
weekly_reportcases 后，应能看出重复步骤；当这些步骤稳定后，就可以提升为 procedural memory。 - 需要参考上下文和历史结果时，更适合查 episodes；任务可重复且最佳动作序列已知时，更适合直接用 procedural memory。
- procedural memory 更像 skill library，因为它保存可复用方法、决策点和检查项，而不只是发生过什么。
- 可以用 workflow version、owner review、test cases 和 deprecation notes，让过时流程能安全更新或下线。