（来源：科技行者）
2026年初，有个说法在AI圈子里悄悄流传：如果一个AI系统足够聪明，它是不是应该能自己发现自己的短板，然后自己想办法补上？
这听起来像科幻小说，但NeoHorse团队做了一件挺实在的事，他们没有去写一个能自我改写代码的超级智能体，而是盯上了一个平时不太起眼的东西，路由系统。
这个选择本身就很有意思。
想象一下你是一个客服中心的调度员，每天要把打进来的电话分给不同水平的客服。简单的问题分给新人，复杂的投诉转给资深员工，特别棘手的升级给主管。做久了你会发现一件事，你手里握着的调度记录，其实是一份关于"这个团队到底能干什么、不能干什么"的完整档案。谁擅长处理哪类问题，谁在什么场景下会掉链子，全都写在这些分配记录里。
大模型的世界里，这个调度员就是路由系统。当用户发来一个请求，路由系统要判断这个任务有多难，然后决定用哪个模型去处理。NeoHorse团队的洞察是：这套路由系统每天产生的记录，本身就是一座关于模型能力的金矿，而这座金矿此前基本被浪费了。
递归自我提升*：Recursive Self-Improvement，简称RSI，指AI系统逐渐参与到改进自身的过程中，从优化单次回答，到调整自己的执行环境，再到从自己产生的经验里学习，是一种越往后自动化程度越高的改进路径。
这篇论文的核心问题，就是怎么把路由系统这座金矿真正利用起来，让模型通过"被使用"这件事本身变得更强。
哪里卡住了
先说清楚一件事，训练一个会用工具、会执行任务的智能体模型，传统做法是收集一堆"指令-回答"的问答对，喂给模型学。
但这种做法有个天生的缺陷。
一个真实的智能体任务从来不是一问一答那么简单。它可能是这样的：用户提出需求，模型思考该怎么做，调用一个工具查资料，工具返回结果，模型根据结果再思考，可能再调用一次工具，最后才给出答案。中间还可能出错，模型发现走错了路，得往回退，换个方法重试。
这整个过程叫做一条轨迹，如果你只截取最后的问答对来训练，等于把一部电影剪成了一张海报，中间所有的决策逻辑、试错过程、恢复能力全部丢了。
Trajectory（轨迹）*：模型和环境之间一次完整交互的全过程记录，包括用户请求、模型的思考过程、工具调用、工具返回的结果，以及最终的处理结果。
之前的一些研究，比如FireAct和AgentTuning，已经开始用完整轨迹来训练模型，这是个进步。但这些轨迹大多是靠一个固定的老师模型生成的，学生模型学的时候只能照猫画虎，模仿老师当时怎么做，而不是根据自己实际会犯的错误去调整。这就好比让一个刚学开车的人只看教练的示范视频学车，而不是真正坐在方向盘后面，教练根据他自己的操作习惯现场纠正。前者学得再认真，遇到真实路况还是会手忙脚乱，因为视频里的情况和他自己开车时遇到的情况压根不是一回事。
NeoHorse团队面对的问题就是：怎么让训练数据不只是"老师做过的事"，而是能跟上"学生自己实际会遇到什么"？答案就藏在路由系统天天产生的海量交互记录里。
从路由记录里挖出训练金矿
NeoHorse的做法是建立一个异构模型池，配合智能路由，在真实任务场景里跑起来。
异构模型池*：由多个能力档次不同的模型组成的模型集合，路由系统根据任务难度从中挑选合适的模型去执行。
每次有用户请求进来，路由系统要做三件事：预测这个任务需要多强的能力，决定派哪个模型去处理，记录最后处理的结果如何。这三件事连起来，就形成了一条"预测-行动-结果"的完整链路。这条链路里藏着两种宝贵的信息，一种是任务本身的执行经验，另一种是关于模型能力边界的证据，也就是模型在哪些地方游刃有余，在哪些地方力不从心。
这里团队做了一个精细的数据组织设计，把每次交互切分成三个层级。
最大的单位叫轨迹，指一次完整的任务执行过程。中间层叫用户轮次，从一次用户提问开始，到下一次提问或任务结束为止，这是训练数据的基本单元。最小的单位叫子场景，把几个围绕同一个小目标的用户轮次归并到一起，方便打语义标签。
这种三层结构不是随便设计的。
打个比方，你去医院看病，挂号、问诊、检查、开药、复诊，这是一整套完整流程，对应"轨迹"。其中"医生问你哪里不舒服然后给出初步判断"是一个单独的互动回合，对应"用户轮次"。而"检查发现问题后调整治疗方案"这一连串相关的回合，共同服务于"确诊并治好这个病"这个小目标，对应"子场景"。如果病历只按整个就诊过程记录，你没法单独分析某次问诊质量；如果只按每句对话记录，你又看不出这几次对话其实是在解决同一个问题。三层结构让你既能看清全局，也能精确定位到某个环节出了什么问题。
数据质量控制也做得很细。所有轨迹先经过结构校验，检查请求和回复是否完整、工具调用有没有闭环、有没有孤立的观察结果找不到对应的调用。这一步靠的是可复现的规则，不依赖模型打分，因为这些结构性问题是客观可判定的。
通过结构校验的轨迹，接着进入六维语义评估，从目标达成、指令遵循、工具使用、证据一致性、错误恢复、终止行为六个维度打分，每个维度给出PASS、WARN、FAIL或者未评估四种状态之一。
六维语义评估*：对一条轨迹从目标达成度、是否遵守指令、工具使用是否得当、证据是否前后一致、出错后能否恢复、任务是否正确终止这六个方面分别打分，而不是压缩成一个笼统的总分。
为什么不直接给一个综合分数就完了？因为一个笼统的分数会掩盖问题所在。如果一条轨迹总分是及格线，你根本不知道它是哪里出了问题，是目标没达成，还是工具用错了，还是最后没能正确收尾。分开打分之后，训练团队才能对症下药，知道该给模型补哪方面的课。
除了质量打分，团队还给每条数据打上了场景、目标、结果三个维度的标签，描述用户到底在做什么、期望达成什么效果、最后结果是否验证成功。这套标签体系连起来，就是一张关于"用户想干什么、模型做得怎么样"的地图，为后续的数据分配提供依据。
路由分数，怎么变成学习节奏
有了这些精细标注的数据，接下来的问题是：怎么用？
团队想到的办法是把路由系统对任务难度的预测，变成训练的节奏器。
具体来说，路由系统会把每个用户请求分到四个服务档位里，从简单到复杂依次是C0、C1、C2、C3。
服务档位*：C0应对低风险的简单请求，C1是默认的通用档位，C2支持多步推理和执行，C3提供最高能力或可靠性保障，必要时甚至会组合多个模型协同处理。
这个档位信息原本是给线上服务用的，用来决定该派哪个模型去处理请求。但团队发现，这其实也是一个天然的难度标签，可以拿来给训练数据排队。
不过这里有个坑要避开。实际被派去执行任务的模型，未必真实反映了这个任务的难度，因为用户可能手动指定了模型，服务器可能正忙没有空闲资源，运营策略也可能临时调整了派单逻辑。如果直接拿"实际用了哪个模型"当难度标签，等于把噪音也当成了信号。
团队的解决办法是重新估算，只根据请求本身和当前对话历史，独立算出一个难度分数，不管当时实际派给了哪个模型。这个分数分为硬排序和软排序两种算法，硬排序直接用档位编号，软排序则用四个档位的加权平均，能区分出档位相同但难度略有差异的样本。
有了这个分数，团队设计了一个三阶段课程学习方案。
课程学习*：按照由易到难的顺序给模型喂训练数据，而不是把所有难度混在一起随机打乱，让模型先打好基础再挑战难题。
训练分三个阶段，每个阶段大约占三分之一的数据量，随着阶段推进，高难度样本的比例逐渐增加，但每个阶段都会保留一部分低难度样本，不会让高难度样本完全占满后期训练。
这个设计的用意值得琢磨。
想象你在健身房请了个私教，第一周私教如果直接让你举最大重量的杠铃，你大概率会受伤，而且动作变形，学到的都是错误姿势。合理的做法是先从轻重量练熟动作，再逐渐加码。但如果训练全程只在做轻重量，你又永远突破不了自己的极限。私教真正的做法是循序渐进地加重，同时时不时穿插一些基础动作巩固，防止你只会举重却忘了怎么正确发力。三阶段课程学习就是这个逻辑，既要循序渐进往难处走，又不能把简单样本彻底抛弃，防止训练末期模型只见过高难度样本，反而在简单任务上变得生疏。
监督微调，学的是什么
具体到训练细节，团队用的是标准的监督微调思路，但对哪些内容该算进损失函数做了精心设计。
监督微调*：SFT，Supervised Fine-Tuning，用人工或者高质量标注的数据继续训练一个已经预训练好的模型，让它学会特定任务的做法。
每条训练样本包含当前这一轮用户请求，以及模型针对这轮请求产生的思考过程、工具调用、可见回复。历史轮次里，只保留可见的回复内容和工具交互结果作为背景信息，但历史轮次的思考过程会被去掉。
为什么要把历史的思考过程去掉？
这里的逻辑是，思考过程是模型内部的推理链条，属于"过程"，而不是"结果"。保留历史轮次里可见的回复和工具交互，是因为模型确实需要知道之前发生了什么事，才能在当前轮次做出合理判断。但历史轮次的思考过程如果也全部保留，会让训练序列变得极其冗长，而且当前轮次的学习目标是让模型学会针对这一轮的问题该怎么思考，而不是重复背诵历史上的思考轨迹。
训练时，只有当前轮次里模型该说的话，也就是思考内容、工具调用、可见回复这些部分，会被计入损失函数，其他所有内容包括系统指令、工具规格说明、用户消息、工具返回结果，全部不计入损失，只作为上下文背景存在。
这就像老师批改作文，只给学生自己写的那部分打分，题目要求、参考材料这些不算学生的产出，不该被打分。
学生自己生成的答案，才是最真实的考验
监督微调有个绕不开的短板，它学的是"记录下来的正确答案"，但模型部署上线之后，面对的是自己一步步生成的内容，而不是照抄一份现成的标准答案。
这个差距被称为分布偏移。训练时模型总是看到"正确的前一步"，但实际使用时模型自己生成的前一步可能就已经错了，后面的推理建立在错误的地基上，越走越偏。
团队引入了在线策略蒸馏来解决这个问题。
在线策略蒸馏*：On-Policy Distillation，简称OPD，让学生模型自己生成回答，教师模型则针对学生生成的这些内容提供逐个词元的概率分布指导，而不是简单地把教师原本准备好的答案硬塞给学生。
这个方法和监督微调最本质的区别在于，监督微调教的是"标准答案该怎么写"，在线策略蒸馏教的是"你刚才这样写，接下来该怎么修正"。
打个比方，监督微调像是照着字帖临摹，字帖上写的什么你就照着描什么。在线策略蒸馏更像是书法老师站在你身后，看着你自己下笔写的每一笔，实时告诉你这一笔该往哪个方向收。如果只靠临摹字帖，你永远学不会自己独立创作时该怎么控制笔锋，因为字帖上的每一笔都是提前设计好的，不是你真实书写时会遇到的状态。而站在身后实时纠正的老师，才能真正针对你自己写字的习惯给出有效指导。
团队同样把路由分数用在了这里，用同样的三阶段方式安排"起始情境"的呈现顺序，学生模型从这些情境出发自己生成回答，固定住的教师模型则给出逐词元的指导信号，用反向KL散度作为优化目标，只更新学生模型的参数。
为了让计算更高效，团队采用了一个简化技巧，只保留概率最高的K个候选词元，把剩下所有的概率质量归并成一个额外的桶，这样既保留了关键信息，又大幅压缩了计算量。
评估反馈，反过来决定下一轮训练什么
整套系统最有意思的地方在于闭环设计。
每一轮训练完成后，当前模型会在一个和训练数据完全隔离的评估集上接受测试，测试结果按照场景标签、质量维度、结果状态、路由档位聚合起来，形成一份"模型能力缺陷画像"。
这份画像不是拿来打分排名用的，而是直接指导下一轮训练该往哪里倾斜数据比例。表现薄弱的领域会被增加覆盖，表现良好的领域适当保留但不再过度堆积。
评估-筛选-更新循环*：模型评估的结果反过来影响下一批训练数据的构成，形成一个持续运转的闭环，模型学到的东西决定了它接下来会从什么样的数据里继续学习。
这个设计打破了"训练数据一次性准备好、训练完就结束"的传统模式。传统模式类似于一次性备考，考前把所有可能考的知识点复习一遍，考完就结束了。而这套闭环设计更像是一个长期跟踪辅导的家教，每次模拟考之后，家教会根据这次考试暴露出的具体薄弱环节，调整下一阶段的学习计划，专门加强薄弱点，而不是每次都把整本教材从头到尾重新过一遍。如果没有这个反馈环节，团队就只能凭经验猜测模型哪里学得不够，训练资源很容易浪费在模型已经掌握得很好的地方。
数字说话，效果到底怎么样
说了这么多方法设计，最终还是要看效果。
团队在十个基准测试上评估了两个规模的模型，一个是40亿参数级别，一个是90亿参数级别，覆盖了基于执行环境的智能体任务、工具调用、代码生成、指令遵循四大类能力。
40亿参数模型经过训练后，宏观平均分从58.94提升到64.87。90亿参数模型从65.60提升到69.04。
这两个数字背后藏着一个更值得关注的现象：训练后的40亿参数模型，在多个基准上已经追平甚至超过了未经训练的90亿参数基础模型。这意味着后训练方法能在一定程度上弥补模型规模带来的差距，一个更小的模型经过恰当的训练，可以打出接近大模型的战斗力。
具体到几个代表性的智能体测试基准，训练后的40亿参数模型在PinchBench上从71.19分提升到77.33分，在τ?-Bench上从84.29分提升到88.46分，在WorkBuddy Bench上从24.62分大幅跃升到34.41分。
90亿参数模型的提升同样可观，在PinchBench上从74.55分提升到82.25分，在τ?-Bench上从88.04分提升到90.82分，在VitaBench上从31.25分提升到42.25分。
不过团队也很坦诚地指出，规模效应在训练之后依然存在，而且不是均匀分布的。
在需要持续调试、从失败中恢复、维持长序列状态追踪的任务上，90亿参数模型的优势依然明显。而在相对静态的指令遵循类任务上，两个规模模型之间的差距反而比较小。
团队用具体的执行轨迹案例说明了这个差异。在一个WorkBuddy的代码修复任务里，40亿参数模型只尝试了一次实现就停下了，没有建立起有效的测试和修复循环，留下了一个线程执行语义上的错误。而90亿参数模型完整走完了编辑、测试、检查、修复的循环，反复根据执行反馈调整，直到通过验证。
另一个更有说服力的案例出现在PinchBench的数据分析任务中。当发现pandas库不可用时，40亿参数模型反复尝试安装依赖、手动解析CSV、修补脚本，这些尝试始终无法解决根本问题，还引入了新的错误，最终没能完成报告。90亿参数模型则果断放弃了原有思路，转而使用Python标准库里的csv模块和数学函数库，顺利完成了分析和报告。相比40亿参数模型的这次尝试，90亿参数模型在请求次数、执行时间、词元消耗三项指标上分别减少了约70.8%、76.7%、83.6%。
这个对比揭示了一个重要事实，更大模型的优势不是"做得更多"，而是"更懂得什么时候该换思路"。这种判断力，恰恰是执行智能体任务里最难训练出来的能力。
数据来源也做了对照实验。团队把自家路由系统产生的轨迹数据和一份公开的合成工具智能体数据集Toucan放在完全相同的训练条件下对比，结果路由系统数据训练出的模型在五个基准上的平均分是70.57，公开数据集训练出的模型是64.32，差距达到6.26分，其中HumanEval提升8.54分，τ?-Bench提升11.31分。这说明真实交互场景里产生的数据，比人工合成的数据更贴近部署时模型会遇到的实际情况，训练出来的能力也更能迁移到真实使用场景。
团队还做了一组数据规模的扩展实验，从同一批质量排序过的轨迹池里，逐步扩大训练数据量，保持模型初始化、优化设置、训练轮数等条件不变，只改变数据量。结果显示，五个基准的平均分随着数据量的对数增长稳步从69.31提升到71.45，没有出现明显的性能瓶颈。这说明在当前的数据规模范围内，继续投入高质量的智能体交互数据，依然能换来实实在在的性能提升。
写在后面
读完这篇论文，最让我觉得有意思的一点，不是任何一个具体的技术细节，而是这个团队选择切入点的方式。
大部分谈论"AI自我提升"的讨论，容易滑向科幻式的宏大叙事，聊模型能不能自己改代码、自己设计新架构。但NeoHorse团队做的事情朴素得多，也现实得多，他们只是重新审视了一个已经存在、每天都在运转、大家却没太当回事的系统，路由系统，然后发现这个系统本身就自带一套观察自己能力边界的机制。
这背后其实藏着一个更普遍的道理：很多时候，你想找的答案不需要凭空发明，它可能就藏在你现有系统日常运转产生的副产品里，只是没人把它当回事去挖掘。路由系统本来的职责是决定"这次该用哪个模型"，但顺带记录下来的"为什么这么决定、结果怎么样"，恰恰是训练下一代模型最缺的那种带着真实反馈的经验数据。
另一个值得拿出来说的细节，是团队处理"哪个模型实际被使用"这个信号时的谨慎态度。他们明确指出，不能把执行时实际用了哪个模型当成难度标签，因为这里面混杂了用户手动指定、服务资源紧张、运营策略调整这些噪音。这种对数据源头保持警惕的态度，在很多论文里其实是缺失的，大家往往默认能拿到的信号就是干净的信号。这个细节提醒我，做数据工程的时候，第一步永远该问：这个信号到底测量的是我想测量的东西，还是别的什么东西的混合物？
论文的结尾也很克制，团队自己承认这只是"评估-筛选-更新"这个循环跑了一遍，还没经过多轮迭代的验证，至于这种自我提升能不能在模型能力持续演化的过程中长期维持下去，仍然是个悬而未决的问题。这种不夸大的态度，反倒让人更愿意相信这个方向是认真的。
如果这个循环真的能持续跑下去，一代代模型不断被使用、被观察、被针对性地补短板，那会是什么样子？会不会有一天，我们回头看今天这种"人工设计训练数据、人工决定训练重点"的方式，就像现在回看手工特征工程的年代一样，觉得那是一个必然会被自动化取代的过渡阶段？
Q&A
Q1：NeoHorse-1是什么？
A：NeoHorse-1是一个探索递归自我提升的智能体模型系列，核心思路是利用部署中的路由系统记录的交互数据来指导模型的后续训练，形成一个评估反馈驱动训练数据分配的闭环。
Q2：NeoHorse-1的训练效果具体提升了多少？
A：在十个基准测试上，40亿参数模型的宏观平均分从58.94提升到64.87，90亿参数模型从65.60提升到69.04，训练后的40亿参数模型在多个测试上已经追平甚至超过未训练的90亿参数基础模型。
Q3：路由系统在NeoHorse-1的训练中起什么作用？
A：路由系统给每次任务预测所需能力档位，这个信号被用来给训练数据排课程顺序，从低难度逐步过渡到高难度，同时评估反馈还会指导下一轮训练该往哪些薄弱领域倾斜数据。
