王云鹤创业后交出首个模型
1 小时前 / 阅读约15分钟
来源:36kr
基元律动发布首个Agent-Native模型NeoHorse,由无问芯穹提供基础设施支撑,清华、北大参与研究。该模型重点提升Agent工作能力,通过筛选Harness执行信号构建数据体系,采用路由引导课程学习等方法进行后训练。

王云鹤创业后,首次交卷了大模型成果。

量子位获悉,华为诺亚方舟实验室前主任、盘古大模型负责人王云鹤创办的基元律动,发布首个Agent-Native模型NeoHorse。

该模型由无问芯穹提供底层基础设施支撑与Infra优化技术能力,清华大学、北京大学团队参与算法和训练方法研究,共同探索提升Agent后训练的数据利用效率和训练效果。

NeoHorse-1包含4B和9B两个版本,重点面向Agent工作过程中需要的一组能力,包括调用工具、读取环境反馈、发现错误、调整路径,并最终完成任务。

在覆盖Harness Agent、工具使用、代码和指令遵循等10项评测中,经过Agentic Post-Training后,4B模型综合表现已经达到/略超9B基础模型。

一家一直强调多模型协作的公司,为什么又开始自己训练模型?基元律动准备加入基础模型牌桌了吗?

从NeoHorse给出的答案看,方向并没有发生这样的变化。

这款模型更像是基元律动过去积累的多模型执行经验,第一次进入了模型参数。

帮Agent挑模型的公司,也开始训练模型

一直以来,分数往往成为比较模型的主要依据。

但当模型开始被放进Agent系统、承担完整任务后,单一分数的解释力就会下降。

一项任务中,模型不仅要给出一个看似合理的答案,还要在执行过程中持续读取环境反馈,处理错误,并根据实际进展调整后续路径;不同环节对模型能力的要求也不一样。

由此,基元律动团队形成了一个判断。

模型不归一将是AI产业长期存在的一种结构。

模型越多、分工越细,价格和能力差异越明显,就越需要一套系统回答几个问题——

这一步应该用哪个模型?哪些环节可以交给成本更低的模型?什么时候需要升级到推理和执行能力更强的模型?一条执行路径受阻后,应该换谁接手?多个模型能否并行给出方案,再把结果聚合起来?

王云鹤团队把这一层系统称为Routing Harness(旗下相关开源项目OpenSquilla已经接入多款模型,通过统一接口,在Agent运行过程中进行细粒度路由、模型切换和多模型协作)。

同样,基于这一思路,基元律动似乎没有太强的理由自己训练模型。市场上已经有足够丰富的模型供给,按需调用看起来更加灵活。

随着调度系统持续运行,另一类资产开始沉淀,如“什么任务需要什么能力”“模型在哪一步容易失败”“什么样的修复路径有效”“怎样的结果能够通过环境验证”。

这些信息一方面可以提升路由判断,另一方面也开始具备训练价值。

这有点像一家连接大量品牌与消费者的平台。交易过程中积累的需求、评价和使用反馈,可以帮助商品找到更合适的用户,也可以进一步反馈给产品研发。

平台服务市场的过程由此成为下一轮产品改进的数据来源。

NeoHorse承担的就是把基元律动过去在Harness中积累的一部分执行经验,转化成模型能力。

把多模型走过的路,练进Agent-Native模型

NeoHorse的数据来源值得一提。

它的核心语料是将Routing Harness产生的Agent执行信号与公开数据结合,构建面向Agent后训练的数据体系。

Agent在Harness里完成一次任务,会留下完整的执行记录。

  1. 输入任务→ 路由器判断需要什么能力
  2. → 选择某个模型
  3. → 模型进行推理和工具调用
  4. → 环境返回结果
  5. → 模型继续执行或发生错误
  6. → 系统切换模型或调整路径
  7. → 任务最终完成或失败

常见问答数据往往集中在“问题”和“答案”两端。

Routing Harness的数据中还包含另外几层信息:任务需要什么能力,系统做出了什么执行决策,以及环境最终给出了什么反馈。

比如,路由器最初判断某项任务只需要普通模型,但执行过程中连续失败,随后升级到能力更强的模型,任务才被完成。

这条轨迹包含的信息远多于一次失败。

系统可以知道,最初的能力判断可能偏低,模型在哪一步出现问题,更强模型采用了怎样的策略,哪条执行路径最终通过环境验证,以及完成任务额外消耗了多少Token和时间。

更重要的一点在于,基元律动观察到的并非某个模型对自身能力的判断,而是多个模型面对相似任务时留下的横向表现。

其中既有成功路径,也有中途失败、随后被其他模型接手的执行记录。

从训练角度看,失败轨迹甚至可能提供更多信息。

最终答案能够告诉模型一条可行路径,失败与修复过程则补充了另外两类知识,哪里容易出错,以及出错以后如何调整。

“学习的除了多个模型给出的结果,还有多个模型在任务环境中实际走过的路径”,这也是NeoHorse比较有辨识度的一点。

Agent工作日志怎么变成模型能力?

把所有日志全部投入训练,并不会自然得到一个更强的Agent模型。

Agent轨迹通常很长,其中混有系统提示、用户请求、工具参数、执行结果、重复尝试、错误信息以及大量中间输出。

有些步骤具有训练价值,有些更接近噪声。还有一些轨迹流程完整,结果本身却并不正确。

基元律动首先需要解决“哪些数据值得模型学习”这个问题

根据技术报告,每条轨迹都会经过结构检查,确认请求、模型回复、工具调用和环境结果之间能够对应。

随后,系统会从六个维度评估执行质量,包括是否完成用户目标、是否遵守指令、工具使用是否合理、结论是否有证据支撑、发生错误后能否恢复,以及模型是否在合适的时机终止任务。

这里还涉及Agent训练里容易被混在一起的问题

任务结束并不等于用户目标已经满足——模型输出“任务已经完成”只能说明执行流程停止了,无法证明交付物符合用户要求。

因此,完成状态、目标满足度、环境证据和用户反馈,需要作为不同信号分别记录。

数据完成筛选后,路由信号开始发挥另一项作用。

路由器会估计任务所需能力,并形成不同能力档位的信号。NeoHorse在训练过程中据此安排样本顺序,先学习能力需求较低的任务,再逐渐增加更加复杂的执行轨迹,同时保留基础任务覆盖。

这一方法被称为Routing-Guided Curriculum,也就是路由引导的课程学习。

通俗一点理解,路由信号在线上决定任务交给谁,在训练阶段还可以告诉模型,哪些任务更适合先学,哪些适合后学。

除了常规监督微调,NeoHorse还使用了On-Policy Distillation

可以理解为先让学生按照自己的方式解题,再由老师针对学生实际走到的步骤给出指导。

这样一来,教师模型处理的是学生模型当前分布下会遇到的问题,而非预先准备的一套标准错误。

经过这些环节,多模型长期执行任务积累下来的经验,开始被用于NeoHorse的后训练。

后训练之后,提升的是什么?

从当前技术报告给出的结果看,Agentic Post-Training在4B和9B两个尺度上都带来了稳定提升。

其中,NeoHorse-1-4B的综合表现(宏平均得分从58.94提升到64.87)已经达到同规模SOTA——在所有可对比的基准上均超越其基础模型Qwen3.5-4B,并在4B同规模对比模型中综合领先。

但SOTA并不意味着能力是均匀铺开的。

进一步拆分结果可以看到,4B模型的提升主要集中在一类任务上

这类任务通常拥有相对明确的工作流程,环境反馈能够被观察,成功与失败可以验证,最终交付标准也比较清楚。

比如在一个项目排期任务中,基础模型虽然找到了工作目录中的文件,却没有继续读取一封包含最新依赖约束的邮件。

结果,它按照已经过期的信息生成计划,并把文件写到了错误位置。

经过后训练的模型会继续读取新增证据,发现约束已经变化,重新计算排期、验证结果,再把交付物保存到正确位置。

二者的差异体现在Agent执行链条上。

一个模型大致知道任务应该怎么做,另一个模型已经能把获取证据、更新约束、执行、验证和交付串成较完整的工作流。

达到同规模SOTA,并不意味着要让NeoHorse-1-4B接管所有任务。基元律动更关心怎样精细划分不同模型的能力边界。

能够由4B稳定完成的任务,可以减少更大规模模型的调用;能够由更强模型完成的任务,也不需要持续升级到价格最高的旗舰模型;难度继续上升以后,再交给模型池中能力更强的模型。

这里正好衔接上Routing Harness与自研模型之间的关系。

模型不断向外扩展可承担任务的成本区间,路由系统则根据任务难度和执行情况,把不同能力放到合适的位置。

除了API调用费,这套模式还有什么价值?

说到这里,基元律动几条产品线之间的关系也逐渐清晰起来。

第一层是OpenSquilla开源版。

通过免费、开源、本地部署和桌面产品,基元律动降低开发者使用多模型Agent的门槛,同时连接开发者和任务入口。

第二层是TokenRhythm API。

其定位接近“中国版OpenRouter”,通过统一接口提供不同模型的调用能力,承接开发者和企业的模型使用需求,同时帮助模型厂商连接更多应用场景。

企业不需要分别适配大量模型接口,就能更方便地评测、选择和切换模型。

第三层是面向企业的服务与部署能力。

金融、制造等行业对权限、稳定性、私有部署和服务保障有不同要求,也由此形成进一步的商业空间。

第四层才是NeoHorse。

NeoHorse首先验证了一项关键连接:Harness执行过程中产生的有效经验,经过筛选和训练以后,确实有机会被转化成模型自身的能力。

由此,基元律动此前提出的商业飞轮第一次出现了模型层面的结果。

这一点也带来了优化推理经济账的可能。

如果NeoHorse后续能够稳定承接一批高频、标准相对明确的Agent任务,平台便多了一种可以自主调度的能力供给。

这些任务可以进一步优化推理成本、响应速度和稳定性,也让模型供给配置更加灵活。随着模型继续迭代,其可覆盖的任务范围还有进一步扩大的空间。

从这个角度看,基元律动想做的事情有点像制造体系中的工艺积累。

外部模型生态提供不同能力,Harness负责组织执行;在执行过程中形成的经验,再进入下一轮模型改进。

从连接模型、提供服务,到把服务中产生的经验转化为模型能力,并进一步改善效率和质量,这也是基元律动在API聚合平台之外,多走出去的一步。

模型之外,基元律动在构建什么?

基元律动设想中的循环大致可以用几条业务线串起来:

  1. Routing Harness连接开发者与Agent任务
  2. → TokenRhythm API连接模型供给与调用需求
  3. → Harness组织执行,积累路由与任务轨迹
  4. → 可用轨迹经过筛选,用于模型训练
  5. → 更新后的模型返回Harness,参与适配任务
  6. → 改善任务体验,探索更好的响应速度与成本效率
  7. → 持续使用、付费与经营效率的提升
  8. → 支持下一轮服务完善和研发投入

其中一个关键变化在于,模型产生的轨迹,不再只停留在消费和调用环节,它还可能成为下一轮模型训练的来源。

Agent完成一次任务,Harness就多获得一次关于能力边界的观察。

某个模型失败,系统知道能力缺口可能出现在哪里;另一个模型成功接手,系统得到一条新的修复路径;用户最终接受或者拒绝结果,又提供一层外部反馈。

任务积累越多,路由判断可能越准确;路由判断更加准确以后,筛选出的训练轨迹也会更贴近实际任务;模型更适合任务以后,API服务又有机会获得更好的成本和体验。

如果这一循环能够长期成立,基元律动与常规API聚合平台之间的差异,也会逐渐从路由规则和模型列表,进入训练任务设计、训练方法以及模型参数。

最后再通过产品表现呈现出来。

距离RSI还有多远?

以上是基元律动开始谈论RSI(Recursive Self-Improvement,递归自我改进)的背景。

基元律动目前验证RSI的范围更接近一套工程闭环,可以拆成两个部分。

第一个是Data-RSI。

模型在Harness中持续执行任务,每一次路由、工具调用、失败恢复和最终结果,都会生成新的结构化记录。

这些记录经过筛选和处理以后,可以进入后续训练的数据池。训练数据因此不必全部依赖人工提前准备,也能够随着系统持续使用而增加。

第二个是Model-RSI。

系统根据评测结果识别当前模型的能力短板,调整下一轮训练数据分布,更新模型,再把新模型放回Harness参与执行。

也就是说,模型从执行经验中学习,更新后的模型又通过新的任务执行,为下一轮训练产生新的反馈。

不过,以NeoHorse目前公开的信息,还不能把这套体系视为完整RSI

技术报告目前验证的是一次“执行—评估—选择—更新”闭环。信号设计、奖励设计和训练流程仍由人类设定,多代模型迭代以后能否继续稳定获得增益,也需要更多实验确认。

因此更准确的表述是,NeoHorse这次发布完成了两层验证。

一层是商业上的,系统积累的数据,能够进入模型训练,并转化成可测量的能力提升。

另一层是技术上的,王云鹤带领创业团队完成了一次面向RSI方向的单轮工程验证。

模型越多,这家公司越值钱?

当然,基元律动的故事要成立,还需要跨过几道关。

第一,开源生态能否持续转化为API使用和收入。

第二,随着任务类型增加,系统能否持续获得足够高质量、可用于训练的Agent轨迹。

第三,模型能力改善以后,能否稳定转化成更好的任务体验和执行效率,并进一步体现在经营数据上。

第四,多轮模型迭代以后,能力增益还能持续多久。

这些问题都需要更长时间观察。

以及还有一个绕不开的变量——DeepSeek、Qwen、MiniMax等模型厂商也在向Harness和Agent产品延伸,模型与Agent基础设施垂直整合的趋势越来越明显。

以基元律动为例,这家公司目前拥有的差异之一是模型中立,以及跨模型执行过程中形成的横向比较数据。

但如果模型之间的能力差异足够大,跨模型调度有机会成为一门独立生意;如果头部模型逐渐覆盖更多任务,或者厂商自己把Routing、工具调用和Agent框架一起打包,留给中间层的空间就会被压缩。

上游能力越来越强、越来越便宜的时候,中间这一层为什么还需要存在?

对基元律动来说,NeoHorse至少让这个问题多了一层新的观察角度。

过去它证明自己会“用模型”,现在开始尝试证明,长期使用模型积累下来的数据,也能沉淀成自己的模型能力。

这条路如果走通,基元律动的护城河就不只在路由策略上;如果走不通,它仍然要面对所有模型中间层都会遇到的问题。

GitHub:https://github.com/TokenRhythm/NeoHorse

抱抱脸:https://huggingface.co/collections/TokenRhythm/neohorse-1