专题研究

The Harness is the Dataset：轨迹捕获驱动的预训练与中训练数据构建

DeepMind Philipp Schmid 的金句背后，是一套完整的数据工程范式转移。本文深度解析这一洞见对大模型预训练数据、中训练数据构建的具体启发，并给出可操作的数据飞轮方案。

2026年3月29日 Harness Engineering 预训练数据中训练数据 Agent 轨迹数据飞轮数据合成执行轨迹 Philipp Schmid

引言：这句话从哪里来，为什么这么说

原始背景

2026 年 1 月 5 日，DeepMind Staff Engineer Philipp Schmid 在个人博客发表了一篇文章：The importance of Agent Harness in 2026。

文章的出发点，是他观察到的一个现象：顶级模型在静态 benchmark 上的差距正在缩小，但这是一种幻觉。 真正的差距在复杂的、多步骤的长任务上才会浮现——模型在执行第 50 步、第 100 步工具调用后，是否还能稳定地遵循初始指令？标准 benchmark 根本无法测量这种”持久性（durability）”。

他在文章结尾的”What Comes Next”部分，给出了三条判断，其中第三条就是这句被广泛引用的话：

“The Harness is the Dataset: Competitive advantage is no longer the prompt. It is the trajectories your Harness captures. Every time your agent fails to follow an instruction late in a workflow can be used for training the next iteration.” — Philipp Schmid, The importance of Agent Harness in 2026

他真正想说的是什么

在文章的完整语境里，这句话有一个非常具体的指向，并非泛泛而谈”数据很重要”。

Schmid 观察到，我们正在走向训练环境与推理环境的融合（convergence of training and inference environments）。Harness 运行时发现的”模型在长任务第 N 步开始偏轨”的具体失败数据，会被直接喂回训练，用来构建”不会在长任务中越跑越偏”的下一代模型。

用他的原话：

“The Harness will become the primary tool for solving ‘model drift’. Labs will use the harness to detect exactly when a model stops following instructions or reasoning correctly after the 100th step. This data will be fed directly back into training.”

所以，这句话的完整意思是：

竞争优势不再是谁写的 prompt 更好，而是谁的 Harness 在真实任务中跑得更久、更广，积累了更多高质量的执行轨迹——这些轨迹是下一代模型的训练数据，而且是别人无法复制的私有数据。

为什么这个洞见在 2026 年 3 月才开始大规模传播

这篇博文发布于 2026 年 1 月初，但真正在中文 AI 社区引发广泛讨论是在 2026 年 3 月下旬——恰好是 Claude 4、GPT-5 等新一代基础模型集中发布之后。

这不是巧合：当多个”足够聪明”的基础模型同时存在，应用层开发者开始真实感受到”换模型并不能解决核心问题”，Schmid 三个月前的预判才变得切身可感。

从数据研究者的视角重新解读

这篇文章的其他读者（Agent 工程师、应用开发者）关注的是：“怎么把 Harness 建好”。

但从大模型训练数据研究者的视角，这句话指向的是另一个问题：

下一代预训练和中训练数据从哪里来？

传统数据工程的答案是：爬互联网、写清洗流水线、人工标注、合成数据。Schmid 的洞见给出了一个新答案：把系统跑起来，把跑的过程记录下来——Harness 就是数据工厂，执行轨迹就是原材料。

本文的核心任务，就是把这个洞见翻译成对预训练数据和中训练（Continual Pre-training）数据构建的具体启发与可操作方案。

一、从传统数据观到轨迹数据观

1.1 传统预训练数据的生产逻辑

传统预训练数据的生产逻辑，可以概括为“采集-过滤-混合”三步：

互联网 / 教科书 / 代码库
        ↓
   清洗 + 去重 + 质量过滤
        ↓
   领域配比 + 课程编排
        ↓
   静态数据集（一次性生成）

这个逻辑的隐含假设是：语言本身就是知识的载体，只要数据足够多、足够干净、分布足够合理，模型就能学到知识和推理能力。

在大模型早期，这个假设基本成立。但随着模型能力跃升到 Agentic 阶段，问题逐渐暴露：静态文本无法描述行动，文档无法捕获决策过程，语料库里缺少的不是知识，而是”怎么做”的执行经验。

1.2 轨迹数据的本质差异

Harness 捕获的数据形态，与传统训练数据有本质区别：

维度	传统预训练语料	Harness 捕获的轨迹数据
数据形态	静态文本片段	动态执行序列（思考→动作→反馈→修正）
知识类型	陈述性知识（知道什么）	程序性知识（怎么做）
错误信号	无（正确文本的堆砌）	有（失败的尝试 + 恢复策略）
上下文	独立片段	任务完整闭环（目标→执行→验证）
来源	人类历史书写	模型在真实环境中的执行经验
稀缺性	高质量文本正在枯竭	随着 Agent 部署规模扩大而增长
可验证性	几乎无法自动验证	有明确的成功/失败信号

这张表格揭示了一个关键事实：轨迹数据是一种根本上不同于传统预训练语料的数据类型，它填补的是”执行经验”这一维度的空白。

1.3 Harness 金句的深层含义

当 Schmid 说”Harness is the Dataset”时，他实际上在说三件事：

第一层：Harness 是数据生成器 一个好的 Harness（内置 Memory、Tools、Orchestration、Evaluation、Observability 的完整系统）每天运行，就每天在产出数据。这不是副产品，这是核心资产。

第二层：轨迹是新的稀缺资源 传统互联网文本趋于饱和（Epoch AI 估算高质量英文文本约 9T tokens，到 2026 年行将用尽），但执行轨迹随着 Harness 的规模扩大而指数增长，且天然包含任务成功/失败标注。

第三层：数据壁垒的新形式 过去的数据壁垒是”谁能爬到更多互联网数据”。现在变成了：谁的 Harness 覆盖了更多真实任务场景，捕获了更高质量的执行轨迹，谁就有不可复制的训练数据壁垒。

二、对预训练数据构建的启发

预训练阶段的目标是让模型建立广泛的知识基础和能力基因。从 Harness 视角看，预训练数据构建有以下几个新方向：

2.1 执行轨迹作为预训练语料

当前问题：预训练语料大量是”结果文本”（文章、文档、代码），缺少”过程文本”（推理链、调试过程、迭代过程）。

Harness 启发：把各类工具使用日志、代码执行过程、问题解决轨迹纳入预训练数据。

具体来源：

代码执行轨迹：GitHub Issue 里的 debug 对话（报错→分析→修复→验证）完整序列
命令行交互记录：真实的 shell session 日志（任务目标→执行→输出→调整的完整循环）
数学解题过程：不仅是最终答案，而是包含错误尝试和修正的完整推导过程
API 调用日志：工具调用（请求→响应→解析→决策）的完整链路
搜索式问题解决：Stack Overflow 的最佳答案 + 评论中的质疑与修正讨论

示例：从 GitHub Issue 提取预训练语料

原始数据:
  Issue 标题: "KeyError when using pandas groupby with custom aggregation"
  用户描述 + 代码 + 报错 → 回复1（错误方向）→ 回复2（接近） 
  → 最终解答 + 验证 → 关闭

构造为预训练文本:
  [任务]: 解决 pandas groupby 自定义聚合的 KeyError
  [尝试1]: ... [失败原因]: ...
  [尝试2]: ... [更接近]: ...
  [正确方案]: ... [验证]: 问题已解决

预期效果：让模型在预训练阶段就内化”执行-观察-修正”的循环思维模式，而不是等到 SFT 阶段才学。

2.2 Harness 记录的反事实路径

传统数据只保留”正确”的内容，但 Harness 自然记录了失败路径。这些失败轨迹对预训练同样有价值。

反事实预训练数据的构建方式：

数据类型	来源	格式
修复前后的代码对	Git commit diff	`[坏代码] → [错误类型] → [好代码]`
推理错误及纠正	数学竞赛错误解析	`[错误推理链] → [找到错误] → [正确推理]`
工具调用失败恢复	Agent 执行日志	`[调用] → [报错] → [调整参数] → [成功]`
编辑历史	Wikipedia revision	`[草稿1] → [修改理由] → [改进版本]`

直觉上说：让模型见过足够多的”坏→好”转变，它就学会了评判自身输出质量并进行修正的元认知能力。

2.3 Harness 作为数据质量评估工具

这是一个更间接但非常实用的方向：用 Harness（运行 Agent）来评估预训练数据质量，替代昂贵的人工标注。

当前数据质量评估的痛点：

规则过滤只能捕捉表面特征（长度、标点、语言等）
训练分类器需要大量人工标注
LLM-as-Judge 成本高，且质量上限取决于评委模型

基于 Harness 的质量评估方案：

候选预训练文档
      ↓
  设计验证任务（根据文档类型自动生成）
      ↓
  运行 Agent 完成任务
      ↓
  执行结果评分（有/无外部 Harness 提示下的差异）
      ↓
  质量分数 = Agent 能从文档中提取并正确应用知识的能力

举例说明：

一篇讲”Python 装饰器”的教程，质量评估标准不再是”可读性评分”，而是：给模型这篇文档，它是否能正确实现一个复杂装饰器场景？
一篇讲”HTTP 状态码”的文档，质量高低不在于文笔，而在于：读完后 Agent 调用 API 的成功率是否提升？

这种评估方式的本质是：从”文本好看”到”对 Agent 有用”的质量观转变。

2.4 预训练数据的”Harness 友好性”改造

这是最激进也最有价值的方向：主动改造预训练数据，使其对 Harness 更友好。

具体策略：

策略1：结构化标注注入 在原始文本上叠加结构化标注，使文本从”叙述性”变为”过程化”：

原始文本:
  "要解决内存泄漏，首先用 Valgrind 检查，然后分析报告..."

增强版本:
  [目标]: 诊断 C++ 程序内存泄漏
  [工具]: Valgrind
  [步骤1]: valgrind --leak-check=full ./program → [预期输出格式: ...]
  [分析]: 关注 "definitely lost" 字段
  [步骤2]: 定位到源码行 → [修复模式: ...]
  [验证]: 重新运行 Valgrind，确认 "0 bytes in 0 blocks"

策略2：API/工具文档的轨迹化 传统 API 文档只有”参数说明 + 示例”，改造为包含”调用场景 + 错误处理 + 完整工作流”的轨迹化文档：

[原版]: requests.get(url, params=None, **kwargs) → Response
[轨迹化版]:
  场景: 爬取带分页的数据
  Step1: 检查 API 是否有速率限制 → 添加 sleep(1)
  Step2: 处理 429 响应 → 指数退避
  Step3: 验证响应完整性 → 检查 status_code + json()
  常见陷阱: SSL 验证失败 → verify=False (开发环境) / 安装证书 (生产)

策略3：问题导向的知识重构 将知识型文档重构为”问题-决策-后果”格式，直接对齐 Agent 的认知模式：

原始: 数据库索引的介绍文章
重构:
  [问题]: 查询 orders 表速度慢（10M 行，按 user_id + date 筛选）
  [选项A]: 单列索引 user_id → 优点... 缺点: 日期范围扫描慢
  [选项B]: 复合索引 (user_id, date) → 优点... 注意事项: 列顺序很重要
  [决策依据]: 查询模式中 user_id 选择性更高 → 选 B
  [验证]: EXPLAIN ANALYZE 对比前后执行计划

三、对中训练（Continual Pre-training）数据构建的启发

中训练处于预训练和 SFT 之间，是让通用模型获得特定领域深度能力的关键阶段。Harness 视角在这里给出了最直接、最可操作的方案。

3.1 中训练数据的核心目标重定义

传统中训练数据构建的目标是：让模型在特定领域知识上更”博学”——堆入更多领域文档、教材、论文。

Harness 视角重新定义这个目标为：让模型在特定领域的 Harness 中执行任务的能力更强——不只是”知道”，而是”能做”。

两者的数据要求差异巨大：

目标	数据需求	典型来源
博学（Know）	高质量领域文本	论文、教材、文档
能做（Do）	任务完成轨迹	Harness 执行记录、交互日志
两者兼顾	知识 + 执行经验的交织	Harness 驱动的场景化数据

3.2 Harness 驱动的中训练数据生产流水线

以下是一个完整的、基于 Harness 思想的中训练数据生产方案：

┌────────────────────────────────────────────────────────┐
│            Harness 驱动的中训练数据生产流水线               │
└────────────────────────────────────────────────────────┘

Phase 1: Harness 构建
─────────────────────
  1. 定义目标领域（如：代码工程 / 金融分析 / 科学研究）
  2. 构建该领域的 Harness：
     • Memory: 领域知识库 + 历史执行经验
     • Tools: 领域专用工具集（代码执行器/数据库/API）
     • Evaluation: 领域任务的成功判断标准
     • Observability: 完整的执行过程追踪

Phase 2: 任务执行与轨迹捕获
─────────────────────────────
  1. 设计任务集（从真实用户需求采样，或从 Skill Graph 反推）
  2. 让当前最强模型在 Harness 中执行任务
  3. 记录完整执行轨迹：
     • 目标理解过程
     • 工具调用序列（包括参数构造思路）
     • 中间结果 + 观察
     • 错误发生 + 诊断 + 修复
     • 最终输出 + 验证
  4. 记录 Harness 的反馈信号（成功/失败/部分成功）

Phase 3: 轨迹质量过滤与增强
─────────────────────────────
  1. 按任务成功率过滤（保留完全成功 + 有价值的部分成功）
  2. 按执行效率过滤（去除冗余步骤过多的轨迹）
  3. 增强失败轨迹（加入专家注释"为什么失败"+"正确应是"）
  4. 构造对比对（好轨迹 vs 坏轨迹），用于后续偏好学习

Phase 4: 中训练语料构造
─────────────────────────
  1. 轨迹 → 中训练文本（按特定格式序列化）
  2. 混合策略：
     • 40-50% 领域知识文档（传统语料）
     • 30-40% Harness 捕获的执行轨迹
     • 10-20% 失败轨迹 + 诊断分析
  3. 课程编排：从简单任务轨迹到复杂任务轨迹渐进呈现

Phase 5: 训练 → 部署 → 轨迹质量提升（飞轮）
──────────────────────────────────────────────
  训练后模型部署回 Harness
  → 产出更高质量的轨迹（因为模型更强了）
  → 新轨迹再次作为训练数据
  → 飞轮转动

3.3 轨迹数据的结构化格式设计

中训练数据的格式设计至关重要，需要兼顾”语言模型友好”和”执行过程完整”：

格式A：思考-动作-观察（TAO 格式）

<task>在 PostgreSQL 中优化一个慢查询（执行时间 8s → 目标 < 200ms）</task>

<think>先看 EXPLAIN ANALYZE 输出，找到瓶颈在哪</think>
<action>EXPLAIN ANALYZE SELECT * FROM orders WHERE user_id = 12345 AND date > '2025-01-01'</action>
<observation>Seq Scan on orders (cost=0.00..89432.00 rows=1024) actual time=0.043..7823.421</observation>

<think>发现做了全表顺序扫描，orders 表有 12M 行，没有使用索引。需要在 (user_id, date) 上建复合索引，注意 user_id 的选择性更高，应该放在前面。</think>
<action>CREATE INDEX CONCURRENTLY idx_orders_user_date ON orders(user_id, date DESC)</action>
<observation>CREATE INDEX 执行完毕，耗时 45s</observation>

<think>再次验证查询性能</think>
<action>EXPLAIN ANALYZE SELECT * FROM orders WHERE user_id = 12345 AND date > '2025-01-01'</action>
<observation>Index Scan using idx_orders_user_date (cost=0.56..87.23) actual time=0.032..0.187</observation>

<result>查询从 7.8s 降至 187ms，优化成功。关键决策：复合索引列顺序遵循"选择性高的列在前"原则，DATE 倒序排列以匹配查询的 > 语义。</result>

格式B：带失败恢复的轨迹（错误也是数据）

<task>用 Python 异步爬取 100 个 URL，处理速率限制</task>

<attempt n=1>
<code>asyncio.gather(*[fetch(url) for url in urls])</code>
<error>aiohttp.ClientResponseError: 429 Too Many Requests (第 23 个请求)</error>
<diagnosis>并发太高，触发了服务器速率限制，需要控制并发数</diagnosis>
</attempt>

<attempt n=2>
<think>使用 Semaphore 限制并发，设置 max_concurrent=5</think>
<code>sem = asyncio.Semaphore(5); await asyncio.gather(*[fetch_with_sem(url) for url in urls])</code>
<error>部分 URL 仍然 429，且整体耗时 120s，效率太低</error>
<diagnosis>固定并发数不够灵活，需要引入退避机制 + 速率自适应</diagnosis>
</attempt>

<attempt n=3>
<think>使用指数退避（exponential backoff）处理 429，并动态调整并发</think>
<code>... tenacity.retry(wait=wait_exponential(min=1, max=30)) ...</code>
<result>成功率 100%，耗时 28s，无 429 错误。关键经验：固定并发 + 退避优于一味降低并发。</result>
</attempt>

格式C：知识驱动的执行（将知识与应用绑定）

<background>
  向量数据库的 HNSW 索引原理：通过分层图结构实现 ANN 搜索，
  ef_construction 控制建索引时的候选集大小，m 控制每层节点连接数。
  权衡：ef_construction↑ = 召回率↑ + 建索引时间↑
</background>

<task>为 500万 embedding 构建 Milvus 索引，要求 P99 查询 < 50ms，召回率 > 95%</task>

<think>根据数据规模，HNSW 比 IVF 更适合。初始参数：m=16, ef_construction=200</think>
...

3.4 不同领域的 Harness 轨迹数据策略

领域	核心 Harness 组件	轨迹特征	数据难点
代码工程	代码执行器、测试框架、Linter	代码→测试→修复的完整循环	需要真实运行环境
数据分析	SQL 引擎、Python 数据栈、可视化	探索性分析的迭代过程	轨迹路径多、验证较难
科学研究	论文检索、实验模拟、数据分析	假设→实验→修正的科学循环	任务周期长，难以自动标注
系统运维	命令行工具、监控API、诊断工具	告警→诊断→修复的操作序列	生产环境数据敏感
金融分析	数据API、回测框架、风控系统	假设→验证→风险评估	数据版权和隐私问题

四、Harness 即数据集：具体实施路径

4.1 从零开始构建 Harness 数据飞轮

这是一个完整的落地路径，适合从零开始建设 Harness 驱动数据体系的团队：

第一步：Harness 建设（第 1-2 周）

选定目标领域和核心任务类型
搭建 Observability 基础设施（关键！没有观测就没有数据）
定义轨迹记录格式（什么需要记，粒度多细）
建立执行结果的自动评判标准

第二步：种子数据积累（第 3-6 周）

用当前最强模型 + Harness 执行 1000+ 真实任务
过滤出成功率 > 80% 的高质量轨迹
人工抽检 10%，验证轨迹质量
建立数据版本管理机制

第三步：首轮中训练（第 7-10 周）

混合轨迹数据（40%）+ 传统领域语料（60%）
训练模型，重点评估任务执行成功率（而非传统 benchmark）
关键指标：Harness 中的任务成功率 > 传统知识类 benchmark 分数

第四步：飞轮启动（第 11 周起）

用训练后的新模型替换 Harness 中的执行模型
新模型产出更高质量轨迹
数据质量和数量同步提升
每 4-6 周进行一次增量训练

飞轮核心指标追踪（每轮）:
  ✓ Harness 任务成功率（核心指标）
  ✓ 平均轨迹质量分（人工抽检）
  ✓ 每轮新增高质量轨迹数
  ✓ 模型在 Harness 外任务上的迁移效果

4.2 轨迹数据的质量分级体系

不是所有轨迹都值得用于训练，需要建立分级体系：

等级	标准	用途
Gold	完全成功 + 路径高效 + 有清晰的思考过程	中训练核心语料
Silver	最终成功 + 有合理的探索过程 + 错误被正确诊断	中训练补充语料 + SFT 数据
Bronze	部分成功或失败但有高质量诊断	失败分析语料 + 偏好学习负样本
Noise	随机游走 + 无意义循环 + 无法解释的成功	丢弃

Gold/Silver 轨迹用于学习”怎么做对”；Bronze 轨迹用于学习”为什么会错以及如何恢复”——两类都不可缺。

4.3 与传统数据构建方法的融合策略

Harness 驱动的数据并非要取代传统方法，而是补足其无法覆盖的维度：

数据类型          比例建议       能力贡献
─────────────────────────────────────────
高质量文本语料      30-40%       知识深度 / 语言质量
领域专业文档        15-20%       领域知识密度
Harness 执行轨迹   25-35%       任务执行能力 / 工具使用
失败轨迹+诊断       5-10%       错误恢复 / 自我修正
对比样本对         5-10%        判断力 / 偏好对齐
─────────────────────────────────────────
合计              100%

关键原则：这个比例不是固定的，应该根据目标模型的用途动态调整。偏向”知识助手”的模型多加文档；偏向”任务执行 Agent”的模型多加轨迹数据。

五、竞争优势的护城河分析

Schmid 强调”竞争优势在于轨迹”，这是一个值得深入分析的商业洞见。

5.1 为什么轨迹数据构成护城河？

可复制性分析：

资源	可复制性	理由
基础模型	高	可切换 GPT/Claude/Gemini
提示词	高	逆向工程相对容易
RAG 知识库	中	文档来源可参考，但整理成本高
Harness 执行轨迹	低	来自真实任务场景，积累需要时间和规模
领域 Harness 设计	中低	设计可参考，但调优需要大量实验