Harness Continual Learning：持续学习，从模型走向参数 Agent Harness

长期以来，持续学习主要研究模型参数如何沿任务序列更新，以及系统如何在学习新任务时避免灾难性遗忘。经验回放、正则化、优化约束和架构扩展等方法虽然路径不同，但共享同一个基本前提： 持续学习主要发生在模型内部 。 但在 Agentic AI 时代，这一 以模型参数为中心的前提正在发生变化 。一个部署中的智能体不仅由基础模型决定，还依赖围绕模型运行的一整套 Harness ，包括系统提示词、交互记忆、可复用技能、外部工具、工作流与路由策略。即使不微调模型，智能体也能通过更新这些状态持续改变行为。换句话说， 当基础模型保持冻结时，持续学习和演化的对象可以不再局限于模型参数 ， 而是扩展到 Harness （如图 1 所示）。 基于这一背景，南京大学推理与学习研究组与澳大利亚伍伦贡大学的研究者共同提出 Harness Continual Learning 。该工作首次以传统持续学习的基本问题为出发点，将学习对象由模型参数拓展至 Harness，系统定义并研究 Harness 如何沿连续任务序列获取新能力、保留既有行为，以及应对更新过程中产生的遗忘。 这一转变为模型之外的持续学习建立了新的研究对象与基本框架 。 图 1 - 持续学习对象的转变：从更新模型参数，转向围绕冻结基础模型持续演化的 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：决定部署。 只有同时满足当前改进、历史保持与系统有效性要求的候选，才有资格成为下一版本 ( )；否则，系统继续部署原来的 ( )。 图 2 - Harness Continual Learning 总体框架 03 HCL 与传统持续学习的关系 HCL 延续了持续学习最核心的目标： 在获取新能力的同时保留已有能力 ，但将这一目标从模型参数进一步扩展到了 Harness 所承载的经验、能力和执行策略。 从功能上看， HCL 将持续学习中长期形成的多类思想组织到了同一个系统中 ：Experience Memory 负责保留历史经验；抽象记忆与 Capability Map 支撑知识迁移和能力复用；Continual Optimizer 提供面向新任务的可塑性；Continual Evaluator 则通过历史约束保护