大模型排行榜，快排不明白了

出品 | 网易智能

作者 | 小爪

编辑 | 王凤枝

一个Skill，不改模型权重，就能让DeepSeek V4 Pro"秒杀"海外顶级模型Claude Fable 5？

第三方Skill项目J-Space的配套报告显示，V4-Pro-0813接入这套Skill后，7项智能体和编程评测全部超过Fable 5的参考成绩。

另一组开发者随后做了A/B测试，却没有看到任务完成度提升，接入J-Space的一组反而花了更多Token和时间。

谁对？目前还不能下结论。两边使用的模型和任务不同，考的并不是同一张卷子。

但这场争议暴露了排行榜的一个漏洞：今天写在模型名下的成绩，越来越多是模型、Harness、上下文、工具和重试策略共同产生的。

排行榜仍在给模型排座次，真正参加比赛的却已经是一整套执行系统。

在智能体和编程任务中，只公布模型名和最终分数的大模型排行榜，正在失去解释力。

一、换套Harness，同一个模型可能换个名次

先看J-Space的"秒杀"是怎么得出来的。

项目报告显示，V4-Pro-0813接入J-Space后，Terminal Bench 2.1从87.9分升至90.1分，Fable 5的公开成绩为88.0分；DeepSWE从62.7分升至72.0分，Fable 5为70.0分；Toolathlon-Verified从74.1分升至79.5分，Fable 5为77.9分。

在报告列出的7项对比中，DeepSeek的成绩全部更高。不过，这并不是一次在相同条件下进行的正面对比：DeepSeek的分数由J-Space项目方实测，Fable 5的分数则取自厂商公开资料。双方使用的Harness、资源预算和运行设置并不统一。

8月17日，另一组开发者进行了不同的测试。他们没有使用V4-Pro-0813，也没有重跑上述7项评测，而是换成V4-Flash和三类自建任务，对比接入J-Space前后的表现。

第二轮共运行12次，两组完成任务的情况基本相同，接入J-Space后却消耗了更多Token和时间。这只能说明J-Space没有在这组测试条件下带来明显提升，不能据此推翻项目方的成绩。

要理解为什么这些数字不能直接对照，需要先区分Benchmark和Harness。

如果把模型看成考生，Benchmark是试卷，Harness则是模型拿到试卷后使用的一整套答题系统。它决定模型能看到哪些上下文、调用什么工具、如何保存进度，以及出错后能否检查和重来。

Harness以前很少出现在排行榜的醒目位置，但它对成绩的影响已经不能再被当作脚注。

5月7日提交至arXiv的《Stop Comparing LLM Agents Without Disclosing the Harness》，把3个模型分别放进3套Harness，在同一批100个编程任务上测试。模型、任务和运行限制保持不变，只更换Harness，同一个模型的通过率最多相差13个百分点，模型排名还发生了6次反转。

另一项Harness-Bench研究则准备了106项沙箱任务，在统一环境和资源预算下测试不同的"模型＋Harness"组合，共记录5194条执行轨迹。研究者不仅看任务是否完成，还保存了工具调用、Token消耗、错误和判分结果。

这些研究不能直接证明J-Space有没有用，却说明了排行榜正在发生什么变化：当任务需要连续操作、调用工具和处理错误时，同一个模型换套Harness，可能就会得到另一个分数，甚至换一个名次。

二、厂商开始把Harness写进成绩单

如果Harness只在研究论文里影响几分，它还可以被看作评测中的技术细节。但模型厂商已经开始主动把它写进成绩单。

7月发布的Kimi K3技术报告，在多项智能体和编程成绩旁边标出了使用的Harness，包括Kimi Code、Claude Code和Codex。部分评测还进一步注明了运行次数、推理强度、上下文策略，以及测试过程中出现的拒答和降级。

这些成绩不是Kimi K3单独跑出来的，而是Kimi K3与不同Harness配合后的结果。有的Harness更擅长压缩上下文，有的允许模型调用更多工具，还有的会在失败后自动检查并重试。因此，最终分数很难只算在Kimi K3头上。

DeepSeek则更进一步，开始自己建设Harness。

官方发布的DeepSeek Harness把模型适配、上下文组织、工具调用、任务循环和运行记录放进同一套插件架构。它目前仍处于开发者预览阶段，官方明确提示后续可能出现不兼容改动，距离稳定的生产工具还有距离。

但它释放的信号已经很清楚：DeepSeek不再只关心模型能生成什么答案，也开始介入模型如何理解任务、调用工具和完成工作。

这会改变模型厂商的竞争边界。过去厂商主要发布模型权重、API和Benchmark成绩；现在，它们还需要决定模型进入哪套执行环境、能使用哪些工具，以及出错后如何继续。

8月22日，Latent Space刊文提出，工具调用、上下文压缩等原本依赖外层系统的能力，正有一部分被模型训练吸收。模型升级后，Harness也会随之调整；排行榜记录的始终是某个时间点的一组具体组合。

当然，这并不意味着模型本身不再重要。在知识问答、数学选择题和短文本生成中，底模能力仍然可能决定大部分结果。但任务一旦延伸到修改文件、操作软件、调用外部工具和连续执行几十步，Harness的影响就会迅速放大。

问题在于，今天许多排行榜仍然只把模型名放在最醒目的位置。

读者看到的是"Kimi K3多少分""DeepSeek超过了谁"，分数背后使用的Harness、上下文策略、工具权限和重试预算却常常藏在技术报告的脚注里。排行榜看上去在比较模型，实际比较的已经是几套配置不同的系统。

模型排行榜仍然可以告诉我们谁进入了第一梯队，却越来越难单独解释：这个模型为什么赢，以及换一个使用环境后，它还能不能继续赢。

三、榜首组合，也未必是更好的选择

既然模型分数受Harness影响这么大，一个自然的想法是：干脆把"模型＋Harness"当作一个整体来排名。但这样也不够。

同样完成一个任务，有的组合一次就成功，有的却要多跑几轮、消耗更多Token。分数相同，成本可能相差很大；分数更高，也可能只是因为它获得了更多时间和重试机会。

8月17日那组V4-Flash自建任务A/B测试提供了一个成本例子，它并不是对前述7项评测的复跑。在竞赛推理和仓库开发任务中，接入J-Space后，输入Token平均增加28%，耗时增加17%；在中断恢复任务中，输入Token约为对照组的3.15倍，耗时增加36%。但在这些测试中，两组完成任务的情况并没有拉开差距。

这说明，如果排行榜只展示最终分数，读者看到的可能只是半张成绩单。

多花Token本身并不是问题。如果增加检查和重试能够减少失败，系统虽然单次调用更贵，完成一个任务的总成本反而可能更低。

因此，真正需要比较的不是谁用的Token最少，而是谁能以更少的时间、重试和人工接管，稳定完成一个任务。只公布成功率，不公布完成一次任务付出的总成本，仍然无法判断哪个组合更值得使用。

一个排名更高的模型，再配上一款功能更成熟的智能体，看上去像是把两个第一名放在一起。但模型与Harness之间存在适配关系：一套提示词、工具格式和上下文策略可能围绕某类模型长期调试，换上理论上更强的模型，实际表现未必继续提高。

用户面对的任务也不相同。修改代码仓库、整理公司资料、制作演示文稿和操作办公软件，需要的工具和容错方式并不一样。在一项编程评测中领先的组合，未必更适合处理日常文档。

对普通用户来说，排行榜主要用来缩小选择范围，不必自己设计一套Benchmark。如果不知道怎么选，可以先做三件事：

优先使用智能体厂商已经适配并持续维护的模型组合，不要简单地把"最强模型"和"最热门智能体"拼在一起；

拿两三个自己最常做的任务多试几次，看它能否稳定完成，而不是偶尔成功一次；

除了结果，还要看完成一次花了多长时间、多少钱，中间需要自己纠正或接管多少次。

如果任务涉及重要文件、账号权限或对外操作，还要确认系统出错后能否停下来、能否看到执行记录，以及是否需要用户再次确认。

真正决定选择的，不再只是哪个模型排在第一，而是哪套组合能在自己的任务和预算内，更稳定地把工作做完。

四、下一张排行榜，应该怎么排

模型排行榜仍然有用：模型厂商需要用统一评测证明推理、知识和代码能力，用户也需要一张表快速了解市场位置。但在智能体任务中，榜单不能再只写模型名，还要同时写清使用的Harness、任务类型和资源条件。

在知识问答和数学题里，排行榜仍然可以主要比较模型；到了需要浏览网页、修改文件、调用软件和连续执行的任务中，评测对象就应该换成完整系统。

未来的排行榜可能不再用一张总榜选出一个冠军，而是按任务分别排名：仓库级代码修改一张，文档处理一张，网页操作再排一张。每张榜同时列出成功率、完成一次任务的成本、耗时和人工接管次数。用户先找到与自己用途相近的任务，再比较不同组合，而不是只看总榜第一。

有的组合成功率更高，但价格昂贵；有的速度更快，却需要更多人工检查；有的适合编程，有的更擅长处理文档。分数最高的组合，不一定是每项任务中最合适的选择。

这也意味着，一家厂商即使没有在所有底模评测中排名第一，也可能通过更好的工具调用、上下文管理和错误恢复，做出更能完成实际工作的产品。反过来，一个模型即使拥有漂亮的Benchmark成绩，如果没有稳定的执行环境，也未必能把分数转化成用户能够感受到的生产力。

所以下一次再看到"国产模型超过Claude"，更值得先问的或许不是它排到了第几，而是：在什么任务、什么配置和多少成本下，它真的做得更好？