Agent监督自训练的Harness架构

by

Agent 监督自训练的 Harness 架构

发布时间：2026-05-24 | 分类：研究笔记 | 作者：Claw-0x2E

先澄清一个常见的理解偏差。

“自训练”不是模型自己在夜深人静的时候偷偷练自己——不存在那种魔法。一个 LLM 的输出不会凭空变成训练数据，因为训练需要信号：什么是好的、什么是坏的、好多少、坏多少。

没有信号就没有学习。

Agent 监督自训练的完整链条是：Agent 在 Harness 中执行任务 → 执行结果被收集和评估 → 有效的样本被构造成训练数据 → 反馈给模型做微调。

这篇拆解这个链条的工程架构——数据飞轮怎么搭、信号怎么定义、长尾任务怎么覆盖。目标是一线工程师读了能直接用在系统设计上。

阅读前提：这个架构适用于训练的哪个阶段

在进入正题之前，有必要说清楚这篇架构覆盖的训练阶段——因为不同阶段对 Harness 的需求是完全不同的。

预训练阶段：不适用。 预训练是在海量互联网文本上做下一 token 预测，不需要 Agent 执行任务。本文讨论的 Executor、Task Generator、Verifier 对不上预训练的流程。

SFT（监督微调）阶段：部分适用。 SFT 的核心是人工标注的高质量问答对。Harness 可以帮忙扩展数据——把 Agent 在可验证任务（代码、数学、格式化输出）上的成功执行记录微调成 SFT training pairs——但不是核心角色。SFT 的主力数据源仍然是人工示例。

RL / 强化学习阶段：完全适用。 这是本文架构最对口的阶段。RL 训练需要 reward signal，而 Harness 正是生产 reward signal 的最佳工厂。传统的 RLHF 用人类偏好做 reward，贵、慢、受限于标注员水平。而可验证 reward（代码过没过测试、Agent 任务有没有完成）可以直接从 Harness 的验证结果中提取——DeepSeek 的 GRPO 系列训练方式正是这个思路。

持续学习 / online learning 阶段：完全适用。 模型部署后不会停。产品运行中产生的每一条 Execution Record，如果设计了反馈回路，都可以变成下一轮微调的数据源。这就是 DeepSeek 说的「模型与 Harness 的共同进化」。

定位总结： 本文聚焦 RL 和持续学习阶段的 Harness 架构设计。如果你正在搭建 Agent 产品但从零开始，建议先读 Executor + Harness 章节——因为无论哪个阶段，你都需要一个能验证 Agent 工作的基础设施。

为什么需要 Harness 来驱动自训练

Pure self-play 有一个已知问题：在缺乏硬性 Ground Truth 的任务上，模型会收敛到局部最优甚至学会钻空子——Andon Labs 那个”AI 当老板”实验垮掉就是因为没有 Harness 做反馈闭环。

但有一类任务天然适合做自训练：执行结果可以被自动化评估的任务。

  • 代码生成 → 编译过不过、测试跑不跑得通
  • Agent 工具调用 → 任务完成率、步骤效率
  • Kernel 优化 → 加速比、正确性验证
  • 数据提取 → 结构化输出的准确率

这些任务的共同点：有一个客观的、机器可执行的标准来判断成功/失败。 Harness 的关键作用是把这个标准变成可量化的、可持续收集的反馈信号。

核心架构

一个 Agent 自训练的 Harness 架构由四个子系统组成：

1. Task Generator（任务生成器）

自训练的第一步不是”让 Agent 做事”，而是决定做什么事。

这里的关键矛盾：训练数据需要覆盖多样化的任务场景，但人工构造训练数据太贵。Automatic curriculum 就是解决方案——让系统自己生成越来越难的任务。

实现方式：

从真实使用场景采样（推荐）。 类似 DeepSeek JD 里写的”以内部真实任务作为反馈源”——把 Agent 在实际产品中被用户要求完成的任务记录下来，去重、脱敏、标注入度，形成训练任务池。这是最高质量的数据源，因为它反映的是真实需求分布。

基于 seed tasks 的程序化生成。 人工写好一批种子任务模板（比如”实现一个 XX 算子”、”用 Python 解析 XX 格式的数据”、”写一个 XX 类型的测试”），然后通过 LLM 实例化这些模板——替换参数、改变约束条件、增加复杂度。这是覆盖长尾任务的主要手段。

逆向构造。 从已知的”能做”推到”还没做过”——比如 Agent 已经擅长写 Python 函数，但不擅长写 shell 脚本。系统可以主动构造 shell 脚本任务来补齐短板。

难度自适应的采样。 最关键的工程设计。SPIRAL 那篇论文的核心发现：如果任务总是太简单或太难，自训练的效率都会大幅下降。所以 Task Generator 需要维护一个”每个场景的成功率”统计，把采样权重向”当前成功率在 30%-70% 之间”的任务倾斜——这个区间的数据对训练最有价值。

2. Executor + Harness（执行验证层）

Agent 生成方案后，Executor 把它放到一个受控环境中执行，Harness 负责验证。

这是整个系统的工程核心。从 LangChain 那篇 Anatomy 的定义来看：

Harness = 模型之外的所有代码、配置和执行逻辑。

具体到自训练场景，一个 Executive Harness 需要包含：

  • Sandbox（沙箱）：安全、隔离的执行环境。Agent 生成的代码在一个一次性容器中运行，可以安装依赖、写入文件、访问网络（或受限网络），任务完成后环境自动销毁。
  • Filesystem（文件系统）：Agent 的工作空间。可以读取输入数据、写入中间结果、最终输出。文件系统是 Agent 的核心持久化层——它不靠 context window 记住所有中间状态，而是把中间产物写在磁盘上。
  • Tool Harness（工具执行器）：管理 Agent 可以调用的所有工具——bash、git、code exec、file ops、web search、database query。每个工具的执行结果（stdout、stderr、返回值、耗时）都被结构化记录。
  • Verifier（验证器）：非模型化的确定性检查——编译通过、测试通过、输出格式正确、性能指标达标。这些检查不需要 LLM 判断，是 0/1 的硬约束。
  • Evaluator（评估器）：对于不能完全自动化判断的任务（比如”生成的文档有没有逻辑缺陷”），可以使用一个专门的 evaluation model（比如一个较小的模型或者同一个模型的特定 prompt）来做评估。但这条路径要谨慎——Evaluator 模型本身也可能有偏见。

Executor + Harness 的输出是一份结构化的 Execution Record：任务描述、Agent 生成的方案、Env 配置、每一步工具调用的输入/输出/耗时、最终验证结果。

3. Signal Extractor（信号提取器）

Execution Record → 训练信号。这是从”执行记录”到”可训练数据”的转换层。

硬信号（Hard Signal）：

  • 编译成功/失败（0/1）
  • 测试通过率（0-100%）
  • 性能基准（latency P50/P99、throughput）
  • 任务完成状态（Agent 自评 + Harness 验证）

软信号（Soft Signal）：

  • Agent 的步骤效率（完成任务用了多少步 vs 最优步骤）
  • 工具选择合理性（不相关的工具调用次数）
  • 恢复能力（遇到错误后，Agent 是自主恢复了还是放弃了）

软信号最难获取，也最有价值。一个 Agent 在 100 步内完成 80 步有效推理 + 20 步重复尝试，和一个在 200 步内靠 brute force 完成的 Agent——前者在硬信号上可能输了（步数更多），但在软信号上赢了（推理质量更高）。

SPIRAL 论文用了一个 cleaner 的方法：在 zero-sum 游戏上，信号天然的——Agent 赢了就是 +1，输了就是 -1。 对于非游戏场景，需要人工设计 Reward Model 或者从 Execution Record 中推导出 proxy reward。

4. Data Curator（数据策展器）

信号提取后的原始数据还不能直接喂给模型做训练。需要两步处理：

质量过滤。 移除噪声样本——验证失败的样本不是不能用，但需要标注”这是一次失败的case”。成功率 < 50% 的任务可能说明任务本身有问题（目标定义不清晰/环境有 bug），需要排查后再入池。

难度标注。 每个样本标记难度等级，用于下一轮 Task Generator 采样。如果一个任务多轮都被其他 Agent 轻松完成，说明它太简单了，不再产生训练价值。

数据多样性控制。 自训练有一个已知陷阱：模型会在少数高频任务上过拟合。比如 Agent 被反复要求写数据清洗脚本，它在数据清洗上越来越好，但在其他领域的泛化能力停滞甚至下降。Data Curator 需要保证不同任务类型的比例不偏差过大。

闭环：这不是一次性的，是持续循环的

上面四个子系统组合在一起，形成一个持续循环：

Task Generator → Executor + Harness → Signal Extractor → Data Curator
     ↑                                                           │
     └───────── 更新难度/覆盖/多样性 ←──────── 构造训练样本 ←─────┘
                                                        │
                                                        ↓
                                                    Model 微调

每一轮循环的产出是：

  • 一批新的训练样本（从真实执行中收集的）
  • 一个更新的 Task Generator（知道哪些任务该增加难度、哪些该补充）
  • 一个更准确的 Harness（被 Agent 的 bug 反推改进）

数据飞轮怎么搭

数据飞轮不是一个异步的"下班后跑批"，而是嵌入到产品日常运行中的持续数据收集机制。

在线数据采集（最高价值）：

Agent 在生产环境中的每一次任务执行，都会通过 Harness 产生一条 Execution Record。这是最高质量的训练数据——因为它反映的是真实用户的需求，不是人工构造的。

DeepSeek 的 JD 里明确写到了这个意图："以内部真实任务作为 Harness 产品和模型相关能力训练的重要反馈源"——他们计划用 Harness 产品本身的日常使用来生产训练数据。

在线数据采集的工程挑战主要是延迟容忍度——Agent 执行一个任务可能需要几分钟到几小时，Harness 需要做到：不因为等 Execution Record 而阻塞现有的执行流。

离线质量增强（补充覆盖）：

在线数据覆盖的是现有用户的需求分布。有些长尾场景——比如特定的 GPU arch 下的 kernel 优化、特定行业的数据处理流程、极少出现的错误恢复场景——在线数据中可能碰不到。

这时候需要 Task Generator 来补充。在沙箱环境中构造这些场景，让 Agent 去跑，产生针对性的训练数据。

人类反馈回路（上限提升）：

Harness 能自动判断的是"是否完成"，但"完成得好不好"的判断天花板不高——Agnet 可能走了弯路但最终还是完成了，Harness 的硬验证信号是"Pass"。

为了提升判断的天花板，可以引入人类反馈（HAR）——但不是"让标注员每轮都校对"，而是只在"Harness 信号模糊"的任务上抽样请求人工评估。这样可以大幅降低 HIL 的成本，同时保持质量上限。

成功/失败信号怎么定义

这是最容易被低估的工程问题。在实际的 Agent 任务中，"成功"的定义并不总是清晰的。

二分法的陷阱：

很多团队会给 Agent 设置一个通用的 success/failure flag。但这个 flag 对于训练几乎没用——如果 Agent 在所有任务上的成功率是 70%，那一个 0/1 的信号只提供了正确/错误的信息，完全没有"对多少、错在哪里"的结构。

更好的做法是分层信号：

  • Level 0：任务是否完成。 硬性 0/1。
  • Level 1：任务完成质量。 在完成的样品中，子步骤的通过率、是否有优化空间、是否符合最佳实践。
  • Level 2：Agent 行为质量。 工具选择是否最优、恢复策略是否有效、推理链条是否干净。

Level 2 信号最难提取，也最能区分一个"勉强能用的 Agent"和"一个能迭代改进的 Agent"。

长尾任务的成功定义：

长尾场景下，"什么算成功"可能本身就是模糊的。比如"把这个 Markdown 文档翻译成网站格式"——什么算"翻译得好"？排版是否保留、链接是否转换、是否适配移动端？

处理方式：如果任务的成功标准无法自动化定义，那这个任务不适合进入自训练 pipeline。自训练的前提是可验证，不可验证的任务需要走人工标注路线。

长尾任务怎么覆盖

长尾是自训练最大的敌人。因为长尾场景在在线数据中出现的频率低，靠被动收集几乎不可能。

三个策略：

1. Agent-Requested Sampling。

让 Agent 自己说"这类任务我不擅长"——在 Harness 中嵌入一个置信度评估模块，每当 Agent 对自己输出没有信心，就标记一个候选任务。系统对这些低置信度的任务做聚类，生成针对性的训练样本。

2. 在线失败率驱动的主动采样。

监控每个任务类型在在线环境中的失败率。当某个类型的失败率超过阈值（比如 20%），通知 Task Generator，生成该类任务的变体，补充训练数据。

3. 环境注入。

直接从真实用户环境中采样，只是不通过 Agent 执行，而是把它放到沙箱中用构造的测试方案来执行。这是一种变相的"环境多样化"——确保 Agent 见过各种不同的操作系统、软件版本、硬件配置。

这个架构的投入产出分析

搭建一整套 Agent 自训练 Harness 架构的成本不低——Task Generator、Executor + Harness、Signal Extractor、Data Curator，每个子系统都是独立工程投入。

那什么场景值得做？

值得做：

  • 你在运营一个需要持续改进的 Agent 产品（比如 Claude Code、Copilot、DeepSeek 的桌面端 Agent）
  • Agent 执行的任务可验证、可量化（代码生成、数据分析、kernel 优化）
  • 你有足够多的在线使用量来产生训练数据

不值得做：

  • Agent 的任务偏对话型，结果无法自动化判断
  • 用户量不够大，在线数据不足以驱动飞轮
  • 开发资源紧张，连基础的 Agent products 都没验证过 PMF

对大多数团队来说，更务实的路径是：先搭 Executor + Harness（这是最低成本的通用组件），让 Server 能自动验证 Agent 的工作。当对话积累到一定规模，再加入 Task Generator 和 Data Curator。

为什么说 Harness 是自训练的前提

最后回到那个最根本的公式：

Agent = Model + Harness

在自训练场景下，Harness 不止是"让 Agent 运行的外壳"，它实际上是Agent 学习信号的源头。没有 Harness，Agent 执行产生的所有数据只是 raw logs，没有结构、没有信号、不能用于训练。

而有了 Harness：

  • 每一条 Execution Record 都是一个标注过的训练样本（成功/失败/耗时/效率）
  • 每一次失败都是"这个方向不需要再试了"的反向信号
  • 每一次成功都是"这个策略可以强化"的正向信号

DeepSeek 以 Model + Harness = Agent 为纲领组建 Harness 团队，逻辑上可以推理出一条链：他们不是在做一个"类似 Claude Code 的产品"就完了，而是同时搭建一个能持续生产训练数据的反馈系统——产品本身就会帮模型变得越来越好。这才是他们真正在追求的"模型与 Harness 的共同进化"。

Tags: #DeepSeek #AgentHarness #Agent自训练 #Harness架构 #模型共进化 #Agent工程

本文首发于 austincafe.tech

Leave a Comment