做深度学习项目的同学大概率都遇到过这样一个场景模型在一个任务上收敛得很好测试指标也很漂亮但只要开始学习第二个任务前面学过的东西就会像被橡皮擦擦掉一样准确率直线下跌。这种现象在学术界叫灾难性遗忘也是持续学习方向最核心的难点。而最近一段时间随着 Agent 开发越来越热问题又发生了变化模型参数层面的遗忘还没有完全解决我们又开始思考一个 Agent 在长期运行过程中如何积累技能、记忆和工具使用经验而不是把每一次对话都当成一次性的临时任务。于是“持续学习”这个词开始从模型参数层面延伸到 Agent 的 Harness 执行框架中。这篇文章会先梳理持续学习的基本问题和主流方法再解释 Agent Harness 到底代表什么最后用一段简化代码演示如何把持续学习的思路落到一个最小 Agent Harness 原型里。如果你正在做模型微调、Agent 项目或者只是想把持续学习这块知识补完整这篇文章应该能给你一个比较系统的视角。1. 背景与核心概念1.1 持续学习解决什么问题持续学习英文常写作 Continual Learning也有人叫 Lifelong Learning 或 Incremental Learning。通俗来说就是希望模型能够像人一样在一生中不断学习新知识同时不忘记已经学会的旧知识。现实场景里这种需求非常普遍一个推荐系统要不断吸收新的用户行为数据一个质检模型要适应新产线的缺陷类型一个人脸识别系统要不断注册新用户一个客服 Agent 要持续学习新的业务规则。如果每次来新数据就把模型从头训一遍成本太高而且很多场景下历史数据可能因为隐私、合规或存储问题根本拿不到。所以持续学习的核心约束是在只能访问当前任务数据的情况下让模型学会新任务同时尽量保持旧任务的能力不退化。这个需求和普通的迁移学习不一样。迁移学习通常只关心目标域的表现对源域的性能损失没有硬性要求而持续学习必须在一个统一的模型里同时维护多个任务的能力不能顾此失彼。这也是为什么持续学习领域中“稳定性”和“可塑性”总是被放在一起讨论。1.2 模型参数之外的“学习”载体传统持续学习研究主要集中在模型参数上。模型是一个神经网络知识分布在一堆权重里学习新任务会更新权重也就可能破坏旧任务对应的权重结构。于是研究者提出了大量方法有的在损失函数里加正则项有的保存少量旧样本在训练时一起回放有的干脆在旧任务上微调之后用知识蒸馏把旧能力“蒸馏”回来。但到了 Agent 时代学习这件事的载体变多了。一个现代 Agent 的能力不只来自神经网络权重还来自它外部的 Harness——也就是我们给 Agent 搭建的执行环境、工具列表、技能注册、记忆系统、上下文管理策略以及安全边界。Agent 今天学会怎么调用天气接口明天学会怎么操作数据库这些能力并不一定都写进模型权重里更多时候是写在外部系统的配置、脚本和工具调用逻辑里。所以我说“从模型参数走向 Agent Harness”本质上是把持续学习的对象从单一模型权重扩展到了整个 Agent 系统结构。这个视角转变很重要因为它直接影响了我们设计系统的思路不再只盯着 loss 和梯度还要关注记忆、技能、工具链和上下文的持续积累与维护。1.3 本文适合哪些读者这篇文章适合三类读者第一类是用了很久微调模型但被“学了新的就忘了旧的”困扰的算法工程师可以从 EWC、回放等方向找到解决思路。第二类是正在做 Agent 项目想知道怎么把系统设计得更像“一个可以长期进化的系统”的开发者。第三类是概念还比较模糊的入门同学对持续学习、灾难性遗忘、Agent Harness 都只听过名字想一次性把脉络理清楚。如果你属于第一类可以直接看第 3 章的代码示例如果你属于第二类建议重点看第 4 章和第 5 章那里会用一个最小原型演示 Harness 如何承担持续学习的职责如果你是入门我建议按章节顺序读下来先把几个术语的边界搞清楚。2. 持续学习的基础问题2.1 什么是灾难性遗忘灾难性遗忘是持续学习领域最经典的难点。1989 年 McCloskey 和 Cohen 就在论文里描述过这个现象神经网络在顺序学习多个任务时学习新任务会剧烈覆盖旧任务的知识导致旧任务性能突然下降。你可以这样理解神经网络的容量是有限的后一个任务的梯度更新会把前一个任务形成的特征空间“挤”坏。尤其是当两个任务的输入分布差别较大时这种覆盖会非常明显。举一个常见例子先用猫狗图片训练一个分类器准确率 95%然后切换到识别花朵的任务训完之后回去测猫狗数据集准确率可能掉到 60% 以下。这里要说明的是灾难性遗忘并不仅仅是“数据太少”导致的过拟合。即使在数据充足的情况下只要网络以纯梯度下降方式顺序学习两个任务遗忘就可能发生。因为损失函数在旧任务方向上的梯度已经被新任务主导旧任务解在参数空间里相当于被“推开”了。2.2 稳定性与可塑性困境持续学习研究里有一个著名的矛盾模型同时追求两个目标——稳定性和可塑性。稳定性指模型在学完新知识后旧知识仍然保留可塑性指模型能够快速有效地吸收新知识。这两者在梯度下降框架下天然冲突如果对参数改变过于放任新任务学得太快旧能力就会崩溃如果对参数改变过于保守旧能力虽然保住了但新任务又学不进去。这也解释了为什么持续学习没有银弹。不同任务、不同数据分布、不同资源约束下需要在稳定性和可塑性之间取一个平衡点。很多看起来复杂的方法本质上都是在尝试用某种机制动态调节这个平衡。例如 EWC 用 Fisher 信息量来标记哪些参数对旧任务重要从而对重要参数施加更大的更新惩罚而弹性权重巩固、在线 EWC、SI 等方法则是从不同角度估计“参数重要性”。2.3 任务增量、领域增量与类增量持续学习通常按照数据与任务的定义方式划分成三种设定理解这三种设定对后续技术选型非常关键。任务增量学习是最容易的一种设定。每个样本带有任务 ID训练和测试时都知道当前属于哪个任务模型可以针对不同任务使用不同头部或不同路由任务之间干扰较小。领域增量学习稍微难一点输入分布会变化但标签语义一致测试时没有任务 ID模型必须用一个共享头部处理所有领域。类增量学习最难新任务不断带来新的类别测试时只有样本不知道它属于哪个任务而且必须区分所有已学类别。实际的 Agent 场景更接近类增量和领域增量的混合体Agent 可能不断遇到新的用户意图、新的工具、新的业务规则而系统无法每次都收到“现在是第几个任务”这样的提示。因此纯粹依赖任务 ID 的方法在 Agent 场景中往往不适用需要更灵活的记忆与结构机制。3. 模型参数层面的持续学习技术在讨论 Agent Harness 之前有必要先把参数层面的技术基础打牢。因为很多思路——比如正则、回放、蒸馏——在 Agent 系统里依然适用只是载体和实现方式变了。3.1 正则化方法EWC 的核心思想弹性权重巩固是持续学习最经典的方法之一。它的核心思想来自贝叶斯视角训练完旧任务后参数的最优解已经接近一个低损失区域在新任务训练时应该限制参数不要偏离旧任务最优解太远尤其是那些对旧任务很重要的参数。关键問題变成了如何定义“重要性”EWC 用 Fisher 信息矩阵的对角线来估计每个参数的 Fisher 信息量。Fisher 信息越大说明参数对对数似然的影响越敏感也就越重要。训练新任务时损失函数中增加一个惩罚项惩罚量正比于 Fisher 信息乘以参数偏移量的平方。下面给出一个简化实现使用 PyTorch 描述核心过程。# 文件路径continual/ewc.py import torch import torch.nn as nn from torch.utils.data import DataLoader class EWC: 弹性权重巩固Elastic Weight Consolidation的简化实现。 核心思路 1. 旧任务训练完成后计算每个参数的 Fisher 信息量。 2. 学习新任务时在损失函数里加入正则惩罚项 避免 Fisher 信息较大的参数偏离旧任务最优解太远。 def __init__(self, model): self.model model self.fisher {} # 参数名 - Fisher 信息量 self.old_params {} # 参数名 - 旧任务结束后的参数值 def consolidate(self, dataloader: DataLoader, loss_fn, devicecpu): 旧任务训练完后调用计算 Fisher 信息矩阵的对角线近似。 self.model.train() grads_sq {} for name, param in self.model.named_parameters(): if param.requires_grad: grads_sq[name] torch.zeros_like(param.data) total 0 for x, y in dataloader: x, y x.to(device), y.to(device) output self.model(x) loss loss_fn(output, y) self.model.zero_grad() loss.backward() for name, param in self.model.named_parameters(): if param.grad is not None: # Fisher 对角线的 Monte Carlo 近似梯度平方的累计均值 grads_sq[name] param.grad.detach().pow(2) total 1 for name, param in self.model.named_parameters(): self.old_params[name] param.data.clone() self.fisher[name] grads_sq[name] / max(total, 1) def penalty(self, model, lambda_ewc1000.0): 返回 EWC 正则项叠加到当前任务的 loss 上。 reg_loss 0.0 for name, param in model.named_parameters(): if name in self.old_params and name in self.fisher: diff param - self.old_params[name] reg_loss (self.fisher[name] * diff.pow(2)).sum() return lambda_ewc * reg_loss在训练新任务时只需要把ewc.penalty(model)加到损失函数里# 文件路径train_new_task.py核心片段 loss criterion(output, target) ewc.penalty(model, lambda_ewc1000.0) loss.backward() optimizer.step()要注意几点。第一EWC 的 Fisher 计算是在旧任务数据上做一次前向和反向得到的如果旧数据太多可以用一个固定大小的子集近似。第二lambda_ewc是稳定性与可塑性的调节旋钮值越大旧任务能力保留越好但新任务可能学不动需要根据实验调到合适范围。第三这个实现是“离线 EWC”如果任务是一个接一个在线到达可以使用 Online EWC 或 SI 等方法让 Fisher 信息按时间指数衰减。3.2 经验回放简单但有效的反遗忘手段经验回放是另一个经典思路把旧任务的一部分样本保存在缓冲池里训练新任务时把这些旧样本混进新的 batch 中一起训练。因为模型能随时看到旧数据就会不断校正对旧任务的表征遗忘现象会显著减轻。经验回放的优点在于实现简单、效果好而且对于小规模任务非常可靠。缺点也很明显需要保存样本数据可能带来隐私和存储问题如果保存的是原始输入回放内容可能偏离真实环境的数据分布。后面的衍生研究主要围绕两个方向如何选择更“有代表性”的样本保存以及如何尽量少保存甚至不保存原始图片比如生成式回放和潜在空间回放。下面是一个简化实现属于最基本的随机回放池。# 文件路径continual/replay.py import random class ReplayBuffer: 固定容量样本缓冲池。训练新任务时将旧样本混入当前 batch。 def __init__(self, capacity500): self.capacity capacity self.buffer [] def add(self, x, y): if len(self.buffer) self.capacity: # 简单策略随机替换一个旧样本 idx random.randint(0, len(self.buffer) - 1) self.buffer[idx] (x, y) else: self.buffer.append((x, y)) def sample(self, batch_size: int): size min(batch_size, len(self.buffer)) return random.sample(self.buffer, size) def __len__(self): return len(self.buffer)实际训练循环中可以这样混合新旧样本# 文件路径train_with_replay.py核心片段 replay_buffer ReplayBuffer(capacity500) for x_batch, y_batch in new_task_loader: # 从回放池中取一批旧样本 replay_samples replay_buffer.sample(batch_size32) replay_x torch.stack([s[0] for s in replay_samples]) replay_y torch.stack([s[1] for s in replay_samples]) combined_x torch.cat([x_batch, replay_x], dim0) combined_y torch.cat([y_batch, replay_y], dim0) output model(combined_x) loss loss_fn(output, combined_y) optimizer.zero_grad() loss.backward() optimizer.step()回放策略的工程细节很多是随机采样还是按困难程度加权旧样本保存多少张合适是否需要为每个类别设置容量配额这些会影响最终效果。我的建议是如果只是做一个简单 demo随机回放完全够用如果是生产项目建议把回放池设计成类别均衡并且对新样本做一定筛选避免相似重复样本占满容量。3.3 动态结构方法给网络增加通道正则化和回放都是在固定结构的网络上做文章而动态结构方法选择直接改变网络结构。典型思路是为每个新任务增加新的子模块或新的可训练通道旧任务的参数尽量不动。例如 Progressive Networks 为每个新任务增加一个并行网络旧网络的特征通过横向连接传入新网络PackNet 则通过剪枝将不同任务的参数放到不同的子网络中。这类方法的好处是稳定性极高几乎不会遗忘旧任务因为旧参数根本没被改动代价是模型参数量会随任务数量线性增长推理时可能需要路由机制判断走哪个子网络。动态结构是“参数级持续学习”里最接近工程落地的一类很多推荐系统和多业务线模型会采用类似思路做多任务共享架构只是轻量很多。不过在 Agent 场景中动态结构并不一定意味着扩展神经网络。它可能表现为每当遇到新的工具类型就新增一个 skill 模块每当遇到新业务领域就新增一条可插拔的上下文处理链。整个系统更像“乐高积木”而不是一棵不断变大的网络。3.4 参数层面的局限参数层面的方法确实有效但放在 Agent 场景中会暴露几个问题。第一个问题是“知识表达方式不匹配”Agent 很多能力存储在工具调用逻辑、提示词模板、外部脚本和配置文件里这些都不是神经网络权重。第二个问题是“多模态异构数据”Agent 遇到的数据不只是图片或文本标签还有用户指令、工具返回结果、环境状态等等很难统一放进一个回放缓冲区。第三个问题是“实时性”Agent 的学习往往是增量式的今天学会一个技能未来几天可能一直在用需要有稳定的持久化机制而不是等一个任务训完再默默算一次 Fisher。所以我们必须把视角从参数层面拉出来看向 Agent 的外壳——Harness。4. Agent Harness持续学习的新阶段4.1 Harness 到底是什么Harness 这个词在英文里有“马具、挽具、利用、控制”的含义。在软件开发中它常指“测试夹具”或“执行框架”例如 OpenAI 早期的 Codex harness 研究框架就是在沙箱环境中执行模型生成的代码、验证程序行为。在 Agent 开发领域Harness 通常指承载 Agent 运行的“外部执行环境 工具调度框架”。具体来说它定义了 Agent 能看到什么上下文、能调用哪些工具、工具的输入输出如何解析、一次执行最多可以运行多少步、遇到异常怎么处理、长期记忆怎么存取。换句话说模型是大脑Harness 是神经系统、四肢和记忆仓库。模型只负责推理和决策而真正与外部世界交互的是 Harness。这里我刻意不展开介绍某个具体产品因为市面上相关工具迭代太快。你可以把 Agent Harness 理解成一类工程模式它把模型和外部系统解耦给 Agent 提供一个稳定、可扩展、可观测的运行底座。无论你用的是哪种底层模型Harness 的设计思路都是共通的。4.2 从模型参数到 Agent 全链路当我们把“学习”的对象从模型参数扩展到 Agent 全链路持续学习的内容就变成四个层次。第一层是模型参数依然需要解决灾难性遗忘但 Agent 场景下新数据可能以日志形式到达无法像离线训练那样完整迭代需要在线学习或定期增量训练方案。第二层是记忆系统Agent 需要记住用户的偏好、过去的对话结果、已执行过的动作并且要让这些记忆能被检索出来不能被新对话淹没。第三层是技能与工具Agent 每次学会一个新工具调用方式都应该能保存为一个可复用技能而不是散落在某一段对话中。第四层是策略与行为Agent 需要从反馈中学习什么时候该主动调用工具、什么时候该拒绝危险请求、回答的置信度达到多少才能下结论。这四个层次互相影响。例如一个 Agent 学会了新工具但如果记忆系统没有把工具的使用条件和注意事项保存好下次遇到类似场景它可能不会主动调用相反如果记忆系统设计得很强即使模型权重更新不大Agent 在行为层面也能表现出“学会了新东西”。4.3 Agent Harness 的持续学习对象从工程实现的角度看Agent Harness 里最需要被“持续学习”的组件主要有这么几个。第一个是记忆管理器。它不只是单纯的存储还要负责遗忘和压缩。一个对话系统如果永久保存所有原始对话会又慢又乱需要定期把旧对话摘要化把不重要的记忆丢弃把重要的记忆提取成长期记忆。第二个是技能注册中心。每项技能就是一个可以被模型调用的函数注册中心需要保存技能的名称、描述、参数结构、依赖条件以及版本。当 Agent 遇到新场景时新技能可以被动态注册旧技能可以升级为 v2同时保留 v1 用于兼容。第三个是上下文构建器。它负责把当前输入、长期记忆、近期对话、可用技能列表压缩进一次模型调用的上下文中。上下文需要控制长度还要保障关键信息不丢失这是“上下文工程”的核心。第四个是反馈闭环。每次工具执行结果、用户反馈、异常日志都需要被记录并形成可用于后续迭代的评估信号。如果系统定期拿这些反馈去微调模型那么 Agent 就真正形成了一个持续学习的闭环。下面用一个最小原型把这些组件串起来。5. 实战搭建一个最小 Agent Harness 原型5.1 需求设计我们不做生产级框架而是演示“模型只负责决策、Harness 负责执行和记忆”的核心模式。系统需要支持以下功能注册若干个技能工具保存最近的对话记忆用户输入后由模型生成一个 JSON 动作Harness 解析并调用对应技能技能执行结果作为上下文的一部分继续保留。这个原型的关键设计点是“模型与工具解耦”。模型不直接执行函数它只输出动作意图Harness 根据动作名称查找技能并执行。这样一来未来的技能更新、模型替换都不会互相影响Harness 也就成了 Agent 持续进化的稳定底座。5.2 代码实现先定义技能和 Harness 的数据结构。# 文件路径agent_harness/harness.py import json from dataclasses import dataclass, field from typing import Callable, Dict, List, Optional dataclass class Skill: 一个可复用的技能单元。 name 是模型在动作里引用的名称 description 用于给模型提供上下文说明什么场景应该调用 fn 是真正执行工具逻辑的函数。 name: str description: str fn: Callable dataclass class AgentHarness: 最小 Agent Harness 原型。 职责划分 1. 管理可用技能列表 2. 维护短期记忆 3. 构造上下文交给模型 4. 解析模型输出的 JSON 动作执行对应技能。 model: object memory: List[dict] field(default_factorylist) skills: Dict[str, Skill] field(default_factorydict) max_memory: int 100 max_steps: int 3 def register_skill(self, skill: Skill): self.skills[skill.name] skill def remember(self, turn: dict): self.memory.append(turn) if len(self.memory) self.max_memory: # 简单策略移除最旧记录 self.memory.pop(0) def run(self, user_input: str) - str: context self.build_context(user_input) for step in range(self.max_steps): model_output self.model.generate(context) action self.parse_action(model_output) if action is None: # 模型没有输出动作说明它选择了直接回答 return model_output if action[name] not in self.skills: return f未知技能{action[name]}请检查技能注册表。 result self.execute_action(action) self.remember({ input: user_input, step: step, action: action, result: result, }) # 演示用途执行完一个技能后立即返回结果 return result return 步骤过多已强制结束。 def parse_action(self, model_output: str) - Optional[dict]: 尝试把模型输出解析为 {action: 技能名, args: [参数列表]}。 try: data json.loads(model_output) if action in data and args in data: return {name: data[action], args: data[args]} except json.JSONDecodeError: pass return None def execute_action(self, action: dict): skill self.skills[action[name]] return skill.fn(*action[args]) def build_context(self, user_input: str) - str: recent_memory self.memory[-5:] memory_text \n.join( f用户{m[input]}执行结果{m.get(result, )} for m in recent_memory ) skill_text \n.join( f- {s.name}: {s.description} for s in self.skills.values() ) return ( 你是 Agent Harness 中的决策模型请严格输出 JSON 动作。\n f可用技能\n{skill_text}\n f最近记忆\n{memory_text}\n f用户输入{user_input}\n )为了让这个原型可以脱离真实大模型运行我们写一个演示用的 DummyModel。它不进行真正的推理而是根据上下文里的关键词返回一个预先写好的 JSON 动作模拟大模型“决策”的过程。# 文件路径agent_harness/dummy_model.py class DummyModel: 演示用假模型。 真实场景中这里会调用大模型 API 让模型基于上下文输出动作 JSON。 这里用规则代替模型便于跑通整个流程。 def generate(self, prompt: str) - str: if 计算 in prompt and 价格 in prompt: return {action: add_price, args: [19.9, 3.5]} if 时间 in prompt: return {action: get_time, args: []} return 抱歉我没有理解你的意思请重新描述。然后定义两个实际技能函数一个计算两数之和一个返回当前时间。在实际项目中这里就是对接具体工具接口的位置。# 文件路径agent_harness/skills.py from datetime import datetime def add_price(a: float, b: float) - str: 计算两个价格之和。 return f{a b:.2f} 元 def get_time() - str: 获取服务器当前时间。 return datetime.now().strftime(%H:%M:%S)5.3 运行与验证把所有模块拼起来编写主入口脚本。# 文件路径agent_harness/main.py from harness import AgentHarness, Skill from dummy_model import DummyModel from skills import add_price, get_time def main(): harness AgentHarness(modelDummyModel()) harness.register_skill(Skill( nameadd_price, description计算两个商品价格的总和适合用户询问价格合计时使用, fnadd_price, )) harness.register_skill(Skill( nameget_time, description获取当前系统时间适合用户询问时间时使用, fnget_time, )) # 场景一价格计算 result harness.run(请帮我计算商品价格 19.9 和运费 3.5 的总价) print(Agent:, result) # 场景二时间查询 result harness.run(现在几点了) print(Agent:, result) # 场景三没有对应技能 result harness.run(讲讲今天的天气) print(Agent:, result) if __name__ __main__: main()预期的输出效果大致如下Agent: 23.40 元 Agent: 14:30:25 Agent: 抱歉我没有理解你的意思请重新描述。需要注意的是这个原型还很粗糙。模型输出偶尔会不符合 JSON 格式也可能一次性构造多个动作真实的 Agent Harness 还需要增加重试、异常捕捉、工具调用超时、动作参数校验等机制。这里的目的是展示 Harness 的核心分工模型负责生成动作Harness 负责匹配技能、执行动作、记录记忆。5.4 如何扩展成真正的持续学习系统上面这个原型加入记忆和技能注册之后已经具备“持续迭代”的基础。你可以在三个方面做扩展。第一把短期记忆改成长期记忆。短期记忆是一个固定长度的 list长期记忆则需要使用向量数据库每次对话结束后将关键信息编码成向量保存下次构建上下文时根据用户输入做相似度检索。这就是 RAG 的常见用法也是 Agent 记忆系统的底层能力。第二把技能注册中心组学化。可以设计成每个技能带一个 embedding 描述模型在决策时通过路由网络自动判断调用哪个技能甚至可以定期从执行日志中挖掘高频调用序列把“多个技能组合使用”沉淀为一条新的复合技能。这比手工注册更加高效。第三加入离线评估与模型增量更新。Harness 持续记录执行日志每周或每月用这些日志对底层模型做一次增量训练训练时可以采用第 3 章提过的 EWC、经验回放等方法来保护原有能力。这样系统就从“参数级持续学习”走到了“Agent 级持续学习”。6. 常见问题与排查思路在设计和调试持续学习系统时我遇到的常见问题基本集中在下面几类整理成一个排查表。问题现象常见原因解决思路学完新任务后旧任务准确率明显下降灾难性遗忘参数被新任务覆盖用 EWC 正则、经验回放或知识蒸馏保护旧能力Agent 在长时间对话后开始重复或混乱短期记忆过长关键信息被淹没引入记忆窗口、摘要压缩、向量检索新技能注册后模型始终不调用技能描述不清晰或上下文没有包含技能列表优化技能描述检查上下文构建逻辑模型输出固定格式的 JSON 失败了模型本身稳定性差或提示词约束不足增加解析重试、提供 few-shot 示例、后处理修复工具执行超时外部服务不稳定或 Harness 没有超时机制增加超时时间、重试和降级预案模型参数增量更新后行为出现明显漂移新数据分布与旧数据差异大在增量数据中加入旧数据回放评估多组指标从经验来看持续学习项目的大部分 bug 都不是“模型学不会”而是“旧能力的评估体系缺失”。很多人只盯着新任务的指标觉得自己进步了转头发现旧任务已经崩了。我建议在系统设计的第一天就同时维护新任务、旧任务和回放集三套评估指标并且把旧任务指标写进 CI每天自动运行一次。还有一个容易忽略的点是“回放数据污染”。如果旧样本里包含了错误标签或已经失效的业务规则回放反而会把模型带偏。所以不要只关注回放的容量还要维护数据质量过期样本要定期清理不稳定的标签要有置信度标记。7. 最佳实践与工程建议7.1 参数层面的建议在模型参数持续学习方面最稳妥的起步方案不是上复杂算法而是先做好两件事一是把训练数据按任务或领域打上 tag便于回放和评估二是建立旧任务回归测试集每次增量训练后自动跑一遍。算法引入顺序建议是先做经验回放再考虑 EWC最后才是更复杂的方法。因为经验回放实现成本低、效果直观大部分业务场景用回放就能解决大部分遗忘问题EWC 适合历史数据无法保存的场景但调参成本偏高。知识蒸馏也是一种很实用的保护旧能力的方法尤其当旧模型没有训练数据、只有 logits 可用时。7.2 Harness 工程层面的建议在 Agent Harness 的工程实现里我认为核心原则是“模型与工具解耦”。模型永远不应该直接接触外部服务的密钥或数据库连接所有工具都必须通过 Harness 中转。接口定义要稳定。每个技能在注册时除了函数实现还应该记录清晰的描述、参数 schema、依赖条件、版本号和兼容策略。技能升级时建议保留旧版本一段时间防止模型在上下文中已经按旧版本习惯生成动作。日志和可观测性非常关键。每个动作的请求参数、执行结果、耗时、错误信息都需要记录而且最好形成结构化日志。没有日志就无法判断模型为什么不调用某技能、工具为什么失败、记忆检索为什么召回不到关键信息。安全边界也不能放松。工具调用要遵循最小权限原则Harness 需要维护工具白名单对可疑动作做拦截涉及真实业务数据写操作时要经过二次确认。配置和密钥要集中管理不要散落在代码和 prompt 里。7.3 持续学习评估体系评估体系是持续学习项目中最容易被轻视但回报最大的一部分。至少要包含以下指标旧任务性能保留率增量训练后旧任务准确率相比训练前的下降比例。新任务学习效率训练完成所需样本量或迭代轮数。回放集一致性回放样本在增量训练前后的预测稳定性。Agent 端到端任务成功率Harness 在真实综合任务中的最终成功率。工具调用准确率模型在上下文中是否正确选择了技能、参数是否正确。这些指标要跑在固定测试集上而不是靠人工观察几个 demo 判断。尤其在做 Agent 系统时单个对话的效果错觉很强必须量化统计。8. 总结与下一步学习路线这篇文章从模型参数的持续学习讲到 Agent Harness主要的收获可以归纳成三点。第一持续学习的核心是“稳定性和可塑性”的权衡经典方法包括 EWC、经验回放和动态结构。无论技术怎么包装本质都是在想办法降低新知识对旧知识的破坏。第二Agent 时代的持续学习载体已经不只是模型权重而是整个 Harness 系统包括记忆、技能、上下文和反馈闭环。第三工程落地的关键是构建评估体系在没有回归测试集的情况下任何持续学习方案都可能让你“自我感觉良好”。如果你刚接触这个方向建议的后续学习路线如下。先从参数级持续学习入手自己跑一个 EWC 和回放的实验加深对灾难性遗忘的直觉然后学习 RAG 和向量数据库理解 Agent 的长期记忆怎么设计与检索接着了解主流 Agent 框架的 Harness 设计重点看工具注册、上下文构建和错误处理机制最后在自己的项目里尝试加一个最小 Harness把技能、记忆、日志沉淀下来再考虑用执行日志反哺模型。希望这篇文章能帮你把“持续学习”和“Agent Harness”这两个概念真正串起来。如果你正在某个部分卡住欢迎留言交流我也会根据大家的反馈补充更细的实战案例。