热门 AI Benchmark 是怎么做出来的？

一套有用的 benchmark，能把关于 AI 能力的问题变成其他人可以运行的测试。但测试的每一步都有取舍：题目从哪里来、允许模型做什么、怎样判断成功、哪些失败应该计入成绩。

这篇文章拆解九组近期被采用的 LLM / agent benchmark，重点看它们怎样制作、设计带来了什么好处、为什么有人用，以及哪里还能改进。案例以 2025–2026 年的发布、更新和实际采用为主；较早的论文用于解释仍在使用的评测设计。

下文区分三类内容：论文、代码和修订记录能确认的事实；根据公开采用记录作出的解释；还需要实验验证的改进建议。谁在使用可以查证，为什么选择使用则更难确定。本文研究了公开方法和部分评分代码，没有完整复跑这些评测。

1. Terminal-Bench：把工作任务、运行环境和检查方法一起交出来

它想解决什么问题？

能写出一段代码，与能在电脑环境里完成任务，是不同的要求。后者可能需要查看文件、安装依赖、运行程序、定位错误，再修改自己的做法。Terminal-Bench 把这类终端任务作为研究对象。

这里主要拆解 2025 年 11 月发布的 2.0，并用后来的修订说明它怎样演进；2.0 的设计和 2026 年 8 月的 4.0 分数不能混在一起。项目时间线

它是怎么做出来的？

先收集任务，再审核。 Mike A. Merrill、Alexander G. Shaw 等人的论文记录：93 位贡献者提交了 229 个任务，最终选出 89 个组成 2.0。筛选考虑难度和质量，由有经验的审核者检查。论文 §2.2

每道题交付一套可以运行的材料。 包括任务说明、预装文件和软件的容器、人工参考解，以及检查结果的测试。参考解用来确认任务有解，正式测试检查 AI 操作后的结果。运行和记录由 Harbor 等工具支持。任务仓库、Harbor

审核不只看文字。 团队会运行参考解、检查什么也不做是否会得分，查看多个模型的失败记录，还用专门尝试钻空子的 agent 检查评分漏洞。这样可以发现“模型失败”其实是题目或测试有问题的情况。论文 §2.3、附录 B

怎样运行和评分？

给 agent 一份任务说明和一个初始化后的环境，让它操作，结束后检查环境的最终状态。检查的是目标是否完成，不要求它按参考解的命令顺序执行。论文也区分了模型与 agent 框架的组合：换一个框架，可能改变同一模型的表现。论文 §2.1、§3

对使用者来说，一条完整成绩应包含任务版本、模型、agent 框架、运行资源、尝试次数和成功率。Harbor 负责组织这些运行和结果，而不仅是下载题目。框架

做得好在哪里，为什么有人用？

它把“能完成任务”变成了可执行的检查。 只要最终结果符合要求，就可以接受不同做法。这比把 AI 的操作顺序与参考解逐字比较更合理。

它减少了其他团队重复搭环境的工作。 有任务、有运行工具、有结果记录，外部团队更容易接入自己的 agent。Terminal-Bench 2.0 出现在 Claude、Gemini、Kimi 的报告里；4.0 已被 Artificial Analysis 纳入指数。Claude、Gemini、Kimi、AA

我的解释是：终端 agent 需要一个共同测试，而项目同时提供了任务和使用工具。人员贡献也能具体追踪：Kelly Buchanan 等人组织 2.1 修订，Ryan Marten 等人推动持续版本管理。公开记录支持这些工作确实发生，但无法证明其中哪一项单独导致了流行。2.1、持续维护方法

哪些问题已经出现？还能怎样改？

问题与现状	可以怎么改	怎样检查改进有效？
题意、测试和环境可能不一致。 2.1 修订了 28 个任务，说明多轮审核后仍可能有错。修订记录	把已发现的错误、不同合法解和投机解加入检查库，随着任务更新反复运行。	分别统计“正确解被拒绝”和“错误解被放过”的比例；只看模型分数上涨不够。
资源配置会改变结果。 Anthropic 的受控实验发现，同一模型与任务在不同资源配置下出现分差；4.0 已做资源校准。实验、4.0	在已有校准基础上，再报告固定时间或固定费用下的成绩，让使用者知道多花资源换来了多少成功率。	固定模型和框架，改变资源；检查排名是否稳定、资源不足错误是否下降。
公开题目和解法会带来泄漏风险。 4.0 移除的任务中包含已有公开解法的任务。4.0	保留公开开发集，再增加独立编写、按期更新的测试任务；对公开与新任务使用一致的运行条件。	看方法的提升是否也出现在新任务上。代价是新题审核和维护成本更高。

可以借鉴的做法： 发布题目时，同时发布让别人运行、检查和报告错误的工具。质量不能只靠发布前一次审核。

2. BrowseComp：把“难搜索”和“好评分”放在一起

它想解决什么问题？

“会做研究”包含找资料、判断来源、分析和写作。BrowseComp 选了其中较明确的一部分：能否在网上找到难找的事实，并给出正确的短答案。 它由 Jason Wei、Zhiqing Sun、Spencer Papay 等人开发，于 2025 年 4 月发布。作者介绍

它是怎么做出来的？

人工先确定一个有证据支持的事实。 答案要简短，并尽量不随时间变化。
围绕这个事实倒过来写问题。 例如先知道某个事件，再用几个相关条件描述它，让答题者查出事件名称；这是方法示意，不是原题。
检查是不是太容易。 作者让出题人尝试当时的模型和简单搜索；部分题目也交给另一位出题人尝试。
检查答案和表述。 如果发现另一个符合条件的答案，继续修改问题。论文也明确承认，这不能保证所有题目都只有一个合法答案。论文 §2

这是一种有目的的难题筛选。题目不代表日常上网请求的自然比例，难度也受当时参与筛选的模型影响。

怎样运行和评分？

agent 搜索网页后提交回答。评分流程的设计是：提取最终答案，让评分模型判断它与参考答案是否含义相同，再计算答对比例。短答案让评分更简单，但评分器并不会因此自动证明参考答案完整、或回答中的所有证据可靠。 某个代码版本中的实现问题会在文末的代码检查中单独说明。评分代码

一个重要的设计取舍是：它更容易判断“最后答案对了吗”，较难解释“为什么找到了答案”或“为什么没找到”。如果搜索服务不同，分数中也包含搜索服务带来的差异。

做得好在哪里，为什么有人用？

它给了浏览能力一个清楚的比较目标。 开放式长报告很难统一评分；短事实答案较容易检查。它也保留了需要多次搜索的难度。作者介绍

OpenAI、Anthropic、Google 和 Moonshot 都报告了 BrowseComp 结果。我的解释是，当团队开始比较浏览型 agent 时，这种清楚、可接入的测试很有用；品牌和发布渠道可能帮助传播，但现有资料无法给出各因素的贡献大小。OpenAI、Anthropic、Google、Moonshot

哪些问题值得改？

问题与依据	可以怎么改	怎样检查改进有效？
参考答案可能不是唯一答案。这是作者明确承认的风险。论文 §2.1	对与参考答案不同、但附有证据的回答提供复核流程。人工确认后，更新可接受答案或修改题目。	抽查被判错的回答，统计其中有多少实际上满足题目要求；同时检查新增答案是否过度放宽标准。
实时网页和搜索服务会变。固定语料的 BrowseComp-Plus 已针对这个问题作出改进。后续论文	分别测试固定资料库和实时网络；在固定条件下比较 agent 或检索方法，在实时条件下比较完整系统。	固定一项、只更换另一项，看分差来自哪里。代价是固定资料库不能覆盖真实网络的全部变化。
答案正确不代表证据正确。原评分主要比较最终答案。代码	单独检查引用是否真的支持答案，并记录搜索次数、费用与耗时；不要把所有结果压成一个总分。	人工抽查引用，比较“答对且证据有效”的比例，并检查更高成本是否带来稳定收益。

BrowseComp-Plus 展示了一种具体的后续改进：它用固定资料库和证据标注，让研究者更容易区分“检索不到”和“拿到了证据但没用好”。这是已有工作实践过的改进方向。论文、项目

可以借鉴的做法： 把问题缩小到能可靠评分的范围，同时检查这种简化漏掉了什么。

3. τ²-bench：先搭一个可检查的世界，再让双方解决问题

它想解决什么问题？

客服和技术支持常常需要双方配合：AI 能改后台设置，用户能操作自己的设备；双方掌握的信息也不同。τ²-bench 想测这种多轮协作。2025 年 6 月的论文由 Victor Barres、Honghua Dong、Soham Ray、Xujie Si、Karthik Narasimhan 撰写。论文

它是怎么做出来的？

以论文新建的 Telecom 领域为例，流程是：

搭后台和用户设备。 用模型辅助生成数据库、工具和测试，再由人修改；AI 操作后台，模拟用户操作模拟设备。
写小故障。 每个故障都有初始状态、可行的解决操作，以及检查是否解决的条件。
组合故障。 避免互相冲突的组合，并运行参考操作检查能否解决。
抽取测试任务。 从组合任务中选出覆盖不同意图和复杂度的集合。
补业务政策和用户说明，再人工修订。 这些材料共同决定双方知道什么、能做什么。论文 §3.2

怎样运行和评分？

待测 agent 与一个模型扮演的用户对话，双方按权限调用工具。评分规则由任务指定，不能把整个系列概括成“只比较一次数据库”。所检查的代码支持比较目标数据库状态和检查指定状态条件；其他检查由对应评分模块负责。环境评分代码

论文中的 Telecom 主要通过状态条件判断问题是否解决。它还比较三种设置：正常协作；AI 独自控制所有工具；给出参考操作计划后再协作。这样能帮助分析失败与沟通、计划执行之间的关系，但条件同时改变了信息和控制权限，不能把分差解释成完全独立的单一能力。论文 §3.3、§4.2

可靠性要看重复运行。 pass^k 关心同一道任务在 k 次运行中都成功；它与“试 k 次，只要一次成功”的 pass@k 不同。前者随 k 增加会更严格，适合研究服务是否稳定。指标实现

做得好在哪里，为什么有人用？

任务不只是一段对话，而是可以检查的状态变化。 参考操作能帮助检查任务本身有解，组合小故障也使出题过程更系统。

它能帮助定位失败原因。 用户协作与给定计划的对照，比只公布一个成功率提供更多信息。GPT-5.2 和 Gemini 3.1 Pro 报告了 τ² 的相关领域结果，说明这套方法已被其他团队采用。GPT-5.2、Gemini

我的解释是，Sierra 团队熟悉服务流程，能够把“单次工具调用分数看不出来的问题”做成测试。后来的 τ³ 将公司文档检索和语音条件加入系列，也明确引用部署经验作为设计来源。τ³ 作者文章

哪些问题值得改？

问题与依据	可以怎么改	怎样检查改进有效？
模拟用户会影响结果。使用模型模拟用户是设计的一部分，真实用户的表达和错误未必相同。论文	对同一任务更换用户模型、表达方式和知识水平，再用少量真人任务校准。	检查排名在不同用户条件下是否稳定；人工判断失败主要来自 agent、模拟用户还是任务描述。代价是真人验证更贵。
完成状态不等于所有过程要求都满足。论文 Telecom 的状态检查有明确范围。论文 §3.3	对确有过程要求的任务，另加授权、确认或禁止操作的检查；任务目标和过程规则分别报告。	构造“最终状态正确、过程违规”的轨迹，检查是否能检出，同时避免惩罚不同但合法的操作顺序。
更多组合不一定等于更多新能力。如果训练和测试都由相同小故障组成，仍可能只是在熟悉的组合中变化。这里是需要检验的风险。	分别留出未见过的组合、工具或业务规则；明确每组测试在测哪一种新情况。	看改进方法是否在这些留出组仍有效，并用参考操作确认新任务仍然可解。

仓库 2026 年 7 月的 v1.0.1 修复了 banking_knowledge 的部分评分问题，并说明该领域修复前后的结果不可直接比较。它再次说明：比较成绩时，领域、模拟用户和评分版本都要写清楚。仓库说明

可以借鉴的做法： 先定义可检查的任务世界，再研究互动；同时给模拟器和评分器安排独立验证。

4. OSWorld-Verified：真实软件带来价值，也带来维护负担

怎么设计、怎么做？

原 OSWorld 框架在 2024 年提出，这里关注它支撑的 2025 年 Verified 修订。任务来自实际的软件使用场景，并为每道题准备初始文件、窗口和软件状态。运行时恢复虚拟机，按配置准备任务，让 agent 操作，最后取出文件或软件状态进行检查。原论文 §2、§3

评分并不只看截图像不像。 框架可以读取软件配置、文档或表格等内容，按任务要求检查结果。不同实验允许的观察和操作方式可能不同：截图、软件的可访问性信息、键鼠操作或命令行，都应在报告里说明。原论文

Verified 继续修正网页变化、初始化失败、任务歧义和评分问题。XLANG 团队记录了 300 多条反馈，约十人投入两个月；反馈数量不能理解成坏题数量。Mengqi Yuan、Zilong Zhou 等人的具体修订和重评工作也有公开记录。修订文章

优点和成功原因

真实软件让测试目标直观，也允许研究跨软件操作。 一套统一环境减少了每个团队从头搭桌面的工作。GPT-5.4 和 Sonnet 4.6 都使用 Verified，支持它已成为近期电脑操作比较的一种共同测试。GPT-5.4、Sonnet

我的解释是，论文定义任务，项目提供环境，而长期维护让这些任务继续可用。这三部分共同支撑采用。2026 年的 OSWorld 2.0 增加更长的工作流程，是后续设计，成绩应单列。2.0 论文

问题和改进

问题与现状	可以怎么改	怎样检查改进有效？
网页变化、加载失败和初始化错误已经出现。Verified 记录	每轮实验先检查初始状态是否正确；保留网络和软件版本信息；将环境无法运行与正常任务失败分开记录。	同一参考操作在不同日期重复执行，检查无模型参与时的失败率。不能只删除失败任务而不报告。
合法做法可能超出评分器预期，题意也可能含糊。Verified 记录	建立多种正确结果的样例；数值、文字内容与视觉效果分别检查，必要时由人复核。	让人工审核一批“自动判失败”的结果，统计误拒率及修订后变化。
评分前的后处理可能影响判断。原框架支持保存文件等后处理；是否掩盖了 agent 漏做的步骤，需要逐题检查。原论文	将 agent 自己完成的状态与评分器后处理后的状态分别保存；检查要求保存的任务是否由 agent 完成保存。	对“完成编辑但未保存”的轨迹做专项测试。这是审计建议，不是已经确认所有任务都有这个缺陷。

可以借鉴的做法： 真实环境的质量取决于持续检查；准备环境和读取结果的代码也属于评测方法。

5. WebArena：把网站固定下来，再检查任务是否真的完成

它想解决什么问题？

WebArena 检查 agent 能否在网站里完成用户请求，包括真正修改网站中的数据。来自卡内基梅隆大学的 Shuyan Zhou、Frank F. Xu 等人搭建了可操作的购物、论坛、软件协作和内容管理网站，并配上工具与参考资料站点。项目介绍

原版发布于 2023 年，但此后仍被用于比较 agent：OpenAI 在 2025 年 1 月的 Computer-Using Agent 报告中使用了它；2025 年末的 WebArena-Verified 又重新检查了它的评分。这里需要区分评测版本，报告分数时要说明用的是哪一版。原版仓库、CUA 报告、Verified 工作坊论文介绍

它是怎么做出来的？

先让其他团队也能运行这些网站。 仓库提供网站环境、部署说明、任务配置和 agent 运行代码，并区分用于浏览的演示站点与正式评测需要自行部署的环境，同时说明如何重置网站。仓库
先写任务目标，再变化其中的细节。 作者编写了 241 个任务模板，展开成 812 个请求。模板规定目标，把部分细节设为变量；来自同一模板的题目仍可能需要不同操作。论文 §3.1
同时审核答案和检查程序。 信息查找任务的答案由两人标注，有分歧时交给第三人；编写评分程序的作者会实际执行任务并查看状态。论文 §3.2

可以用一个自拟例子理解：让 agent 找到一个项目，添加指定标题的笔记，再返回链接。这不是数据集原题。测试应当区分“找到了项目”“打开了编辑器”和“正确保存了笔记”这几件事。

怎样运行和评分？

原版代码根据每道题的配置组合检查：比较返回的答案、检查网址，或定位并检查页面内容。答案检查包含精确匹配、必要文字匹配，也包含模型判断语义是否一致。因此，“用程序评分”不代表原版每道题都在用确定性的规则检查数据库。固定版本的评分代码

这个设计希望接受能达到目标的不同操作路径，但具体评分器仍可能漏掉要求。以上面的笔记为例：只检查编辑器是否打开，条件太宽；要求每次点击都与参考操作一样，条件又太窄。

WebArena-Verified 改了什么？

Amine El hattami、Megh Thakkar、Nicolas Chapados 和 Christopher Pal 报告了对全部 812 道题的审核，包括含糊的指令和与任务不一致的评分器。这是对已有 benchmark 的具体维护工作。工作坊论文介绍

其中三项改动很值得拆解：

明确 agent 应当返回什么。 用结构化字段说明操作类型、完成状态和取回的数据，帮助区分“到达了页面”和“完成了信息提取”。回答格式
先统一数据表示，再比较。 用按数据类型处理的规则替代宽松的子串匹配和 LLM 判断，让等价表示得到一致的结果。不过，规则每次给出相同结果，并不代表它一定判断正确。评分设计
保存可以重新评分的证据。 记录浏览器与服务器之间的通信，让运行结束后的评分不必依赖仍在运行的网站。agent 实际执行任务时，仍然需要环境。网络记录评测

这些改动也会改变测试内容。文档说明，部分开放式请求被改写成可以精确核对的事实提取任务。这减少了评分歧义，也减少了对归纳总结能力的考察。若要求涉及页面实际呈现的内容或浏览器内部状态，仅检查网络通信也不够。任务改写、网络检查的限制

这里引用的仓库版本包含 812 道题，Hard 子集为 258 道；较早的工作坊摘要写的是 137 道。可见，连子集名称也需要附上版本。完整集、Hard 子集和原版 WebArena 的分数应分别报告。固定版本仓库、早期摘要

做得好在哪里，为什么有人用？

它提供了可复用的浏览器实验环境。 研究者能在可操作的应用中研究规划、出错后的恢复和任务完成。原版仓库如今推荐通过 AgentLab 和 BrowserGym 开展实验，也说明配套工具能延续一个 benchmark 的使用价值。仓库

使用者不局限于原作者团队。 OpenAI 的 CUA 报告和微软研究院的 Magentic-One 研究都采用了 WebArena，但 agent 和实验协议不同。这能证明它被外部团队采用，不能据此直接比较两套系统。CUA、Magentic-One

我的解释是，它出现的时机有帮助：当研究者开始关注能实际操作的 agent 时，WebArena 已经提供了应用、任务和检查完成情况的方法。原团队让测试可以使用，后续框架和评分器工作降低了持续使用的负担。这些贡献可以查证，但无法单独量化它们对流行程度的影响。

哪些问题值得改？

问题与现状	可以怎么改	怎样检查改进有效？
自动检查可能漏掉任务要求。 Verified 已修复一批有记录的评分问题。审核说明	收集不同的合法解，以及看起来成功、实际未完成的例子。例如请求发出了，但预期修改没有保存下来。	对照人工检查和保存的状态，分别统计错误放过与错误拒绝。这些是建议增加的审核案例，不是在声称 Verified 目前一定存在这些错误。
相近任务可能同时出现在开发集和测试集。 Magentic-One 按模板划分这两部分。研究 §5.1	同一模板的题目放在同一组；研究更广泛的泛化时，再留出未见过的工作流程和网站。	分别比较熟悉模板的新参数、新模板、新网站上的表现，它们衡量的是不同程度的迁移能力。
固定网站只覆盖部分上网场景。 2026 年 7 月介绍的 WebArena-Pro 已扩展到 20 个应用、300 个任务，并包含音频和视频。Pro 介绍	在固定版本之外，有控制地改变布局、数据和权限。覆盖范围更广，与适应变化更强，应分别检查。	保持任务目标不变，逐项测量改动后的表现下降，并确认题目仍有解。新 benchmark 也不能自动继承原版的采用程度。
重置和运行网站会增加实验成本。原版要求遵循重置流程，Verified 也提供了环境管理工具。原版部署、Verified 工具	记录初始状态检查，隔离会修改同一份数据的运行，把环境失败单列。	改变任务顺序，比较串行与并行运行。先检查共享状态造成的差异，再判断是否是模型能力变化。

可以借鉴的做法： 同时设计任务、环境和证明任务成功的证据。WebArena-Verified 又补充了一点：要让有价值的 benchmark 长期可信，就需要持续检查它怎样给分。

6. HLE：高难度题目依赖专家组织和审核

怎么设计、怎么做？

HLE 由 CAIS、Scale 与领域专家合作建设，Long Phan、Dan Hendrycks、Summer Yue 等参与。其目标是高难度、答案相对明确的学术问题。论文

出题人提交题目、答案和解题说明；题目先经过当时多个模型的难度筛选，再由相关领域的人审核并修改，最后由组织者或审核者批准。项目也用奖励和署名机会吸引专家参与。论文 §3

发布后的反馈同样重要。官方于 2025 年 4 月将最终版定为 2,500 题，修正反馈中确认的错误，并去除容易直接搜索到答案的题目。最终版说明

怎样评分？

主要看答案是否正确，也让模型报告置信度，用来判断它答错时是否仍过度自信。官方方法使用模型提取和判断答案；即使问题有标准答案，答案表述、精度和判断模型仍会影响边缘情况。是否允许工具、是否包含图像，需要分别报告。评分方法

优点和成功原因

专家网络帮助团队获得跨学科的难题，统一题目形式又便于模型团队接入。 它在旧测试难以区分强模型时提供了新的比较材料。Claude、Gemini、Qwen 和 Kimi 的报告都有 HLE 结果。Claude、Gemini、Qwen、Kimi

我的解释是，需求、专家组织、统一评分与传播资源共同起了作用。专家审核提高题目质量，但“专家出题”并不意味着一定没有错题。

问题和改进

问题与依据	可以怎么改	怎样检查改进有效？
题目曾因错误或可直接搜索而修订。最终版说明	持续接受有证据的质疑，由另一位领域专家复核；保留修改记录和受影响的成绩。	定期抽样检查专家间分歧、错题比例及修订带来的分数变化。
按模型失败筛题，会偏向那些筛选模型的弱点。这是筛选方式带来的风险，影响大小需实验确认。筛选方法	保留少量未按模型表现筛选的专家题作对照，并在未参与筛题的模型上验证。	检查区分能力是否仍存在，分数是否主要由少数学科或特殊题型推动。
答对封闭问题不等于会自主科研。官方明确说明了范围。范围	对一部分题目额外审核推导和证据；若要测科研，再配独立的实验或研究任务，分别报告结果。	检查短答案正确但推理错误的比例，以及知识分数是否能预测另一组研究任务表现。额外审核会增加成本。

可以借鉴的做法： 难度、正确性和用途要分别检查；给题目增加难度，并不能自动扩大分数的含义。

7. GDPval / GDPval-AA：用工作成果作比较，但不能把分数直接当生产率

怎么设计、怎么做？

Tejal Patwardhan、Rachel Dias、Elizabeth Proehl 等人的 GDPval 从美国经济中的知识工作出发，选择行业与职业，请有经验的从业者依据工作经历编写请求、参考文件和交付物。完整集合为 1,320 个任务，公开 gold 子集为 220 个任务；两者不能混写。论文 §2

任务经过模型辅助筛查和多轮人工审核。原研究由相关职业专家盲评比较工作成果，并写出选择理由；另提供实验性的自动评分方法。论文 §2.4–2.5

怎样运行和评分？

AI 拿到请求和材料，制作文档、表格或其他文件。评审比较 AI 与参照成果的质量。任务接近工作产物，但这种实验仍是在给定材料和条件下进行的。发布说明

GDPval-AA 是另一套运行和评分流程。 Artificial Analysis 使用 220 个公开任务，通过 Stirrup 提供工具，并从盲式成对比较得到 Elo。它和原始 GDPval 的专家比较、胜率或平局比例需要分别写明。AA 方法

优点和成功原因

读者容易理解测试结果对应什么工作成果。 专家参与出题和审核，也让质量判断更贴近相应职业的要求。AA 平台进一步提供了跨模型的比较入口；Claude 与 Gemini 的报告采用了 GDPval-AA。Claude、Gemini

我的解释是，agent 开始生成实际工作文件时，这类评测回应了“做出的东西能不能用”的需求。人员资源在这里非常具体：从业经验、出题、审核和评审时间。

问题和改进

问题与依据	可以怎么改	怎样检查改进有效？
初版任务通常一次给足背景，不测真实工作中反复澄清需求的过程。论文 §5	保留原版，再增加允许追问、补材料和接受修改意见的交互版。	比较首版成果、修改后成果及所需用户时间；任务范围改变后单独发布成绩。
人工判断有分歧，自动评分也不能完全替代专家。论文 §5	把事实、计算、要求覆盖和呈现质量分别审查；多位评审盲评，对关键分歧复核。	加入“排版漂亮但事实错误”和“内容正确但格式一般”的对照成果，检查评分能否区分。
覆盖的任务不等于整个职业。原评测对工作类型和条件有明确限制。发布说明	同时报告人类复核和修正时间，并按职业和任务类型展示结果，避免仅用一个总分解释自动化价值。	在独立工作任务上验证：质量达标时，人类总投入是否减少。不能只用模型生成耗时推算生产率。

可以借鉴的做法： 用实际成果可以增加评测的实用价值，但经济意义需要另做验证。

8. ARC-AGI-2：保留简单题目形式，把精力放在新规则与人类测试上

怎么设计和评分？

François Chollet、Mike Knoop、Gregory Kamradt 等人的 ARC-AGI-2 保留输入—输出图格形式：给几个示例，再给新的输入，让系统填出对应输出。题目采用离散颜色和有限网格，输出可以直接检查。论文 §3

项目组织人类参与者试题，利用正确率和完成时间检查难度，也校准不同题目子集。公开题、用于评估的保留题、竞赛规则和成本要求共同构成项目；具体允许的尝试次数与资源应按所引用的比赛或榜单协议说明。论文 §4、发布与竞赛

优点与成功原因

题目形式简单，想测的问题清楚：能否用少量示例处理新的规则。 保留格式也方便已有工具继续使用。竞赛组织和公开资源为方法开发提供了参与方式；Gemini 和 Sonnet 4.6 都报告 ARC-AGI-2。Gemini、Sonnet

我的解释是，明确的研究目标和长期组织能力帮助它形成共同测试。不能把竞赛热度或图格分数直接解释成通用智能。

问题和改进

问题	可以怎么改	怎样检查改进有效？
大量搜索可能提高得分，费用却不同。作者在设计中专门讨论了暴力搜索与效率。论文	除最高分外，按相同费用、时间和尝试次数比较。	看方法优势在多个预算下是否存在，避免只比较最昂贵的一次结果。
人类能解的图格题，仍是一类有限任务。	增加独立设计的规则家族和其他交互任务作对照；明确哪些能力预计能够迁移。	检查提升是否跨任务家族出现，而不只在熟悉的图格形式中出现。
反复向保留集提交成绩，仍可能逐渐适应该集合。论文对前代长期反馈提出过此风险。论文	限制对保留集的反复试探，定期更换由独立人员构建、难度校准后的集合。	对比原集合与新集合的表现，并公布两组难度参照。代价是维护和历史比较更复杂。

ARC-AGI-3 已转向交互环境，是已有的扩展路线；它与 2 的任务不同，应单独分析，不能把发布新版本本身当作已经证明迁移能力。3 的发布

9. LiveCodeBench：让题目时间成为实验条件

怎么设计和评分？

Naman Jain 等人的原项目从 LeetCode、AtCoder、Codeforces 等竞赛收集题目，并记录发布时间。代码生成场景给题意和示例，由未展示的测试检查程序。原项目还设计了代码修复、代码执行和预测测试输出等场景，不能把某个模型报告的一行成绩理解为全部场景都测过。论文

近期 Qwen3.5 和 Kimi K2.5 使用的 v6，在仓库中标为包含 2023 年 5 月至 2025 年 4 月的 1,055 道题。仓库也区分较快的精简测试配置和完整测试。仓库、Qwen、Kimi

LiveCodeBench Pro 是另一项工作。 Zihan Zheng、Zerui Cheng 等人组织竞赛专家分析题目与失败代码，Gemini 3.1 Pro 使用的是 Pro；作者、任务和分数都要分别引用。Pro 论文、Gemini

优点与成功原因

新竞赛题提供了可持续获取题目的渠道，时间记录让污染风险更容易讨论。 可执行测试又便于自动比较。我的解释是，这既回应了旧代码题可能被模型见过的问题，也让模型团队容易接入熟悉的代码评测方式。

问题和改进

问题	可以怎么改	怎样检查改进有效？
最近发布的模型，不一定没有见过较早的题。 v6 题目截止于 2025 年 4 月，不能因为名称含 Live 就保证没有污染。仓库	写明任务时间窗口；尽可能使用确认晚于训练数据或模型冻结时间的新题。模型训练范围未知时明确标注。	在不同时间段、相近难度的题目上比较，并检查重复题与同题改写；新旧分差也可能来自难度变化，不能单独证明污染。
测试通过仍受测试覆盖影响；精简与完整配置也不同。仓库	对部分题目补充边界测试，用修改过的错误程序检查测试能否检出问题。	比较完整与精简测试的分歧，检查新增测试是否误拒合法程序。
竞赛编程成绩不能直接代表仓库维护、需求沟通或部署能力。	与仓库级任务分别报告，不把不同工作类型混成一个“会写代码”的结论。	在独立的软件工程任务上检查优势是否保留；不把更多竞赛题当成覆盖范围已经扩大。

可以借鉴的做法： 时间、题目来源和测试配置都应进入成绩说明；名称里的“新”或“live”不能代替验证。

这些设计共同说明了什么？

它们的成功并不是来自同一种设计。BrowseComp 让答案容易检查；τ² 搭建了可控制的交互世界；Terminal-Bench、OSWorld 和 WebArena 提供了任务环境；HLE 与 GDPval 依赖专家组织。共同点是：它们把一个当时重要的问题，做成了其他团队能使用的测试。

但每个优点也有代价：

设计选择	得到了什么？	需要补上什么检查？
用短答案或自动测试评分	成本较低，便于比较	答案是否完整，测试会不会误判，是否漏掉过程问题
使用真实网页和软件	更接近使用场景	环境变化、初始化失败和复现问题
筛选能难倒当前模型的题	更容易区分当时的强模型	是否偏向特定模型弱点，是否仍代表想测的能力
公开数据、代码和参考解	更容易研究、复现和采用	训练或搜索时接触答案的风险
经常修订题目和评分	结果更可靠，项目寿命更长	版本区分、重跑成本与历史结果是否可比

理解一个 benchmark 时，更有用的问题是：哪一个设计解决了哪一个问题，它又引入了什么代价，我们怎样测量这个代价。 “真实”“难”“全面”都需要这些具体解释。

三个值得验证的改进方向

以下是从案例整理出的研究建议，尚未验证效果，也不声称是全新的方向。

系统检查评分器。 收集合法的不同解、表面正确的错误解和违规完成的轨迹，由专家确认，再比较评分器的误拒与误放。研究结果应包括准确性、审核成本和不同任务上的表现。
分开测模型、工具与运行条件。 固定任务，让同一模型使用不同框架，或让同一框架使用不同模型；再控制预算与环境。这样才能解释分差来自哪里。
同时测稳定条件与真实变化。 例如固定资料库与实时网页分别评测，再检查两边的结果是否一致。稳定性和实际适用范围需要同时报告。

一个评分代码的局部检查

核对 BrowseComp 参考实现时，可以看到一个具体的不一致：在 commit 652c89d 中，解析函数返回 correct: yes，调用者随后却与 yes 比较。按这条路径，即使模拟评分器作出肯定判断，也不会被计为正确。固定版本第 92–108 行

从该版本提取函数，用模拟评分器输出进行了局部检查。检查没有调用模型、读取测试题或运行完整 benchmark。关键的字符串比较可以简化为：

import re

reply = "correct: yes"                 # 模拟评分器的输出
parsed = re.search(r"correct: (yes|no)", reply).group(0)
print(parsed == "yes")                 # False：parsed 仍包含 "correct: "

这个发现只针对所检查的参考代码版本，不能据此认定论文或模型公司使用了同一条代码路径，也不能推断其公开成绩错误。 它提示我们：除了审核题目，还应给评分代码准备确定的正确、错误和无法解析样例。

来源与范围

本文按所引用的版本描述方法，后续修订单独注明。关于采用原因的解释来自公开记录，没有进行作者访谈或因果对照。改进建议都附有验证方法，但尚未在本文中验证效果。除评分解析的局部检查外，没有完整复跑 benchmark，也没有在本文中复制测试题和答案。

主要资料按案例列在下面；正文中的链接对应具体陈述的依据。

Terminal-Bench：论文、时间线、任务仓库、Harbor、2.1 修订、4.0 发布、持续维护方法、资源配置实验。
BrowseComp：论文、作者介绍、固定版本评分代码、BrowseComp-Plus 论文、后续项目。
τ 系列：τ² 论文、环境评分器、指标实现、仓库和版本说明、τ³ 发布。
OSWorld：原始框架、Verified 修订、2.0 论文。
WebArena： 项目、原论文、仓库、固定版本评分器、CUA 采用记录、Magentic-One 与数据划分。
WebArena 后续工作： Verified 工作坊论文介绍、固定版本仓库、回答格式、数据统一规则、网络记录评测、Pro 介绍。
HLE：初版论文、最终版与评分说明。
GDPval：论文、发布说明、GDPval-AA 方法。
ARC：ARC-AGI-2 论文、发布与竞赛、ARC-AGI-3 发布。
LiveCodeBench：原论文、仓库和版本、Pro 论文。
采用记录：GPT-5.2、GPT-5.4、GPT-5.6、Claude Opus 4.6、Claude Sonnet 4.6、Gemini 3.1 Pro、Qwen3.5、Kimi K2.5、Artificial Analysis 指数。