模式矩阵 /模式白皮书/F3

F3 · Experience Replay · 经验回放

它解决什么问题

一家公司运营几年，员工换了几代，工程师做过的所有事都散落在 Slack 消息、Jira ticket、内部 wiki、邮件存档里。这些是企业的"沉默资产"——80% 没人翻，但每一条都可能在新任务接手时省下半天工夫。资深员工离职带走的不只是技能，还有"踩过的坑、试过的失败路径、当年怎么发现某个关键变量的过程"——这些没法用一份 skill 包概括，但有用得很。

Experience Replay 在 agent 系统里解的是同一个问题——让历史 trajectory 不要变成沉默资产。它在新任务来时主动检索相似的历史轨迹（成功的、失败的、零散的），把可复用部分注入当前 context。它和 Skill Package 的区别在颗粒度：Skill Package 装的是 verified 可调用单位，Experience Replay 装的是更宽泛的参考资产——经验有用但不一定 verified。CER（Contextual Experience Replay）在 WebArena 上把 GPT-4o baseline 的成功率提升了 51%，且完全 training-free。

为什么坐标是「反思 × 循环」

• 纵轴 · 反思：学过的东西不能白学，喂回给后续任务，这是基于历史回看的反思。它不改当下输出（那是 Generator-Critic），也不固化成可调用单位（那是 Skill Package），而是把过去的完整经验当作参考资产供 agent 借鉴。
• 横轴 · 循环：结构是训练时（或执行时）存、推理时取的跨调用 outer loop。经验在一次任务里产生并存档，在另一次任务里被检索回来注入——这条"存—取"回路跨越多次调用，是强化学习里 experience replay 机制在 LLM agent 时代的 inference-time 变体。

核心机制

一个 Experience Replay 闭环由六段组成：Task → Retrieve → Adapt → Execute → Distill → Store。两个核心设计判断决定它能不能工业化：

1. multi-level 分层存储：经验必须分层存，单层要么太散要么太空。AgentRR 给的是双层——low-level（具体 action：调了什么 tool、参数填什么、得到什么 observation，用于 debug）加 high-level（泛化策略：用了什么 approach、应对什么类型问题、什么时候 work，更接近工程师的判断）。Manning 往上延伸成三层抽象阶梯：

2. training-free 注入：重训 LLM 太贵，CER 的做法是把过去 trajectory（裁剪加摘要后）作为 context 注入当前 prompt，让 LLM 在 context window 里 in-context learning，跳过训练阶段。检索时优先 effectiveness 高加 outcome 成功的经验，复用后回写 effectiveness——没用的 lesson 自动 deprecate。

适合的生产场景

• 累积运行时间长的 agent：客服、运维、数据分析这类任务反复出现、经验可沉淀的场景。工程价值随时间增长——3 个月后才有显著效果，6 个月后变核心红利。
• 组织知识沉淀：把公司散落在 wiki、Confluence、Notion 的经验接进来，agent 几秒检索整理出来用。enterprise 场景接现有知识库最经济。
• 失败资产复用：80% 的 trajectory 是失败的，AgentHER 用 hindsight relabel 让失败 trajectory 涨值——一个失败追求目标 A 的轨迹往往是某个可达目标 B 的成功示范，在 WebArena 加 ToolBench 上比只用成功轨迹高 7.1 到 11.7 个百分点。

容易出错的地方

• 冷启动死锁：前 3 个月几乎没价值，但不积累 6 个月后也没价值。团队容易决策"先停掉等系统稳定再上"，结果再也上不来。防法是冷启动期用 synthetic experience seeding，把团队过去 documented 的最佳实践写成 30-50 条 bootstrap 数据灌进库。
• 陈旧教训漂移：半年前对的经验，产品改版后已经不适用，agent 还在注入，反而让人走错方向。防法是 effectiveness_score 持续衰减加 heuristic 时间戳降权加季度 review 主动 deprecate。
• 检索偏差放大：embedding 相似不等于任务结构相似。"用户增长分析"检索出"用户流失分析"经验，把流失的 funnel 框架硬套到增长上——增长和流失是反向问题。防法是加 task type classifier 粗筛、block 跨类型检索、检索后 LLM 二次审查适用性。
• 无结构全量 dump：把所有 trajectory 全塞进 vector DB 让 agent 自己挑，没有 multi-level 分层。没有结构的经验跟没有经验差不多。

关键指标

• 检索命中率（健康区 >70%）：召回的历史经验中真正被采用的比例。低说明 task_signature 用了 hash 而非语义，或检索偏差。
• effectiveness 分（健康区 ≥0.5）：经验被检索后任务成功率。低于 0.5 且复用 5 次以上的 lesson 进 archive，这是抗 superstitious lesson（错误归因伪经验）的关键。
• experience store 增长加 retrieval count（冷启动期主看这两项）：前 3 个月不看成功率提升，看 store 是否在长、经验是否被检索，给反思工程争取时间。
• 质量增量（健康区 3 个月后显著、6 个月后甩开 baseline）：成功率相对无经验复用的增益，这是 lagging indicator。

最小骨架

# 检索 + 注入 (CER training-free)
past = retrieve(task)                      # top-K, 优先 effectiveness 高 + success
context += render_for_context(past)        # high-level strategy + author metadata
heuristics = get_L2_by_signature(task)     # 跨任务规律
context += render(heuristics)

result = agent.run(task, prior_context=context, trajectory_collector=traj)

# 记录新经验 (自动提炼 high-level, 用便宜模型)
record(task, traj, outcome, author_id)     # high + low 双层

# 回写 effectiveness (lesson accuracy 反馈环)
for e in past:
    update_effectiveness(e, current_task_succeeded=result.ok)

# 周期性蒸馏 L2 (同 signature 经验 >= 5 条才做, 防 overfit)
monthly_distill_L2(signature)

四个工程要点：embed 和 high-level 提炼都用最便宜的模型（频次高、store 会涨到几十万条）；effectiveness_score 是核心 metric，健康线 ≥0.5；author_id metadata 别省，它让 agent 能告诉用户"这事谁做过、可咨询谁"；task_signature 用语义不用 hash，否则命中率低。

企业落地一例

一家 SaaS 公司的 8 人数据团队，PM 问"Q2 新功能上线后 D7 留存没明显涨，分析一下原因"。8 个数据科学家分头做，一个月后出 5 份独立报告（3 份没做完）。复盘发现 3 份做了几乎一样的 cohort 分析，2 份用不同归因方法但都漏了同一个 confounding variable（黑五时段自然流量基线变了），0 份引用团队 6 个月前做过的同类分析——那份分析是离职的 Sarah 做的，方法搭好了、confounding 那条她也踩过写了 case note，但归档在 Sharepoint 没人翻。团队上 Experience Replay 后，再有类似任务，第一个开干的人触发检索，拿到 Sarah 那份分析（含"留存分析必查时段效应"那条 heuristic），作为 cross-task heuristic 注入 prompt。配套 6 个决策：multi-level schema（high-level approach 加 low-level SQL）、CER 注入 top-5 加 author metadata、embed 用 cheap model、成功加失败加中性轨迹都存、30 天 cold tier、每月自动蒸馏 L2。8 人月浪费压到 1 人月做好新分析。

与其他模式的关系

• Skill Package（F2）：配对兄弟模式，边界要钉清楚。Skill Package 装 verified 可调用单位（"这事做过 3 次都成功，封成 skill 直接调"），Experience Replay 装更宽泛的参考资产（"这事 Sarah 6 个月前做过，方法和坑都在 trace 里，agent 自己看着学"）。前者是模块，后者是案例库。agent 优先调 skill，没匹配时回退到 experience 检索；experience 反复成功后毕业升级成 skill。
• Failure Journals（记忆模块）：同源输入。Failure Journals 提供失败 trajectory 库，Experience Replay 提供检索加注入机制，两者配合。AgentHER 之后失败 trajectory 还成了高价值训练原料。
• Generator-Critic（F1）：层级递进。Generator-Critic 改单次输出，Experience Replay 让累积经验跨任务复用。

一句话记住它

Experience Replay 是反思工程里"时间是朋友"那一刀——投资在前、红利在后，它把组织里散落的零散经验做成可检索资产，agent 的成熟度不在今天多聪明，而在三个月、六个月后比现在聪明多少。

本页属于 ADPS 33 模式白皮书。返回 模式矩阵与白皮书目录， 或查看配套 可运行代码目录。