Agent 执行轨迹怎么变成训练数据？一次后训练闭环拆解
一个排期测试暴露的问题
技术报告里记录了一个典型失败：一个 4B 基础模型在项目排期任务中找到了工作目录里的文件，却漏读了一封包含最新依赖约束的邮件。它基于过时信息生成计划，并把文件写到了错误位置。
这个错误很说明问题。模型不是「不会写代码」，也不是「读不懂中文」，它缺的是「做事的过程感」：什么时候该先扩大信息搜索范围、工具返回什么算异常、发现自己基于过时假设之后该怎么回头。这些能力在教科书式的指令—响应对里几乎不会出现，因为它不是知识，是执行策略。
9 月 8 日，一个由高校与企业联合推出的开源模型家族 NeoHorse-1（含 4B、9B 两个版本）尝试把这类经验系统化地沉淀进模型参数里，并把整条路径写成技术报告公开。它的价值不在于榜单分数，而在于把「Agent 执行轨迹 → 训练样本 → 模型更新 → 回到执行环境」这条链路拆得足够细，可以照着复现。下面按「是什么 / 怎么做 / 取舍 / 谁适合」讲。
数据不是问答对，而是执行轨迹
报告的核心判断是：Agent 后训练数据不能由静态的指令—响应对充分表示。真正有信息量的是把用户请求、模型推理、工具动作、环境观察、任务结果串起来的执行轨迹。
这套轨迹由部署时的路由 Harness（负责在异构模型池里为每个请求挑模型的调度层）产生。主语料规模在 10⁵–10⁶ 条轨迹量级，另外混入公开的指令、推理、工具使用、代码、偏好数据来拓宽能力覆盖。
轨迹被组织成三个相互连接的粒度，这是整个设计里最容易被忽略、但最影响训练效果的一步：
- trajectory（轨迹）：一次完整交互，保留用户请求、模型响应、工具调用、环境观察、纠错尝试和最终结果。
- user turn（用户轮）：从一个用户请求开始，到下一个用户请求或任务终止为止，是基本序列化训练单元。
- subscene（子场景）：把共享同一局部目标的相邻轮次聚在一起，是语义刻画单元。
在每条 user turn 内部，当前的请求及其穿插的推理、工具调用、观察被完整保留，形成「推理—行动—反馈」链；更早的轮次只保留可见回复和工具交互作为上下文，早期轮次的推理内容会被丢掉。这一点值得注意：它既控制了上下文膨胀，也避免模型把「上一轮的想法」当成必须延续的承诺。每条记录都保留指向父轨迹与所属 subscene 的链接，让质量、语义、路由、结果信号能在各自合适的粒度上对齐。
从轨迹到权重：七步流水线
第 1 步：采集。 Harness 为每个用户轮记录三样东西——预测的能力需求（capability demand）、实际选中的服务层级、以及随后的完整交互。前者是后训练最有价值的副产品。
第 2 步：准入与清洗。 报告列出的关口包括：精确与近似去重、评测集去污染、结构校验、六维语义评估，以及 subscene 级的 Scene / Goal / Outcome 标注。这一步决定了后面的课程能不能排得动——没有语义标签，就没有难度分档的依据。
第 3 步：序列化。 按上面的粒度规则把原始日志转成训练样本，保留交织的推理、工具调用与 Harness 上下文。
第 4 步：课程排序。 用路由系统预测的能力需求给样本估难度，组织成三阶段课程，先低难度样本，再逐步过渡到复杂轨迹。
第 5 步：课程化监督微调（SFT），按同一进阶顺序训练。
第 6 步：路由引导的在线策略蒸馏（On-Policy Distillation）。 教师模型针对学生实际生成的响应给出监督，而不是让学生去拟合教师预先写好的轨迹，且进阶顺序与 SFT 阶段保持一致。
第 7 步：能力导向的数据配比回流。 把评测反馈转成下一次训练的混合比例：这次学出来的能力，决定下一次该学什么。至此形成「评测—选择—更新」的闭环，更新后的模型重新回到 Harness 里执行任务。
一个示意性的记录结构
报告没有给出可直接照抄的代码，但按它的描述，轨迹记录的 schema 大致应该长这样：
{
"trajectory_id": "t-9f31",
"subscene_id": "s-2207",
"turn_index": 3,
"predicted_capability_demand": 0.72, // 路由给出的难度信号，用于课程分档
"selected_tier": "large", // 实际服务层级，不作为难度标签使用
"request": "把依赖升级到邮件里说的版本，然后重跑排期",
"steps": [
{"type": "reasoning", "text": "先确认邮件中的约束版本"},
{"type": "tool_call", "name": "read_mail", "args": {"q": "dependency"}},
{"type": "observation", "content": "锁定 xxx>=4.2"},
{"type": "tool_call", "name": "write_file", "args": {"path": "plan.md"}},
{"type": "observation", "content": "OK"}
],
"outcome": "success",
"labels": {"scene": "project-scheduling", "goal": "upgrade-and-rerun"}
}
课程分档的逻辑可以抽象成这样（示意）：
# 用路由预测的能力需求排序，而不是用「最终服务的模型是谁」当难度
def bucket(demand):
if demand < 0.4: return 1 # 单步、反馈明确
if demand < 0.7: return 2 # 多步工具链、需重试
return 3 # 长程状态维护、需失败恢复
samples.sort(key=lambda x: (bucket(x.predicted_capability_demand), -x.turn_index))
这里有个关键设计选择：为什么不直接用「这条请求最后是强模型还是弱模型答的」当难度标签？ 报告里写得很清楚——实际路由结果还可能反映用户手动覆盖、服务可用性、部署策略等与任务难度无关的因素。用服务层级当标签，会把策略噪声当成难度信号喂给课程学习。
与已有方案的取舍
相比通用指令/偏好数据：轨迹数据保留了推理—行动—反馈链，能训练「何时搜索、工具返回什么算异常、走错了怎么回头」这类过程能力。代价是采集成本高、依赖真实部署环境，且必须做严格的质量准入，否则噪声轨迹会教出坏习惯。公开数据仍然需要——报告把它作为拓宽覆盖面的一方，而不是主力。
相比 off-policy 蒸馏：让学生拟合教师写好的完整轨迹更省事、更稳定；但学生自己的分布一旦偏离教师轨迹，错误会累积。在线策略蒸馏把教师的监督对准学生自己生成的内容，纠的是学生真实偏差，代价是需要在训练循环里持续推理学生模型，算力开销更大，也更依赖底层训练基础设施的弹性调度能力。
4B 还是 9B：在覆盖 Harness Agent、工具使用、代码与指令遵循的 11 项基准上，后训练把宏平均从 58.94 提到 64.87（4B），从 65.60 提到 69.04（9B）。报告特别指出，收益主要集中在流程清晰、反馈可观察、结果可验证的任务上；而 9B 版本在复杂状态维护、长程调试和失败恢复上仍保持明显优势。也就是说，4B 后训练能显著缩小与 9B 底座的总体差距，但换不来长程任务上的稳定性。此外两个尺寸原生上下文都是 262,144 tokens，官方说明底模能力可扩展至约 100 万 tokens，权重为 BF16 safetensors。
相对「直接上强化学习」：这条路线里没有显式的可验证奖励，它用评测反馈调节的是数据配比，而非每一步策略梯度。好处是训练更稳、更容易和现有 SFT/蒸馏管线拼接；代价是闭环的收敛速度取决于评测信号的质量与粒度。
适合谁用
- Agent 系统研发者：如果你已经有生产环境里的执行日志，这套「轨迹 → 清洗 → 语义标注 → 课程 → 蒸馏」的流程可以直接迁移到自己的数据上，未必需要从头训模型。
- 模型后训练工程师：报告里最容易复用的两个点，一是用路由/调度信号免费获得难度估计，二是把评测反馈接成数据配比而非损失函数。
- 想做本地小模型的团队：4B 尺寸加 262K 上下文，在「流程清晰、可验证」的任务上性价比最高。
不太适合的场景也要说清：如果你的任务几乎没有可观察反馈、失败也无法判定，那么轨迹里就没有可学的纠错信号，这套方法退化成有监督微调；如果你需要的是长程状态维护和复杂调试，4B 的后训练收益会明显缩水，仍然要靠更大的底座。
复现时最容易被忽略的三件事
- 难度标签的来源。用任务本身的能力需求估计，而不是用最终服务的模型身份——后者混杂了太多与难度无关的部署因素。
- 跨轮推理的取舍。保留当前轮的完整推理链，但丢掉历史轮的推理，只留可见回复和工具交互。这直接影响样本质量和上下文成本。
- 蒸馏与课程必须同序。SFT 的三阶段进阶如果在蒸馏阶段被打乱，学生在后半段的分布会重新失控。
一句话总结：把「做事的过程」当成一等公民的数据，比把「题和答案」堆得更多更重要。
参考链接：
- NeoHorse-1: Towards Recursive Self-Improvement via Agentic Post-Training with Routing Harness — https://huggingface.co/papers/2609.08183
- 开源仓库与技术报告 — https://github.com/TokenRhythm/NeoHorse
- 基元律动发布模型 NeoHorse，探索 Harness 驱动的 RSI 路径 — https://www.leiphone.com/category/industrynews/E7j0Qq5zBynzWv64.html
浙公网安备 33010602011771号