CodexQA

Industry & PracticeResearch & Benchmarks

静默的仪器误差重排智能体排行榜

CodexQA 团队32 min read

在 41 项触及数据库的任务上,通用智能体比专用支架低 13 分,因为它的回合大约只有一半被评分。按同一规则给未评分的一半评分后,合在一起的差距收成平局。一次误读四个文件的重评分还让分数下降 59 到 82 分。

In this piece

静默的仪器误差重排智能体排行榜

Yangze Liu,单位:山东大学(Shandong University)

摘要

在一个公开的智能体排行榜上,通用智能体在触及数据库的任务上比一个为航空公司客服基准搭建的支架低 13 分,读者可能得出结论:通用性以精度为代价。这一差距来自评分器。通用智能体经常以一种永远不会触发评分的方式结束对话,因此它的回合大约只有一半被评分,其余被存成失败。按该基准自己的规则给未评分的那一半评分,合在一起的差距就消失了,而且不用重跑任何智能体。我们只根据已发布制品审计两个维护仔细的公开排行榜 HAL 和 \tau^{2}-bench,又发现三种仪器误差。一列成本把嵌套的模型调用算了两次,而且各行不均匀。归档轨迹把评分器写出的动作记成智能体动作。在更新的评估器下对已保存轨迹重新评分,本身就是一次新的测量:一项正确且已宣布的修复会重排排行榜,而一次误读四个文件的模式检查使它们的分数下降 59 到 82 分,同时不打印任何错误。每一种都产出了一个看上去合理的数字,HAL 维护者在五周内确认了他们的三项。这些案例合在一起表明,智能体评测的基础设施,也就是给评测评分、记日志、重放和版本化的代码,是测量的一部分,并且会静默失败,因此分数和排序可以在没有任何可见迹象的情况下移动。这些失败模式来自智能体评测流水线的构建方式,而这些流水线变化得和它们所测量的智能体一样快,因此我们预期别处还有更多。我们提出能暴露仪器的廉价检查:报告被评分的比例,从根跨度汇总成本,给每一个被记录动作标注来源,并用一份公开的重评分差异钉住评估器版本。

1 引言

整体智能体排行榜(HAL)在 TAU-bench Airline 上评估智能体。这是一个客服基准,智能体在其中为模拟客户更改航班预订 [6, 16]。HAL 在 Tool-Calling(一个为该基准编写的支架)和它自己的 Generalist 智能体下运行了相同的模型。在 HAL 为两种支架都运行过的九个模型所发布的结果中,在 50 项任务里参考解会查询或更改数据库的 41 项上,Generalist 落后 13 分,并且其中八个模型都落后。读者会得出结论:通用智能体在任务专用基准上付出很大代价。这个结论是评分器制造的。TAU-bench 只在回合正式结束时计算奖励,而 Generalist 经常以一种不触发该结束的方式关闭回合,因此它的回合大约只有一半曾经被评分,其余被记成失败。当未评分的回合按同一规则离线评分时,两种支架合在一起的差距收成平局,大多数按模型的差距缩到几点,而回合本来就已经被评分的 Tool-Calling 几乎不动(图 1)。

这一差距来自那些为严格智能体评测设定议程的人所建的排行榜。Kapoor 等人主张,智能体基准应当在精度旁边报告成本,而且评测实践缺乏可复现结果所需的标准化 [5]。HAL 是回应这一呼吁的基础设施,它有一套旨在去掉常见实现缺陷的共享支架,并发布完整轨迹供任何人检查 [6]。如果仪器在这里也能静默失败,粗心就不是正确的解释。错误存在于智能体评测流水线被组装起来的方式之中,其他流水线也是按同样的方式建造的。

这些流水线还在不断变化。智能体支架、追踪库、模拟器和评估器都以周为尺度发布新版本,公开排行榜积累的是在许多这些版本下产出的行。每个版本都是一件略有不同的仪器。二月提交的模型和七月提交的模型可能由不同的评分代码打分,而排行榜把两个数字放在同一列里,仿佛一根尺子产出了它们。这个领域已经学会问是哪个模型版本、哪个支架产出了分数。它很少问是哪一件仪器。

仪器误差难以看见,因为分数不携带它是如何制成的痕迹。跳过一个回合的评分器返回零,看起来像失败。把一次调用算两次的成本汇总器返回一个落在其他美元数字范围内的美元数字。静默丢掉一部分环境的重评分返回一个介于零和一之间的通过率。基准审计考察任务和奖励规则是否健全 [18],HAL 小组最近的一份综述把支架和自动评分器算进智能体评测现在必须审视的表面 [4]。然而,把这些规则应用到某一条轨迹、记录它、给它计价并存储它的运行时代码,在排行榜发布之后很少被重新推导。

本文从已发布制品重新推导两个公开排行榜 HAL 和 \tau^{2}-bench 的运行时仪器。我们发现支持一个结论:仪器必须作为测量的一部分被审计,排行榜应当公布让读者能够审计它的少数几个数字。第 2 节解释为什么智能体评测特别容易暴露。第 3 节呈现我们发现的四种误差,每一种都来自公开制品,没有运行智能体。即使一项正确且已宣布的评估器修复也会重排排行榜:一次有文档的 \tau^{2}-bench 重评分把一个模型从第九名移到并列第五。第 4 节把四个案例放在一起读。第 5 节提出现在就便宜到可以采纳的检查,第 6 节讨论这些案例对修复、粗比较、披露和开放发布意味着什么。HAL 维护者在他们自己的归档上复现了三项 HAL 误差,并在我们报告后的五周内给排行榜加上披露 [8]。这一回应是披露最好的样子,而归档中的数字仍然是原来的样子。

2 为什么智能体评测容易暴露

第 3 节的四个案例支持一个主张。决定智能体何时被评分、什么被记录和计价、轨迹如何被重放、以及哪个评估器版本适用的代码,是测量的一部分。它变化得和智能体一样快,它的误差产出的是看上去合理的数字而不是失败,因此排行榜应当在分数旁边公布对仪器的检查。

静态基准较少暴露于此。问答基准把一个字符串与参照比较一次,在一个函数里,评分代码很少依赖于模型在回答之前做了什么。智能体评测在四个地方不同,每一处都给误差留下藏身之处。

评分由智能体行为触发。在交互式基准中,评分器在回合结束时运行,而回合在智能体或模拟用户做了某件特定的事时结束,例如调用一个终止工具或发出停止词元。一个结束对话的方式与基准作者所想不同的支架,因此可以改变评分是否发生,而缺失的评分通常被存成失败。

日志有层次。一次模型调用经过支架、包装库和供应商客户端,现代追踪在每一层都做检测。成本或词元合计是否正确,取决于汇总器把哪些层加起来。这一选择在合计中不可见,并且随每次运行碰巧采取的客户端路径而变化。

重放写进记录。为了决定智能体是否到达正确的终态,有状态的评分器常常把黄金动作通过智能体所用的同一个环境对象重放。环境在那次重放期间记录的任何东西,都坐在与智能体自己的动作相同的列表和日志里,轨迹归档把它继承下来。

评估器和归档以不同速度移动。基准发布新的评分代码和新的任务标准,而旧结果留在排行榜上,旧轨迹留在存储里。在新代码下对已保存轨迹重新评分,被当作保持结果可比的办法提供出来,但它是一次新的测量,其正确性取决于新代码是否理解旧文件。一旦支架被归档,如 HAL 的仓库在 2026 年 7 月那样,更正往往以注释的形式到来,旁边的数字则保持原样。

3 四种仪器误差

我们从它们所发布的内容重新推导两个公开排行榜的若干部分:HAL 在 Hugging Face 上的加密追踪归档,其自己发布的脚本可以解密;以及 \tau^{2}-bench 的排行榜和仓库轨迹 [6, 3]。没有运行智能体,也没有调用模型。HAL 的数字用独立编写的代码第二次重算,每一个数字都可以从已发布脚本复现 [9]。表 1 把四个案例并排放在一起,附录 A 给出步骤。

表 1:四个案例。没有一个案例里流水线抛出错误,每一个都产出了落在读者会预期的范围内的数字。

案例分数声称的内容仪器实际做的事它移动了多少
HAL 成本一次运行中智能体花费的美元对一个包装跨度及其子跨度上的用量求和,而它们携带同一次响应134 次运行中有 70 次恰好为 2 倍,46 次为 1 倍
HAL Generalist 评分Generalist 支架的精度只给智能体移交或模拟用户关闭的回合评分,其余存成失败从 0.30 到 0.43,把相对 Tool-Calling 的 13 分差距收掉
HAL 轨迹智能体采取的动作把评分器的黄金重放写进智能体的动作列表出现在 2334 条航空记录的 68% 中
\tau^{2}-bench 重评分同一条轨迹再次被评分应用新标准,或在没有用户工具的情况下重建环境航空上为 -7 到 +2.5 分,电信上最多 -82

3.1 把某些调用算两次的成本列

HAL 的成本列是 Kapoor 等人所呼吁的成本感知评测的实现,而对许多行,它报告的钱是实际花费的两倍。支架用一个追踪库记录模型调用,其中一次包装调用和它所作出的供应商客户端调用表现为父跨度和子跨度,带有相同的响应和相同的用量块。汇总对每一个跨度上的用量求和,因此只要出现嵌套,词元和美元就被算两次。在有日志的运行中,略多于一半的运行所报告的词元恰好是根跨度词元的两倍,我们能够匹配到已记录归档的 94 个排行榜行中有 44 个在归档自己的结果字段里带有加倍的成本。加倍跟随一次运行所走的客户端路径,而该路径取决于支架和模型的供应商。在 SciCode 上,全部十次零样本运行都是干净的,而另外两个支架的大多数运行大约是其成本的两倍,因此一个基准的成本轴混着加倍的行和未加倍的行。

统一的两倍因子只会重新缩放这条轴。不均匀的因子会让点彼此相对移动,而 HAL 之所以存在、要画出的成本–精度前沿会改变形状。一行显示这有多么不可见:高推理设置下带 Claude Opus 4.1 的 Tool-Calling 支架被列为一次运行 149.98 美元,而其根跨度成本是 74.99 美元。两个数字都是五十项航空任务可信的价格,行里没有任何东西告诉读者哪一个是真的。HAL 论文在为自己的日志分析准备文本记录时去掉“任何与 weave 日志相关的冗余调用” [6],因此重复在流水线的一部分被处理了,却没有在计算成本列的那一部分被处理。这是组件由不同的人在不同时间编写时会打开的那种缝隙。

3.2 只在一半时间里被评分的智能体

Generalist 在 TAU-bench 上较差的排名,很大程度上是对其回合如何结束的度量。在 TAU-bench 中,奖励只在回合完成时计算,而这发生在智能体调用终止工具,或模拟用户用停止词元回答一条消息时 [16]。Generalist 把自己的循环跑到完成,向用户发送一条结束消息然后退出。如果它沿途把客户交给了人工座席,那次移交是终止工具,评分器就会运行。否则结束消息是未经请求的,模拟器通常不会用停止词元回答它,后面也没有进一步的步骤,因此数据库从未被比较,回合以奖励零存储。把评分器的动作与智能体自己的工具调用在原始日志中分开(第 3.3 节),可以看出哪些回合被评分了。Tool-Calling 在其回合的 98% 中被评分,Generalist 为 51%。它未评分的回合完全不含结束事件,结束在一条给用户的消息上,中位动作数为九,远低于任何步数上限。

离线给这些回合评分,收掉了 Generalist 相对 Tool-Calling 合在一起的劣势。把智能体自己的动作通过被钉住的环境重放,并用基准自己的奖励函数,Generalist 在这 41 项任务上合在一起的精度从 0.30 升到 0.43,Tool-Calling 几乎不动,因为它的回合本来就已经被评分。在两种支架下都运行过的九个模型上,已发布的、有利于 Tool-Calling 的 13 分差距变成平局。在这个排行榜上,两种支架之间的差别是评分器是否运行。

纠正的一部分不能来自什么都不做。合在一起的增益大部分来自黄金只读取数据库的任务。基准规则在回合让数据库保持原样时就通过这些任务,正如它通过另一个支架已被评分的回合。在黄金要求写数据库的任务上,未被触碰的数据库会失败,而 Generalist 仍然从 0.28 升到 0.33。在这些任务上通过的 23 个未评分回合,每一个都在智能体自己的工具调用中包含所需的写入。这些是被记成失败的已解决任务。

按模型看,这一纠正把每一次比较都推向 Generalist,并改变一个模型上两种支架的顺序,即 gemini-2.0-flash(图 1)。按已发布结果,九个模型中有八个 Generalist 落后于 Tool-Calling;一旦每个回合都被评分,则是七个。逐次运行看,给每个回合评分,逆转了这 41 项任务上 27 次已归档的 Generalist 与 Tool-Calling 运行之间 351 个成对排序中的 48 个。一个模型的格子含有一到两次运行,每次大约 41 条记录,因此这些数据并不能分辨最终落在零附近几点之内的按模型差距,我们依托它们的主张是移动的方向。HAL 还运行了第三个支架 Few-Shot,并在自己的日志分析发现演示中有基准任务之后撤回了其结果 [6]。与其归档追踪的比较以同样的方式移动,如附录 A 所报告。这些支架在设计上仍然不同,因为它们在不同的步数预算下运行,而且 Tool-Calling 把航空政策放在系统提示里,而 Generalist 必须打开文件才能读到它,因此纠正后的比较是按所建成的支架之间的比较,现在评分方式相同。它不再支持的读法是:通用智能体在这个基准上付出很大代价。

图 1:HAL 的 TAU-bench Airline 上 Generalist 对 Tool-Calling,针对两种支架都运行过的九个模型,记录的黄金至少含一个非终止动作,按每个模型的运行合并。箭头从 Generalist 的已发布精度指向每个回合都被评分时的精度。三角形是同样重评分之后的 Tool-Calling,它最多移动 2.5 分。最上面一行合并全部九个模型,已发布差距在那里收成平局。星号标出两种支架改变顺序的那一个模型。每个按模型的行依托 40 到 82 条 Generalist 记录。HAL 撤回的 Few-Shot 在表 2 中。

图 1:HAL 的 TAU-bench Airline 上 Generalist 对 Tool-Calling,针对两种支架都运行过的九个模型,记录的黄金至少含一个非终止动作,按每个模型的运行合并。箭头从 Generalist 的已发布精度指向每个回合都被评分时的精度。三角形是同样重评分之后的 Tool-Calling,它最多移动 2.5 分。最上面一行合并全部九个模型,已发布差距在那里收成平局。星号标出两种支架改变顺序的那一个模型。每个按模型的行依托 40 到 82 条 Generalist 记录。HAL 撤回的 Few-Shot 在表 2 中。

3.3 含有评分器动作的轨迹

归档轨迹记录了智能体从未采取的动作。TAU-bench 的环境把每一个已执行动作追加到一个列表,而为了计算奖励,评分器重置数据,并通过同一个步进函数重放黄金动作,该函数把它们追加到同一个列表。HAL 把那个列表存成智能体采取的动作。把每条记录与原始日志中智能体自己的工具调用对齐,发现评分器的动作出现在 2334 条公开航空记录的 68% 中。它们通常坐在末尾。在以移交给人工座席结束的 Generalist 回合中,它们坐在中间,因为支架在评分器运行之后追加它的结束消息。在 58 条记录中,智能体根本没有作出工具调用,而记录却显示完整的黄金工具序列。

被注入的动作改变了记录关于智能体所说的话。逐字重放所存储的动作,在黄金至少有两个非终止动作的记录中,有 70% 复现了所记录的奖励;先去掉评分器的动作,一致率升到 92%。任何计数动作或在这些追踪上微调的人,读到的部分是评分器行为,而污染恰好在智能体做得最少的地方最强。这个案例的意义超出 HAL,因为轨迹归档现在被当作本身就是研究产品 [6, 7]。只剥掉每条记录末尾的读者会错过中间的副本,记录里也没有任何东西警告它们在那里。只有当流水线记录每一行是谁写的,日志才是关于智能体的证据。

3.4 版本不稳定的重新评分

\tau^{2}-bench 把重新评分当作在新评分代码下保持旧轨迹可比的办法,而这一操作本身是一次带有自身误差的新测量 [3, 15]。我们在四种评估器构建下对公开轨迹文件重新评分,并把评估器代码与任务数据交叉。结果分成三种,它们在可见程度上不同。

1.0.1 版本中的银行重评分被宣布了,它仍然重排了排行榜。更新日志警告银行分数跨该版本不可比,并说其评分修复只会把分数向上移动,一个被纠正的黄金值是可能使任务失败的例外。我们对成对仿真的重评分没有发现从通过变成失败的情况,全部移动都来自评估器代码,没有来自任务数据。在官方排行榜上,这次重评分仍然逆转了 17 份提交之间 136 个成对排序中的 4 个,并把 gemini-3-flash 从第九名移到并列第五。这是做得好的案例,它表明即使有文档的评估器变更也是一次排名事件。

航空重评分被列出来了,但没有被标记。1.0.0 版本在实质上改变了 50 项航空任务中 14 项的评估标准,同时数据库和政策不变,其更新日志列出任务修复,却没有关于可比性的警告。通过有文档的重评分命令应用到四个较旧的航空文件,新标准在两个方向上翻转 800 次仿真中的 77 次,使按模型的分数移动 -7 到 +2.5 分,并逆转 gpt-4.1-mini 与 claude-3-7-sonnet 的顺序。把一个被重评分的文件与一个没有被重评分的文件比较的读者,是在比较两件仪器。

电信重评分没有抛出错误。重评分命令通过匹配一个智能体名称来决定文件是否以单独模式记录,四个用密切相关的单独智能体记录的仓库文件落入非单独路径。重放环境随后在没有用户侧工具的情况下被建立,每一次被重放的用户调用都返回未找到消息,而在 1.0.1 引入的宽松重放下,命令按次调用警告,并针对一个从未收到那些更改的状态继续。四个分数下降 59 到 82 分,命令打印出一个数字。一个用被识别的单独智能体记录的伴随文件重评分到其记录分数,这就把原因隔离到模式检查。一个社区拉取请求修复了该检查 [1],但在此期间产出的任何分数看起来都和其他分数一样。

3.5 披露之后发生了什么

我们在 2026 年 9 月 3 日向维护者并在追踪数据集上报告了三项 HAL 事项,把 \tau-bench 的根因作为议题提交,并把 \tau^{2}-bench 事项作为议题提交 [8, 11, 10]。10 月 7 日,一位 HAL 维护者回复说,团队已在自己的归档上复现全部三项,并给排行榜加上披露,日期为 10 月 5 日。截至 2026 年 11 月 3 日,每个基准页面上的成本说明说,嵌套的追踪跨度把同一次 API 响应算了两次,这一高估在各行之间不均匀,成本尚未被重新推导。航空页面把 Generalist 行标为下界,不能与 Tool-Calling 行直接比较,其追踪通知告诉用户在把所记录动作当作智能体的动作之前,先去掉任务的参考动作,并补充说在一些记录中这些动作坐在内部,后面还有智能体动作。归档本身没有改变,维护者正在跟进 \tau-bench 议题以查找根因。截至 2026 年 11 月 3 日,\tau-bench 议题和 \tau^{2}-bench 议题没有维护者回复,单独模式检查的社区修复处于开放且未合并状态。带着完全确认的五周周转对任何项目都算快,而结果仍然是注释旁边的数字保持原样。

4 共同模式

四种误差在它们所产出的分数里都是静默的。没有一个抛出异常,没有一个产出读者预期范围之外的值,没有一个能只从分数检测出来。每一个都只是通过从更低层记录重算分数并比较才被发现。

每一种误差也来自一个局部上合理的决定。对所有跨度上的用量求和,是抓住每一次调用的自然方式。只在回合结束时计算奖励,是回合级奖励的自然定义。通过真实环境重放黄金,是建立参照状态最忠实的方式。让重放宽松,使工具改变之后旧文件仍可评分。失败来自各自合理、由不同的人在不同时间编写的组件之间的相互作用:一个追踪库和一个客户端库,一条基准的终止规则和支架的结束回合,一个评分器和一个归档器,一个评估器和一种更旧的文件格式。对任何一个组件的代码审查很可能都会让它通过。

这就是为什么我们预期,在还没有人重新推导的智能体排行榜里还有更多这样的误差。这一预期是来自机制的论证。每一个交互式基准都把评分门控在终止上,每一个新支架都带来自己的结束方式。每一个通过供应商客户端之上的包装库记日志的排行榜都可能嵌套跨度。每一个通过智能体环境重放黄金的有状态评分器都可能写进智能体的记录。每一个在保留旧结果的同时修订评分器的基准都面临版本问题。这些条件没有一条是 HAL 或 \tau^{2}-bench 特有的。找到这四项的搜索也很小:两个排行榜,在几天里从它们的公开制品阅读,没有智能体运行,没有模型调用。我们早先的工作在别处发现了同样的仪器与模型分离:在一个多轮函数调用基准中,其评分器从不看智能体应当提问的那一轮 [12];在编码智能体中,切换支架翻转的任务数和重跑同一配置一样多,因此单个通过率是分辨支架的错误仪器 [13]。产生它们的条件是常见的,找到它们是便宜的,而排行榜很少被重新推导,这正是未被发现的案例预期会多于已被发现案例的局面。

5 暴露仪器的检查

四种误差中的每一种,都会从流水线已经拥有的一个额外数字中可见。下面的检查每项只需几行代码,并且不要求改变任何任务或奖励规则。

报告被评分的比例。每一个排行榜格子都应当说明有多少回合到达了评分器,其余单独计为未评分。一个写着“精度 0.30,已评分 51%”的 Generalist 格子,会在任何结论被得出之前拦住读者。Rollout Cards 提议声明被丢弃和失败的运行 [14],被评分比例是同一想法用在一次运行内部。

从根跨度汇总成本并打印乘数。成本和词元应当只在根跨度上求和,或按响应标识去重,流水线应当报告每次运行的全跨度用量与根跨度用量之比。恰好为二的比率是任何读者都能认出的缺陷签名,打印它只花费一次除法。

给每一个被记录动作标注来源。每个被记录的动作都应当携带是谁产生的:智能体、用户模拟器或评分器。评分器的参照重放应当在单独的环境中运行,或写到单独的列表。记录里有来源,下游研究就可以过滤;缺少它的归档,不重新推导评分器就无法清洗。没有这个标签,读者必须从动作坐在哪里推断来源,而这一推断恰好在支架于评分器之后写入的地方失败。

钉住评估器版本并公布重评分差异。每一个分数都应当写出产出它的评估器构建和任务数据版本。一次重评分应当打印它作出的按任务变更,并在一次重放中不匹配的工具返回所占份额超过阈值时失败,而不是按次调用警告并返回一个数字。一个仍然开放的社区拉取请求,让 \tau^{2}-bench 的重评分命令报告不匹配计数,并把该阈值作为一个选项加上 [2]。当排行榜被重新评分时,前后对照表应当放在它旁边,正如 \tau^{2}-bench 已经为银行所做的。它的 2.0.0 版本走得更远,把 1.x 和 2.0 的结果放在分开的排行榜标签下,并警告它们不可比 [15]。最近一份综述建议对每一个基准组件做版本控制 [4],这项检查就是把该建议用到评分器上,并把重评分本身当作需要自己的差异的测量。

把勘误附在归档上,让它跟着走。冻结的归档不能被纠正,但它可以在数据集内部携带一份机器可读的勘误文件,列出已知的仪器误差、受影响的记录和纠正规则。网页上的通知到不了在它出现之前下载了追踪、或把一个数字抄进论文的人。

6 讨论

每一种误差都有一个小修复,HAL 维护者也行动得很快,但有两件事比修复活得更久。代码被修复时已发布的数字并不改变,因为归档是冻结的,排行榜行只计算过一次。更重要的是,这一类会复发。每个案例都来自组件之间合理的相互作用,因此修复一个组件,就把条件留给下一个支架或下一次发布。一类反复出现的静默误差需要一项能抓住这一类的检查,这就是第 5 节所提议的。

作为粗略指南来读,排行榜经得起这些误差,因为它们没有一个改变哪一代模型比哪一代更强。但它们并不小。成本轴上一些行乘以二而另一些行不乘,两种支架之间在每个回合都被评分时就会收掉的 13 分差距,以及一次把分数从 0.99 带到 0.17 的重评分,都是粗略指南的读者会据以行动的差别。按支架拆开结果、并把成本对精度作图的排行榜,邀请的正是这些误差所败坏的比较。

在 HAL 这个案例里,披露过程运转良好,我们毫无保留地肯定它。它仍然依赖于一位外部读者解密归档并重放评分器,这不是一个领域可以依赖的过程。披露也住在网页上,而被下载的轨迹和被抄走的数字在没有它们的情况下流通。一个只有在志愿者重新推导流水线时仪器误差才会浮出的系统,只会找到其中的一小部分。

发布代码和轨迹使这次审计成为可能,没有它们我们什么也找不到。然而,重跑已发布的代码会复现已发布的误差,而混合了评分器动作和智能体动作的轨迹归档同时是可复现的和错误的。开放对于审计仪器是必要的,它本身并不执行审计。

7 相关工作

Kapoor 等人主张,智能体评测应当计入成本,通过适当的留出防范过拟合,并标准化其实践以求可复现 [5],HAL 实现了共享支架并大规模发布日志 [6]。我们的案例取自那套基础设施。

对我们这一主张最接近的表述来自同一组人。他们 2026 年 10 月关于智能体评测的综述观察到,智能体评测所需要的支架、自动评分器和沙箱环境“本身就是新的审视表面”,警告一个被广泛采用的框架会集中其默认指标的影响,并建议对每个基准组件做版本控制,以便结果随时间保持可比 [4]。第 2 节的主张把这一看法收紧了,而不是首创它。本文加上的是证据:这一风险在被维护的公开排行榜上已经实现,并且大到足以重排它们,形式是四种带有对分数和排名之已测影响的静默误差,全部位于运行时流水线,没有一个位于基准设计。在我们的检查中,被钉住的评估器版本遵循该综述关于版本化的建议,而被评分比例、根跨度乘数、动作来源和归档内部的勘误,回答的是其实践没有覆盖的失败模式。该综述把 HAL 的标准化成本报告当作共享基础设施的例子,而那一成本列正是我们第一个案例发现对某些行加倍的那一列,这就是我们所说的:一件仪器可以是标准化的,同时仍然是错的。

Zhu 等人提出了智能体基准检查清单,它审计任务设置和奖励设计,并在其他问题之中报告 TAU-bench 把空回答计为成功 [18]。UTBoost 表明,SWE-bench 中不足的测试用例让错误补丁通过,并且一旦加上测试就会改变排行榜排名 [17]。两者考察的是基准的评分规则是否正确。我们把规则当作给定,考察已发布的运行时流水线在发布之后是否正确地应用了它、记录了它、给它计价并存储了它。两种审计是互补的,一个基准可以通过检查清单,而其排行榜仍然携带第 3 节的每一种误差。

Kirgis 等人主张,日志分析对可信的智能体评测是必要的,并在 TAU-bench Airline 上说明它 [7]。我们的第三个案例加了一个前提:日志必须说明每一条是谁写的,因为写进智能体记录的评分器会把日志分析变成对评分器的部分分析。Rollout Cards 把推出记录当作可复现性的单位,发现 50 个被审计的仓库没有一个报告失败或被跳过的运行,并表明只改变施加于固定推出的报告规则就可以逆转排名 [14]。他们关心的是施加于一份固定记录的规则。我们关心的是记录以及产出它的仪器本身可以是错的,而且仪器跨版本变化。\tau-bench 和 \tau^{2}-bench 是我们三个案例背后的基准 [16, 3],\tau^{2}-bench 为其银行重评分发布前后排行榜表的做法,是我们提议的重评分差异的样板。我们自己早先的论文报告了仪器与模型的进一步分离,分别在多轮函数调用 [12] 和编码智能体支架 [13] 中。

8 局限

我们的证据来自两个排行榜以及它们所托管的基准,别处类似误差常见这一预期依托的是第 4 节的机制,而不是一份调查。HAL 的重评分使用 HAL 设置所钉住的 \tau-bench 提交,并把用户模拟器打成桩,因此它们只评估数据库和输出标准。

9 结论

智能体评测已经学会问是哪个模型、哪个支架产出了分数。这里的案例表明,它还必须问是哪一件仪器产出了分数,因为仪器由快速移动的部件建成,它们的相互作用失败时没有声响。一个没有运行的评分器、一个被算了两次的成本、一个智能体从未采取的动作,以及一次重建了错误世界的重评分,看起来都像普通结果。修复是小的,而本来会暴露每一种误差的检查更小。这个领域需要的是把它们公布在每一个分数旁边的习惯,这样下一个静默误差由排行榜自己抓住,而不是由一位外部读者重新推导其归档。

致谢

我们感谢 HAL 维护者在他们自己的归档上复现并确认三项 HAL 发现,并给排行榜加上披露;也感谢提出单独模式检查和宽松重放之修复的 \tau^{2}-bench 贡献者。

参考文献

译注:参考文献共十八条,编号、作者顺序和链接与原文一致。每条先保留原文著录,再另起一行给出中文题名和中文著录,包括文献类型、版本日期、开启日期、回复日期和更正日期。作者姓名、仓库名、讨论编号、议题编号、预印本号和网址不译。这样读者可以按编号回查原文,同时不必靠英文题名才能知道每条文献在说什么。

[1] Abelo9996. Fix: Detect llm_agent_solo_gt as solo mode when re-grading trajectories. GitHub pull request sierra-research/tau2-bench #508, https://github.com/sierra-research/tau2-bench/pull/508, 2026a. 中文题名:修复:在重新评分轨迹时把 llm_agent_solo_gt 检测为单独模式。著录:GitHub 拉取请求 sierra-research/tau2-bench 第 508 号,2026a。

[2] Abelo9996. Feat(evaluate-trajs): Report how far a lenient replay diverged, and allow strict. GitHub pull request sierra-research/tau2-bench #573, https://github.com/sierra-research/tau2-bench/pull/573, 2026b. 中文题名:功能(evaluate-trajs):报告宽松重放偏离了多远,并允许严格模式。著录:GitHub 拉取请求 sierra-research/tau2-bench 第 573 号,2026b。

[3] Victor Barres, Honghua Dong, Soham Ray, Xujie Si, and Karthik Narasimhan. \tau^{2}-bench: Evaluating conversational agents in a dual-control environment. arXiv:2506.07982, 2025. 中文题名:\tau^{2}-bench:在双控制环境中评估对话智能体。著录:arXiv:2506.07982,2025。

[4] Felix Chen, Stephan Rabanser, Peter Kirgis, Nitya Nadgir, Rishi Bommasani, Magda Dubois, Elham Tabassi, Cozmin Ududec, Anka Reuel, Sanmi Koyejo, Sayash Kapoor, and Arvind Narayanan. Emerging trends in AI agent evaluation. https://sage.cs.princeton.edu/trends/, 2026. Version dated 19 October 2026. 中文题名:人工智能智能体评测的新兴趋势。著录:https://sage.cs.princeton.edu/trends/,2026。版本日期为 2026 年 10 月 19 日。

[5] Sayash Kapoor, Benedikt Stroebl, Zachary S. Siegel, Nitya Nadgir, and Arvind Narayanan. AI agents that matter. arXiv:2407.01502, 2024. 中文题名:要紧的人工智能智能体。著录:arXiv:2407.01502,2024。

[6] Sayash Kapoor, Benedikt Stroebl, Peter Kirgis, Nitya Nadgir, Zachary S. Siegel, Boyi Wei, Tianci Xue, Ziru Chen, Felix Chen, Saiteja Utpala, Franck Ndzomga, Dheeraj Oruganty, Sophie Luskin, Kangheng Liu, Botao Yu, Amit Arora, Dongyoon Hahm, Harsh Trivedi, Huan Sun, Juyong Lee, Tengjun Jin, Yifan Mai, Yifei Zhou, Yuxuan Zhu, Rishi Bommasani, Daniel Kang, Dawn Song, Peter Henderson, Yu Su, Percy Liang, and Arvind Narayanan. Holistic agent leaderboard: The missing infrastructure for AI agent evaluation. arXiv:2510.11977, 2025. 中文题名:整体智能体排行榜:人工智能智能体评测所缺少的基础设施。著录:arXiv:2510.11977,2025。

[7] Peter Kirgis, Sayash Kapoor, Stephan Rabanser, Nitya Nadgir, Cozmin Ududec, Magda Dubois, J. J. Allaire, Conrad Stosz, Marius Hobbhahn, Jacob Steinhardt, and Arvind Narayanan. Log analysis is necessary for credible evaluation of AI agents. arXiv:2605.08545, 2026. 中文题名:日志分析对可信地评估人工智能智能体是必要的。著录:arXiv:2605.08545,2026。

[8] Yangze Liu. Three reproducible measurement issues in these archives (cost double count, ungraded Generalist episodes, grader-injected actions). Hugging Face discussion #9 on agent-evals/hal_traces, https://huggingface.co/datasets/agent-evals/hal_traces/discussions/9, 2026a. Opened 3 September 2026, with a reply from the HAL maintainers on 7 October 2026 and a correction by the author on 2 November 2026. 中文题名:这些归档中三个可复现的测量问题(成本重复计数、未评分的 Generalist 回合、评分器注入的动作)。著录:Hugging Face 上 agent-evals/hal_traces 的第 9 号讨论,2026a。2026 年 9 月 3 日开启,HAL 维护者于 2026 年 10 月 7 日回复,作者于 2026 年 11 月 2 日更正。

[9] Yangze Liu. Measurement artifacts in two public agent leaderboards: Reports and reproduction scripts. https://github.com/YangzeLiu/eval-instrument-disclosure, 2026b. Released 3 September 2026, with corrections added 2 and 3 November 2026. 中文题名:两个公开智能体排行榜中的测量制品:报告与复现脚本。著录:https://github.com/YangzeLiu/eval-instrument-disclosure,2026b。2026 年 9 月 3 日发布,2026 年 11 月 2 日和 3 日加入更正。

[10] Yangze Liu. evaluate-trajs lenient replay re-grades llm_agent_solo_gt telecom files from 0.72 to 0.10 with no error. GitHub issue sierra-research/tau2-bench #502, https://github.com/sierra-research/tau2-bench/issues/502, 2026c. 中文题名:evaluate-trajs 的宽松重放把 llm_agent_solo_gt 电信文件从 0.72 重评到 0.10,且没有错误。著录:GitHub 议题 sierra-research/tau2-bench 第 502 号,2026c。

[11] Yangze Liu. Env.calculate_reward replays gold through self.step, appending gold actions to self.actions. GitHub issue sierra-research/tau-bench #92, https://github.com/sierra-research/tau-bench/issues/92, 2026d. 中文题名:Env.calculate_reward 通过 self.step 重放黄金,把黄金动作追加到 self.actions。著录:GitHub 议题 sierra-research/tau-bench 第 92 号,2026d。

[12] Yangze Liu and Zhongyi Han. Asking earns nothing: Scoring the decision to act in BFCL multi-turn. arXiv:2610.04429, 2026a. 中文题名:提问得不到分:给 BFCL 多轮中决定行动的那一步评分。著录:arXiv:2610.04429,2026a。

[13] Yangze Liu and Zhongyi Han. What does a harness buy? Tokens, mostly. arXiv:2610.04433, 2026b. 中文题名:支架买到了什么?主要是词元。著录:arXiv:2610.04433,2026b。

[14] Charlie Masters, Ziyuan Liu, and Stefano V. Albrecht. Rollout cards: A reproducibility standard for agent research. arXiv:2605.12131, 2026. 中文题名:推出卡片:智能体研究的可复现性标准。著录:arXiv:2605.12131,2026。

[15] Sierra Research. \tau^{2}-bench repository and CHANGELOG, releases 1.0.0, 1.0.1 and 2.0.0. https://github.com/sierra-research/tau2-bench, 2026. 中文题名:\tau^{2}-bench 仓库与更新日志,版本 1.0.0、1.0.1 和 2.0.0。著录:https://github.com/sierra-research/tau2-bench,2026。

[16] Shunyu Yao, Noah Shinn, Pedram Razavi, and Karthik Narasimhan. \tau-bench: A benchmark for tool-agent-user interaction in real-world domains. arXiv:2406.12045, 2024. 中文题名:\tau-bench:真实世界领域中工具–智能体–用户交互的基准。著录:arXiv:2406.12045,2024。

[17] Boxi Yu, Yuxuan Zhu, Pinjia He, and Daniel Kang. UTBoost: Rigorous evaluation of coding agents on SWE-bench. arXiv:2506.09289, 2025. 中文题名:UTBoost:在 SWE-bench 上严格评估编码智能体。著录:arXiv:2506.09289,2025。

[18] Yuxuan Zhu, Tengjun Jin, Yada Pruksachatkun, Andy Zhang, Shu Liu, Sasha Cui, Sayash Kapoor, Shayne Longpre, Kevin Meng, Rebecca Weiss, Fazl Barez, Rahul Gupta, Jwala Dhamala, Jacob Merizian, Mario Giulianelli, Harry Coppock, Cozmin Ududec, Jasjeet Sekhon, Jacob Steinhardt, Antony Kellermann, Sarah Schwettmann, Matei Zaharia, Ion Stoica, Percy Liang, and Daniel Kang. Establishing best practices for building rigorous agentic benchmarks. arXiv:2507.02825, 2025. 中文题名:为构建严格的智能体基准确立最佳实践。著录:arXiv:2507.02825,2025。

附录 A 这些数字是如何得到的

HAL 在 Hugging Face 上发布 380 个加密追踪归档,其网站上的解密脚本使用固定口令。我们解密了 TAU-bench Airline、ScienceAgentBench 和 CORE-Bench Hard 的 138 个归档,以及用于成本分析的 SciCode 和 SWE-bench Verified Mini 归档。

成本案例对每次运行比较三件事:归档所报告的词元用量、对所有已记录调用的求和,以及只对根调用的求和。在有日志的 134 次运行中,有 133 次所报告的用量等于全部调用之和,这直接识别出汇总规则。在调用带有用量数据的 133 次运行上,所报告的成本比根跨度成本高出 36.5%,一次调用不带用量块的 CORE-Bench 运行被排除,因为两种求和都无法形成。

对 TAU-bench 案例,我们安装了 HAL 的基准设置所钉住的 \tau-bench 提交,并通过环境重放所记录的动作,语言模型客户端和用户模拟器被打成桩,这样评分评估的是数据库比较和输出检查,没有任何模型调用。为把评分器的动作与智能体的动作分开,我们从每个归档中记录的模型输出解析智能体自己的工具调用,并按顺序、依照工具名和参数,把它们与所记录的动作列表对齐。没有匹配智能体调用的已记录动作就是评分器的。当记录在任何位置持有黄金动作的这样一个被注入副本,或其记录奖励为正时,该回合计为已评分。我们第一次审计于九月报告在 HAL 讨论页上,使用了更简单的规则,只在黄金动作构成记录末尾时把回合计为已评分,该规则错过了 73 个 Generalist 回合,其唯一的注入副本坐在记录中间。这里的数字取代那份报告,更正发在同一讨论中 [8]。HAL 从其一个分叉安装智能体,该分叉的航空黄金在 50 项任务中的三项上与被钉住的提交不同,因此每一次重评分也对照嵌入每条记录的黄金运行,这不改变合在一起的数字。

两项检查支持这一分类。在每一个被记录的结束事件上重新运行评分器,并使用嵌入记录的黄金,对全部 1951 条已评分记录复现了所记录的奖励。只在已评分回合上重放智能体自己的动作,对 Tool-Calling 记录的 97%、Few-Shot 的 97% 和 Generalist 的 84% 复现了所记录的奖励,而且几乎每一次 Generalist 的不一致都是评分器通过、离线重放失败的回合,因此对未评分回合的离线重评分如果说有偏差,是低估了 Generalist。正文中合在一起的数字,把每个支架的全部运行合并到黄金至少含一个非终止动作的记录上。表 2 给出图 1 背后的按模型数值。把撤回的 Few-Shot 追踪包括进来,按已发布结果,在有第二个支架的十个模型中,Generalist 在九个上是三个支架里的最后一名;一旦每个回合都被评分,则在六个上是最后一名,同时它在 claude-3.7-sonnet 上是第一,在 gemini-2.0-flash 上与 Few-Shot 并列第一,在 deepseek-r1 上与它并列最后,在 deepseek-v3 上是第二。

表 2:HAL 上按模型的 TAU-bench Airline 精度,记录的黄金至少含一个非终止动作,按每个模型的运行合并。Tool-Calling 和 Few-Shot 在重评分之后显示,这使 Few-Shot 不变,只移动 claude-3.7-sonnet 的 Tool-Calling(已发布为 0.48)和 gpt-4.1(已发布为 0.27)。HAL 因测试集泄漏撤回了 Few-Shot,其归档追踪供参照显示。claude-opus-4 没有 Tool-Calling 运行。

GeneralistTool-Generalist,Generalist,Few-Shot
模型记录数Calling已发布全部已评分(已撤回)
claude-3.7-sonnet810.490.520.600.46
claude-opus-482n/a0.410.500.57
claude-opus-4.1820.510.370.500.55
deepseek-r1410.310.100.240.24
deepseek-v3410.380.170.370.22
gemini-2.0-flash410.220.200.320.32
gpt-4.1410.290.200.270.51
gpt-5820.440.340.430.50
o3400.490.200.380.46
o4-mini820.410.180.380.49

Found it useful? Pass it on

WeChat

Scan with WeChat to open it on your phone and forward it.

Subscribe via RSS

Submit a correction