（来源：机器之心）

长期以来，持续学习主要研究模型参数如何沿任务序列更新，以及系统如何在学习新任务时避免灾难性遗忘。经验回放、正则化、优化约束和架构扩展等方法虽然路径不同，但共享同一个基本前提：持续学习主要发生在模型内部。

但在 Agentic AI 时代，这一以模型参数为中心的前提正在发生变化。一个部署中的智能体不仅由基础模型决定，还依赖围绕模型运行的一整套 Harness，包括系统提示词、交互记忆、可复用技能、外部工具、工作流与路由策略。即使不微调模型，智能体也能通过更新这些状态持续改变行为。换句话说，当基础模型保持冻结时，持续学习和演化的对象可以不再局限于模型参数，而是扩展到 Harness（如图 1 所示）。

基于这一背景，南京大学推理与学习研究组与澳大利亚伍伦贡大学的研究者共同提出 Harness Continual Learning。该工作首次以传统持续学习的基本问题为出发点，将学习对象由模型参数拓展至 Harness，系统定义并研究 Harness 如何沿连续任务序列获取新能力、保留既有行为，以及应对更新过程中产生的遗忘。这一转变为模型之外的持续学习建立了新的研究对象与基本框架。

• 论文题目：Harness Continual Learning ：Continual Adaptation Beyond Model Parameters

• 论文链接：https://arxiv.org/pdf/2608.19013

• 所属机构：南京大学推理与学习研究组，澳大利亚伍伦贡大学

01 Harness 成为持续学习的对象

在持续学习对象的转变这一前提下，作者提出并形式化了 Harness Continual Learning（HCL）：在基础模型 () 保持冻结的条件下，Agent 沿连续交互序列更新已部署的 Harness，在获取新行为的同时，尽可能保留过去已经可靠的行为。HCL 关注的不是一次孤立的 Prompt、Memory 或 Workflow 优化，而是一串持续部署的 Harness 状态：

 每次更新不仅要回答 “当前任务是否得到改善”，还要进一步追问：这种改善是否以破坏过去已经学会的行为为代价 ？ 因此，HCL 将持续学习的研究对象从模型参数扩展到 Harness 状态，并将整条演化轨迹中的能力获取与能力保持纳入统一研究。

但要让这一过程成为一个可研究的持续学习问题，首先需要明确：究竟什么状态在被更新，又哪些部分共同决定 Agent 的后续行为。

02 HCL 如何做到持续学习？

HCL 框架将第 n 阶段的 Harness 状态表示为：

一个能够持续学习的 Harness，需要同时具备理解新任务、积累经验、形成能力以及组织执行的能力。因此，HCL 将 Harness 分解为四类共同演化的状态：

• Task Interface：解析和规范化任务，决定 Agent 如何理解输入；

• Experience Memory：保存交互经历，并从中抽象可迁移的规律；

• Capability Map：管理外部工具、感知模型与内部可复用技能；

• Adaptive Router：根据任务选择相关记忆与能力，并组织执行流程。

这并不是对所有 Agent 架构的唯一规定，而是一种覆盖常见 Harness 功能的参考分解。它的作用是明确 HCL 究竟在 “学习什么”：当基础模型保持冻结时，持续变化的是模型之外这些共同决定 Agent 行为的系统状态。

然而，具备持续学习能力并不意味着 Harness 的演化一定朝着更好的方向发展。

什么会被遗忘？——Harness-level Forgetting

因为 Harness 的更新并不总是带来正向积累。这些遗忘可能来源于刚才介绍的四个组件的演化过程，例如：新增记忆可能干扰旧知识的检索，技能修订可能破坏原本合法的工具调用，路由或工作流调整也可能让此前能够完成的任务再次失败。即使基础模型完全冻结，一个有助于当前任务的 Harness 更新，仍可能损害 Agent 已经具备的可靠行为。

这些退化虽然发生在 Harness 的不同组成部分中，但最终都会影响同一个核心问题：Agent 是否能够在获得新能力的同时，保留过去已经可靠的行为。

本文将这种由 Harness 更新引起的既有可靠行为退化定义为 Harness-level Forgetting。它不仅表现为旧问题从正确变为错误，也可能表现为工具调用失效或动作轨迹无法完成原有目标。对这种遗忘进行形式化、测量与控制，正是 HCL 希望解决的核心问题。

哪些更新值得长期保留？——Guarded Harness Evolution

因此，Harness 持续学习的关键并不是让系统不断生成修改，而是建立一种能够判断修改价值的演化机制。

HCL 提出 Guarded Harness Evolution，将 “生成修改” 与 “部署修改” 分开，形成 Proposal–Evaluation–Commitment 闭环。希望防止系统在更新时陷入局部修补：当前问题被解决了，过去已经可靠的行为却可能悄然失效。

Proposal：提出候选。

Continual Optimizer 根据当前 Harness、原始交互、执行结果与反馈，判断问题更可能来自接口、记忆、能力还是路由，即对应前文中的四类 Harness 状态： Task Interface、Experience Memory、Capability Map 和 Adaptive Router，并为相关组件生成候选修改。候选状态 () 保持隔离，在评估完成前不会影响真实系统。

) 与当前部署状态 (

Evaluation：评估候选。

Continual Evaluator 从三个方面检查候选：

1. 是否改善当前任务；

2. 是否保留历史锚点上已经可靠的行为；

3. 是否满足输出格式、工具调用和环境动作等有效性要求。

其中，历史锚点只用于评估，不向 Optimizer 开放，避免候选生成过程针对锚点进行适配。历史损失容忍度 () 则规定一次更新最多可以造成多大的历史退化；在受控实验中，作者使用固定标量 (b) 调节这一约束。

Commitment：决定部署。

只有同时满足当前改进、历史保持与系统有效性要求的候选，才有资格成为下一版本 ()。

)；否则，系统继续部署原来的 (

03 HCL 与传统持续学习的关系

HCL 延续了持续学习最核心的目标：在获取新能力的同时保留已有能力，但将这一目标从模型参数进一步扩展到了 Harness 所承载的经验、能力和执行策略。

从功能上看，HCL 将持续学习中长期形成的多类思想组织到了同一个系统中：Experience Memory 负责保留历史经验；抽象记忆与 Capability Map 支撑知识迁移和能力复用；Continual Optimizer 提供面向新任务的可塑性；Continual Evaluator 则通过历史约束保护已经可靠的行为。

传统持续学习中的经验回放、知识迁移、能力扩展、优化与稳定性控制，往往分布在不同技术路线中；HCL 则将这些目标统一到 Harness 持续演化的闭环中，使不同机制共同服务于 “获取新能力，同时保留既有行为” 这一长期目标。

因此，HCL 并不是简单移植某一种持续学习算法，而是将持续学习的基本思想进一步延伸到 Agent 系统层面，使模型之外的经验、能力和执行策略也成为持续学习过程中需要获取、组合和保护的对象。

04 HCL 能否在冻结模型下持续获取能力？

如果 Harness 确实能够成为一种新的持续学习对象，那么自然的问题是：这种演化是否能够在真实任务中带来能力提升，又是否能够控制长期遗忘？

本文在开放世界交互、文本推理和多模态感知三类任务流中验证 HCL，并使用不同的基础模型。所有实验中，模型参数始终冻结，因此性能变化完全来自 Harness 的持续演化。

在 ALFWorld 中，Static Harness 的最终平均成功率为 47.12%，Stability-HCL 和 Plasticity-HCL 分别提升至 61.74% 和 62.98%。尽管两者最终性能接近，其平均遗忘却分别为 2.64 和 10.94 个百分点，说明不同的更新约束会产生截然不同的历史损失。

这一差异在图 3 中更加直观：在更长，更复杂的 Minecraft 环境测试中，Static Harness 在第 15 个任务后停止推进，而 HCL 完成了全部 50 个任务。HCL 共使用 83 次环境动作，少于 MemRL 的 88 次和 MemP 的 91 次，表明 Harness 演化不仅支持了长期任务推进，也带来了更高的执行效率。

在文本推理任务流中，冻结的 DeepSeek-V4-Flash 零样本最终平均性能为 45.50%，Plasticity-HCL 将其提升至 64.70%，平均遗忘仅为 0.07；其中，GSM8K 从 49.40% 提升至 92.00%。

在多模态感知任务流中，冻结的 Qwen3.6-27B 零样本最终平均性能为 39.40%，连续多任务基线 DGG 为 42.73%，Stability-HCL 则达到 68.92%，平均遗忘仅为 0.22 个百分点。

这些结果给出了两个直接答案：即使模型参数完全不变，Agent 仍能通过 Harness 演化持续积累能力；但不同的 Harness 更新策略也会带来不同程度的历史行为退化。 HCL 所研究的能力获取与遗忘，由此成为可以观察和量化的系统现象。

05 HCL 中的稳定性–可塑性权衡

前面的实验说明，Harness 演化同时带来了能力提升和历史损失。因此，一个自然的问题是：系统应该如何在稳定性和可塑性之间选择？

为了研究这一关系，本文只改变历史损失容忍度 b，其余条件保持不变。如表 1 所示，随着约束逐渐放宽，遗忘持续增加，而最终性能呈非单调变化，最优结果反而出现在中等容忍度下。

表 1｜历史损失容忍度带来的性能 — 遗忘权衡。更宽松的约束增加了遗忘，却未必提高最终性能。

图 4 则进一步给出了遗忘如何沿任务序列逐步累积：整体来看，更严格的历史约束能够持续压低旧任务上的性能退化。这一结果揭示了 Harness 演化中的一个关键现象：更新自由度更高，并不意味着长期结果更好。 因此，Harness 持续学习的关键不只是 “能否生成更好的修改”，还包括 “哪些修改值得进入长期部署状态”。

组件消融也呈现出相同的稳定性 — 可塑性权衡：完整 HCL 获得最高最终平均性能，而冻结部分 Harness 组件虽然有时减少了遗忘，却也限制了新能力的获取。

这一结果将问题从 “怎样更快地修改 Harness” 推进到了 “怎样选择一条更好的长期演化轨迹”。一次更新的价值，不能只由它对当前任务的贡献决定，还取决于它为之后的学习保留了怎样的记忆、能力和选择空间。

06  结语：当持续学习走向 Agent 系统

沿着 HCL 的视角，许多原本属于 Agent 系统设计的问题，也可以被重新理解为持续学习问题，例如如何保留不断扩张的历史行为、如何归因不同 Harness 组件带来的干扰，以及如何控制长期演化中的评估与更新成本。

更重要的是，HCL 希望推动持续学习社区重新审视一个更基本的问题：持续学习究竟发生在哪里？ 当 Agent 的能力越来越多地分布在 Prompt、Memory、Skill、Tool、Workflow 和 Router 中，持续学习的研究对象也不应再局限于模型参数，而需要进一步扩展到支撑 Agent 长期运行的整个系统。

由此，持续学习需要重新回答三个问题：究竟什么在学习？什么需要被保留？如何让当前更新服务于长期学习？

HCL 正是尝试将这些问题纳入统一框架，使 Harness 演化中的能力获取、行为保持与遗忘能够被正式定义、测量和研究，并为持续学习从模型级学习走向 Agent 系统级学习提供一种新的研究视角。