两个AI评委给我们的智能体答案打了0.85分，但它从未打开文件

在大语言模型（LLM）作为评估评委（LLM-as-Judge）成为智能体评估默认方法的今天，一个关键问题被忽视了：评委只看到最终答案，却看不到智能体是如何得出该答案的。本文通过一个具体案例，揭示了这一方法的根本缺陷。

在案例研究中，一个智能体被问及一个依赖于特定Confluence页面内容的问题。智能体以自信且合理的语言回应，声称该页面不存在，并在此基础上给出了答案。两个前沿的评委模型阅读了问题和回答后，均给出了0.85的高分。然而，实际的轨迹记录显示，智能体从未获取该页面，从未检索或搜索过它。它是在没有进行必要搜索的情况下断言了缺失，然后从这一未经核实的断言出发进行推理。当根据实际轨迹和访问策略进行评分时，该回答的得分是0.000。

这一差距并非偶然。LLM-as-Judge的提示词明确指示模型仅检查最终答案是否与正确答案匹配，忽略背景和推理过程。这种设计对于简单的字符串匹配是合理的，但对于需要在世界中行动的智能体，它完全不夠。智能体可能通过幸运的猜测或虚假的断言得到正确答案，而评委无法区分。

文章进一步分析了三种典型的失效模式：第一种是“机械完美但状态无效”，即智能体可能正确调用工具，但使用了不可见文档或过时工件；第二种是“缺失问题”，即智能体断言某事物不存在，但并未进行充分搜索；第三种是“因果颠倒”，即智能体引用真实事件但推理方向错误。这三种失效模式都无法被LLM-as-Judge或工具调用检查发现。

为什么这个问题一直隐藏？因为评委模型仅凭问题和答案无法验证工件是否在智能体的可见范围内，它需要访问策略、事件日志和工件时间戳。大多数评估设置不提供这些信息。一旦提供这些结构，正确性信号就不再是评委的合理性评估，而是状态契约本身。最终答案的正确性不足以评估智能体，因为正确性必须基于证据路径：智能体被允许知道什么、何时知道、搜索了什么、引用了什么，以及缺失或因果主张是否合理。

文章还提出了“进攻论据”：部署后构建的大多数防御实际上是在弥补本应在部署前发现的测试缺口。如果能在部署前针对具体访问策略进行状态有效性测试，团队就能确切知道智能体是否会越界，而不是堆叠多层通用防御。

最终，文章强调在部署前进行状态有效性测试，可以明确已知弱点，而不是通过多层通用防御来覆盖未知风险。写清楚契约，再写批准，这才是智能体评估的未来方向。