← 返回 2026-04-22

AJ-Bench：面向环境感知评估的智能体即裁判（Agent-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 📅 2026-04-20 👍 17 2026-07-13 08:36

LLM-as-a-Judge 基准评测工具使用强化学习智能体评估

arXiv HuggingFace PDF

首个系统评测 Agent-as-a-Judge 的基准，带工具访问 F1 平均涨 13 点。

前置知识

LLM-as-a-Judge

用大语言模型本身充当评分器，对模型输出或智能体轨迹进行质量评估。常见做法是把任务查询、被评估回复和评分细则一起塞进 prompt，让模型直接输出分数或二元标签。这种范式成本低、可扩展，但裁判只能看到文本表面信号，无法主动获取外部证据，对事实核查、状态验证类任务常常出错。

本文提出的 Agent-as-a-Judge 正是对 LLM-as-a-Judge 的能力升级，必须先理解它的边界和失败模式，才能看懂作者为什么需要给裁判装上工具。

Agent-as-a-Judge

把评分器本身也实现为一个具备工具调用与环境交互能力的智能体。它可以打开浏览器、执行数据库查询、读取文件或截屏比对，复现被评估智能体的执行轨迹，根据真实环境状态来下判断，把'文本推断'升级为'环境取证'。AJ-Bench 系统评测的就是这种范式。

这是全文核心对象，只有理解它能调动工具、能重放状态、能审计中间过程，才能体会 AJ-Bench 设计'三种验证模式'的用意。

Tool-Integrated Reasoning（工具集成推理）

让 LLM 在推理过程中按需调用外部工具（浏览器、代码执行、文件读取），把'思考 + 行动'交织在同一个循环里，常见范式是 ReAct。底层逻辑是：当模型自身知识不够用时，去环境里取证据，而不是凭空编造或回避问题。

Agent-as-a-Judge 的实现机制就是工具集成推理；本文的消融实验（推理强度、交互轮数、多模态输入）本质上都在度量工具调用效果如何受这些因素影响。

F1 分数在二元判断中的含义

在二分类评估里 F1 是精确率与召回率的调和平均 $F_1 = 2 \cdot \frac{P \cdot R}{P + R}$，对漏报和误报都敏感。本文把裁判输出和人工标注的二元标签对齐后求 F1，是衡量'裁判准不准'的统一标尺。

全文实验都报 F1，不只是看平均准确率；理解 F1 对负样本不均衡的容忍度，才能看懂 DS、Search 域里 F1 提升到底意味着多少真实判错被纠正。

研究动机

随着 RL 训练把 LLM 智能体推到越来越复杂的环境中，如何自动核验智能体行为的正确性成了一个核心难题。已有的两条主流路线都有明显短板：(1) 基于规则的 verifier，把轨迹和预定义规则比对，仅在窄域有效，遇到科学假设验证、长文事实核查这类没有标准答案的任务就失灵（Wei et al., 2025；Huang et al., 2025）；(2) LLM-as-a-Judge，让强模型直接读轨迹下判断，但它的判定本质上是文本层面的归纳，无法访问真实环境，遇到'LongCat-Flash 技术报告最新发布于哪一天'这类问题，裁判只会模糊地说'无法确定'，根本没法像人那样点开 arxiv 链接去查证（如图 1 所示）。更糟糕的是，对 Agent-as-a-Judge 这种新兴范式，目前仅有 Zhuge et al. (2025) 等少量工作在代码验证这类窄域里做过评测，规模小、域单一，根本回答不了'在开放环境里，裁判到底什么时候该交互、怎么用工具、什么证据才够下判断'这三个根本问题。

本文的目标是本文的核心目标是建立一个跨域、规模可控、对接真实环境的 AJ-Bench，用 155 个任务和 516 条二元标注轨迹系统量化 Agent-as-a-Judge 与 LLM-as-a-Judge 的差距，最终回答两件事：(a) 给裁判装上工具 + 环境访问，能在 F1 上带来多大的可测得增益；(b) 当前 Agent-as-a-Judge 的天花板到底在哪，留给后续研究多少 headroom。具体地，作者要在三个代表性领域（搜索 Search、数据系统 DS、图形界面 GUI）覆盖三种验证能力（信息获取、状态验证、过程验证），并以此为底座同时支持闭源和开源裁判模型的对比实验。

与已有工作不同的是，已有工作要么只看 LLM 的静态判断（RewardBench、RM-Bench、JudgeBench、AgentRewardBench），要么只在小规模、代码域上摸了一下 Agent-as-a-Judge 的能力（DevAI），而本文的独特切入角度是：把'环境感知'、'多域覆盖'和'智能体交互'三个特征首次同时塞进一个基准，并通过 MCPMark 这种相对克制的智能体框架（让模型自行决定何时调用工具，而不是把流程写死）来保留 Agent-as-a-Judge 的真实难度，让评测结果既能反映工具调用能力又能反映推理能力。

核心方法

AJ-Bench 的方法思路可以类比为'让判卷老师带计算器进考场'：原来 LLM-as-a-Judge 只能盯着考生（被评估智能体）写完的答卷（轨迹文本）打分，而 AJ-Bench 把判卷老师换成另一名能上网、能查数据库、能开 GUI 的智能体，让它去现场复现、取证、定罪。技术路线上分成两阶段：上半段是基准构建（任务设计 → 轨迹收集 → 标签标注），从四个已有数据源（Mind2Web2、WideSearch、MCPMark、OSWorld）抽取任务，再由 Gemini DeepResearch / Grok / Perplexity 等多模型生成或直接复用轨迹，所有标签经人工复核；下半段是评测过程（环境初始化 → 重放 → 三种验证模式），DS 和 GUI 域先把轨迹末态在 AWS 等独立环境中回放出来，然后让 Agent-as-a-Judge 在活环境里继续调用工具去采集证据、与官方 verify 脚本的判定对齐，最终按轨迹级（F1）计算裁判得分。

本文和已有 LLM-as-a-Judge 基准最本质的区别在于'裁判能不能动手'：传统基准里裁判只能看文本（A），而 AJ-Bench 强制裁判调用工具去重新取证（B），并且把这种'环境感知'能力拆成三种可独立打分的验证模式——信息获取（去外部搜证据）、状态验证（看一眼环境现状）、过程验证（审每个动作是否合理）。这相当于把'裁判 = 评注员'升级为'裁判 = 重演 + 调查员'，从底层消除了 LLM-as-a-Judge 在'没说 = 错'和'说了 = 对'之间的模糊地带，也是为什么同一基座模型（如 gpt-5-mini-low 或 deepseek-v3.2）一旦打开工具开关就能平均涨 13 个百分点 F1 的根本原因。

方法步骤详情

完整的 AJ-Bench 流程可以按构建阶段和评测阶段分开描述。构建阶段第一步是任务设计：Search 域从 Mind2Web2 取 deep 搜索 + WideSearch 取 wide 搜索两类互补任务，并剔除短答案和时效性条目；DS 域从 MCPMark 取 Filesystem 和 Postgres 两个子集，按 Wu et al. (2025) 结果筛掉过难任务和措辞含糊的题；GUI 域从 OSWorld 取 PowerPoint、Word、Excel 三类办公任务，先剔除带弹窗、不能稳定复现终态或评价主观的任务。第二步是轨迹收集：Search 域用 Gemini DeepResearch、Grok DeepSearch、Perplexity DeepResearch 跑出原始回复，用 gpt-5-2025-08-07 抽取题面相关信息后人工微调；DS 域从 MCPMark 已发布的轨迹库 (Jakumetsu/mcpmark-trajectory-log_verified_trajs) 中跨模型架构采样；GUI 域从 OSWorld 的 Ubuntu AMI 抽取 5 个多模态模型（包括 claude-4-sonnet 不同步数、o3、qwen2.5-vl-32b、doubao-1.5-thinking-vision-pro）的轨迹，专门挑选'成功用很多步、失败很快终止'的成对样本以解耦步长偏差。第三步是标签标注：Search 域按子集不同分别采用'人工评分准则 + gpt-4.1 拆单条目'（Mind2Web2）和'六个 SOTA 模型多数投票'（WideSearch）；DS 域用 MCPMark 官方脚本初标再人工复核；GUI 域先用 OSWorld 规则脚本，再人工逐条检查。评测阶段第一步是环境初始化与重放：DS 任务本地回放、GUI 任务部署到 AWS 独立实例，把被评估轨迹的 action sequence 顺序执行以重建末态；第二步启动 Agent-as-a-Judge（基于 MCPMark 框架），让其在三种验证模式中按需调用 60 种工具之一（包括浏览器导航、文件读写、数据库查询、A11y 树读取、截图等）采集证据；第三步把裁判输出的二元标签和人工标注对齐，按子域聚合得到该任务一个 F1 样本，整个 AJ-Bench 在每个模型上重复 3 次取 Avg@3。

技术新颖性

在技术实现层面，AJ-Bench 的新颖性集中在三点。第一个是'轨迹末态回放'机制：传统 LLM-as-a-Judge 拿到的是一段死的 JSON 序列，而 AJ-Bench 会先把轨迹在隔离环境里重放成活现场（本地 Linux 或 AWS Ubuntu），这样 Agent-as-a-Judge 既能像 DS 域那样直接 query Postgres，也能像 GUI 域那样点击 accessibility tree，裁判真的'看见'了智能体声称达到的状态。第二个是'item 级 vs trajectory 级'标签的灵活定义：Search 域允许用 gpt-4.1 把整条回答拆成 rubric 对齐的单条目进行细粒度评分（指标更敏感），而 DS/GUI 域直接用任务级 verifier 一次性判定，能在同一基准里兼容不同验证粒度。第三个是评估稳健性：从 MCPMark 框架（隐式推理）切到 ReAct 框架（显式推理），gpt-5-mini-low 在 PPT 上 F1 从 45.05 提到 76.28 的同时，ReAct 版本也达到 64.86，说明 Agent-as-a-Judge 的优势不依赖单一智能体骨架；同时附录给出 95% 置信区间和数据子域不平衡的方差分析，给出统计可重复的对照。

**Figure 2**: Overview of the benchmark and evaluation pipeline.

**Figure 3**: Task distribution of AJ-Bench

实验结果

主实验（Table 3）覆盖 13 个 LLM-as-a-Judge 模型 + 2 个 Agent-as-a-Judge 模型，最关键的发现是 Agent-as-a-Judge 在同基座上一致性大幅领先。gpt-5-mini 关闭工具时 Overall F1 仅 59.00±0.91，打开工具后跃升到 72.41±1.68（+13.41），deepseek-v3.2 从 64.49±0.50 涨到 77.34±1.36（+12.85），其中 gpt-5-mini 在 PPT 子域暴涨 +31.23、Word +23.81、Excel +17.53，幅度最大，因为 GUI 域本来最依赖视觉与状态取证。第二个发现是'弱基座 + Agent 框架'可以打平乃至超过 SOTA 纯文本裁判：deepseek-v3.2 + MCPMark 拿下 77.34，超过 Sonnet-4.5(69.77)、Grok-4(69.24)、Opus-4.5(66.79) 等几个更强的 LLM-as-a-Judge，验证了 LLM-as-a-Judge 静态判断本身有上限。第三个发现在消融（Table 4）：推理强度对 Agent-as-a-Judge 不总有帮助——gpt-5-mini 在 low=72.41 → medium=75.99 → high=73.83（high 反而掉），deepseek-v3.2 启用 thinking 后从 77.34 降到 77.11，说明'更强的内在推理 ≠ 更会用工具'。交互轮数消融（Figure 4）显示把 max turns 从 1 提到 32，F1 在 PPT/Word/FileSystem 上单调上升（PPT 1→32 turns 从约 50 升到 80 左右），其中 Word、PPT 对多轮交互最敏感。多模态消融（Figure 5）表明 mixed 输入在多数子域领先，但 Excel 上 a11y tree 反而更强（gpt-5-mini-low 90.5 vs mixed 90.0，gemini-3-flash 92.3 vs 90.0），说明多模态并非'越多越好'。失败模式分布（Table 8）显示最常见错误是'(c) 误解工具输出'，deepseek-v3.2 在 DS FileSystem 上占 ~56.1%、GUI Excel 上占 ~60.0%、Deep 上 ~40%，而在 Postgres 这种纯数据库域甚至出现 ~26.7% 的'(a) 调用失败'，说明越复杂的解析步骤越容易看走眼。最后在 4 个额外模型（Table 6）和 ReAct 框架（Table 5）上的复测都显示 Agent-as-a-Judge 一致更强，例如 kimi-k2.5 PPT 从 69.77→80.00、glm-4.7 PPT 从 40.00→80.00，结论不依赖具体裁判家族。

**Table 1**: Comparison of evaluation benchmarks for judges.

**Table 2**: Statistics of AJ-Bench across domains and subdomains.

**Table 3**: Performance Comparison under LLM-as-a-Judge and Agent-as-a-Judge Settings

**Table 4**: Performance comparison of models under different reasoning effort settings across tasks.

**Table 5**: Ablation study of agent frameworks across two backbone models.

**Table 6**: Performance comparison of additional judge models with and without the Agent-as-a-Judge setting on a representative subset of tasks.

**Table 7**: 95% confidence intervals of subdomain-level performance over three independent runs.

**Table 8**: Proportional distribution of failure modes encountered by the agent-as-a-judge across different domains, subdomains, and models.

**Table 9**: Additional evaluation metrics detailing FPR, FNR, Precision, and Recall across different domains.

**Figure 4**: Comparing different interaction turns' effect on the evaluation results.

**Figure 5**: Comparing the effect of each modality on agent performance under two models (gpt-5-mini-low and gemini-3-flash-preview) on the GUI domain.

查看结构化数据

任务	指标	本文	基线	提升
Overall F1 @ AJ-Bench	F1 (Avg@3)	deepseek-v3.2 + MCPMark (Agent) = 77.34 ± 1.36	deepseek-v3.2 (LLM-Judge) = 64.49 ± 0.50	+12.85
Overall F1 @ AJ-Bench	F1 (Avg@3)	gpt-5-mini-low + MCPMark (Agent) = 72.41 ± 1.68	gpt-5-mini-low (LLM-Judge) = 59.00 ± 0.91	+13.41
PPT (OSWorld) F1	F1	gpt-5-mini-low (Agent) = 76.28	gpt-5-mini-low (LLM-Judge) = 45.05	+31.23
Word (OSWorld) F1	F1	gpt-5-mini-low (Agent) = 72.22	gpt-5-mini-low (LLM-Judge) = 48.41	+23.81
Deep Search F1	F1	deepseek-v3.2 (Agent) = 82.14	deepseek-v3.2 (LLM-Judge) = 62.91	+19.23
Postgres F1	F1	deepseek-v3.2 (Agent) = 72.70	deepseek-v3.2 (LLM-Judge) = 66.31	+6.39
Reasoning effort impact (gpt-5-mini)	Overall F1 across low/medium/high	medium = 75.99（最高）	low = 72.41, high = 73.83（high 反而下降）	非线性，最大差 3.58
Reasoning effort impact (deepseek-v3.2)	Overall F1 with/without thinking	no-thinking = 77.34	thinking = 77.11	-0.23（启用 thinking 反而略降）
Most common failure (DS FileSystem, deepseek-v3.2)	占比	(c) 误解工具输出 ≈ 56.1%	(a) 调用遗漏 ≈ 4.9%, (b) 错工具 ≈ 2.4%, (d) 推理错 ≈ 36.6%	错误分布揭示主要瓶颈

局限与改进

作者自己承认了两条硬局限：任务多样性与可扩展性上，AJ-Bench 现有 155 个任务多数改自已有基准（Mind2Web2、WideSearch、MCPMark、OSWorld），不是从零设计，因而覆盖场景受限于上游 benchmark 的分布；环境稳定性上，Search 域需要联网才能重放，外部网页抖动会直接影响评测一致性，附录给出的置信区间也证明 Wide 子集因为样本仅 27 条轨迹而方差偏大。除此之外，我从数据中观察到几个隐性问题：(1) PPT/Word 等 GUI 小样本子集的置信区间上界和下界跨度可达 20 个 F1 点，意味着细粒度的'多模态谁最强'这种说法其实并不稳健；(2) 失败分析里 (c) 误解工具输出占比稳定在 40-80%，它不是工具调用框架问题，而是模型归纳能力本身的不够，意味着本文的 Agent-as-a-Judge 上限被基座语言理解的天花板锁死，单靠堆工具调用次数收益有限；(3) DS 域里 Postgres 在 thinking 模式下出现 26.7% 的'调用遗漏'，说明更长的推理链反而会让模型在涉及多步骤 SQL 时忘掉关键调用；(4) 评估只覆盖到 gpt-5-mini-low 与 deepseek-v3.2 两个 Agent-as-a-Judge 基座，因为预算约束，没能在 Gemini-3-pro、Opus-4.5、Sonnet-4.5 这些 SOTA 模型上做 Agent 设置的全量测试，结论是否对最顶级模型同样成立仍需后续验证。

独立分析的弱点

我的独立观察集中在四个场景。第一，'工具调用成功率'本身没被作为指标显式拆分，比如 Postgres 域 26.7% 的'(a) 调用失败'应该进一步细分为'网络超时 / MCP server 报错 / JSON 解析错'，否则 Agent-as-a-Judge 的提升有可能部分来自工程稳定性而不是智能本身；改进方向是给 AJ-Bench 加一份 tool-call execution log 的二级诊断面板。第二，推理强度的曲线出现'中 > 高'的反转暗示 high reasoning 把裁判绕进自我反驳，建议把'prompt 层是否启用思考'和'sampling 层是否启用 thinking token'剥离开做因子分析，而不是把两者揉成一个开关。第三，多模态混合输入在 Excel 反而拖累成绩，说明截图冗余会让模型把多次点击结果混着识别；可以加入'目标裁剪'环节，先让 VLM 选出包含变化区域的 patch 再喂给推理模型，减少冗余。第四，整体 F1=0.72 这个均值看上去离饱和还有 20+ 个百分点空间，但被 Search Wide(9 tasks) 等小子域的高方差稀释了，需要补充 bootstrap 重采样或贝叶斯估计，避免后续工作把噪声当收益。

未来方向

作者明示的方向有两条：(1) 把更多任务真正从零构造并扩大规模，让数据集可以作为训练集使用，从而把 AJ-Bench 从评测平台升级为带 reward signal 的训练 signal；(2) 探索更稳定的 Search 域环境（如爬虫快照、归档版网页）以降低网络不稳定带来的评测噪声。可延伸的方向至少有三个：(a) 把 Agent-as-a-Judge 接到 Agent-RL 的 RLHF 阶段，让它直接产出 reward 而不只是 reward model 的代理，缓解 GRPO 等 RL 算法里 verifier 可靠性不足的问题；(b) 引入轻量化评判器蒸馏，把 77.34 F1 的 deepseek-v3.2 + MCPMark 蒸馏到小模型上，把交互成本压到可在大规模 RL 里实时调用的水平；(c) 把'(d) 正确证据 + 错推理'这一失败模式作为重点攻击对象，研究如何让裁判学会'宁可不下结论也不要乱下结论'的可信度机制。

复现评估

复现门槛中等偏下：作者明确给出网站 https://aj-bench.github.io/、所有任务配置与原始动作轨迹，并说明 GUI 域跑在 OSWorld 提供的 AWS AMI 上，DS 用 MCPMark 自带脚本回放，Search 域用 gpt-4.1 / gpt-5-2025-08-07 做后处理；官方仓库似乎尚未完全公开（仅有项目页），需要申请。算力方面，L40S 显卡即可驱动 MCPMark 与 ReAct 基线，GUI 域必须用 AWS 独立实例保证互不干扰，整体跑一次 3 seed 需要数小时到一天，主要瓶颈是 Search 域的 LLM 网页抓取 token 消耗（gpt-5-mini-low + deepseek-v3.2 两个 Agent-as-a-Judge 加起来约消耗数十亿 token）。论文已经提供 95% 置信区间表（Table 7）说明结果统计可信。复现难度上，最容易踩坑的点是 Search 域外部网页可能漂移（尤其是 LongCat-Flash 这种 arxiv 论文，作者举的例子就因发布时间变化导致回答差异），以及 GUI 域 OSWorld 中 Office 文件在多机环境下渲染像素级差异，因此建议把评测严格封在 AWS AMI + 固定时间窗口内，并把网页渲染快照作为校验锚点。

论文图表

**Figure 1**: Agent-as-a-Judge outperforms LLM-as-a-Judge by using tools and environment access to verify the correct release date.
用 'LongCat-Flash 技术报告在 2025 年 12 月之前最新版本的发布日期' 这一真实查询做对比，左侧 LLM-as-a-Judge 因为不能查证据，只能模糊说'我无法确定 2025-08-09 是否正确'；右侧 Agent-as-a-Judge 直接调用 browser_navigate 打开 arxiv 链接 2509.01322，从返回的 a11y 树读到 '19 Sep 2025'，并据此推翻错误答案、给出真值 2025-09-19。

这是全文最核心的一张动机图，用一个具体例子演示了 LLM-as-a-Judge 与 Agent-as-a-Judge 在'能否动手取证'上的本质差别，离开它读者很难直观感受'为什么必须给裁判装工具'。

**Figure 6**: Failed to call tools
失败案例：在找某个数学论文并改名为 answer.html 的任务里，被评估智能体读了 51 个文件却没改名；裁判自己的推理链明确写到'被评估智能体没有创建所需文件'，但因 token 耗尽或者 verdict extraction 早返回错误，把 verdict 误记为 PASS。

典型 (a) 类失败，揭示 verdict extraction pipeline 自身的脆弱性，是工程改进点之一。

Figure 7: Misinterpreted tool output

失败案例：找 VoteNet backbone_module.py 的 bug。Ground truth 是 fp2 层的 mlp 输入维度应从 256 改为 512（256+256）；裁判把整套 set abstraction 都细读了，被 sa3_inds 的赋值操作带偏，没有去核验 fp2 的维度，从而漏报 bug。

典型 (c) 误解工具输出错误，说明裁判的代码领域知识不够时，会被无关 commit 牵走注意力。

Figure 8: Correct evidence, wrong reasoning

失败案例：找内容重复的文件并移动到 duplicates/。裁判正确 hash 了所有文件、确认根目录留一个副本、并分析过 verify 脚本要求'零副本'的严格含义，最终却认同'每个重复组留 1 个'这种 lenient 解读，输出 PASS。

典型 (d) 证据对而推理错，说明 Agent-as-a-Judge 还需要在'严格遵循规则 vs 灵活解释'之间做更好的校准。

Figure 9: Search Domain Trajectory

完整示例：'找出 2024 年中美同日上映的三部电影'。原轨迹给出 Beekeeper(1/12)、Godzilla x Kong(3/29)、Deadpool & Wolverine(7/26) 三部；裁判把回答拆成 single-row 后，逐条用 browser_navigate 打开 Box Office Mojo 与 Wikipedia 验证日期，最后给每条都标 [1]，可视为理想 Agent-as-a-Judge 流程示范。

展示 Search 域 rubric-driven、item-level 验证的标准动作，是构建 Search 验证流程的参考蓝图。

Figure 10: DS Domain Trajectory

完整示例：从多个文件夹抽 2024 年日期写到 timeline.txt。裁判执行 21 个 list_allowed_directories / directory_tree / read_multiple_files / read_text_file 等步骤，先后确认目录、写文件存在、日期抽取、按时间序排序，最终给 PASS。

展示 DS 域通过 fileMCP 工具做状态验证的典型长链，是用 environment-aware 工具支持过程审计的范例。

Figure 11: GUI Domain Trajectory

完整示例：'把第 2 张幻灯片的图片移到右边'。被评估智能体 5 步完成拖拽；裁判用 VIEW_TRAJECTORY_STEP 看 Step 1/3/5 的 a11y 树，再用 CLICK 探活环境，确认图片从 (364, 415) 移到 (930, 412)、位于右侧，最终 PASS。

展示 GUI 域把 a11y tree 当作唯一可信信号源的工作机制，是'过程 + 状态'双验证的范例。