Agent 当裁判光看 Trajectory 不够，它得自己去环境里查证 —— AJ-Bench 论文解读

Agent 当裁判光看 Trajectory 不够它得自己去环境里查证 —— AJ-Bench 论文解读核心摘要我们做 Agent RL 训练的时候有个特别恶心的问题用 LLM-as-a-Judge 给 trajectory 打分模型经常一本正经地胡说八道。比如让它判断某论文最新版的发布日期是不是 2025-08-09它没法上网查到头来只能我无法确认或者瞎蒙一个。这篇来自中科大、新国立和美团的工作把让 Judge 也变成 Agent这件事第一次系统化做出来了 —— 给 Judge 配上浏览器、文件系统、Postgres、PPT/Word/Excel 等 60 个工具让它自己去环境里复现状态、查证据、再下结论。实测下来同一个 base model开启 Agentic 模式之后平均 F1 涨 13 个点gpt-5-mini-low 从 59.0 涨到 72.4deepseek-v3.2 从 64.5 涨到 77.3。更有意思的是开了工具的 deepseek-v3.2反过来把不开工具的 gpt-5、claude-opus-4.5 都甩在身后。但论文也很坦诚地说F1 离饱和还远60–80% 的 failure case 是工具调对了、证据拿到了结论却推错了或者看不懂工具输出—— 这暴露的是另一个层面的能力鸿沟。值得一读尤其如果你正在搞 Agent 强化学习、Reward Modeling、或者在思考 LLM-as-a-Judge 在复杂任务上为什么不靠谱。论文信息标题AJ-Bench: Benchmarking Agent-as-a-Judge for Environment-Aware Evaluation作者Wentao Shi*, Yu Wang*, Yuyang Zhao*, Yuxin Chen, Fuli Feng, Xueyuan Hao, Xi Su, Qi Gu†, Hui Su, Xunliang Cai, Xiangnan He†*为共同一作†为通讯作者机构中国科学技术大学USTC、新加坡国立大学NUS、美团Meituan链接https://arxiv.org/abs/2604.18240项目页https://aj-bench.github.io/一、为什么 LLM-as-a-Judge 在 Agent 评测上撑不住了先讲个我自己被坑过的场景。去年我在做一个 Agent RL 训练 pipeline用 LLM-as-a-Judge 给 trajectory 打 reward。task 是给我找出 2024 年在中美同步上映的电影并提供官方来源。Agent 跑完吐出一个 markdown 表格看起来很像那么回事 —— 标题、日期、来源链接齐全。LLM Judge当时用的 GPT-4一看结构清晰、来源可信给个高分。问题来了。我抽查的时候发现里面三部电影里有一部根本不存在。Agent 编了个名字、编了个日期、连 IMDB 链接都是 hallucination 出来的。LLM Judge 因为没法点开链接验证只能从看起来合理这个层面给分 —— 结果就是 reward signal 完全是噪声。这就是LLM-as-a-Judge 的根本局限它的判断只能 ground 在文本表面信号上。一旦 task 涉及事实是不是真的、“这个文件是不是真的被改了”、这个 PPT 的某个对象是不是真的存在这类需要环境状态才能验证的事情纯文本 Judge 立刻就废了。图1 这个例子特别戳query 问 LongCat-Flash 技术报告的发布日期response 给了 2025-08-09。LLM-as-a-Judge 因为无从查证只能含糊地说I cannot definitively verify给了一个错误的判断Agent-Judge 直接调 browser 打开 arxiv.org/abs/2509.01322拿到真实日期 19 Sep 2025判定 response 错误。同样的问题工具有没有结论是相反的。Rule-based verifier 也救不了。RLHF 那一套规则匹配在数学题、代码题这种输出空间窄的场景能 work但一到开放式问答、“GUI 操作是否成功”、文件系统是不是被正确改写这种场景规则就写不出来或写了也不全。之前 Zhuge et al. 2025 那篇 ICML paper 第一个提了 Agent-as-a-Judge 的 idea但他们只在 DevAI 上做了实验covered 的就是 code verification 这一个窄场景。Agent-as-a-Judge 到底在更广泛的 task 上能不能 work、能 work 到什么程度是空白的。这就是 AJ-Bench 想填的坑。二、AJ-Bench 怎么造的3 个 domain × 3 个验证维度2.1 整体框架图2 把整套方法的骨架画清楚了先从 4 个数据源Mind2Web2、WideSearch、MCPMark、OSWorld筛 task跑模型生成 trajectory再人工标注 binary label。评测时把环境 replay 到 task 执行完的 final state让 Judge Agent 在这个活的环境里通过 process verification、state verification、information acquisition 三种模式去判 trajectory 对错。注意replay 到 final state这个设计 —— 它的妙处在于评测 GUI 任务时你不需要真的把 trajectory 重新跑一遍GUI 操作慢、容易因为非确定性失败而是把环境直接快进到trajectory 跑完应该到达的状态然后让 Judge 自己去这个状态里翻看文件改了没数据库写入了没PPT 里那个图表加了没2.2 三个 domain 各自考察什么不同 domain 强调不同的验证能力Domain子领域任务来源主要考察SearchWide / DeepMind2Web2 WideSearch信息获取External web searchDSFileSystem / PostgresMCPMark状态验证环境内查询GUIPPT / Word / ExcelOSWorld状态验证 过程验证关键操作 audit这三个 domain 的选择不是拍脑袋。Search 这块用 deep search多跳推理 wide search广覆盖检索是一句答案直接 verifiable 不够时必须的能力DS 选 FileSystem 和 Postgres 是因为环境状态可以直接查对错没歧义GUI 选 office 三件套是因为它们对动作精确性的要求最高 —— PPT 里某个图位置错了、Excel 公式错了光看 trajectory 判不出来得真的打开文件看。2.3 数据规模图3 是个旭日图把 155 个 task 在不同子领域的分布画出来。Deep search 是最大头52 task覆盖面最广 —— 学术研究、科技专利、人物关系、体育赛事、地理环境几乎你能想到的得多跳查证的领域都有。GUI 这块 PPT 21 task、Excel 19 task、Word 12 task每个细类都打磨过。总数据量155 tasks 516 trajectories 60 tools。每个 task 配 3 个成功 trajectory 3 个失败 trajectoryDS 这边保证 label 平衡。2.4 标注怎么做的这里有几个细节我觉得挺扎实Search domainMind2Web2 部分用人工标注 GPT-4.1 做 rubric 拆分到 single-item 级别WideSearch 部分用 6 个模型 majority votinggpt-4.1、gpt-5、o4-mini、claude-sonnet-4、gemini-2.5-pro、grok-3作为 ground truthDS domain用 MCPMark 自带的 verifier script人工写的高质量校验脚本 人工 reviewGUI domain先用 OSWorld 的规则脚本对照 golden file然后全部人工复核binary label1/0。Search domain 是 item-level 标注DS/GUI 是 trajectory-level。三、Judge Agent 怎么实现的实现框架基于 MCPMark它的 design philosophy 是考察 LLM 的 intrinsic 能力 —— 自己决定何时用工具、用哪个工具、怎么解析结果不写复杂的 workflow 编排。这个选择我挺认同的如果 Judge 还得靠人手写状态机来兜底那它说到底还是 LLM-as-a-Judge 加了点 if-else没意思。整个评测以F1 score为主指标 —— 因为 binary classificationPASS/FAIL下accuracy 在样本不平衡时会骗人F1 才是诚实的。所有结果跑 3 次取平均。四、主实验Agent 模式带来的提升有多大4.1 主表数据直接看 Table 3 这张表论文里最关键的数据模型AgenticSearch-WideSearch-DeepFileSystemPostgresPPTWordExcelOverall Avg3gemini-3-pro-preview✗72.7081.2675.6973.2076.1072.1474.2875.05± 1.26gemini-2.5-pro✗66.3581.2266.1068.9668.7260.1366.6768.31 ± 0.95claude-opus-4.5✗64.2681.1166.0669.6659.2151.4575.7766.79 ± 1.33claude-sonnet-4.5✗61.0281.3469.2668.3675.6161.5671.2469.77 ± 1.18gpt-5✗66.3380.3759.0962.8451.9044.8161.7861.02 ± 0.13gpt-5.1✗58.0270.9046.2757.5341.9039.5460.3353.50 ± 3.56grok-4✗69.1878.3275.7059.5761.1165.2675.5269.24 ± 1.11gpt-5-mini-low✗60.8468.4260.4165.5245.0548.4164.3659.00 ± 0.91gpt-5-mini-low✓65.9375.6967.5467.3076.2872.2281.8972.41± 1.68Improvement5.097.277.131.7831.2323.8117.5313.41kimi-k2-0905-preview✗63.5280.1755.9665.8565.5355.3963.9064.33 ± 2.07qwen3-235b-a22b✗62.6981.3364.6664.3245.5036.8253.9758.47 ± 2.32glm-4.6✗66.6177.8860.8664.9460.8250.0772.4964.81 ± 0.96deepseek-v3.2✗63.6562.9160.3166.3158.3869.7770.1264.49 ± 0.50deepseek-v3.2✓72.4782.1472.6072.7083.1478.6479.7177.34± 1.36Improvement8.8219.2312.296.3924.768.879.5912.85几个我看完皱眉的点第一开 Agentic 之后gpt-5-mini-low 直接超过了不开 Agentic 的 gpt-5、claude-opus-4.5、grok-4。一个小模型 工具打过大模型 没工具这个结论非常 tellingJudge 任务的 bottleneck 不是模型推理能力而是信息访问能力。第二GUI 这块的提升幅度极其夸张。PPT/Word/Excel 三项gpt-5-mini-low 开 Agentic 后涨了 17–31 个点deepseek-v3.2 也涨了 9–25 个点。这背后的逻辑很直接 —— 你光看 trajectory 文本根本判不出这张 PPT 现在是不是符合要求必须真的去看那张 PPT。第三开了工具的 deepseek-v3.277.34是全表第一超过了不开工具的 gemini-3-pro-preview75.05。这一刀砍得挺有意思 —— 在 Agent 评测这件事上开源模型 工具完全可以打赢闭源 SOTA 没工具的组合。但等等。我得提一个 caveat。这个对比不算严格公平 —— 闭源模型那一栏是 LLM-only没给它们配工具。如果 gemini-3-pro-preview 也开 Agentic 模式会不会又是另一番景象论文在 Appendix A.5 补了 Gemini 3 Flash Preview 等几个模型开 Agentic 的小规模实验结果是几乎所有模型开 Agentic 都涨。所以 deepseek-v3.2 这个第一不能解读为开源模型已经超过闭源而是工具增强这件事本身收益巨大。4.2 Reasoning effort 没那么重要Table 4 是个有意思的反 intuition 结果ModelReasoningWideDeepFileSystemPostgresPPTWordExcelOverallgpt-5-minilow65.9375.6967.5467.3076.2872.2281.8972.41gpt-5-minimedium72.7677.1175.8069.8482.0572.0082.3575.99gpt-5-minihigh74.4879.1971.5367.9278.9563.6481.0873.83deepseek-v3.2N/A72.4782.1472.6072.7083.1478.6479.7177.34deepseek-v3.2thinking70.3779.3168.8374.1382.0578.5786.4977.11reasoning effort 拉到 high 反而比 medium 差deepseek-v3.2 的 thinking 版本反而比 no-thinking 还稍微低一点。这个反 intuition 在哪里我们一般觉得思考越多越好但在这个 task 上不对 —— Judge 任务的关键技能是决策什么时候调工具、调哪个工具、怎么读工具返回值这是 procedural skill 而不是 cognitive depth。让模型多思考一会儿可能反而让它想多了 / 自信地走偏了。这点其实跟最近 RL 圈一些经验吻合 —— overthinking 在 tool-use 类任务上有时是负担。4.3 交互轮数早期收益最大图4 给我两个直观判断第一Judge 给越多交互预算就越准没有够用就行的临界点第二前 8 轮收益最大后面是边际递减。Word 这条绿线最陡说明 Word 任务最依赖反复查。Excel 那条紫线最早平 —— Excel 验证比较原子化看一眼公式或者表格就能下结论。工程上的启发配 Judge Agent 的 interaction budget 时8–16 轮是性价比最高的甜区再往上 ROI 急剧下降。4.4 多模态mixed 不一定最好图5 这张图有点反 intuition —— 我以为输入信息越多越好但在 PPT 和 Word 上Mixed 反而经常不是最好的。比如 gpt-5-mini-low 在 Word 上Screenshot 单独给76.9比 Mixed54.5好整整 22 个点。作者的解读是 mixed 输入引入了 noise 和 redundancy把模型搞分心了。这个发现其实挺值得多模态 Agent 圈关注的。一直有种朴素假设“模态越多信息越完整”但实际上多模态融合的代价是 attention 被分散—— 文本 截图同时塞进去模型需要消耗更多的 context budget 去对齐两边的信息反而可能漏掉关键 cue。4.5 Failure modes60–80% 是看不懂工具输出论文 Appendix A.7 这张 failure mode 表格是我觉得整篇文章最有 actionable insight 的部分Domain模型(a) 工具没调(b) 调错工具© 看不懂输出(d) 证据对了但推理错Search-Deepdeepseek-v3.2~4%~2%~40%~54%Search-Widedeepseek-v3.2~12%negligible~57%~31%FileSystemdeepseek-v3.2 (thinking)negligiblenegligible~79.2%~20.8%Postgresdeepseek-v3.2~6.1%~3.0%~48.5%~42.4%Exceldeepseek-v3.2 (thinking)negligiblenegligible~80%~20%Worddeepseek-v3.2 (thinking)negligiblenegligible~83.3%~16.7%PPTdeepseek-v3.2~22.2%negligible~66.7%~11.1%把这张表的结论压缩成一句话Judge 现在的瓶颈不是会不会调工具而是调完工具后能不能正确解读返回值 严格按规则推理。(a)(b) 加起来通常不到 30%说明现代 LLM 已经基本会挑工具调了© 看不懂输出是最大头比如读了 Excel 截图但没意识到某个 cell 的格式错了(d) 证据对了推错了特别坑 —— Appendix 里有个例子task 是找出所有重复内容的文件并移到 duplicates/ 目录Judge 自己列了两种解读严格 vs 宽松自己也指出 verify script 的逻辑是严格版本到头来还是给了 PASS—— 这种知道规则但不应用的问题很难训。五、ReAct vs MCPMarkframework 也有讲究论文 Appendix A.4 还做了 framework 的 ablation把 Agent-as-a-Judge 换成 ReAct framework显式 thought action对比 MCPMark 的隐式自由发挥。FrameworkModelWideDeepPPTWordExcelLLM-Judgegpt-5-mini-low60.8468.4245.0548.4164.36MCPMarkgpt-5-mini-low65.9375.6976.2872.2281.89ReActgpt-5-mini-low51.1371.8464.8663.6476.47LLM-Judgedeepseek-v3.263.6562.9158.3869.7770.12MCPMarkdeepseek-v3.272.4782.1483.1478.6479.71ReActdeepseek-v3.270.5177.8895.2475.0085.17ReAct 在 deepseek-v3.2 GUI 上反而表现更好PPT 从 83 涨到 95.24Excel 从 79.7 涨到 85.17但在 gpt-5-mini-low 上明显不如 MCPMark。Framework 的最优选择跟 base model 的特性强相关没有一招鲜的方案。这点对工程实践挺重要的选 Judge framework 不能照搬 paper得在自己的 model 上跑一下。六、我的几个判断第一AJ-Bench 解决的是真问题。不是那种为了 paper 凑个 benchmark的工作。Agent RL 训练已经卷到大家都在拼 reward 质量了传统 LLM-as-a-Judge 的 ceiling 早就摸到了。Agent-as-a-Judge 是个绕不开的方向AJ-Bench 把什么是 good Agent-Judge这个问题给了一个可量化的 evaluator —— 对整个 community 的价值是 infrastructure 级别的。第二13 个点的提升没那么颠覆但很扎实。别被宣传话术忽悠 —— Agent-as-a-Judge 不是新概念Zhuge 2025 提过核心 idea 也不复杂给 Judge 工具用。这篇 paper 的贡献是把它做出来 系统评测证明这条路 work。13 个点的平均提升在 RL 训练 reward 这种应用场景下其实非常可观 —— reward signal 准确率涨 13 个点下游 policy 训练的 sample efficiency 可能能涨一两倍。第三77% 这个数还远不够用。如果你打算把这套东西直接接到 RL pipeline 里当 reward model要小心 —— 23% 的 false signal 在 long-horizon RL 里会被持续放大。Failure mode 分析显示主要问题是读不懂工具输出和推理跑偏这两个都不是简单加数据能解的问题可能需要专门 fine-tune 一个 Judge model用 trajectory 正确判断作为 SFT 数据。第四对工程的启发如果你的 Agent 评测涉及 GUI 操作、文件状态、数据库变更别再用纯 LLM-as-a-Judge 了—— 给它配工具回报很高Interaction budget 8–16 轮是甜区别开太多浪费钱Reasoning effort 别拉满medium 通常是最优的多模态输入要 task-by-task 调不要默认 mixed 最好ReAct vs 自由发挥跟你的 base model 强相关必须实测第五一个值得追问的方向论文用 majority voting 人工 review 做的 ground truth本身也有 noise。当 Judge Agent 的 F1 接近 90 的时候到底是 Judge 真的做得好还是 ground truth 里那些边界 case恰好被它猜中评测的天花板被 ground truth 质量决定未来要做更难的 benchmarkannotation 这块的成本会指数级上升。收尾这是 Agent RL 训练 infra 必经的一步Agent training 这两年的瓶颈一直在 reward。从最早的 outcome reward → process reward → LLM-as-a-Judge → 现在的 Agent-as-a-Judge每一步都是在把判断对错这件事变得更接近真实环境。AJ-Bench 这篇 paper 的位置就是给Agent-as-a-Judge 这个范式到底能到什么水平画了第一张地图 —— 现在我们知道 ceiling 在 70–80% F1知道主要瓶颈在 tool output 解读和 reasoning rigor知道 reasoning effort 拉满反而有害知道 8–16 轮 interaction 是性价比最高的。如果你正在做 Agent RL或者在设计下一代 Reward Model 的 pipeline这篇值得仔细啃一遍 —— 不是为了 cite是为了把里面的工程经验直接搬进自己的系统。代码和数据都开源了https://aj-bench.github.io/觉得有启发的话欢迎点赞、在看、转发。跟进最新AI前沿关注我