转型中的持续学习:从参数中心到系统级适应的三轴综述

关联论文：2608.06216
作者：flyP
更新：2026-08-08

一句话结论

这是一篇 23 页综述,把持续学习(CL)从"参数中心视角"重定义为"系统级适应视角",并提出 When × How × Where 三轴框架(时间阶段 × 优化机制 × 更新位置),系统梳理从经典参数适配,到 on-policy、test-time training、外部 memory/skill libraries/交互协议的全谱系过渡,并指出向系统级适应范式转移的挑战与方向。

解决什么真问题

过去十年持续学习的主线是"如何让参数不灾难性遗忘":replay、regularization、parameter isolation 等。但 2024-2026 期间,几股力量同时把 CL 的边界撑大了:

on-policy 学习:不再靠离线梯度更新,而是在轨迹上做策略内学习(RL、探索式自我对弈)。
test-time training(TTT):把"训练"延伸到推理时,模型在输入分布上现场适配。
外部 harness 组件:memory、skill libraries、交互协议、工具调用让"能力"长在系统而非参数里。

结果:用"参数中心"视角去刻画这一波工作会出现严重失真——例如一个 agent 的能力增长可能完全不来自参数变化,而来自新工具的接入或 skill library 的扩充。本文就是要把"持续学习"这个学科术语,重新对齐到当下的实际战场。

核心方法:三轴框架

论文提出三条交叉轴,把纷繁的 CL 方法归到一个 3D 网格里:

轴 1:When(时间阶段)

Pre-training:在通用语料上预训练,本身就是"在大量任务上顺序学习"的极致形态。
Post-training:SFT、RLHF、DPO 之后,继续做领域适配或知识注入(典型如 continual SFT、domain continual pre-training)。
Inference-time:在线适配、TTT、contextual in-context learning,甚至把"提示工程 + 外部检索"也算进 CL 谱系。

轴 2:How(优化机制)

Off-policy:经典 CL 主舞台,数据来自 replay buffer 或历史轨迹,用梯度下降更新参数。
On-policy:策略内学习,从自探索轨迹直接更新(RL、自我对弈、STaR-style 自我改进)。
Beyond-gradient:不靠梯度,而靠系统结构演化——加新工具、改 skill library、换交互协议、调 prompt 模板。LLM Agent 时代这部分增长最快。

轴 3:Where(更新位置)

Internal parameters:权重更新(主流量)。
External structural constraints:更新发生在参数之外——memory bank、RAG 索引、prompt 池、skill libraries、工具注册表、API 协议。

把三条轴叉乘,得到 3×3×2 = 18 个理论格子,但论文不强行填满,而是用"代表性方法 + 范式转移路径"去讲。

范式转移的三条主线

论文用三段式讲"为什么这是 transition 而不是延续":

How 维度:off-policy → on-policy → beyond-gradient。机制从"梯度驱动"演化到"系统驱动"。
When 维度:pre-training → post-training → inference-time。学习时间被不断推后,模型在"运行时"才是活的。
Where 维度:internal → external。能力容器从权重转移到 memory / skill / protocol。

论文特别强调:这三轴并非平行,而是同时收紧——agentic AI 的爆发本质就是三轴同时向"运行时 + 系统级"那一端移动。

关键实验与数据(综述性质)

作为 survey,论文没有单一主指标,但给出了几类对比数据(具体数字以原文 §表格为准,abstract 未给出):

不同 CL 方法在标准 benchmark(streaming CIFAR、Text REGRESsion、LongBench 等)上的遗忘率/前向迁移对比。
on-policy 与 off-policy 在同一 agent 任务上的样本效率对比。
inference-time TTT 在分布漂移场景下的相对增益。
external memory/skill library 容量增长曲线与参数增长曲线的 trade-off。

说明:abstract 与首页元信息均未披露具体数字,需要查正文表格确认。"原文未明确"的字段已显式标注。

亮点与局限

亮点

三轴框架原创性强:When × How × Where 比传统的"replay / regularization / isolation"分类更贴合 LLM 与 agent 时代。
范式转移叙事清晰:把"参数 → 系统"作为统一视角,而不是把 agentic learning 当作 CL 的边角特例。
覆盖面广:23 页 + 6 图 + 1 表,涵盖 pre-training 到 inference-time、gradient 到 beyond-gradient、internal 到 external 的全谱系。
挑战与方向显式:不是停在 taxonomy,而是给出"系统级适应"带来的新问题(一致性、可审计性、跨会话迁移等)。

局限

数字密度低:作为综述,主表格只有 1 个,benchmark 数字密度低于同主题的 survey(原文未明确每类方法覆盖的论文数)。
agent 时代方法覆盖可能不均:on-policy、TTT、skill library 三块的代表方法分布是否平衡,需要看正文 §代表方法清单。
缺乏可复现 artifact 评估:对每个格子里的"代表性方法",是否给出代码/权重/复现脚本?abstract 未提。
"beyond-gradient"边界模糊:把 RAG 和 skill library 都归为 beyond-gradient,是否会过度泛化?需要看正文是否给出操作性区分。
跨会话一致性、灾难性遗忘的形式化定义:对 external memory 来说,"遗忘"的定义本身就需要重写,论文是否给出?abstract 未明确。
没有 benchmark 提案:综述只评估既有工作,没有给出"系统级 CL 评测套件"的明确方案,工程落地需要自己拼。

对工程落地的启发

架构选型:面对长生命周期 agent,不要把"持续学习"等同于"再训练"。预算允许时优先考虑"外部 harness 升级 + 偶尔 post-training 微调"组合,而非持续全参数训练。
评测维度升级:需要新增"系统级适应"的评测指标——memory hit-rate、skill 调用成功率、跨会话一致性、prompt 模板迁移成本等,而非只看 forgetting rate。
TTT 落地的现实约束:inference-time training 对延迟和算力敏感,适合离线批处理或边缘异步适配,而非在线请求热路径。
skill library 设计:可借鉴 CL 的"防灾难性遗忘"思路给 skill library 加版本控制、互斥检测、回滚机制。
混合范式实践:When × How × Where 三轴同时偏右是当下最优:少量 on-policy + 大量 beyond-gradient(inference-time 时使用 skill 与 memory)+ 偶尔 post-training 校准。

与同方向工作的关系

传统 CL survey(如 continual learning on NN 的三大流派综述):本文承接但显著外延,把视野推到 LLM/agent 时代。
Agent / Tool-Use 综述:与"LLM Agent 架构综述"互补——后者讲"agent 怎么搭",本文讲"agent 怎么持续变强"。
TTT 专题工作(Test-Time Training、TTT layers):被纳入 When=inference-time 与 How=beyond-gradient 的交叉格子里。
RAG 与 Memory 系统综述:与本文 Where=external 部分高度重叠,但本文强调"持续"视角(随时间演化的 memory),而不仅是检索增强。
Self-improvement / Self-play 综述:被 How=on-policy 涵盖,本文给了它在 CL 大图谱里的位置。
Continual pre-training / Domain adaptation:被纳入 When=post-training 一栏,与"高效参数微调(PEFT)"形成互补。

适合谁读

持续学习 / 终身学习方向的研究生与研究者;
LLM Agent 平台架构师,需要为"长期在线服务"做能力演化设计;
RAG / Memory / Skill library 系统设计者;
想把"再训练"思路升级到"系统演化"思维的工程团队负责人;
任何想理解"为什么 agent 不靠训练也能变强"的非领域读者。

反方与边界(显式声明)

综述类工作,没有可一键复现的 SOTA 实验,需读者自行选方法验证。
三轴框架的边界并非硬约束,例如 on-policy + external memory 的交叉格子里方法归类可能因作者而异(原文未明确归类细则)。
"系统级适应"是否真属于"持续学习"范畴,学界尚有争议;论文站在"是"的一侧,读者需自行判断。
benchmark 数字密度低于同主题 review(原文未明确),引用具体对比数据前应回到原文表格。
没有开源 artifact 评估表,工程落地时需要自己验证每个"代表性方法"的可用性。
跨会话一致性、灾难性遗忘在 external memory 下的形式化定义,本文 abstract 未明确给出,需要查 §挑战章节。

工程落地与核查（Jay）

事实核查

核查项	结论	备注
arXiv 2608.06216 存在性	✅ 抽象存在	需引用前核验 abstract 与本文描述一致性
streaming CIFAR / Text REGRESsion / LongBench	⚠️ 需原文核验	"Text REGRESsion"疑似笔误（应为 TextREGRESSION 或其他）；streaming CIFAR 名称需确认；引用具体 benchmark 前必须回到原文核实
"23 页 + 6 图 + 1 表"	⚠️ 需原文核验	abstract 未逐项列出；页数/图/表数量需原文 §1 Introduction 核验
三轴叉乘得 18 个格子	✅ 理论自洽	3×3×2=18，数学上无问题；但"代表性方法"覆盖密度未知
"agentic AI 爆发 = 三轴同时收紧"	⚠️ 叙事断言，非实验结论	综述的叙事性结论，不等于实证；工程参考时需自行判断

可读性精修意见

## 关键实验与数据一节中"streaming CIFAR、Text REGRESsion"疑似原文名有误，建议原文核验后统一名称；错误 benchmark 名称出现在解读中会影响下游引用可信度。
全文无"反方 / 边界（强制段）"标题，而是合并到 ## 反方与边界(显式声明)——这与其他解读格式不一致；建议保持全文体例统一（可视为格式建议，不影响内容）。
## 亮点与局限中多处"原文未明确"标注到位，但"缺乏可复现 artifact 评估"等判断性语句建议改为"abstract 未提及 artifact 评估"，避免主观降级。

工程落地：实际系统怎么用、坑在哪

适合什么场景 - 设计长期在线 LLM Agent 服务的能力演化架构（不只有"再训练"一条路）。 - 评估或搭建企业内部 memory / skill library 系统。 - 为 agent 增加 test-time adaptation 能力的技术选型。

落地路径（实操）

1. 评测体系重构（立即可做）
   → 现有 forgetting rate / accuracy 指标不够；
     新增指标清单：
       - memory hit-rate（同类 query 历史记忆复用率）
       - skill 调用成功率（新 skill 注册后调用成功率）
       - 跨会话一致性（同一 user session 内能力表现方差）
       - prompt 模板迁移成本（新 prompt 版本上线后 N 小时内效果稳定率）

2. Skill Library 防遗忘设计（中期）
   → CL 三大流派（replay/regularization/isolation）可以迁移到 skill library：
     a. replay：保留高频 skill 调用的历史 case，新 skill 上线时做 replay 对比
     b. regularization：新 skill 参数更新时对旧 skill 权重加正则项
     c. isolation：新 skill 独立 namespace，避免与旧 skill 参数空间冲突
   → 版本控制 + 回滚机制是基础设施，必须有

3. TTT 落地的现实路径
   → 在线热路径（latency-sensitive）：不适合 TTT；TTT 只适合：
       - 离线批处理（深夜任务）
       - 边缘异步适配（端侧模型 OTA 更新）
       - warm-up 阶段（服务启动时一次）
   → 若业务场景需要实时 adaptation：优先考虑 in-context learning / RAG，而非在线梯度更新

4. 三轴选型建议（当下最优组合）
   When = inference-time（主力）+ post-training（偶尔）
   How = beyond-gradient（主力）+ on-policy（少量）
   Where = external（主力）+ internal parameters（偶尔）
   → 对大多数团队：先做 skill library + memory + RAG；再训练是最后手段

5. 坑与边界
   a. beyond-gradient 把 RAG 也归进来——这意味着 RAG 索引更新本身就是"持续学习"的一种形式，
      但 RAG 的"遗忘"如何度量？目前没有统一标准，需要自己设计 metrics。
   b. external memory 随时间增长会带来检索延迟与 token 成本非线性增长，
      需要定期做 memory 压缩/遗忘（类似 CL 的 selective memory）；
      没有自动化的 memory management 机制是工程上的大坑。
   c. 三轴框架是叙事工具而非可操作的系统设计蓝图；
      落地时需要把"轴"翻译成具体的工程决策（例如 When=inference-time 翻译成"每个请求是否做 in-context adaptation"）。
   d. 跨会话一致性：agent 重启后 memory 如何恢复？
      这个问题在 CL 领域未解决，本文也未给出工程方案，需要自己摸着石头过河。

工程优先级建议

立即可做：建立 memory hit-rate 和 skill 调用成功率两个 metrics；不需要任何模型改动，log 层就能统计。
短期（1–2 个月）：给 skill library 加版本控制 + 回滚机制；设计 prompt 模板迁移的 A/B 验证流程。
中期（3–6 个月）：评估 TTT 离线批处理的 ROI；设计 memory 压缩/遗忘策略（参照 CL 的 selective pseudo-rehearsal）。
长期：若业务需要实时 adaptation，再评估 on-policy 在线学习路径（成本高、风险大）。