让 AI 评估 AI，最容易错在哪里？从 3,808 个工具调用任务说起

如果一个 AI Agent 真的完成了任务，谁来判断它是不是“做对了”？

过去常见做法，是再叫来一个更强的语言模型当评委：给它看问题和 Agent 的操作记录，让它判断结果好不好。这个方法听起来合理，毕竟 AI 评委能读懂自然语言，也能处理复杂背景。但它真的可靠吗？如果 Agent 调用的不是一个普通聊天问题，而是一串有先后依赖的工具流程呢？

AgentJudgeBench 就是专门来回答这个问题的。它不是又做一个泛泛的“AI 裁判排行榜”，而是把镜头拉近到 Agent 最常见、也最容易被高估的能力：调用工具并完成工作流。

先理解 Agent 工具调用

普通问答通常是：问一句话，模型给一个答案。

Agent 工作流则像一张任务清单：先查订单，再查库存；先读取用户权限，再决定能否退款；先获取天气，再决定是否发送通知。每一步都可能成功、失败、重复或顺序错误，而且前后步骤会互相影响。

这意味着，哪怕最终答案看起来不错，过程也可能存在严重问题：Agent 可能误用了工具，可能在权限检查前就执行了敏感操作，也可能因为某个依赖没满足而“阴差阳错”得到正确答案。

研究团队构建了 3,808 个评测实例，覆盖六种不同的工作流 DAG——可以把它理解为六种“有向任务关系图”。每种流程又有三个难度等级。

它们不只是随机生成几段工具调用，而是试图回答更难的问题：

换句话说，这项工作把“最终答案对不对”拆成了“过程是否合理、依赖是否满足、工具是否真的执行成功”。

AgentJudgeBench 最有价值的地方，是它提醒我们：自然语言描述得通顺，不等于执行过程真的可靠。

假设一个 Agent 要完成“先查权限，再执行退款”。如果它最后确实退钱了，但把权限检查跳过了，AI 评委可能只看到“退款成功”，给出高分。

反过来，如果 Agent 正确执行了每一个步骤，但工具返回的是稍有不同的字段格式，评委可能又误以为任务失败。

这就是评测里的“裁判盲区”：评委往往根据最终结果或局部文本做判断，却不一定理解完整的工作流约束。问题越依赖流程、越有前后关系，这种盲区越明显。

第一，Agent 正在从“会聊天”走向“会办事”。一旦它能发邮件、改数据库、操作软件或调用支付接口，评测就不能只考最终一句话，而要检查整条执行链。

第二，LLM-as-a-judge 虽然便宜、快、容易扩展，但它不是万能的裁判。对于开放式写作，AI 评委可以参考语义和风格；对于工具调用、数据流、权限和安全边界，最好引入可执行验证器、日志断言或人工抽查。

第三，模型规模不是唯一答案。小型评委模型成本低、延迟低，如果能配合结构化工作流和确定性检查，可能比盲目换一个昂贵模型更实用。

你可以把 Agent 看成一名新员工，把 AI 评委看成只看汇报材料的经理。

如果员工最后说“事情办好了”，经理当然会觉得不错。但真正可靠的经理还会问：

AgentJudgeBench 做的事情，就是把这几个问题系统化、规模化。它不一定意味着 AI 评委不能用，而是意味着我们不能把“它看起来像评委”当成“它真的适合当裁判”。

Agent 的能力，不只在于它能不能给出一个答案；AI 评委的能力，也不只在于它能不能读懂答案。工具调用有依赖、有顺序、有失败路径，评测必须看见完整流程，才能避免“结果正确、过程错误”。

让 AI Agent 做任务，最危险的未必是它直接做错，而是它“最后看起来做对了”😅

新研究 AgentJudgeBench 专门测试：让另一个 AI 当评委，去判断 Agent 的工具调用是否可靠。结果覆盖 3,808 个任务、6 种工作流结构和 3 个难度等级。

它提醒我们：Agent 任务不是普通聊天。查权限、查库存、发通知、退款……每一步都有先后依赖，漏掉一步，过程就可能完全变了。

所以，评估 Agent 不能再只看“最终答案写得像不像真的”，而要追问：权限对不对？顺序对不对？工具真的执行了吗？错误后有没有停止？

未来更靠谱的方案，可能是“结构化日志 + 可执行验证器 + AI 评委”的组合，而不是把全部希望押在 AI 评委身上。