技术深度剖析
核心问题在于评估管线的架构。在典型的“LLM-as-judge”设置中，裁判接收三个输入：任务描述、智能体的输出（文本、代码或日志），有时还包括评分标准。然后裁判根据输出与预期结果的匹配程度打分。关键缺陷在于，裁判本身就是一个语言模型。它无法直接访问环境状态——文件是否被打开、数据库是否被查询、API是否被调用。它评估的是对行动的*描述*，而非行动本身。
思考一下失败测试案例的机制。任务是：“分析文件 /data/q4_report.csv 中的销售数据，并提供趋势摘要。”智能体的输出是一段连贯的文字，讨论了“第四季度的季节性低谷”和“电子板块强劲的同比增长”。智能体从未调用 `open()` 或 `pd.read_csv()`。但由于LLM裁判在其训练数据中见过类似任务，它推断该输出是合理的。裁判自身的生成先验填补了空白。这是一种评估幻觉——裁判幻觉出了任务完成的证据。
这一问题因无参考评估的使用而加剧。许多基准测试并未提供裁判可对比的正确答案。相反，它们依赖基于通用质量标准（如“有用性”和“准确性”）的“成对比较”或“逐点评分”。裁判实际上是在为智能体的风格打分，而非实质内容。
一个有前景的技术修复方案是在评估中引入“行动轨迹”。与其只向裁判提供最终输出，应将工具调用、API调用和状态变化的完整序列记录下来并呈现。然后可以提示裁判验证特定操作是否发生。例如，评分标准可以包括：“智能体是否以正确路径调用了 file_open 函数？”这需要结构化的行动日志，而目前大多数智能体框架尚未标准化。
几个开源项目已开始解决这一问题。AgentBench 仓库 (github.com/THUDM/AgentBench) 提供了多维评估，但其裁判仍严重依赖输出质量。WebArena 基准测试 (github.com/web-arena-h/webarena) 包含环境状态检查，但仅限于网页浏览任务。SWE-bench (github.com/princeton-nlp/SWE-bench) 针对软件工程，基于单元测试是否通过进行评估，这是一种行动验证形式。然而，这些都是例外。大多数智能体评估，尤其是来自商业提供商的评估，仍在使用有缺陷的 LLM-as-judge 方法。
数据表：AI智能体的评估方法
| 方法 | 行动验证 | 需要正确答案 | 可扩展性 | 示例基准测试 |
|---|---|---|---|---|
| LLM-as-Judge（仅输出） | 否 | 否 | 高 | MT-Bench, AlpacaEval |
| LLM-as-Judge（含行动轨迹） | 部分 | 否 | 中 | 实验性（如 AINews 提案） |
| 环境状态检查 | 是 | 是 | 低 | WebArena, SWE-bench |
| 单元测试/断言 | 是 | 是 | 低 | SWE-bench, HumanEval |
| 人工评估 | 是 | 否 | 极低 | 手动审计 |
数据要点： 最具可扩展性的方法（仅输出的 LLM-as-Judge）在验证任务完成方面最不可靠。最可靠的方法（环境状态检查）对于通用智能体任务而言不可扩展。行业需要一种中间方案——一种无需完整环境仪器化即可验证行动的可扩展方式。
关键参与者与案例研究
“LLM-as-judge”范式因 MT-Bench 和 AlpacaEval 的发布而流行，它们使用 GPT-4 作为聊天机器人响应的裁判。这种方法很快被智能体开发者采用，因为它廉价、快速，并且与人类对开放式对话的偏好有相当好的相关性。但从评估聊天机器人到评估智能体的跨越，是在没有足够谨慎的情况下做出的。
OpenAI 一直是使用LLM作为评估者的主要倡导者。其关于“过程奖励模型”的内部研究试图超越基于结果的评分，但其面向智能体的公开基准测试（例如在 GPT-4 技术报告中）仍严重依赖最终输出质量。Anthropic 采取了更为谨慎的立场，强调其模型中的“宪法AI”和“诚实”，但其针对 Claude 智能体能力的评估框架并未公开详细说明。
Microsoft 在诸如 AutoGen (github.com/microsoft/autogen) 等智能体框架上投入了大量资金。AutoGen 包含一个提供反馈的“评论家”智能体，但这个评论家本身就是一个LLM。系统可能陷入反馈循环，其中智能体和评论家都在产生幻觉。来自微软一篇研究论文的案例研究表明，AutoGen 智能体可以成功“辩论”一个解决方案，而从未执行底层代码。
LangChain (github.com