AI榜单第一名,赢的可能根本不是大模型
公众号摘要
同一个大模型，换套 Harness、运行环境和工具链，成绩与成本就可能大不相同。我们以为榜单在比较模型，其实常常在比较完整的 Agent 系统。一个无法复现的第一名，究竟还有多少参考价值？
一个模型登上榜单第一，能说明它就是“最强大模型”吗？
未必。
现在很多 AI 榜单，页面上写的是模型名，真正下场完成任务的却是一整套系统。
同一个模型，换一个 Coding Agent 运行时，测试成绩可能变，Token 消耗可能变，完成任务的速度也可能变。底层模型明明没有升级，最终表现却像换了一个选手。
问题出在哪里？
答案藏在模型外面。
今天的 AI 榜单，有时会把整个工程系统的功劳，全记在模型头上。
你以为在测大脑，其实还测了它怎么工作
让大模型回答一道常识题，模型通常只需要读懂问题并生成答案。
让 Agent 修复一个真实代码仓库，事情就复杂多了。
它要先理解任务，搜索相关文件，调用终端，修改代码，运行测试，阅读报错，再决定继续尝试还是提交答案。中间任何一步走错，都可能导致任务失败。
谁来安排这些动作？
不是模型自己凭空完成的，而是模型外部的一套执行框架。业内通常把它叫作 Harness。
Harness 会决定模型最先看到哪些信息、能够使用什么工具、一次保留多少上下文、失败后能不能重试、什么时候停止、最后以什么格式提交结果。
这些设置看起来像工程细节，实际上会直接改变模型的发挥。
一套成熟的 Harness，会把正确的文件、测试结果和错误信息及时送回模型，让它能够根据反馈修正方案。另一套 Harness 可能不断重复无效搜索，过早丢失关键上下文，或者还没找到问题就耗尽预算。
模型能力相同，完成任务的概率已经不同。
所以，一次 Agent 评测真正测到的是：
模型 × Harness × 运行环境 × 资源预算 × 评分规则
只公布模型名，就像只公开了整道实验中的一个变量。
AI 榜单里，藏着多少没有写出来的条件
最常被忽略的变量，首先是工具链。
两个系统都在做代码修复，一个可以搜索仓库、运行测试并读取完整日志，另一个只能查看有限文件。即使使用同一个模型，它们面对的也不是同一道题。
其次是运行环境。
本地电脑、Docker 和云沙箱可能拥有不同的依赖、网络权限、命令和文件系统能力。一个任务在本地顺利通过，换到受限沙箱里，可能连需要的软件都无法安装。
资源预算同样关键。
有的方案允许模型运行更长时间、调用更多工具、失败后反复重试；有的方案只给一次机会。如果榜单只展示最终通过率，却不公布 Token、时长和重试次数，读者就无法判断这个成绩付出了多大成本。
最后还有评分器。
测试是否覆盖了真正的需求？参考答案有没有与执行过程隔离？评分模型会不会偏爱某种表达方式？平均分看起来非常精确，背后的判断规则却可能并不稳定。
于是，一个很容易被忽略的问题出现了：
榜单上的“模型第一”，到底是模型赢了，还是 Harness、预算和环境一起赢了？
两种排名，回答的根本不是同一个问题
如果我们想比较模型，就应该固定 Harness、运行环境、任务集和资源预算，只替换底层模型。
这时回答的问题是：在同一套工作方式下，哪个模型更适合完成这类任务？
如果我们想比较 Agent 系统，就可以固定模型，再更换 Harness、工具链和任务策略。
这时回答的问题变成了：同一个模型被怎样组织起来，才能更稳定、更便宜地完成工作？
这两类评测都有价值。真正的麻烦，是很多榜单把它们混在一起，最后统一挂到模型名下。
读者看到的是“模型 A 超过模型 B”，实际发生的可能是：模型 A 获得了更好的上下文、更有效的工具调用策略、更充足的重试次数，以及更适合它的评分方式。
这类结果很难复现，也很难直接指导采购。
企业购买一个模型 API，不会自动获得榜单里的完整表现。榜单背后的 Prompt、工具、执行流程和环境配置没有一起交付，线上效果自然可能与演示相差很远。
Ageval 想做的，是把“隐形工作台”摆到台面上
浙江大学 ZJU-REAL 团队开源的 ageval，切中的正是这个问题。
它将 Agent 运行时和执行环境封装成可替换的插件。同一份数据集，可以在不同模型、不同 Harness 和不同环境之间切换。想比较模型，就固定 Agent 与环境；想比较 Harness，就固定模型和任务；想检查沙箱差异，就只更换运行环境。
变量被拆开之后，榜单才知道自己究竟在测什么。
Ageval 还把一次评测划分为五个阶段：lock → environment → run → evaluate → record。
运行前，它会检查依赖、能力和配置；执行时，让 Agent 在指定环境中完成任务；评分阶段再提供参考答案，并可让评分环境断开网络；运行结束后，保存配置快照、评分结果和完整交互轨迹。
按照项目公开资料，榜单成绩会绑定具体的 Agent 运行时和执行环境，并保留 lock.json、结果文件与轨迹记录。
这意味着，一个分数不再只是网页上的数字。别人可以继续追问：它用了什么配置？在哪一步失败？消耗了多少资源？能不能用同一套条件重跑？
不能被追溯的高分，很难成为真正可信的结论。
当然，完整记录也不能自动解决所有问题。任务集是否代表真实需求、评分规则是否合理、测试样本是否被模型见过，仍然需要单独检查。
Ageval 提供的是一套让评测更容易比较和复现的基础设施。它没有保证榜单一定正确，但至少让错误、偏差和隐藏条件更容易被看见。
一个靠谱的 AI 榜单，不能只剩“模型名 + 总分”
今后看 Agent 榜单，至少要找到五类信息：模型的精确版本与调用参数，Harness 的版本与关键策略，运行环境和权限配置，时间与 Token 等资源预算，以及任务集、评分器与完整运行轨迹。
少了其中任何一项，结果都可能难以复现。
逐任务结果也比一个平均分更有价值。
有的系统擅长快速解决简单任务，却会在长链路任务中频繁中断；有的系统偶尔拿到很高的成绩，但每次运行波动很大；还有的系统通过率不错，成本却高到无法进入真实业务。
这些差异，都可能被一个漂亮的总分遮住。
如果一张榜单只公布模型名和总分，最稳妥的态度，是把它当成发现候选模型的入口，而不是最终的采购报告。
真正需要警惕的，可能不是榜单失真
还有一个更深的问题。
当我们习惯把完整系统的表现归功于模型，就会忽略真正决定 AI 如何行动的那一层：谁设置默认 Prompt，谁决定它能用哪些工具，谁控制记忆、权限、重试和停止条件。
这些选择都发生在 Harness 里，普通用户却很少看见。
未来，模型可能越来越容易更换。企业真正难以迁移的，反而是围绕模型积累起来的工作流、Skills、权限体系、评测集和运行记录。
新的平台锁定，也许不会发生在模型层，而会发生在这套“隐形工作台”上。
这也是为什么，评测结果必须绑定完整系统版本。它关系到技术比较是否公平，也关系到使用者能否知道：自己购买的究竟是什么，系统又在依据什么替自己行动。
下次再看到“某模型屠榜”“某模型登顶”，先别急着被那个总分说服。
问一问它用了哪套 Harness，获得了多少预算，运行在什么环境里，失败轨迹有没有公开。
如果这些问题都没有答案，那么榜单展示的可能不是模型能力，而是一场无法复现的系统演示。
AI 榜单下一步最需要增加的，不是更多模型，而是把真正被测试的对象完整写出来。
资料来源
- 智源社区：配套 CLI 与 Skills，浙大开源可插拔 Agent 评测底座
- ZJU-REAL / ageval 开源仓库
说明：本文依据项目公开资料梳理，未对相关榜单进行独立复跑；关于评测披露、模型选型与平台锁定的内容属于分析与建议。