研究提案 已修订

递归式自进化轨迹：从模型优化自身工作框架的过程中提取中训练数据

MiniMax M2.7 展示了模型递归优化自身 Harness 的能力——分析失败→修改框架→评估→保留或回滚，100+ 轮自主迭代。SkillClaw 则证明多用户交互轨迹可驱动技能集体演化。本提案提出系统化提取这类'元轨迹'作为中训练数据，让模型在权重层面理解'如何改进自己的工作流程'。

自进化 元轨迹 中训练 Agent Harness MiniMax SkillClaw 数据合成

触发动机

三条信息线在本周交汇。

第一条：MiniMax M2.7 于 4 月 12 日正式开源。技术细节中最值得注意的不是 SWE-Pro 56.22% 的分数，而是其”递归式框架自优化”能力——M2.7 在内部版本上自主运行了超过 100 轮的闭环迭代：分析失败轨迹 → 规划变更 → 修改 Harness 代码 → 运行评估 → 比较结果 → 决定保留或回滚。在这个过程中，模型自主发现了有效的采样参数组合、设计了针对性的工作流规则（如”修复 bug 后自动在其他文件中搜索相同模式”）、为 Agent 循环添加了循环检测。最终在内部评估集上实现了 30% 的性能提升。

第二条：SkillClaw（arXiv:2604.08377，4 月 9 日）提出了一种集体技能演化框架。核心思路是：多用户部署的 Agent 产生的结构化交互轨迹，经由一个 Agentic Evolver 分析后，自动精炼或创建新技能。WildClawBench 实验中，创意合成任务 6 天内相对增益达 88.41%。关键洞察是：分散的用户交互经验可以被聚合为有结构化证据支撑的技能更新。

第三条：站内 harness-is-the-dataset 研究的核心论点——“Harness 捕获的轨迹就是训练数据”。但此前的思路都是”Agent 在 Harness 中执行任务的轨迹”，没有人想过”Agent 改进 Harness 本身的轨迹”。

三者交叉的洞察是：模型优化自身工作框架时产生的”元轨迹”——不是在做任务，而是在改进做任务的方式——是一种全新的、目前没有人系统化构建的训练数据类型。 这种数据包含的不是领域知识，而是”如何系统性地改进工作流程”的元认知能力。

战略判断：为什么”元轨迹”是一个值得做的方向

行业信号

  1. 自进化从 buzzword 变成了工程现实。M2.7 不是论文中的概念验证——它在生产环境中承担了 RL 团队 30%-50% 的日常工作，且递归自优化已跑了 100+ 轮。MLE Bench Lite 上 66.6% 的奖牌率证明这不是玩具实验。

  2. SkillClaw 和 DeerFlow 的 RFC #1865 表明集体技能演化正在成为热点。SkillClaw 的 Agentic Evolver 机制——接收累积结构化证据，自主推理后做出 Refine/Create/Skip 决策——本质上是一个”元级别”的 Agent 行为。

  3. 当前训练数据的层次缺口。站内已有大量”任务执行轨迹”的 proposal（轨迹分裂法、CoderForge 轨迹、ASTRA 反转等），但全部都是”模型做任务”的轨迹。没有一篇关于”模型改进自己做任务方式”的轨迹。 这是一个层次上的缺口——从 object-level（做任务）到 meta-level（改进做任务的方法）。

能力缺口分析

当前大模型的一个核心弱点是：它们可以在给定框架内执行任务，但很难自主改进框架本身。具体表现为：

  • 给定一个 Agent 脚手架和任务，模型可以执行 → 但让模型优化脚手架以提升成功率，当前模型普遍做不好
  • 给定一组工具和 prompt，模型可以调用 → 但让模型重新设计 prompt 策略或工具编排来提升整体表现，能力很弱
  • M2.7 的 100+ 轮自优化之所以令人印象深刻，正是因为这种能力在当前模型中极为稀缺

这个能力缺口直接指向数据缺口：训练语料中几乎不存在”系统性地分析工作流失败模式、提出改进假设、实施修改、验证效果”的内容。 互联网上的代码仓库有大量的”代码修改”（commit diff），但没有”分析自己的工作方式并改进”的结构化过程记录。

核心思路

从 Agent 自优化闭环中系统化提取”元轨迹”——即模型在分析自身表现、诊断瓶颈、修改工作策略并验证改进效果时产生的完整因果链——将其格式化为中训练语料，让模型在 next-token prediction 阶段就见过大量”如何改进工作流程”的范例。

与”任务执行轨迹”的关键区别：任务轨迹的推理对象是外部世界（代码库、数据库、工具），元轨迹的推理对象是自身的工作方式。

方法论

数据源：三个可操作的元轨迹来源

来源 1：Harness 自优化轨迹（仿 M2.7）

在 sandbox 环境中，让 Agent 在一组 benchmark 任务上反复迭代，允许其修改自身的 system prompt、工具编排策略、错误恢复逻辑：

输入：
- 一组 benchmark 任务（如 SWE-bench verified 的子集）
- 一个初始 Agent Harness（system prompt + 工具定义 + 错误处理逻辑）
- 执行结果日志（成功/失败/错误类型）

元轨迹生成循环：
1. Agent 执行一批任务，收集成功率和失败模式
2. Agent 分析失败模式，生成诊断报告
3. Agent 提出 Harness 修改方案（修改 prompt 的哪部分？添加什么工具编排规则？）
4. 实施修改
5. 在相同任务上重新评估
6. 比较前后差异，决定保留或回滚
7. 生成一条完整的元轨迹记录

每一轮产出一条元轨迹，格式如下：

## 迭代 N：[简要目标]

### 当前表现分析
- 总成功率：X%
- 主要失败模式：
  - 模式 A（占 Y%）：[具体描述]
  - 模式 B（占 Z%）：[具体描述]

### 根因诊断
模式 A 的根因是 [分析过程]...
模式 B 的根因是 [分析过程]...

### 修改方案
变更 1：[具体修改内容及理由]
变更 2：[具体修改内容及理由]
预期效果：[量化预期]

### 验证结果
- 新成功率：X'%
- 模式 A 出现次数：从 N 降到 M
- 模式 B 出现次数：[变化]
- 意外发现：[如有]

### 决策
[保留/回滚] 理由：[分析]

来源 2：多 Agent 集体技能演化轨迹（仿 SkillClaw）

部署多个 Agent 实例执行同类任务，用 Agentic Evolver 聚合多实例的经验并做出技能更新决策。提取 Evolver 的决策过程作为元轨迹：

## 技能演化报告：[技能名称]

### 证据池
- Agent-1 的执行记录：[摘要]，结果：成功/失败
- Agent-2 的执行记录：[摘要]，结果：成功/失败
- Agent-3 的执行记录：[摘要]，结果：成功/失败
[共 N 条]

### 模式分析
反复出现的失败模式：[描述]
跨 Agent 一致的成功策略：[描述]
环境特异性因素：[描述]

### 演化决策
操作类型：[Refine / Create / Skip]
具体变更：[技能定义的修改内容]
验证结果：[非退化性检验]
理由链：[完整的推理过程]

来源 3：CI/CD 反馈驱动的代码策略优化轨迹

这个来源利用站内已有的 CI 失败诊断 proposal（ci-failure-diagnosis-training-data-proposal）的输出，但上升一个层次：不是单次修复，而是多次修复后的策略总结和编码模式改进：

## 策略迭代：[项目/模块名称]

### 最近 N 次 CI 失败统计
- 类型分布：[类型A: X次, 类型B: Y次, ...]
- 平均修复时间：[数据]

### 模式归纳
反复出现的同类问题：[描述]
根因归类：[编码风格? 依赖管理? 测试覆盖?]

### 策略调整
- 新增 lint 规则：[具体内容]
- 修改 CI 配置：[具体内容]  
- 调整代码审查清单：[具体内容]

### 效果验证
调整后 N 次构建的失败率变化：[数据]

处理管线

元轨迹采集（三个来源并行）
    │
    ▼
格式标准化
    │ → 统一结构：诊断→假设→修改→验证→决策
    │ → 保留完整因果链，不压缩中间推理
    │
    ▼
质量验证
    │ → 硬过滤：是否包含量化的前后对比？
    │ → 硬过滤：修改是否真的被执行？（非空谈式建议）
    │ → 硬过滤：验证结果是否与预期一致？（防止 hallucination）
    │ → 软评分：诊断的深度（表面描述 vs 根因分析）
    │ → 软评分：修改方案的创造性（套路 vs 洞察）
    │
    ▼
去重与多样性控制
    │ → 元轨迹的去重不是按文本相似度，而是按"改进策略类型"
    │ → 确保覆盖：prompt 优化、工具编排、错误恢复、资源分配等不同类型
    │
    ▼
中训练语料打包
    │ → 目标格式：连续文本（适合 next-token prediction）
    │ → 迭代间用结构化分隔符连接，保持时序关系
    │
    ▼
输出：中训练语料集

质量验证的核心标准

元轨迹不同于普通语料，需要特殊的质量标准：

  1. 因果完整性：每条轨迹必须包含完整的”观察→诊断→假设→行动→验证”链，缺任何一环都丢弃
  2. 量化锚定：必须有可量化的前后对比数据（成功率、错误次数、执行时间等），纯定性描述的不合格
  3. 非平凡性：排除”什么都没改”或”改了但没效果”的轨迹——我们需要的是确实带来改进的元推理过程
  4. 可验证性：修改后的验证步骤必须是实际执行的（而非推测的），这是与”空谈式改进建议”的关键区别

规模与可行性估算

来源 1（Harness 自优化）

  • 每个 benchmark 子集（50 个任务）可跑 30-50 轮自优化迭代
  • 每轮产出 1 条元轨迹，约 1,500-3,000 token
  • 10 个不同 benchmark 子集 × 40 轮 × 2,000 token = ~80 万 token
  • 可通过变化初始 Harness 配置和任务集来增加多样性
  • 推测：扩展到 50 个不同的初始配置和任务组合，可产出 ~400 万 token

来源 2（集体技能演化）

  • 每个技能类别（参考 SkillClaw 的 6 个功能类别）× 8 个模拟用户 × 6 天
  • 每天每技能约产出 2-3 条 Evolver 决策轨迹
  • 6 类别 × 6 天 × 2.5 条 × 2,000 token = ~18 万 token
  • 扩展到 20 个技能类别 + 更长运行周期：~200 万 token

来源 3（CI 策略迭代）

  • GitHub 上有大量公开的 CI 日志和 commit 历史，但需要重构为策略迭代格式
  • 估计每个成熟开源项目（>1,000 commits）可提取 5-10 条策略迭代轨迹
  • 1,000 个项目 × 7 条 × 3,000 token = ~2,100 万 token

总体规模

  • PoC 阶段（2 周）：来源 1 + 来源 2 的小规模实验，~100 万 token
  • 全量生产（2-3 个月）：三个来源合计 ~2,500 万 token
  • 作为中训练混合数据的一部分，这个规模足以产生可测量的效果（推测，参考 Nemotron-CC 中合成数据占比约 30%，但元轨迹的信息密度更高）

资源需求

  • 来源 1 和 2 需要 Agent 执行环境（sandbox）+ 推理算力
  • 来源 3 主要是数据处理（GitHub 数据挖掘 + LLM 重构）
  • 总估算：8 张 A100 × 2 周（PoC），或等价的 API 调用预算

与已有工作的关系

互补关系：

  • 轨迹分裂法（站内）：拆解长程任务执行轨迹，是 object-level 的。本 proposal 在 meta-level，两者可以在训练中混合使用
  • harness-is-the-dataset（站内）：提出 Harness 轨迹作为训练数据的理念。本 proposal 是其自然延伸——不只是”在 Harness 中做任务的轨迹”，还有”改进 Harness 本身的轨迹”
  • Agent 元认知（站内）：关注”知道自己什么时候不知道”，侧重于不确定性感知。本 proposal 关注”知道自己的工作方式哪里需要改进并实际改进”，是元认知的行动延伸

差异化优势：

  • 与 M2.7 的区别：M2.7 展示了自进化的可行性，但没有公开其元轨迹数据。本 proposal 的目标是构建可复现的元轨迹数据生产管线
  • 与 SkillClaw 的区别：SkillClaw 关注运行时技能更新（推理时优化），本 proposal 关注将这类过程转化为训练数据（权重层面优化）
  • 数据独特性：互联网上不存在”模型系统性地优化自身工作流程”的自然语料。这是一类纯合成的、别人没有的数据类型

落地路径

Phase 1：PoC（2 周）

  1. 选择 SWE-bench verified 的 50 个中等难度任务
  2. 用现有 Agent（如 CodeBuddy）作为基础，搭建 Harness 自优化循环
  3. 跑 30 轮自优化，收集元轨迹
  4. 人工评估元轨迹质量：因果完整性、诊断深度、改进真实性
  5. 产出：质量评估报告 + ~10 万 token 的种子数据集

Phase 2：规模化（4 周）

  1. 扩展到三个来源并行采集
  2. 搭建自动化质量验证管线
  3. 在 1B 规模模型上做消融实验：加入元轨迹 vs 不加入，测量 Agent 自优化能力的变化
  4. 产出：~500 万 token 的元轨迹数据集 + 消融实验报告

Phase 3：集成（2 周）

  1. 将验证有效的元轨迹数据集成到中训练配方中
  2. 与现有的任务执行轨迹、代码数据、工具使用数据按比例混合
  3. 设计评估指标：不只是 benchmark 分数，还要测量”给定 Harness 和失败日志，模型能否提出有效改进”的能力