2726 分钟，听起来像一次模型智力考试。
但 NanoGPT Speedrun Frontier 的关键并不在这里。Prime Intellect 让 18 款前沿模型参与了 153 次自主运行，测试它们能否自己修改优化器、运行实验、读取验证结果，再决定下一步怎么改。榜单上，Fable 5 配合 claude-code · high，拿到 2726 的最佳验证结果，排在首位。
这更像一场“研究团队竞速”，不是单模型擂台。
模型要出主意。代理框架要会调工具、拆任务、重试和收敛。推理预算决定它能试多少次。验证机制则负责判断这次改动到底有没有效。四个环节缺一块，模型再强也可能只是在代码里留下几段漂亮废话。
153 次运行，榜单到底测了什么
任务围绕 NanoGPT 优化器展开。参赛模型需要在真实代码环境里完成自主优化，并用验证结果检验修改是否有效。
Prime Intellect 的实验规模是：
- 覆盖 18 款前沿模型；
- 共进行 153 次自主运行；
- 开放 41 条精选完整轨迹；
- 轨迹包含工具调用、子代理活动和 scratchpad。
公开信息中可以直接核对的配置如下。这里的数字是单次运行的最佳验证结果，不是平均分，也不能直接当成模型的通用排名。
| 模型 | 代理框架 / 档位 | 最佳验证结果 | 说明 |
|---|---|---|---|
| Fable 5 | claude-code · high | 2726 | 榜单标注的领先结果 |
| Opus 5 | 配置信息未完整披露 | 2920 | 需结合原始榜单的完整列名理解 |
| Kimi K3 | prime-agent | 2930 | 同一模型的一组对照 |
| Kimi K3 | kimi-code | 2974 | 同一模型的另一套框架结果 |
原始表格的列名并不完整。像 81.7% 之类的字段，不能凭数字形状猜成成功率、胜率或稳定性指标。评测文章最容易犯的错，就是把看不懂的列解释成自己想要的结论。
还有一个细节不能跳过：Fable 5 的 2726 被榜单列为最佳结果，但不同配置的成绩不能只看数字大小，也不能把所有行放进同一个“模型排名”里比较。各模型使用的 harness 和强度档位并不统一，预算是否相同，公开材料也没有交代完整。
所以，这份榜单能确认的是：某些配置在这项任务上跑出了更好的单次验证结果。它还不能证明某个模型平均能力最高，更不能证明它在其他研究任务里同样领先。
同一个 Kimi K3，换框架就换了成绩
最有信息量的对照，来自 Kimi K3 自己。
它在 prime-agent 下得到 2930，在 kimi-code 下得到 2974。模型没换，结果变了。这个差异至少说明，代理层不是一个可以忽略的外壳。
代理框架会影响很多具体动作：
- 怎样读取仓库和定位瓶颈；
- 是否先做基线测试；
- 如何安排子代理；
- 失败后是回滚、重试，还是继续叠加修改；
- 什么时候停止探索，接受当前结果。
这些动作决定了模型的想法能不能落地。一个模型可能知道应该优化学习率调度，却没有正确执行实验；也可能提出了有效方案，但在几轮失败后把预算耗尽。最后留在榜单上的，是整个系统的产物。
不过，Kimi K3 的对照只能说明“框架可能显著影响结果”，不能据此计算框架贡献占比。两次运行的随机性、提示词、工具权限、推理强度和执行预算都可能不同。没有多次重复和统一控制，就不能把 44 分差距直接归因于代理框架。
这点对模型厂商很刺眼。过去的模型评测习惯把模型名称放在最醒目的位置，把推理档位、工具链和执行器藏在脚注里。自主科研任务会把这个顺序倒过来：模型只是发动机，真正跑多远，还要看变速箱、导航和维修班组。
41 条轨迹，比一个榜首更有用
Prime Intellect 开放 41 条精选完整轨迹，这一步我认为是整件事里最值得肯定的动作。
只看榜单，读者只能知道谁赢了。看轨迹，才有机会知道它为什么赢：
- 它是否先建立了可靠基线；
- 哪些尝试真正改变了验证结果；
- 子代理有没有带来有效分工；
- 工具调用是否浪费了大量预算；
- 失败之后有没有保留可复用的信息；
- 最终改动是扎实优化，还是碰巧撞上了一个有效参数组合。
这和传统论文只展示最终实验结果有些不同。研究型智能体的能力，很大一部分藏在过程里。它如何搜索、如何放弃、如何确认结果，和最后写出哪段代码同样重要。
历史上，编译器优化、自动调参和 AutoML 也经历过类似阶段：榜单先让人兴奋，复现和成本再把兴奋压回现实。一次漂亮的最优结果很容易被传播；一套别人能跑通、能解释、能负担的流程，才会留下来。
“纸上得来终觉浅”，放到智能体评测里，就是不能只看最终分数。轨迹公开，让外部开发者可以检查过程，也让榜单从宣传材料变成了可拆解的工程样本。
对开发者和企业，现实变化是什么
研究型智能体开发者最先受到影响。
如果你正在选择 agent harness，不能只问“它支持哪个模型”。更实用的问题是：
| 决策问题 | 应该检查什么 |
|---|---|
| 要不要换框架 | 同一模型、同一预算下的重复结果 |
| 要不要提高推理档位 | 分数提升是否覆盖额外推理和工具成本 |
| 要不要引入子代理 | 子代理是否减少失败次数，而非只增加调用量 |
| 能否用于真实研究 | 结果能否复现，改动是否可审计，失败是否容易回滚 |
对企业团队，采购和预算也会变得更复杂。过去可以粗略比较模型 API 价格和基准分数；现在还要算代理循环的长度、工具调用次数、失败重试成本，以及人工复核时间。
一个便宜模型，如果需要十几轮试错才能得到稳定结果，未必比一个昂贵但收敛更快的模型划算。反过来，一个榜单上跑出最佳单次成绩的系统，如果复现率低，也不适合直接接管研究流程。实验室最怕的不是偶尔失败，而是没人知道它为什么成功、下次还能不能成功。
这也是模型厂商接下来会面对的评测压力。只公布模型名和最高分，信息越来越不够。用户会追问运行次数、预算、工具权限、随机种子、失败率和轨迹。自主科研能力一旦进入真实工作流，最高分的公关价值会下降，单位有效结果的成本会升上来。
别把一次竞速封成能力王座
这组数据的价值很明确：它把“模型会不会研究”拆成了一个可观察的系统问题。
但它的边界同样明确。
目前看不清的部分包括：
- 153 次运行在各模型和各配置之间如何分配；
- 每种配置是否有足够重复次数；
- 推理预算与计算成本是否统一；
- 41 条轨迹是不是按成功案例精选；
- 结果能否迁移到 NanoGPT 之外的任务；
- 改动是否能被其他团队稳定复现。
因此，Fable 5 的榜首应该被读成一次有效的系统表现，而不是一张“自主科研能力毕业证”。Kimi K3 的两种框架成绩，则提醒我们：榜单上的模型名，已经不足以代表完整参赛者。
我更愿意把这次竞速看成一次工程分工的显影。模型厂商负责把发动机做强，代理框架团队负责把实验流程接起来，评测平台负责让结果可查，使用者负责计算真实成本。谁把四件事拼得更稳，谁才有机会从演示走进研究工作。
模型看着更强，产品未必更可靠。榜单可以奖励一次撞线，研究岗位需要的是每天都能出发、能复盘、能重跑的系统。