TL;DR一篇 2026 年 5 月 20 日提交的 arXiv 论文 (arXiv:2605.21404) 审计了 12 篇知名 LLM Agent 评测论文,关注的不是分数对不对,而是它们有没有把怎么跑出来的说清楚。结论很令人警醒:8 篇 Agent 评测论文的平均披露分只有 0.38(满分 1.0),而 4 篇传统静态评测是 0.66。最大的黑洞是成本(8 篇全都没披露推理花费)和测评环境(没人给出内容寻址的容器镜像)。本文拆解它的审计方法,并谈谈对算法工程师做评测的启示。一、问题的起点:同一个 benchmark,两篇论文打架做过 Agent 评测的人都遇到过这种崩溃时刻:两篇论文报告同一个 benchmark、同一个模型名,分数却对不上。你想搞清楚到底差在哪——是脚手架 (scaffold) 不同?采样温度不同?用了不同子集?还是 evaluator 版本变了?——结果翻遍论文和开源仓库,根本找不到答案。这篇由 Mahdi Naser Moghadasi(BrightMind AI / Texas Tech)与 Faezeh Ghaderi(UT Arlington)合著的论文,正是从这种familiar frustration出发。作者明确把它定位成一份实现报告 (implementation report):不是又造一个新 benchmark,而是退一步审视——现有评测论文,到底有没有把实验过程写到可复现的程度。二、审计方法:五个字段的打分表作者设计了一个轻量的审计 schema,只看五个维度:Benchmark identity(基准身份):用的是哪个版本、哪个子集,说清楚了吗?Harness specification(测评框架规格):跑评测的脚手架、环境长什么样?Inference settings(推理设置):温度、采样、最大步数等。Cost reporting(成本报告):跑一次花了多少 token / 多少钱?Failure breakdown(失败拆解):失败案例的分类与统计。注意一个关键的方法论边界:作者只给披露程度打分,不给结果正确性打分。论文里写得很直白——披露充分不代表结果可信,它只代表你能看懂这个 run 是怎么跑的。这个区分很重要,它把诚实度和正确性解耦,避免把两件事混为一谈。为了让打分可复现,他们还写了一份 codebook(记录打分时遇到的边界情形),由单个审计员一次性完成全部打分,并坦承多评分员审计 (multi-rater audit) 才是下一步该做的事。这种对自身局限的诚实,恰恰是论文想倡导的风气。三、那个 0.38 说明了什么样本是 12 篇 canonical 论文:8 篇 Agent 评测、4 篇传统静态评测。结果是 Agent 组平均 0.38、静态组平均 0.66。差距最大的两项尤其突出:成本:8 篇 Agent 评测论文里,没有一篇以任何形式披露推理成本。这对 Agent 尤其致命——Agent 动辄几十步调用,跑一遍的开销可能差一个数量级,但论文里只报准确率,读者完全无法判断这个分数是用 5 倍预算堆出来的,还是真的更聪明。测评环境:没有一篇完整给出内容寻址 (content-addressed) 的容器镜像。也就是说,即便你想原样复现它的环境,也拿不到一个哈希锁定、保证一致的镜像。为什么 Agent 评测比静态评测的披露更差?一个合理的解释是:Agent 评测的活动部件太多了。静态 benchmark 基本是输入题目—对答案,而 Agent 评测要规定脚手架、工具集、环境状态、多轮交互、超时与重试策略……维度一多,作者要么没意识到要写,要么觉得写不完,于是干脆略过。四、对算法工程师的启示这篇论文没有给出惊艳的新模型,但它的价值在于把一个被长期忽视的工程问题摆上台面:Agent 评测正在重蹈不可复现的覆辙。实用的做法是把这五个字段当成你自己发评测时的 checklist:把脚手架版本、推理设置、单次运行成本、失败分类都写进附录,并尽量发布一个哈希锁定的环境镜像。作者已经把 schema(JSON Schema)、codebook(Markdown)和原始打分表(CSV)全部开源,可以直接拿来当模板。更深一层,它提醒我们:当整个领域都在卷 SOTA 分数时,这个分数怎么来的反而成了稀缺品。一个连成本都不报的 0.38 披露度,意味着今天大量 Agent 排行榜的可信度,可能远低于我们以为的水平。参考资料What Twelve LLM Agent Benchmark Papers Disclose About Themselves: A Pilot Audit and an Open Scoring Schema — arXiv:2605.21404HTML 全文版 — arXiv:2605.21404v1
你的 Agent 跑分到底可不可信？读一篇 LLM 评测“透明度审计
TL;DR一篇 2026 年 5 月 20 日提交的 arXiv 论文 (arXiv:2605.21404) 审计了 12 篇知名 LLM Agent 评测论文,关注的不是分数对不对,而是它们有没有把怎么跑出来的说清楚。结论很令人警醒:8 篇 Agent 评测论文的平均披露分只有 0.38(满分 1.0),而 4 篇传统静态评测是 0.66。最大的黑洞是成本(8 篇全都没披露推理花费)和测评环境(没人给出内容寻址的容器镜像)。本文拆解它的审计方法,并谈谈对算法工程师做评测的启示。一、问题的起点:同一个 benchmark,两篇论文打架做过 Agent 评测的人都遇到过这种崩溃时刻:两篇论文报告同一个 benchmark、同一个模型名,分数却对不上。你想搞清楚到底差在哪——是脚手架 (scaffold) 不同?采样温度不同?用了不同子集?还是 evaluator 版本变了?——结果翻遍论文和开源仓库,根本找不到答案。这篇由 Mahdi Naser Moghadasi(BrightMind AI / Texas Tech)与 Faezeh Ghaderi(UT Arlington)合著的论文,正是从这种familiar frustration出发。作者明确把它定位成一份实现报告 (implementation report):不是又造一个新 benchmark,而是退一步审视——现有评测论文,到底有没有把实验过程写到可复现的程度。二、审计方法:五个字段的打分表作者设计了一个轻量的审计 schema,只看五个维度:Benchmark identity(基准身份):用的是哪个版本、哪个子集,说清楚了吗?Harness specification(测评框架规格):跑评测的脚手架、环境长什么样?Inference settings(推理设置):温度、采样、最大步数等。Cost reporting(成本报告):跑一次花了多少 token / 多少钱?Failure breakdown(失败拆解):失败案例的分类与统计。注意一个关键的方法论边界:作者只给披露程度打分,不给结果正确性打分。论文里写得很直白——披露充分不代表结果可信,它只代表你能看懂这个 run 是怎么跑的。这个区分很重要,它把诚实度和正确性解耦,避免把两件事混为一谈。为了让打分可复现,他们还写了一份 codebook(记录打分时遇到的边界情形),由单个审计员一次性完成全部打分,并坦承多评分员审计 (multi-rater audit) 才是下一步该做的事。这种对自身局限的诚实,恰恰是论文想倡导的风气。三、那个 0.38 说明了什么样本是 12 篇 canonical 论文:8 篇 Agent 评测、4 篇传统静态评测。结果是 Agent 组平均 0.38、静态组平均 0.66。差距最大的两项尤其突出:成本:8 篇 Agent 评测论文里,没有一篇以任何形式披露推理成本。这对 Agent 尤其致命——Agent 动辄几十步调用,跑一遍的开销可能差一个数量级,但论文里只报准确率,读者完全无法判断这个分数是用 5 倍预算堆出来的,还是真的更聪明。测评环境:没有一篇完整给出内容寻址 (content-addressed) 的容器镜像。也就是说,即便你想原样复现它的环境,也拿不到一个哈希锁定、保证一致的镜像。为什么 Agent 评测比静态评测的披露更差?一个合理的解释是:Agent 评测的活动部件太多了。静态 benchmark 基本是输入题目—对答案,而 Agent 评测要规定脚手架、工具集、环境状态、多轮交互、超时与重试策略……维度一多,作者要么没意识到要写,要么觉得写不完,于是干脆略过。四、对算法工程师的启示这篇论文没有给出惊艳的新模型,但它的价值在于把一个被长期忽视的工程问题摆上台面:Agent 评测正在重蹈不可复现的覆辙。实用的做法是把这五个字段当成你自己发评测时的 checklist:把脚手架版本、推理设置、单次运行成本、失败分类都写进附录,并尽量发布一个哈希锁定的环境镜像。作者已经把 schema(JSON Schema)、codebook(Markdown)和原始打分表(CSV)全部开源,可以直接拿来当模板。更深一层,它提醒我们:当整个领域都在卷 SOTA 分数时,这个分数怎么来的反而成了稀缺品。一个连成本都不报的 0.38 披露度,意味着今天大量 Agent 排行榜的可信度,可能远低于我们以为的水平。参考资料What Twelve LLM Agent Benchmark Papers Disclose About Themselves: A Pilot Audit and an Open Scoring Schema — arXiv:2605.21404HTML 全文版 — arXiv:2605.21404v1
