轨迹分裂法：将长程 Agent 执行轨迹拆解为中训练数据的系统方法

触发动机

这篇 proposal 的核心 idea 来自读 KLong（arXiv:2602.17547）时的一个”反向思考”。KLong 论文解决的是 SFT 阶段如何用长轨迹训练的问题——它发现整条长轨迹直接做 SFT 效果很差，必须把轨迹拆成带前缀上下文的重叠子片段。这个发现本身已经很有价值，但我在想：如果 trajectory-splitting 在 SFT 阶段有效，那它在中训练阶段是否同样有效？ 中训练用的是 next-token prediction，对数据形态的要求跟 SFT 不同，但核心矛盾是一样的——长轨迹中信号稀疏，模型很难学到”在第 50 步该怎么做”这类深层行为。再结合站内 harness-is-the-dataset 的 Harness 反转思路，一个完整的想法成形了：不是事后拆轨迹，而是在设计轨迹采集环境时就内建”可分裂”的结构。

战略判断：为什么现在做

行业趋势

2026 年 Q1，Agent 能力竞争的核心战场已经从”单步工具调用”转移到”长程任务执行”。证据链：

1. KLong（arXiv:2602.17547，2026.02）：首次系统证明了 trajectory-splitting SFT + 渐进式 RL 可以让 106B 模型在超长程任务上达到 SOTA。核心发现——直接用完整长轨迹做 SFT 效果很差，但把轨迹拆成带前缀上下文的重叠子片段后效果大幅提升。
2. daVinci-Agency（arXiv:2602.02619，2026.02）：提出 data-efficient 的长程 Agent 训练方法，核心也是解决”长轨迹训练信号稀疏”问题。
3. CodeClash（2026.02）：将代码训练扩展到长程、对抗式竞技编程任务。
4. NL2Repo-Bench（2025.12）：建立了从自然语言到完整仓库级代码生成的长程评测。

趋势判断：长程任务能力是 2026 下半年模型差异化的核心维度。谁能大规模生产高质量的长程执行轨迹数据，谁就在这条赛道上领先。

现有方案的缺口

站内已有的 Agent 训练数据提案（工具调用失败模式、元认知、多 Agent 协作等）都聚焦于单步或少步决策的数据构建。长程轨迹的系统化数据工程方法是一个空白。

KLong 论文虽然给出了 trajectory-splitting 的训练方法，但它没有回答一个更基础的问题：长轨迹数据本身从哪来？怎么大规模生产？怎么控制质量？ 这正是本提案要解决的。

重要性评估

• 能力缺口大：FrontierScience Research 任务 GPT-5.2 仅 25%，长程科研执行是最大的未解决能力
• 数据壁垒高：长程轨迹无法靠单点合成获得，需要完整的执行环境和验证体系
• 方法论可迁移：本提案的轨迹分裂原理适用于代码/科研/搜索等所有长程场景

---

核心洞察

KLong 的 trajectory-splitting 揭示了一个重要的数据工程原理：

长轨迹的训练价值不在于”完整性”，而在于”局部决策的上下文完备性”。

完整的 200 步轨迹对 next-token prediction 来说，前面的步骤在梯度更新时几乎不贡献有效信号（梯度消失 + attention 衰减）。但如果把它拆成 20 个带前缀上下文的 10 步子轨迹，每个子轨迹都包含：

• 前缀：前面步骤的压缩摘要（让模型知道”我在做什么”）
• 当前片段：需要学习的 10 步决策
• 重叠区：与前一个片段有 2-3 步重叠（保证状态连续性）

这样每个训练样本都有密集的有效梯度信号，同时通过前缀保留了长程上下文。

本提案的核心贡献：把这个训练侧的原理，推广为一套数据生产侧的方法论——不是”有了轨迹怎么拆”，而是”怎么设计轨迹采集系统，使得采集出来的轨迹天然适合分裂”。

---

方法论

Phase 1：轨迹采集——设计”可分裂”的执行环境

传统的 Agent 评测环境（SWE-bench、OSWorld 等）记录的是最终结果，中间过程往往丢失或格式混乱。我们需要一个原生面向轨迹采集的执行环境。

关键设计：

1. 显式检查点机制：每 N 步自动保存完整的环境快照（文件系统状态、打开的文件、Shell 历史、变量状态）。这些检查点就是天然的分裂边界。
2. 子目标标注：执行前要求 Agent 输出子目标列表，每完成一个子目标做一次状态标记。子目标边界 = 最佳分裂点。
3. 决策日志结构化：每一步强制记录 {observation, thought, action, result, error_if_any}，不允许黑箱操作。

数据源：

来源	预估规模	长度特点
SWE-bench 风格 PR 修复	10K+ 轨迹	30-80 步
论文复现任务（Papers with Code）	5K+ 轨迹	50-200 步
Kaggle 竞赛全流程	2K+ 轨迹	100-500 步
多文档调研报告生成	3K+ 轨迹	80-300 步

Phase 2：轨迹分裂——四种分裂策略

策略 A：子目标边界分裂（首选）

基于 Agent 自己标注的子目标边界，每个子目标对应一个子轨迹。优点是语义完整，缺点是粒度不均匀。

策略 B：固定窗口 + 重叠分裂（KLong 方式）

固定 K 步一个窗口，相邻窗口重叠 M 步。优点是粒度统一，缺点是可能切断语义。

策略 C：错误恢复边界分裂

以”Agent 犯错→发现错误→纠正”的完整恢复周期为一个子轨迹。这类数据对训练 Agent 的鲁棒性特别有价值。

策略 D：混合分裂

A 为主，在子目标内部如果超过 K 步则用 B 二次分裂，遇到错误恢复用 C 提取。

Phase 3：前缀压缩——关键的数据工程问题

子轨迹单独拿出来是无意义的，必须带前缀。但前缀不能太长（否则回到完整轨迹的老问题）。

三层前缀压缩：

1. 任务描述（固定）：原始任务的完整描述
2. 全局进度（动态生成）：用 LLM 把前面所有已完成步骤压缩为 200-500 token 的结构化摘要——“已完成 X/Y 子目标，当前状态：…”
3. 局部上下文（原始）：前一个子轨迹的最后 3-5 步（原封不动保留）

关键质量指标：前缀质量用”信息可恢复性”衡量——给一个模型看前缀 + 当前子轨迹，它能否正确预测前一个子轨迹的关键动作？如果不能，说明前缀压缩丢失了关键信息。

Phase 4：质量控制——三级门控

1. 执行正确性（必须通过）：原始完整轨迹必须成功完成任务（有测试验证）
2. 子轨迹独立可理解性（采样检查）：随机抽取 10% 的子轨迹，让另一个 LLM 仅凭前缀 + 子轨迹猜测”这段在做什么”，准确率需 >80%
3. 重叠一致性（自动检查）：相邻子轨迹的重叠区必须完全一致（防止分裂引入不一致）

---

规模估算

阶段	输入	输出
原始长轨迹采集	20K 个任务 × 平均 100 步	~2M 步 / ~200M tokens
分裂后子轨迹	平均每条轨迹分裂为 8 段	~160K 子轨迹 / ~400M tokens（含前缀）
质量过滤后	70% 通过率	~112K 高质量子轨迹 / ~280M tokens

280M tokens 对中训练来说是一个有意义的规模（约占典型中训练语料的 5-10%），且每一条都是密集的”有上下文的多步决策”训练信号。

---

与已有工作的关系

已有 proposal	关系	具体连接
Harness is the Dataset	方法论上游	Harness 跑出轨迹，本提案解决”拿到轨迹后怎么处理”
工具调用失败模式	互补	失败恢复子轨迹是本方案策略 C 的特例
论文代码复现	数据源之一	复现轨迹是本方案最有价值的长轨迹来源
形式化验证推理链	正交	那个聚焦推理正确性，本方案聚焦长程执行能力

---

落地路径

1. Week 1-2：搭建带检查点的轨迹采集环境（基于 Docker + E2B sandbox），在 SWE-bench 上采集 1000 条完整轨迹
2. Week 3：实现四种分裂策略 + 前缀压缩器，对比分裂质量
3. Week 4：扩展到论文复现和 Kaggle 任务，形成 10K+ 规模数据集
4. Week 5-6：消融实验——分裂数据 vs 完整轨迹 vs 仅 SFT 数据，在长程任务上评测效果