Agent Harness：让持续学习跳出模型参数

持续学习（Continual Learning）这个概念，过去在大模型语境里几乎默认等于“更新模型参数”。当模型遇到新任务、新语料或新领域时，最常见的做法是准备训练集、做增量微调、再评估和部署。这个思路没有错，但放在 Agent 场景下会越来越吃力。真正的问题不在于模型不会做某件事，而在于整个系统还没有接上完成这件事所需的工具、流程、记忆和权限。于是 Harness 开始成为持续学习的另一个重点：让能力变化发生在模型参数之外，而不是每一次都塞进权重里。Harness Continual Learning 的核心变化，是从“模型参数学习”走向“Agent 外部系统学习”。这篇文章会先讲清楚为什么参数微调不是唯一选项，再给出一个可运行的 Agent Harness 最小骨架，并围绕技能注册、记忆召回、MCP 工具接入、参数选型和故障排查展开，帮助你理解如何在不改模型权重的情况下，让 Agent 系统持续获得新能力。

1. 持续学习为什么从模型参数转向 Agent Harness

1.1 传统持续学习是“让模型权重更新”

传统持续学习研究的目标是让模型在已有能力基础上继续吸收新知识，同时尽量不遗忘旧知识。常见做法包括：

• 使用正则项约束旧任务参数变化，例如 EWC（Elastic Weight Consolidation）。
• 使用知识蒸馏保留旧任务输出，例如 LwF（Learning without Forgetting）。
• 在训练集中混合旧样本，例如 Replay / Experience Replay。
• 在预训练模型上做参数高效微调，例如 LoRA、Adapter。

这些方法有一个共同点：能力的载体是模型参数。新技能必须通过训练数据、损失函数和优化器进入网络权重。这样做的代价也很明显：

在单模型场景里，这些代价可以接受。但在 Agent 场景里，模型只是执行系统的一部分。Agent 要处理的是动态变化的外部环境：新 API、新数据库、新内部系统、新业务规则、新文件格式。如果每次接一个新工具都重新训练一次参数，模型更新速度会远远赶不上业务变化速度。

1.2 Agent 时代的新瓶颈：能力不等于参数

Agent 系统的能力由多个部分组合而成：

• 模型本身的语言理解、推理和生成能力；
• 提示词和系统规则；
• 可调用工具和外部 API；
• 可检索的历史记忆；
• 权限、沙箱和审批流程；
• 评估和回滚机制。

当 Agent 需要学习“调用内部工单系统创建任务”时，真正缺的不一定是模型参数，而是工具注册、参数说明、调用权限和执行结果反馈。把这些能力集中放到一个可维护的外部框架里，就是 Harness 的定位。

Harness 可以简单理解为 Agent 的外围执行与编排系统。它负责决定：

• 当前任务可以调用哪些技能；
• 技能的描述和参数结构是什么；
• 如何把用户问题、历史记忆和可用工具组装成模型输入；
• 模型返回工具调用后，Harness 如何执行、记录、反馈；
• 权限是否允许这次操作；
• 执行失败时如何重试或降级。

模型仍然承担推理和决策，但工具、知识、规则、状态由 Harness 管理。能力升级的路径从“重训模型”变成了“在 Harness 中注册新技能、写入新记忆、调整编排规则”。

1.3 Harness 和 Agent 的区别

实际讨论中经常混用这两个词。可以这样区分：

• Agent 是完成任务的整体，包含模型、工具、记忆和策略。
• Harness 是承载和控制 Agent 运行的外部框架，负责把 Agent 的各个部件装配起来。

一句话：Harness 是 Agent 的“载具和操作台”，模型是“推理内核”。Harness 更关注工具调用、状态管理、权限控制、日志追踪和错误处理；Agent 更关注目标拆解、规划、执行和反馈。

名称上，DeepSeek Harness、Codex Harness 这类工具就是把编码 Agent 的沙箱、命令行、MCP 服务和任务执行编排整合在一起。这类工具的能力和界面更新很快，落地时要以对应版本文档为准，重点学习其设计思想：把能力放在 Harness 层，而不是反复改模型参数。

1.4 模型参数、上下文和 Harness 三种持续学习承载方式对比

在真实项目中，三种方式不是互斥的。最佳状态是：Harness 负责高频变化的外部能力，上下文负责当前任务的临时约束，模型参数负责真正需要长期内化的知识。

2. 环境准备：搭建一个 Harness 最小骨架

2.1 前置知识与技术选型

在进入代码前，先明确环境要求。理解 Agent Harness 不需要 GPU，也不需要训练框架，更多是工程组合。