NeoHorse-1：把「路由系统」变成训练飞轮，4B 模型追平 9B 底座的路从这里开始

你有没有想过一个问题：一个线上跑着的大模型服务，每天处理几十万条请求，这些交互记录除了拿去复盘 badcase，还能干什么？

大多数团队的答案是"存着，以后再说"。但 NeoHorse-1 这篇论文给了一个更激进的回答——这些交互记录，加上路由系统顺手记下的"这个请求该派给强模型还是弱模型"的决策信号，其实就是一套现成的、带难度标注的、来自真实分布的训练语料。模型在线上服役的过程本身，就在为下一代模型生产教材。

你想想看，这不就是 RSI（Recursive Self-Improvement，递归自我改进）一直缺的那块拼图吗？RSI 喊了很多年，核心卡点从来不是一个哲学概念，而是一个具体的工程机制：系统怎么观察自己的能力边界，并把这种观察转成下一轮学习。NeoHorse-1 的回答是：别再造新机制了，线上那个路由线束（routing harness）里已经全有了。

核心摘要：NeoHorse-1 是一组 4B / 9B 的 agent-native 模型，走的是"agentic post-training + 路由线束"路线。系统把异构模型池 + 智能路由的每一轮交互（预测的能力需求、选中的服务档位、后续的完整对话）都记录下来，转成保留交错推理、工具调用和 harness 上下文的训练样本；路由分数被拿来组织三阶段课程学习和 routing-guided on-policy 蒸馏；评测反馈再反过来调整下一轮训练数据的配比，形成"评估—选择—更新"闭环。效果上，10 个基准的宏平均分，4B 从 58.94 提到 64.87，9B 从 65.60 提到 69.04，训练后的 4B 已经逼近 9B 底座的整体水平。我的判断：这不是底层算法突破，而是一次把"数据飞轮"工程化落地的系统整合，但它选的切入点（路由信号当免费难度标签）是真的聪明，值得做 agent 产品的人细读。

论文信息

  • 标题：NeoHorse-1: Towards Recursive Self-Improvement via Agentic Post-Training with Routing Harness
  • 作者：NeoHorse Team（Guoliang Cao、Guohao Dai、Tianyu Guo、Kai Han、Yunhe Wang、Yu Wang 等 38 人，按姓氏字母序，Yunhe Wang 和 Yu Wang 为通讯作者）
  • 机构：TokenRhythm Technologies 牵头，联合 Infinigence AI、清华大学、北京大学、香港中文大学、阿里巴巴集团等
  • 日期：2026 年 9 月 8 日（arXiv:2609.08183）
  • 链接：https://arxiv.org/abs/2609.08183 ｜ 模型：https://hf.co/collections/TokenRhythm/neohorse-1 ｜ 代码：https://github.com/TokenRhythm/NeoHorse

🎯 为什么需要这篇论文：RSI 缺的不是愿景，是机制

先交代下背景。RSI 这个词今年很热，大方向是让 AI 系统参与自己的改进过程——改行为、改脚手架、甚至自动化部分 AI 研究本身。这个愿景的吸引力是结构性的：一旦"模型改进"这件事本身被部分自动化，每一代模型都能参与生产下一代，训练就从"一锤子买卖"变成复利过程。

但愿景归愿景，落地需要一个具体机制回答两个问题：

  1. 系统从哪里观察到"自己哪里行、哪里不行"的证据？
  2. 这些证据怎么变成下一轮训练的具体动作？

Agent 是天然的载体——它写代码、查资料、操作软件时会留下决策、工具交互和任务结果的完整记录。但大多数工作（FireAct、AgentTuning、Agent-FLAN 这些）只把轨迹当静态监督数据用，用完就扔。NeoHorse-1 往前多走了一步：轨迹不只是教材，还是体检报告。路由系统每轮预测的"能力需求档位"是免费的难度估计，交互的最终结果是免费的能力探针。这两个信号合起来，恰好能回答上面两个问题。

说实话，我看到这里的第一反应是：这思路跟推荐系统里的"线上日志 + 偏差校正"挺像的——服务系统的决策日志自带倾向性，但处理得当就是金矿。论文把这个直觉在 LLM agent 场景里完整地工程化了一遍。

NeoHorse-1 总体闭环

图 1（论文 Figure 2）：整个 RSI 闭环。左侧是路由线束——多样化任务进来，Router 在异构模型池上调度；中间交互记录被组织成训练混合数据；右侧 agentic training 三件套（agentic supervision、routing curriculum、routing-guided OPD）产出 NeoHorse-1 模型；上方虚线是能力反馈，指导下一次训练数据配比；下方回流线是更新后的模型回到线束里继续服役，开启下一轮迭代。

🏗️ 数据侧：把路由日志炼成带标签的轨迹语料

这套系统的数据管线有几个设计我觉得值得拆开讲。

三层粒度组织。一条 trajectory 是 harness 执行的完整交互；一个 user turn 从用户请求开始到下一个用户请求（或任务终止）结束，是基本的序列化训练单元；相邻且共享局部目标的若干 user turn 组成 subscene，作为语义标注的单元。这个分层挺务实的——训练按 turn 切，语义理解按"一段在干同一件事"的片段切，比硬按轮次切合理。

质量控制分两道闸。第一道是规则化的结构校验：重建请求/响应/工具调用/观测的事件流，检查因果顺序、工具调用-结果配对闭合、终态明确。产出三档：完整、部分可恢复（只取因果闭合的子轨迹）、隔离。第二道是六维语义评估——目标达成、指令遵循、工具使用、证据一致性、错误恢复、终止，每维打 PASS / WARN / FAIL，且明确规定"证据缺失或 judge 调用中断绝不转成正面结论"。这个细节我喜欢，见过太多数据管线把 judge 超时 silently 当 pass 的。

Subscene 三视图标注是论文里比较新的一块。每个 subscene 沿三个轴打标签：Scene（用户在干什么、什么场景）、Goal（想达成什么、成功怎么判）、Outcome（可验证的实际结果）。关键洞察是把"流程跑完了"和"任务真做成了"分开记录——这两件事在 agent 场景里经常不一致，混在一起统计会严重高估能力。

Subscene 三视图标注

图 2（论文 Figure 3）：左侧一条轨迹被切成 4 个 user turn（q1 到 q4，各自带 LLM 调用），其中共享局部目标的相邻 turn 聚成 subscene；右侧是 Scene / Goal / Outcome 三视图的属性体系，比如 Scene 下的 Task（信息检索 / 分析诊断 / 软件工程）、Asking vs Doing，Goal 下的验收标准与跨轮关系（新目标 / 延续 / 修改），Outcome 下的可验证结果与目标是否真正满足。

路由信号是全文最值钱的零件。线束里的 router 在每个 user turn 级别估计能力需求，分 C0（低风险简单请求）到 C3（最强能力/可靠性）四档。系统为每轮同时保留三个字段：router 的原始预测、策略调整后的决策、实际服务的档位。这个"预测—动作—结果"三元组的分离记录，让难度估计（用于课程排序）和实际执行（可能受用户覆盖、服务可用性、部署策略污染）可以独立分析。

坦白讲，这个设计在工程上的考量比论文写得还细——论文明确说不拿"实际由哪个模型服务"当难度标签，因为实际路由会被各种线上因素污染，而是重新从请求和首个被监督的 assistant 响应之前的历史来估计需求。做过线上系统的人都知道这个区分有多重要。

🔧 方法侧：路由分数驱动的三件套

数据备好之后，训练侧是三个咬合的组件。

Agentic Supervision：以 user turn 为单位的监督

一个 user turn 里，assistant 可能"推理 → 调工具 → 拿结果 → 再推理 → 再回答"（interleaved thinking）。训练样本保留当前轮的推理、工具调用、可见回复作为监督目标（loss mask 置 1），历史轮只留可见回复和工具交互做上下文、历史轮的推理被省掉——这个上下文策略和 DeepSeek-V3.2、Qwen 系的 reasoning-context 约定一致。所有非 assistant 片段（系统指令、工具规格、用户消息、工具结果）都不算 loss。

User turn 监督构造

图 3（论文 Figure 4）：上方是录制的原始交互，下方是转换后的训练序列。历史 user turn 1 的 reasoning 被省略，只留 tool call / result / response 作为上下文（m = 0）；当前 user turn 2 的 reasoning + tool call 与 reasoning + response 两个 assistant 目标段获得预测损失（m = 1），用户请求和工具结果不算损失。因果注意力保证每个 assistant 回复只能看到之前的动作和工具结果。

SFT 目标就是标准的 masked token 级交叉熵，按监督 token 数归一化：

\[\mathcal{L}_{\mathrm{SFT}}(\theta;\mathcal{B})=-\frac{\sum_{i\in\mathcal{B}}\sum_{t=2}^{T_i} m_{i,t}\log p_\theta(x_{i,t}\mid x_{i,\lt t})}{\sum_{i\in\mathcal{B}}\sum_{t=2}^{T_i} m_{i,t}}\]

Routing-Guided Curriculum：把路由分数当难度排序器

课程学习不新鲜，新鲜的是难度信号从哪来。传统做法要显式难度标注或数据集相关启发式，贵且不可迁移。这里直接用 router 的预测：硬排序用分配的档位序号 \(k_i\)，软排序用分数加权的期望档位 \(s_i=\sum_k k\,\pi_{i,k}\)（软分数能区分同档位内的细粒度差异）。

训练分三个阶段，各约三分之一数据，逐步引入高分样本，同时刻意留一部分低分样本到后期——防止训练末尾被高难样本完全主导。三阶段共享同一个 masked SFT 目标，不重置优化器、不重启学习率。

路由课程安排

图 4（论文 Figure 5）：三阶段课程示意。Stage 1 以低分样本为主，Stage 2 覆盖更宽的分数区间，Stage 3 聚焦高分样本但保留浅色（低分）样本。颜色深浅表示路由分数分布。

Routing-Guided OPD：on-policy 蒸馏也按课程走

SFT 有个结构性短板：它学的是录制下来的 assistant 回复，而部署时模型是 condition 在自己生成的前缀上的——这就是经典的 exposure bias。On-policy distillation（OPD，Agarwal et al. ICLR 2024 的 GKD 一脉，最近 Thinking Machines 那篇爆款博客讲的也是这个）让学生自己生成，老师在学生实际到达的状态上给 token 级监督。

NeoHorse-1 的增量是把同一套路由课程复用到 OPD 的起始上下文调度上：用录制的"assistant 响应前一刻"的上下文当生成起点，按路由分数排三阶段，学生从这些起点 rollout，固定老师逐位置给 next-token 分布，优化 reverse KL：

\[\mathcal{L}_{\mathrm{OPD}}(\theta;\mathcal{R})=\frac{1}{\sum_{r\in\mathcal{R}} w_r}\sum_{r\in\mathcal{R}}\frac{w_r}{L_r}\sum_{t=1}^{L_r} D_{\mathrm{KL}}\!\left(\widetilde{P}_{\theta,r,t}\,\|\,\widetilde{Q}_{r,t}\right)\]

两个实现细节值得记：一是分布只保留 rollout 学生的 top-K 候选 token，其余概率质量合并成一个 bin，\(K+1\) 个桶上算 KL——这是控制存储和通信开销的实用 trick；二是 rollout 用的学生 checkpoint 随训练刷新，越到后面的上下文，老师监督的是越新的学生行为。

Routing-guided OPD

图 5（论文 Figure 6）：左侧按路由分数排序的上下文，按 stage 选择后让学生 rollout 生成响应前缀；右侧在每个生成位置，学生 \(\widetilde{P}\) 和固定老师 \(\widetilde{Q}\) 在同一组 top-K 候选 + 剩余质量桶上给出分布，算 reverse KL；只更新学生，虚线表示更新后的学生 checkpoint 用于后续 rollout。

闭环的最后一环：能力导向的数据分配

每轮迭代，当前 checkpoint 在一个与训练集严格去污染隔离的分层评测套件上跑，结果按属性、质量维度、结局状态、路由档位聚合出一份"能力缺陷画像"，下一轮训练混合数据就向弱区倾斜。验证成功的轨迹当正样本，有信息量的失败轨迹指出需要补量的区域。更新后的模型回到线束服役，产生的新轨迹暴露下一批能力缺口——评估、选择、更新的环就这么闭上了。

📊 实验：涨分是真的，但要看清涨在哪

评测覆盖 10 个基准：agentic 六项（BFCL v4、VitaBench、τ²-Bench、PinchBench、WorkBuddy Bench、QwenClawBench）、代码两项（HumanEval、LiveCodeBench v6）、指令遵循两项（IFEval、IFBench）。

4B 与 9B 赛道总览

图 6（论文 Figure 1）：六个 agentic 基准上 4B（上）和 9B（下）赛道的对比，橙色斜纹柱是 NeoHorse-1。能看到它在 PinchBench、WorkBuddy、QwenClaw 这类 harness 执行类任务上领先同赛道对手，VitaBench 上则落后于部分对手。

4B 赛道主表（论文 Table 1，节选关键列）：

模型 BFCL v4 τ²-Bench PinchBench WorkBuddy QwenClaw HumanEval LCB v6 IFEval 平均
Qwen3.5-4B（底座） 61.02 84.29 71.19 24.62 38.47 87.20 53.71 87.06 58.94
Spark-X2.5-4B 63.71 77.72 62.37 26.47 43.52 92.07 54.86 91.13 62.22
Agents-A1-4B 46.60 81.00 75.07 33.37 43.16 92.68 56.57 83.55 61.46
NeoHorse-1-4B 61.79 88.46 77.33 34.41 44.68 96.95 59.43 88.35 64.87

9B 赛道主表（论文 Table 2，节选）：

模型 BFCL v4 τ²-Bench PinchBench QwenClaw HumanEval 平均
Qwen3.5-9B（底座） 64.88 88.04 74.55 44.04 92.68 65.60
Gemma-4-12B-it 62.06 59.37 58.89 43.53 100.00 63.51
Muse-Glimmer-30B 53.74 76.64 71.35 46.11 98.17 67.86
NeoHorse-1-9B 67.43 90.82 82.25 48.73 98.17 69.04

几个值得停顿一秒的数字：

  • 4B 训练后相对底座平均涨 5.93 个点，而且在所有有对比的基准上全面超过 Qwen3.5-4B——不是单点刷出来的。涨幅集中在 harness 执行类和代码类。
  • 更有意思的是，4B 训练后平均分 64.87 已经很接近 9B 底座的 65.60，τ²-Bench 上 88.46 对 88.04 还反超了。训练确实能补偿一部分规模差距——这对部署成本敏感的场景是实打实的信号。
  • 9B 版本继续在多数基准上超过底座，但 IFEval 上还微跌了 0.37（89.09 vs 89.46）。论文自己承认指令遵循基本打平，收益集中在交互执行类。这种诚实我欣赏。

但我必须泼一盆冷水：这些 harness 类基准（QwenClawBench、PinchBench 用 OpenSquilla 做 agent harness）和数据采集侧的 harness 是同一套生态。训练数据来自路由线束，评测又在线束式的环境里跑，分布天然更匹配，涨分里有多少是"能力真提升"、有多少是"熟悉考试形式"，论文没有拆开验证。VitaBench 上 4B 版（32.00）反而输给 Spark-X2.5-4B（37.00）和 Agents-A1-4B（39.25）——恰好 VitaBench 是用官方框架评的、不是自家 harness 生态内的，这个对照挺耐人寻味。

轨迹分析：4B 和 9B 的差距到底差在哪

这部分是全文我最喜欢的定性分析。PinchBench 一个数据分析任务里，pandas 不可用，NeoHorse-1-4B 反复尝试装依赖、手写 CSV 解析、本地补丁，全失败，最后没产出报告；NeoHorse-1-9B 识别出原路被堵死后直接切换到标准库 csv + math，完成任务——而且模型请求数、执行时间、token 用量分别少了 70.8%、76.7%、83.6%。

规模的优势不在"做更多动作"，而在"识别出这条轨迹没前途、及时换策略"。这个观察跟我在 agent 项目里的体感完全一致：小模型最常见的死法不是不会，是死磕。

数据消融：harness 数据 vs 公开数据，差距 6.26 个点

同样从 Qwen3.5-4B 出发、同样的课程算法、同样的预算，一边用自家 routing-harness 轨迹，一边用公开的 Toucan 合成工具 agent 数据：

训练数据 LCB HumanEval IFBench BFCL τ²-Bench 平均
Toucan（公开） 49.14 87.80 56.33 54.77 73.54 64.32
Routing-harness 53.14 96.34 61.33 57.20 84.85 70.57
差值 +4.00 +8.54 +5.00 +2.43 +11.31 6.26 个点

五个基准全胜，τ²-Bench 上差 11.31 个点。真实交互轨迹的监督价值明显高于公开合成数据——这大概是全文对"为什么要建这套系统"最直接的辩护。当然，公平起见要说一句：Toucan 是通用工具调用数据，τ²-Bench 是多轮用户-agent-工具交互，分布差异本来就大，这个对比更像是"领域匹配的真实数据优于不匹配的合成数据"，而非"harness 数据普遍更优"。

数据规模扩展

图 7（论文 Figure 7）：严格嵌套子集上的数据 scaling 曲线。横轴是唯一监督 token 数（百万，对数轴），纵轴是五基准平均分，从底座的 69.31 稳步升到最大规模的 71.45。曲线还在涨、没看到饱和。

附录案例：26 次点击测出一个 DOM 属性错误

附录的五子棋案例很能说明"训练闭合执行环"是什么意思。任务就一个 prompt："用 HTML 写个简单五子棋"。然后用相同的 26 次点击序列回放两个模型生成的页面。Qwen3.5-9B 的版本页面渲染正常，但点击处理器去读 DOM cell 上根本不存在的 cell.clientX / cell.clientY 属性，26 次点击全部产生无效棋盘索引——棋盘始终空白，回合指示器卡在黑方。NeoHorse-1-9B 的版本 26 次点击零运行时异常，黑白各 13 子正确落盘，回合正常轮换。

五子棋案例对比

图 8（论文 Figure 8 左）：Qwen3.5-9B 生成的五子棋页面经过 26 次点击后棋盘依然空白——界面渲染出来了，但交互逻辑是坏的。

五子棋案例对比 NeoHorse

图 9（论文 Figure 8 右）：NeoHorse-1-9B 的版本，同样的 26 次点击后 26 颗棋子全部正确落盘，输入处理、落子渲染、回合切换连成了一条可用的交互链。"渲染出一个像游戏的页面"和"产出一个能玩的游戏"是两回事，这正是 harness 执行类训练要解决的问题。

🤔 我的判断：值钱的不是模型，是那个"免费信号"的用法

亮点：

  1. 路由信号的一鱼三吃是全文最聪明的设计——同一份预测既当课程学习的难度排序器，又当 OPD 的上下文调度器，还当数据分配的缺陷定位器。线上系统本来就要做路由，这些信号是零边际成本的。相比专门标难度或训 reward model，这个杠杆用得漂亮。
  2. 预测-动作-结果分离记录。不把实际服务的模型当难度标签，这个细节体现了对线上系统偏差的清醒认识。
  3. harness 数据 vs Toucan 的 6.26 个点差距，给"真实交互轨迹更值钱"提供了同算法同预算下的直接证据。

问题：

  1. RSI 叙事大于实证。论文自己承认目前只验证了"评估—选择—更新"环的单次通过，增益能否跨代累积完全没测。标题挂着 recursive self-improvement，实质是"一轮带反馈的 post-training"。从一轮到真递归，中间隔着分布漂移、能力饱和、数据同质化一堆硬问题。
  2. 评测生态自洽性存疑。训练数据和部分评测共用同一 harness 生态，而生态外的 VitaBench 上 4B 版反而落后。缺乏第三方 harness 下的泛化验证。
  3. 成本信息缺失。OPD 需要老师在线给学生 rollout 打分，6 维语义评估要 judge 模型逐轨迹检查——整条管线的计算开销只字未提。对想复现的团队，这是最关键的工程参数。
  4. 摘要里说"eleven benchmarks"，正文和表格都是十个——小瑕疵，但说明版本间没对齐。

对工程的启发：如果你在跑一个多模型 agent 服务，这篇论文最值得抄的作业不是课程学习也不是 OPD，而是从今天开始在路由日志里把"预测档位、实际服务档位、任务结局"三个字段分开存。这是未来一切数据飞轮的地基，而且成本几乎为零。课程排序和 on-policy 蒸馏都可以后补，历史日志丢了就再也回不来。

RSI 会不会从这篇论文开始"从设计走向实践"？我觉得还早——但它至少指出了一个被很多人忽略的事实：自我改进需要的观察机制，可能早就躺在你线上系统的日志里了。

觉得有启发的话，欢迎点赞、在看、转发。跟进最新AI前沿，关注我