「评测的评测」：LLM 评审员靠得住吗
智能体跑完一长串工具调用，谁来判它对不对？越来越多评测管线让另一个大语言模型当评审员（LLM-as-a-judge）。但一个关键问题长期缺系统答案：评审员在结构化、带依赖的工作流上，真的可靠吗？ServiceNow 的 AgentJudgeBench（arXiv 2608.26623，作者 Verma、Saha、Subramanian、Aluru）正是围绕这个问题设计的——它不把评审当成开放式文本偏好，而是聚焦由有向无环图（DAG）描述的、存在依赖关系的智能体工具调用工作流，系统研究 LLM 评审员在 agentic 工具调用上的可靠性。
数据集：3808 条、6 种拓扑、3 个难度
基准包含 3808 个实例，覆盖六种 DAG 拓扑（线性、扇出、扇入、菱形、可选 enrichment、类循环）与三个难度档（通过受控改写查询，在保留真实工具调用序列的前提下提升歧义度：易——参数显式、意图清晰；中——部分值隐式或转述、需推理；难——完全隐式、高语言歧义、需语境推理）。实验用五个任务生成模型（Llama 3.3 70B、Llama 3.1 8B、Qwen3 32B、Smollm3 3B、GPT-5.4）与六个评审模型（GPT-5.4、Claude large、Gemini 2.5 Pro、QwQ-32B、GPT-OSS-20B、GPT-OSS-120B），外加 Prometheus-2 作为评审专用基线。任务横跨 15 个企业领域，含 IT 服务管理、合同生命周期管理、电网运营等。每条记录配 5 到 14 个带类型化 JSON schema 的工具。
四个维度：把「对不对」拆开打
AgentJudgeBench 把评审拆成四个可独立打分的指标：工具选择、参数结构、序列准确性、查询覆盖，每个取值 0、0.5 或 1。整体分是四者未加权平均。这种拆解很关键——智能体评测的对象不是单一答案，而是工具选没选对、参数合不合法、执行顺序对不对、依赖满不满足、最终状态对不对。一个局部错误会在后续步骤被放大，而只看最终输出的评审员可能定位不到错误来源。基准还用确定性程序化打分器提供无偏真值，并设计「有标准答案」与「无标准答案」两种条件，隔离给出参考的影响。
核心发现：难度是更硬的天花板
几项发现值得工程团队贴墙。其一，评审与程序化参考的一致性随任务难度单调下降；无标准答案时，下降速度约为有条件时的 1.5 倍。其二，困难且无标准答案的查询上，六个评审模型全部收敛在 77% 到 82% 的窄带里，模型规模没能打破这个区间——指向一个主要由工作流难度驱动的结构性上限。其三，标准答案并非总能帮上忙：对 GPT-5.4 与 Gemini 2.5 Pro，给真实答案反而分别让一致性降 1.5 与 3.9 个百分点，研究者解释为可能的过度锚定——评审员过度依赖参考而非独立核查执行轨迹。其四，缓解手段效果参差：思维链与评审温度几乎无影响；结构化评估量规最多提 6.5 点，但收益不能稳定迁移到所有「评审者—生成者」组合。人工验证研究中，有标准答案时 QwQ-32B 最贴近程序化参考，无标准答案时 GPT-OSS-120B 最贴合人类判断。
意义：别把「模型更大」当成「评审更可靠」
这项研究挑战了一个默认假设：更大的评审员自动是更好的评审员。对工具调用智能体，评审对象是含工具选择、参数、执行顺序与依赖关系的完整轨迹。AgentJudgeBench 的更大贡献，是暴露评测链路本身的脆弱性——一个不可靠的评审员，会悄悄变成定义智能体「表面能力」的机制。对开发者，更稳的做法是把评审标准拆成可检查的结构化条件，并保留程序化验证：工具名、参数格式、依赖是否满足、最终状态分别打分，再把模型判断与规则检查结合；标准答案应被当作辅助证据而非无条件权威，尤其在它可能诱发锚定时。
局限
基准也有边界。论文附录的改写保持性验证显示，中等改写在 94.9%、难的在 76.8% 上获元评审一致；「严格难于前一级」准则上，中等对易一致 58.1%、难对中等 93.9%。Prometheus-2 因采用自有绝对打分协议，与其他六位评审不聚类（低 20 到 30 点）。这些都不削弱其主干结论，但提醒读者：难度分档本身不是完全独立校准的，中等档更应读作稳健性检查。论文以 inproceedings 形式给出引用，数据集已在 Hugging Face 开放。
结语
AgentJudgeBench 不给出一个「最可靠的评审模型」，而是指出评测层自身的裂缝。在智能体评测越来越依赖 LLM 当裁判的当下，它提醒行业：报告某个智能体的分数时，先说清你的评审员在拓扑、难度与标准答案条件上怎么表现。否则，一个脆弱的裁判，会悄悄决定一个智能体看起来有多强。