Continual Learning from Deployment Feedback for Frozen-Weights Agents

原标题（解读）： Learning on the Job：让冻结权重 Agent 从部署反馈中持续学习 实标题： Continual Learning from Deployment Feedback for Frozen-Weights Agents 关联论文： 2607.22157 作者： Valentin Tablan（作者，未标注机构；摘要未注明） 更新： 2026-07-28 精修： 2026-08-05（Jay 二读者审校 + 工程补强）

一句话结论

不微调模型权重的前提下，给冻结 LLM Agent 配一个把每条 episode 蒸馏成「自然语言规则」的外部 memory，仅靠「成功/失败」1-bit 结果反馈就能在 τ-bench 银行域把单次成功率拉到 baseline 的 1.6×，加入事后修正后达 2.6×，并把 baseline 永远解不出的 84 个任务中的 22 个翻成可解。

解决什么真问题

LLM Agent 在生产里跑了几万次，却几乎从不「学习」：

  • 模型权重冻结 → 上次解出来的硬任务，下次复发还是从零摸索。
  • 静态 RAG（一次性灌完整 policy corpus）→ 检索粒度固定在文档级，找不到「这一类坑」对应的具体经验。
  • 在线微调 / RLHF → 成本高、对企业客户有数据合规风险，且「学错一次就污染权重」不可逆。

真正可用的中间方案是：让 Agent 自己从每次 episode 的结果（outcome verdict + 事后修正）里学，把经验蒸馏成可检索的自然语言规则，存到外部 memory，下次取用。这正是本文的「Continual Learning from Deployment Feedback」。

核心方法

系统架构

┌─────────────────────────────────────────────┐
│  Episode Execution (Agent + Tools + Policy)  │
│      ↓ 完成 / 失败 / 修正                   │
│  Outcome Verdict (1-bit: pass/fail)         │
│  + After-the-fact Correction (free text)    │
│      ↓ 蒸馏                                 │
│  Rule Distiller (LLM call)                   │
│      ↓                                      │
│  External Memory: { rule_text, tags, score } │
│      ↓ 检索 (semantic + tag filter)         │
│  Next Episode: inject top-k rules into ctx  │
└─────────────────────────────────────────────┘

关键组件

1) Distiller（蒸馏器）

每条 episode 结束后，调用一次 LLM，把「对话日志 + 工具调用轨迹 + 1-bit 结果 + 修正文本」压缩成 1-3 条规则：

INPUT:  episode_log, verdict, correction_text
OUTPUT: rule(s) = {
  condition:  "当用户要求 X 且账户 Y 时...",
  action:     "应当先 Z 再 W",
  pitfall:    "不要直接...",
  evidence:   episode_id
}

规则以自然语言而非 embedding 存储——好处是可被另一个 LLM 直接读懂、跨模型迁移（这是后文跨模型迁移实验的关键）。

2) External Memory（外部记忆库）

  • 写入：每条规则带 score（初始来自 verdict，pass=+1，fail=-1；后续被引用且带来正向结果再加权）。
  • 读取：semantic 检索（rule_text 向量化）+ tag 过滤（按当前 domain/task type）+ score 排序。
  • 维护：定期去重（相似规则合并）与 pruning（持续负分的规则淘汰）。

3) Feedback Signal（反馈信号）

两种强度：

  • Outcome verdict：1-bit，pass/fail。便宜、自动可获得（τ-bench 自带判定器）。
  • After-the-fact correction：自然语言，由人或强模型给出。贵，但信息密度高。

实验发现：仅 1-bit verdict 已经能提升 1.6×；加入 correction 后再翻到 2.6×。

为什么不用微调

论文明确选择冻结权重 + 外部 memory 的理由：

  1. 数据合规：金融、医疗、政府客户不愿把 episode 日志喂回训练 pipeline。外部 memory 可被审查、删除、版本化。
  2. 跨模型迁移：memory 是自然语言，可被任何 LLM 读；微调权重则与基模耦合。
  3. 失败可逆：写错一条规则可以删，不会污染基模。
  4. 冷启动友好：换一个更强模型，原 memory 立刻生效，无需重训。

关键实验与数据

基准：τ-bench 银行域（多轮对话、工具调用、合规约束）

对照：Static-RAG baseline——一次性检索完整 policy corpus（无 memory 学习）。

主结果：

反馈强度 单次成功率倍数 解决 baseline 永远失败的 84 个任务中
Static-RAG baseline 1.0× 0
1-bit outcome verdict 1.6× 部分
1-bit + correction 2.6× 22 / 84

跨模型迁移（关键实验）：

  • 主实验在 Mistral Large（开源权重、可自托管、适配数据主权）上跑。
  • 在 Claude Sonnet 5（前沿闭源）上复现同样提升。
  • 交叉迁移：让 Claude 读 Mistral 写出的 memory，每个模型都超过自己的「无 memory」baseline。 → 证明 memory 是「文本资产」，不与基模耦合。

跨部署形态：从单任务到长会话、从纯文本到工具调用都验证。

具体百分比与置信区间原文摘要未列出，本文以倍数与绝对任务数（22/84）描述，详细见正文与附录。

亮点与局限

亮点

  1. 强 baseline 对照：与「完整 policy corpus 的 static RAG」打，而不是与 naive prompting 打——结论更扎实。
  2. 正交反馈信号：outcome verdict 与 correction 是两条独立信号，可叠加。
  3. 跨模型可迁移：memory 是 NL，写入与读取解耦，对企业混合模型部署极友好。
  4. 数据主权友好：Mistral Large 自托管路径打通，给受监管行业一个真实可落地选项。
  5. 公开 harness / protocol / data：复现性极佳。

局限

  1. Distiller 仍是 LLM 调用：蒸馏本身有成本与失败模式（编造规则、过抽象），需监控规则质量。
  2. Memory 治理问题悬而未决：长期运行后 memory 会膨胀，去重/pruning 策略的细节与边界条件还需更系统的研究。
  3. τ-bench 是合成环境：真实客服/银行场景存在幻觉容忍度低、合规审计严、用户分布偏等额外挑战。
  4. 修正信号依赖外部源：correction 在生产里谁来给？是用户、运营、还是另一个 LLM judge？这影响系统可扩展性。
  5. 没解决「学错怎么办」：负分 pruning 是事后机制，短期内错误规则仍可能被检索到。
  6. 单次成功率提升 ≠ 长期能力：memory 累积到多少条后增益饱和、是否需要课程式复盘，未在摘要中说明。

对工程落地的启发

  • 客服/Agent 产品可立刻接入：相比「全量微调」，这条路径工程风险低、合规友好、回滚容易，是 2026 年企业 Agent 的合理默认。
  • memory 即「新资产」：把规则库当作版本化、可审计的内容资产来管理，比当作 embedding 向量库严肃。
  • 冷启动策略：先用 1-bit verdict 跑出 baseline → 再逐步引入 correction → 最后做规则审计，是平滑落地曲线。
  • 模型无关性 = 议价权：同一份 memory 可在不同基模间迁移，意味着不会被任一供应商锁死。
  • 监控项：规则命中率、规则带来的 pass-rate uplift、规则陈旧率（被引用但最近 N 次都无贡献）应作为生产 SLI。
  • 谨慎对待自动蒸馏规则：建议在初期由人审核新规则，待置信度建立后再开自动写入。

与同方向工作的关系

  • RAG 家族：本文是「动态 memory RAG」的极致形态——corpus 不是预先存在，而是 Agent 自己边跑边写。
  • Continual learning for LLM：传统路线是参数空间持续更新（LoRA 累积、Replay buffer），本文走的是非参数路线，规避 catastrophic forgetting。
  • Agent self-improvement：与 Reflexion、Self-Refine、AutoEval 等「让 Agent 反思自己」的工作同潮；本文差异在于：(a) 反思结果落到可检索 memory 而非 ephemeral context，(b) 利用 outcome + correction 双信号。
  • Experiential learning for dialogue agents：与 Voyager（Minecraft 技能库）、ChatDB 等有相似的「自然语言 skill library」思想，但本文聚焦合规严肃域。
  • τ-bench 系列：本文是 τ-bench 银行域上较扎实的 Agent 工程实证之一。

适合谁读

  • Agent 产品 / 平台架构师：本文几乎可以当 ADR（架构决策记录）来读。
  • 企业 AI 合规 / 数据治理团队：memory 的可审查/可删除特性直接对应合规诉求。
  • 客服、ITSM、电商售后 Agent 团队：场景高度契合。
  • LLM Ops / 评测工程师：1-bit verdict + 规则 uplift 的评估方法可复用。
  • 不推荐：纯学术 continual learning 研究者（参数空间方法不在本文范围）、纯 prompt 工程师（本文偏系统而非 prompt 模板）。

来源

  • arxiv abstract：https://arxiv.org/abs/2607.22157
  • 论文卡：/shared/research-kb/organized/paper_cards/610-2607-22157.md
  • 队列条目：/shared/research-kb/organized/queue/work-queue.md（[0.5] 二轮解读）

不确定处

  • 摘要未给出具体单次成功率百分比与置信区间，本文以「1.6× / 2.6×」倍数与「22/84 任务」描述。
  • 蒸馏器本身的 prompt 模板、规则粒度、合并/淘汰阈值未在摘要中披露。
  • correction 信号在生产中的来源（人 / 强模型 / 用户）原文未指定。
  • Memory 在长期运行下的饱和行为、规则数量上限未在摘要中给出。

工程落地与核查（Jay）

事实核查摘要

claim 原文是否支持 备注
1.6× / 2.6× 单次成功率 ✅ 摘要原文 基准为 static-RAG，τ-bench 银行域
22/84 任务从不可解变为可解 ✅ 摘要原文 原文："converting 22 of the 84 tasks the baseline never solves"
Mistral Large + Claude Sonnet 5 跨模型迁移 ✅ 摘要原文 原文："measured on Mistral Large...replicated on Claude Sonnet 5"
memory 为自然语言规则（非 embedding） ✅ 摘要原文 原文："distils each episode into retrievable natural-language rules"
harness / protocol / data 公开 ✅ 摘要原文 原文："The harness, protocol, and data are released."
标题"Learning on the Job" ⚠️ 偏差 官方标题为 Continual Learning from Deployment Feedback for Frozen-Weights Agents，摘要未见 "Learning on the Job" 字样；解读标题为简化意译，可接受
作者署名 Valentin Tablan ✅ 摘要原文有 原文 From: Valentin Tablan；机构信息摘要未提供

实际系统怎么用

典型接入路径（企业客服 / ITSM Agent）：

1. 部署基线 Agent（任意 LLM + tools）
2. 接入 τ-bench 或自建判定器（1-bit verdict 来源）
3. 初始化空 External Memory（向量库 + 规则文本库）
4. 跑 episode → Distiller LLM 调用 → 写规则入 memory
5. 下次 episode 检索 top-k 规则注入 context
6. correction 来源优先级：人工标注 > LLM judge > 用户负反馈

Distiller LLM 调用成本估算（以 Mistral Large 自托管为例）： - 每条 episode 一次 LLM call（~2000 tokens 输入，1-3 条规则输出） - 客服场景：1000 次/天 → ~1000 次/天 Distiller call - 建议用更小模型跑 Distiller（如 Mistral Small / Qwen2.5），与主 Agent 解耦

Memory 存储选型： - 规则文本 → PostgreSQL + pgvector（或 Qdrant / Milvus） - tag/score 结构 → 同库 schema 字段 - 初期规模（<1 万条）：单节点足矣；>10 万条建议按 domain 分库

主要坑与应对

坑 描述 建议
规则编造（Hallucinated rules） Distiller LLM 可能生成看似合理但 episode 不支持的规则 初期强制 human-in-the-loop 审核；长期可对规则做 self-consistency 打分（同一 condition 被不同 episode 多次独立推导出则高置信）
Rule explosion 长期运行后规则数量膨胀，检索召回噪声上升 设置 score 阈值：低于 -3 分的规则自动 archive；每月做一次相似规则合并（embedding 相似度 > 0.95 则合并）
Verdict 判定器不准 τ-bench 判定器 vs 真实生产环境 verdict 可能有偏差 自建生产 verdict 管道时，建议用 LLM judge 作为 secondary verifier，交叉验证 pass/fail 标签
跨 domain 干扰 混合 domain 跑时，规则 tag 混淆导致错误检索 Memory 层做 domain tag 强隔离；跨 domain 迁移需重新训练 tag classifier
Mistral Large 自托管 GPU 需求 主 Agent 需足够 context length + tool calling 能力 推荐 2× A100 40G 或等效；Distiller 可用单卡小模型
Correction 来源瓶颈 correction 质量高但来源贵（人工/强模型） 先用 weak-to-strong distillation：用主 Agent 给自己打 correction，逐步引入人工审核

监控指标建议

生产落地必建 SLI（Service Level Indicator）：

- rule_hit_rate：每次 episode 命中规则数（预期 0~5，过高说明 context 注入过度）
- rule_pass_rate：命中规则后 episode 成功率（对比 baseline，应提升）
- rule_staleness_rate：N 天内未被引用的规则占比（> 70% 则需 pruning 审计）
- distiller_error_rate：Distiller LLM 调用失败或返回格式异常的比例（应 < 1%）
- correction_utilization：correction 信号实际被转化为规则的比例

开源资产与复现

摘要明确说 "The harness, protocol, and data are released"，但 abstract 页面未给出具体 GitHub URL。建议在 PDF / HTML 全文中检索 github.com 确认仓库地址后再使用。τ-bench 本身为公开 benchmark，可直接接入。