一句话概括：过去谈「持续学习」，学的是模型参数；而今天的 agent 还有另一份会随经验变化的状态——由 prompt、记忆、工具、技能、路由规则组成的 harness。这篇论文指出：即便模型一个字节都没动，改一次 harness 也足以让此前稳定可靠的行为失效。作者把这个现象命名为 harness 级遗忘（harness-level forgetting），并给出一套「提案 → 评估 → 提交」的守卫式演化机制：更新先当候选，过了「当前有提升 / 历史不倒退 / 结果合法」三道闸才允许上线。
如果你已经允许自己的 agent 改写它自己的 prompt、skill 或记忆文件，这篇值得你花时间。
—— @omarsar0 在推荐这篇论文时的原话
摘要（译）
持续学习长期以来是以模型为中心的：把模型参数当成那份随着序列化经验而改变的状态。但现代 agent 还可以通过一层 harness——prompt、记忆、工具、技能与路由规则——来完成适应。由于这些内容共同决定了后续的执行过程，一次 harness 更新即使在模型冻结的前提下，也可能破坏此前可靠的行为。这带出一个新问题：agent 如何在模型之外持续改进自己的状态，同时保住早先习得的行为？
作者据此提出 Harness Continual Learning（HCL）：一种让 harness 围绕冻结的基础模型演化的新持续学习范式，并把由此造成的早期行为损失定义为 harness 级遗忘。HCL 由四个面向执行的组件实例化：任务接口（Task Interface）、经验记忆（Experience Memory）、能力图谱（Capability Map）、自适应路由（Adaptive Router）。在此之上引入守卫式 harness 演化（guarded harness evolution），把「生成更新」与「提交状态」分开：由 Continual Optimizer 根据执行后反馈起草候选 harness，再由 Continual Evaluator 在检查「当前提升、历史保留、有效性」三项之后才决定是否提交。在文本推理、多模态感知、开放世界交互三类任务上的实验显示出能力累积与失败恢复的效果，多个设置下相对基线提升超过 10%。组件消融衡量了每个 harness 组件的贡献；受控的保留度扫描则揭示出可测量的 harness 级遗忘，并表明稳定性–可塑性的取舍可以被显式调节。
1 引言：持续学习的对象变了
持续学习研究的是「系统如何从序列化的经验中获得能力，同时保住已经学会的行为」。已有的表述基本都通过改变模型参数、表征或架构组件来实现这件事——论文把这条既有路线称为模型中心式持续学习。
agentic AI 的兴起带来了另一个适应来源：一层决定「基础模型如何接收信息、如何检索经验、如何行动」的外部 harness。prompt、记忆、工具与技能说明、路由策略，都可以在多次交互之间持续存在并不断演化——哪怕基础模型始终冻结。于是 agent 的适应不再局限于模型状态：harness 状态同样会累积经验并重塑未来行为。这让 harness 本身成为持续学习的一个新研究对象。
作者把这个方向形式化为 HCL：通过在冻结的基础模型周围顺序更新 harness 状态，来获取并保留能力。这里必须和常见的「harness 优化」划清界限——后者通常是为当前目标搜索更好的 prompt、函数或工作流；而 HCL 研究的是一串更新，它关心的不只是下一次更新对当前交互有没有帮助，还包括不断演化的 harness 有没有守住早先那些更新已经做可靠了的行为。
这个设定带来一个独特的保留问题：harness 的各组件在执行期是耦合的——
- 一次记忆更新可以改变某个早先查询所检索到的证据；
- 一次技能修订可以改变工具的使用方式；
- 一次路由编辑可以弄坏一条此前成功的工作流。
因此一个对近期案例有帮助的更新，完全可能在不改动基础模型的情况下，把早先正确的答案、合法的工具调用或成功的动作轨迹变成失败。这就是 harness 级遗忘——它把经典的稳定性–可塑性问题从模型状态延伸到了 harness 状态。
论文的三条贡献：
- 提出并形式化 Harness Continual Learning，把学习对象从模型状态转移到冻结基础模型周围的 harness 状态；
- 识别出 harness 级遗忘，并提出守卫式 harness 演化——Optimizer 提案、Evaluator 通过「当前 / 历史 / 有效性」三项检查控制提交；
- 在文本推理、多模态感知、开放世界交互上验证：harness 演化确实支持能力累积与失败恢复，同时表现出可测量的遗忘，且稳定性–可塑性取舍可控。
2 相关工作
2.1 Harness 工程
当代 agent 系统在基础模型外面套一层运行时 harness，把「推理」变成「面向任务的执行」。跨实现地看，那些常驻的运行时内容通常承担四种功能：接口把原始指令、观察、文档或多模态输入转成 agent 能用的形式；记忆存放交互记录、摘要与可复用的指导；能力注册表描述工具、API、环境动作与习得技能及其调用条件；路由 / 工作流控制器挑选相关的记忆与能力、排定使用顺序、拼装执行上下文。此外还有执行动作的环境适配器，以及在流水线边界检查结果的任务级校验器。
已有系统各自发展了这套结构的不同部分：ReAct 把推理与环境交互耦合起来；Toolformer、MRKL、HuggingGPT 暴露并协调外部能力；MemGPT、Reflexion、Voyager 则把经验保留成记忆、反馈或可执行技能。这些组件合在一起构成一条耦合的执行流水线——接口决定路由看到什么，记忆与能力描述决定它能选什么，最终的工作流决定模型怎么行动。
harness 工程也已经在用执行反馈去修订 prompt、声明式程序、记忆、工具使用策略、技能与工作流，近期工作还把这个过程扩展到配置搜索、跨层失败诊断与持续的 agent 改进。这些系统都证明了 harness 是可编辑、且能随经验变好的。但它们的主要目标通常是某个组件的质量、或当前任务上的下一个配置——反复改进本身，并不能为完整的 harness 状态提供一条通用的保留判据。本文的不同之处在于：把整个可变 harness 当作一份统一的持续学习状态，并把「跨越多次已提交更新的保留度」当成显式目标。
2.2 模型中心式持续学习
模型中心式持续学习让模型适应非平稳的任务或数据流，同时设法保住早先经验带来的能力，核心挑战是灾难性遗忘。既有路线大致分五类：表征类学习跨任务仍然有用的特征或 prompt；架构类隔离、扩展或选择模型组件以减少任务间干扰；优化类改变更新轨迹或用早期任务的信息约束梯度；正则类惩罚那些支撑旧行为的参数或函数发生变化；回放类保留或重建早期样本并混进新数据。近期工作把这些家族扩展到了大语言模型与更广的知识流，但被学习的状态仍然是模型的知识、表征、架构或参数。本文则把持续学习的对象挪到模型之外：基础模型参数保持冻结，harness 状态在明确的获取与保留约束下演化。
3 HCL 框架
3.1 定义与问题设定
设有一个固定的基础模型 F_θ，以及在第 n 次交互时部署的 harness H_n。模型参数 θ 始终不变，而一次已提交的 harness 更新会影响后续所有交互。HCL 就被定义为：顺序更新已部署的 harness，以获得新行为、同时保住更新前已经可靠的行为。
「此前可靠的行为」可以是一个正确的回答、一次合法的工具调用，或一条满足环境目标的动作轨迹。保留的要求是：在相同的输入与执行条件下重跑，这些行为在后续 harness 更新之后仍然成功。
形式上，第 n 步的原始交互记为 u_n（指令、观察或多模态输入）。harness 把它转成结构化交互 i_n，再结合选中的记忆与能力拼出执行上下文 z_n；模型与外部运行时执行 z_n 产出结果 y_n；执行后反馈记为 f_n。这一整组交互级对象合起来是 e_n = (u_n, i_n, z_n, y_n, f_n)。
Optimizer 把更新规则、当前部署的 harness 与可用的交互证据一起交给基础模型，生成候选 harness：H̃_(n+1) = O(H_n, e_n)。候选始终与已部署的 harness 分离，直到提交决策做出为止。用 G_n ∈ {0,1} 表示这个决策，则 G_n = 1 时 H_(n+1) = H̃_(n+1)，否则 H_(n+1) = H_n——一个候选只有被提交，才会影响后续交互。
框架由此分成两半：一半定义已部署的 harness 状态 H_n（指明它有哪些可变内容，并统一版本化）；另一半控制从 H_n 到 H_(n+1) 的更新（提交前检查当前提升、历史保留与有效性）。
3.2 作为学习对象的 harness 状态
HCL 把可变的 harness 状态组织成 H_n = (I_n, M_n, C_n, R_n) 四个联合版本化的组件。之所以强调「联合」：因为改动其中一个组件可能与其它组件相互作用、并同时影响新行为与已习得的行为，HCL 把所有提议的改动当成一个完整候选 harness 对待——它要么整体替换 H_n，要么一条改动都不进入已部署状态。harness 内容因此不再是一堆各自独立编辑的产物，而是一套协同的持续学习机制。
| 组件 | 执行期的功能 | HCL 中被更新的内容 |
|---|---|---|
任务接口 I_n | 把原始交互转成结构化表示 | prompt、任务模板、解析与归一化规则 |
经验记忆 M_n | 提供可复用的具体交互与抽象指导 | 原始交互记录、LLM 生成的抽象记忆条目 |
能力图谱 C_n | 提供外部操作与可复用的内部技能 | 从抽象记忆中提炼出的内部技能 |
自适应路由 R_n | 挑选并组织记忆与能力 | 路由 prompt、选择标准、工作流模板 |
3.2.1 任务接口（Task Interface）
任务接口是 harness 的输入处理层，把原始任务交互 u_n 转成三元组 i_n = (x_n, g_n, k_n)：x_n 是可用输入，g_n 是任务要达成什么，k_n 记录约束——输出格式、合法的工具用法、环境限制等。I_n 内部规定了一个 LLM 解析器完成这次转换所用的 prompt、任务模板与解析归一化规则。
它的价值在于把异构的任务数据映射到统一表示，让相关输入、目标与约束显式化，从而使不同形态的任务能在同一条持续学习流水线里被处理。由于接口更新会改变任务被理解的方式，I_n 必须与 harness 一起版本化。
3.2.2 经验记忆（Experience Memory）
从持续学习的角度，HCL 把累积的经验组织成互补的两种形态：M_n = (M_n^raw, M_n^abs)。
- 原始记忆
M_n^raw存原始任务输入u_n、产出的回答或动作轨迹y_n，以及随后的环境或校验器反馈f_n。为了让记忆收集简单、存储有界，它按到达顺序、每个任务只保留固定条数。这些记录保存了关于「成功行为」与「遇到过的失败」的任务级证据，帮助 agent 复用早先解法、避免重犯错误。 - 抽象记忆
M_n^abs由 LLM 对原始记忆做总结产生，把反复出现的模式固化成有作用域的指导——输出惯例、可靠的推理套路、需要避开的常见错误。随着新的原始交互写入，总结过程会为相关的未来任务产生新的或更新过的抽象条目。
分工很清楚：原始记忆负责回放与行为恢复，抽象记忆负责跨任务的泛化迁移。
3.2.3 能力图谱（Capability Map）
能力图谱按来源把能力分成两类：C_n = (C_n^outer, C_n^inner)。
- 外部能力把冻结的模型接到外部资源上——API、检索服务、感知模型、计算器、环境动作。每一条都写明其功能、预期输入输出、调用协议、可用条件与已知限制。
- 内部能力是从抽象记忆里进一步提炼出来的可复用技能：LLM 把相关的抽象记忆合并成更通用的技能，带有明确的输入、输出、执行步骤与适用范围。这一步把早先交互累积的知识变成了能被直接调用的过程。
与只有一个预定义外部操作库的静态能力表不同，C_n 能通过经验扩张自己的可执行技能集——这条「累积知识 ⇄ 内部能力」的动态连接，正是冻结模型的 agent 得以持续获取、精炼并迁移技能的原因。
3.2.4 自适应路由（Adaptive Router）
路由把前三者接到实际执行上：给定结构化交互 i_n，它从 M_n 取相关经验、从 C_n 选能力，组织成执行上下文 z_n = R_n(i_n, M_n, C_n)——其中包含结构化任务表示、选中的经验与能力，以及执行所用的工作流。
关键在于：随着 M_n 与 C_n 演化，「哪些经验和能力对某个任务有用、该怎么组织」也会随之改变。每次交互时，R_n 用 LLM 配合自己的路由 prompt、选择标准与工作流模板，把执行策略适配到当前任务和当前可用内容上；而这些路由规格本身也可以跨交互被修订——路由与记忆、能力图谱一同演化。
3.3 守卫式 harness 演化
一次 harness 更新可能在改善当前行为的同时，让早先任务上原本可靠的行为退化。作者因此引入守卫式 harness 演化，用「提案 → 评估 → 提交」把「生成更新」和「上线部署」分开：拿到反馈后，Continual Optimizer 产出一个隔离的候选 harness；Continual Evaluator 只在它同时满足「当前提升 / 历史保留 / 有效性」时才提交，否则 H_n 原样留在线上。这让保留度成为 harness 演化的显式前提，而不是默认「对当前任务有用的更新对早先任务也安全」。
3.3.1 Continual Optimizer：候选生成
交互反馈只说明当次执行成没成功，并不说明 harness 该怎么改。Optimizer 用一套 prompt 模板把已部署的 harness H_n 与交互证据 e_n 交给基础模型，让它结合反馈分析执行结果、检视执行上下文，判断哪些 harness 组件需要修订——可能是改任务接口里的 prompt 或解析规则，可能是往记忆里记录或总结经验，可能是在能力图谱里增删技能，也可能是调整路由的选择与工作流规则。
当多个组件都需要修订时，为了在提供多种更新方向的同时限制 LLM 调用次数，作者用了一个简单的顺序策略：按预定义顺序逐个考虑选中的组件；对每个组件，Optimizer 一次一个地生成至多 K 个备选，每个备选只替换候选 harness 中的该组件、其余保持不变再做评估；得分最高且可接受的那个被保留，作为修订下一个组件的基础；若某组件没有任何备选通过闸门，该组件保持不变。整个过程中 H_n 岿然不动，直到最终候选完成评估并被提交。
3.3.2 Continual Evaluator：历史评估与提交
Evaluator 检查三个互补的方面：当前提升衡量候选是否更好地解决了当前任务；历史保留检查此前可靠的行为有没有被保住；有效性确保更新后的 harness 及其输出仍然可用。H_n 与候选 H̃_(n+1) 在相同的模型、解码、工具、环境与随机种子条件下评估，以构成受控对比。三项全部满足，候选才能替换 H_n。
① 当前提升。令 V_n 为当前任务的验证集，P(H, V_n) 为 harness H 在其上的表现，则提升量 Δ_n = P(H̃_(n+1), V_n) − P(H_n, V_n)；满足 Δ_n ≥ δ_n 即通过，δ_n 是预设的最小提升。视任务不同，P 可以是答案准确率、工具调用成功率或环境完成度。
② 历史保留。当前任务的提升并不能说明候选保住了早先习得的行为。Evaluator 因此维护一个紧凑的锚点集 A_n：每个锚点包含一个此前观察过的案例的原始输入与成功判据，从而可以在已部署 harness 与候选 harness 下各重跑一遍。每个任务结束时，锚点按预设比例从「此前成功」与「此前失败」的案例中抽取；若某一组数量不够，空缺由另一组补足。锚点只用于评估，在候选生成阶段不可见——这一条很关键，否则就是拿考题当复习资料。
对每个锚点 a，定义二值成功指示 q(H, a) ∈ {0,1}。候选造成的历史损失就是「被 H_n 解决、却在候选下失败」的锚点计数 D_n。满足 D_n ≤ B_n 即通过保留判据，B_n 是预设的历史损失容忍度。B_n = 0 意味着候选必须保住 H_n 当前解决的每一个锚点。
③ 有效性检查。候选还必须可执行、且符合任务与运行时要求。检查集 L_n 里的每一项 ℓ 给出 0/1 判定，覆盖产物语法、输出 schema 合规、合法工具使用、任务约束与环境一致性。
三项合起来构成候选级的提交决策：当且仅当 Δ_n ≥ δ_n 且 D_n ≤ B_n 且所有有效性检查全过时，该候选可提交。这是一道硬性准入闸门。当有多个候选过闸，Evaluator 用一个综合当前表现、有效性与历史保留的合成分排序，取最高者提交为 H_(n+1)，同分随机决胜；若无一候选过闸，H_n 继续在线。
3.4 与模型中心式持续学习的对应关系
HCL 借用了模型侧持续学习的若干互补原则，但用 harness 机制而非参数更新来实现它们：
- 回放类保留早期样本 → 经验记忆存下具体交互供日后复用；
- 表征类学习支持跨任务迁移的抽象 → 能力图谱把累积经验转成可复用技能，并与外部能力合并；
- 架构类组织可复用模块以减少干扰 → HCL 把这些例程表示成可调用的能力，由自适应路由为每次交互挑选并编排；
- 优化 / 正则类用早期任务的信息约束更新 → HCL 用 Optimizer + Evaluator 做同一件事：前者从当前反馈提出候选改动，后者在当前验证集与历史锚点上测试它。
作者强调这些对应是概念层面的、并非一一对应的实现。更重要的是，HCL 把这些原则收进了一个统一的系统级表述：传统方法常把回放、表征、架构、优化、正则当成五个独立的解法家族，而 HCL 在同一个「获取–保留」目标下，让它们在一个不断演化的 harness 内部协同工作——把持续学习从参数适应，扩展到agent 基础设施的协同演化。
4 实验
实验分两种体制：ALFWorld 与 Minecraft 考察开放世界交互中的能力累积、复用与失败恢复；文本推理与多模态感知用受控任务流、对此前见过的任务反复评测，使 harness 级遗忘与稳定性–可塑性取舍可直接测量。
值得注意的是作者刻意换用了不同的基础模型，以检验 HCL 是否跨模型家族与规模成立，而非依赖某个特定模型：ALFWorld 用 Qwen3.5-9B；Minecraft 与主多模态实验用 Qwen3.6-27B；文本推理用 DeepSeek-V4-Flash；组件消融用 Qwen3.5-4B。每个设置内部，所有对比共用同一个基础模型，且全程冻结——因此任何适应都只来自 harness 更新，而非模型训练。
4.1 评测协议
每条任务流上只有一个 harness 围绕同一个基础模型顺序演化。记 H^(s) 为学完任务 D_s 之后部署的 harness；每个阶段末尾，在当前任务与所有此前见过的任务上评测它，得到 R_(s,j)（j ≤ s）。当前任务的验证案例与历史锚点只供 Evaluator 判断候选能否提交；最终测试集与二者不相交，只用于汇报。
对度量在同一量纲上的任务流，汇报两项指标：最终平均表现 Avg_T（全流程结束后所有任务分数的均值）与平均旧任务遗忘 Fgt_T（每个早先任务从其历史最好成绩到最终成绩的平均跌幅）。Zero-shot 与 Static Harness 不做顺序更新，故遗忘一栏记为「–」。
两个配置贯穿全文，唯一差别就是历史损失容忍度 B_n：Stability-HCL 取 B_n = 0，任何让已解决锚点失败的候选一律拒绝；Plasticity-HCL 取 B_n = ∞，只要当前提升与有效性达标，锚点损失不构成阻拦。
4.2.1 ALFWorld
文本版 ALFWorld，每回合最多 50 步。持续流按 Pick-and-Place → Look-in-Light → Clean → Heat → Cool → Two-object 六类任务顺序推进，每类用 10 个训练回合做顺序适应；每阶段后在所有已见类别上评测，最终成绩在官方的 134 个评测回合上汇报。
| 方法 | Pick | Look | Clean | Heat | Cool | Two-object | 最终均值 ↑ | 平均遗忘 ↓ |
|---|---|---|---|---|---|---|---|---|
| Static Harness | 95.80 | 66.70 | 25.80 | 26.10 | 9.50 | 58.80 | 47.12 | – |
| RAG 基线 | 95.80 | 83.30 | 41.90 | 39.10 | 14.30 | 58.80 | 55.56 | 1.74 |
| MemP | 95.80 | 83.30 | 48.40 | 34.80 | 9.50 | 47.10 | 53.15 | 5.18 |
| MemRL | 87.50 | 66.70 | 29.00 | 60.90 | 23.80 | 41.20 | 51.51 | 5.64 |
| Stability-HCL（本文） | 100.00 | 83.30 | 51.60 | 30.40 | 28.60 | 76.50 | 61.74 | 2.64 |
| Plasticity-HCL（本文） | 100.00 | 77.80 | 41.90 | 39.10 | 19.00 | 100.00 | 62.98 | 10.94 |
结论有两层。第一层：复用过去的经验能改善静态 harness，但不足以支撑广泛的持续适应。RAG 把最终均值从 47.12% 抬到 55.56%，并且在几个自适应基线里遗忘最低——但纯检索改不了可复用的过程与路由规则。MemP 与 MemRL 也各自改善了某些类别，但在整条流上波动很大。
第二层：两个 HCL 配置通过演化完整的 harness取得更强的总体表现。Plasticity-HCL 拿到最高的 62.98% 并解决了全部 Two-object 回合（100%），显示出对最新任务最强的适应力——但遗忘也最大（10.94）。Stability-HCL 以 61.74% 逼近它，在六类中的四类表现最好，同时把平均遗忘压到 2.64。由于模型冻结、两个配置只差一个 B_n，这组对比直接证明了 Evaluator 能显式控制稳定性–可塑性取舍。
4.2.2 Minecraft
用 Qwen3.6-27B 跑一条 50 任务的 Minecraft 课程，覆盖资源采集、合成、挖矿、工具使用、放置物体、冶炼，以及多个相互依赖操作的复合任务。每次交互后环境反馈存入经验记忆，用于精炼可复用能力与执行工作流；此前验证通过的技能测试被保留为历史锚点——一次能力新增或修订，只有在改善当前目标、且继续通过所有适用的历史测试时才被提交。
结果有两个数：
- 课程推进：Static Harness 跟着 HCL 走了 15 个任务后卡死不动；HCL 完成全部 50 个，从采集、合成一路推进到持久化资产与协同的多步执行。
- 执行效率：整条 50 任务课程的累计环境动作数，HCL 83，MemRL 88，MemP 91（越低越好）。在靠后的多步任务上，HCL 避免了重复的诊断、合成与恢复动作——这条更低的曲线反映的是对累积经验更高效的复用，而不是牺牲了进度。
作者特意说明：两个基线是在本文的 harness 里复现的，而非直接跑官方仓库，以保证任务接口、能力库与环境栈一致、只有记忆管理不同。
4.3.1 文本推理
文本流顺序为 MuSiQue → ProofWriter → GSM8K → HotpotQA，覆盖多跳问答、逻辑演绎、数学推理与知识密集问答。每个任务用 250 例适应、50 例验证、500 例测试，基础模型 DeepSeek-V4-Flash 全程冻结，HCL 只更新四个 harness 组件。
| 方法 | MuSiQue | ProofWriter | GSM8K | HotpotQA | 最终均值 ↑ | 平均遗忘 ↓ |
|---|---|---|---|---|---|---|
| DeepSeek-V4-Flash Zero-shot | 35.00 | 42.80 | 49.40 | 54.80 | 45.50 | – |
| Stability-HCL（本文） | 27.60 | 73.00 | 50.40 | 57.80 | 52.20 | 0.00 |
| Plasticity-HCL（本文） | 29.00 | 77.00 | 92.00 | 60.80 | 64.70 | 0.07 |
Stability-HCL 要求所有被接受的更新都保住锚点集上的表现，把平均遗忘压到 0.00；代价是适应被大幅限制，最终均值 52.20%，低于 Plasticity-HCL 的 64.70%。但它仍然高于 45.50% 的 zero-shot 基线——说明「在完全保住已测行为的前提下获取新行为」是可行的，不是零和。
Plasticity-HCL 放松保留要求、允许更激进的更新，把最终均值从 52.20% 推到 64.70%，而平均遗忘只有 0.07。（注意 MuSiQue 一栏：两个 HCL 配置都低于 zero-shot——作为流的第一个任务，它是被后续更新影响最久的那个。）
4.3.2 多模态感知
多模态流顺序为 COCO 目标检测 → COCO 图像描述 → RefCOCO 视觉定位 → VQAv2，Qwen3.6-27B 全程冻结，同样是 250 / 50 / 500 的划分。这里额外对比了 DGG——一个面向顺序多任务持续学习的近期自适应方法。
| 方法 | 检测 | 描述 | 定位 | VQAv2 | 最终均值 ↑ | 平均遗忘 ↓ |
|---|---|---|---|---|---|---|
| Qwen3.6-27B Zero-shot | 4.27 | 25.47 | 43.00 | 84.87 | 39.40 | – |
| DGG | 29.58 | 29.77 | 48.96 | 62.60 | 42.73 | 0.26 |
| Plasticity-HCL（本文） | 64.14 | 37.31 | 90.60 | 79.80 | 67.96 | 0.81 |
| Stability-HCL（本文） | 65.34 | 39.41 | 91.60 | 79.33 | 68.92 | 0.22 |
两个 HCL 配置的最终均值都大幅超过 Zero-shot 与 DGG，最大增益出现在检测与定位——正是那些需要把空间信息组织成任务特定输出格式的任务（检测从 4.27% 到 65.34%）。描述任务也有改善，说明演化中的组件能在同一条任务流里支撑不同的多模态目标与输出格式。
唯一 Zero-shot 更强的是 VQAv2：冻结模型本来就擅长直接的图问答。但两个 HCL 配置在 VQAv2 上的保持度都远好于 DGG（79.80 / 79.33 对 62.60）。这里还出现了一个与文本流相反的现象：Stability-HCL 同时拿下最高均值（68.92%）与最低遗忘（0.22）——严格保留在这条流上没有付出性能代价。
4.4 稳定性–可塑性取舍
这一节只动一个旋钮：把历史损失容忍度固定为 b，扫 b ∈ {0, 1, 3, ∞}，其余条件全部锁死。其中当前提升判据 δ_n 要求至少多做对两个验证案例；有效性判据要求候选达到至少 90.00% 的输出格式合规率，且不引入任何语法、工具使用或环境违规。b = 0 与 b = ∞ 即前文的 Stability / Plasticity 配置；b = 1 与 b = 3 允许每个候选分别最多新增 1 个和 3 个失败锚点。本节每任务用 300 适应 / 80 验证 / 600 测试，每个早先任务配 80 个锚点。
容忍度 b | MuSiQue | ProofWriter | GSM8K | HotpotQA | 最终均值 ↑ | 平均遗忘 ↓ |
|---|---|---|---|---|---|---|
b = 0 | 27.83 | 73.33 | 84.33 | 59.50 | 61.25 | 0.39 |
b = 1 | 24.83 | 77.50 | 92.33 | 59.17 | 63.46 | 1.22 |
b = 3 | 26.83 | 79.83 | 83.00 | 58.50 | 62.04 | 2.00 |
b = ∞ | 28.33 | 71.00 | 82.00 | 59.17 | 60.13 | 3.45 |
这张表是全文最反直觉的一处。放宽 b 确实单调地削弱保留——平均遗忘从 0.39 一路升到 3.45；但最终表现并不跟着涨：最高的 63.46% 出现在 b = 1，而完全不设限的 b = ∞ 只有 60.13%，甚至低于最严格的 b = 0。
作者给出的一种解释是：每次提交的更新都会改变后续的演化轨迹。没有历史约束时，那些局部有利的更新可能覆盖掉可复用的 harness 内容，既削弱了保留度，也削弱了后续任务可用的经验与能力。因此一个适中的 b 才是最优点——它给适应留了余地，又不允许过度的历史损失。
论文也诚实交代了 b = 0 下仍有 0.39 遗忘的原因：约束只覆盖有限的锚点集，而遗忘是在另一批历史测试案例上度量的——保住 H_n 当前解决的所有锚点，并不能保证 A_n 未覆盖到的历史案例上行为不变。
4.5 消融实验
在受控多模态流上用 Qwen3.5-4B 做组件消融：从 Full HCL 出发，每次禁用一个组件的更新、其余三个保持自适应。
| 配置 | I | M | C | R | 最终均值 ↑ | 平均遗忘 ↓ |
|---|---|---|---|---|---|---|
| Zero-shot | – | – | – | – | 34.84 | – |
| 去掉接口更新 | ✗ | ✓ | ✓ | ✓ | 62.37 | 0.11 |
| 去掉记忆更新 | ✓ | ✗ | ✓ | ✓ | 62.28 | 0.83 |
| 去掉能力更新 | ✓ | ✓ | ✗ | ✓ | 63.12 | 0.06 |
| 去掉路由更新 | ✓ | ✓ | ✓ | ✗ | 62.77 | 0.14 |
| Full HCL | ✓ | ✓ | ✓ | ✓ | 63.41 | 0.45 |
Full HCL 拿到最高的 63.41%，说明四个组件的贡献是互补的。禁用经验记忆或任务接口造成的最终表现下降最大；其中去掉记忆更新还把遗忘推到 0.83，说明演化中的记忆同时支撑了行为的获取与保留。禁用能力图谱或路由的影响较小但一致——作者推测能力更新影响小是因为这条多模态流对可复用可执行过程的依赖，远不如 Minecraft 课程那么重。
这里有一处方法论提醒值得单独记下：几个消融配置的遗忘比 Full HCL 更低，纯粹是因为限制可编辑组件也限制了适应幅度。因此「遗忘更低」本身并不说明这是一个更好的演化 harness，必须与最终表现一起看。
5 结论
论文把 HCL 表述为一种新的持续学习范式：随序列经验演化的是 agent harness 而非模型参数。框架把可变的 harness 组件视为一份统一演化的状态，并把候选生成与评估提交分离，使历史保留成为部署的显式条件。实验表明 harness 演化能累积能力、能从失败中恢复，同时在冻结模型下也会造成可测量的遗忘；显式控制历史损失则让 HCL 得以在稳定与可塑之间取得平衡。
作者同时点名了尚未解决的挑战：更高效的保留度评估、harness 内容的整合（consolidation），以及更长交互流上的评测。
译者附记
几个我觉得对「自己在跑会改写自身 prompt / 技能 / 记忆的 agent」的人最有用的点：
- 「harness 级遗忘」这个命名本身就是这篇的主要贡献。只要你的 agent 有自改 prompt、自写记忆、自增技能的能力，你就已经在无意识地做 HCL 了——只是没有 Evaluator，也没有锚点集。改一次 prompt 让本周的任务更顺，同时悄悄弄坏了三周前那条已经稳定的路径，这件事在没有历史回归测试的系统里根本不会被观测到。
- 「锚点只用于评估、候选生成阶段不可见」是全篇最容易被实现者省掉、也最不能省的一条。一旦让提案方看到锚点，它就会去迎合锚点，保留度指标随即失去意义——这和把测试集喂给训练是同一类错误。
- 表 5 值得反复看：不设限的更新（
b = ∞）最终表现最差。它给出的直觉是——每次提交都在改变后续演化的轨迹，局部最优的自改会吃掉后面要用的复用材料。「每次都采纳看起来更好的那个改动」不是一个安全的默认策略，留一条窄缝（b = 1）反而最好。 - 「所有改动打包成一个候选，要么整体上线、要么一条都不进」比逐个组件各改各的更保守，也更容易归因。四个组件在执行期是耦合的，分开提交等于放弃了对交互效应的控制。
- 遗忘低 ≠ 更好。§4.5 那句提醒适用于任何自改系统的自评指标：把可改动面缩小，退化自然变少，但那是因为你没在学。这两个数必须成对汇报。
- 一处实践成本的提醒：这套机制的代价是每次候选都要在验证集和锚点集上重跑一遍。论文用了每任务 80 个锚点——放到真实系统里，这就是一条必须自动化、否则一定会被跳过的回归流水线。
原文：Borui Kang、Jinrui Gu、Junhan Lv、Wenbin Li、Lei Wang、Yang Gao，《Harness Continual Learning: Continual Adaptation Beyond Model Parameters》，arXiv:2608.19013，2026-08-19 提交。
线索来自 @omarsar0 的推荐。
中文译介：lonX · 完整原文与全部图表请读 arxiv.org/abs/2608.19013