Agent Judge：解决生产环境智能体的长上下文评估（10分钟阅读）

# Agent Judge：解决生产环境中长上下文 Agent 的评估难题 ## 摆脱简单的 LLM 评测方法 大多数团队使用简单的 LLM 评测方法来评估 Agent 的运行轨迹：将用户查询、Agent 的最终输出（可能还有一些元数据）以及一份评分标准交给评测模型，然后询问 Agent 的行为是否符合预期。 随着行业转向能够端到端自主执行任务的长期 Agent，LLM 评测方法无法持续产生准确的评估结果。例如，一个销售 Agent 在返回最终消息之前，可能需要研究潜在客户、更新 CRM、发送邮件并安排会议。再或者，一个编码 Agent 可能需要编辑数十个文件、更新 AWS 配置，并创建一个 GitHub PR。 在这两种情况下，基础的 LLM 评测都会失效：它无法将完整的 Agent 轨迹放入其上下文窗口，也无法根据 Google Calendar、CRM、AWS 或 GitHub 等真实来源系统来验证状态变更。结果，自动化评估的有效性大打折扣。Agent 的失败被漏检，客户不满持续存在，团队不得不回到手动审查 Agent 轨迹的老路上。 LLM 评测方法在长期 Agent 上失效，主要有三个原因： - **长轨迹。** 长期 Agent 的轨迹可能跨越数百次工具调用，涉及数据库、服务、文档和其他系统。像 Codex 和 Claude Code 这样的编码 Agent 可以运行很长时间，因为它们在工作中会压缩上下文。这允许它们的轨迹扩展到数百万个 Token，远远超出 LLM 评测模型单个上下文窗口所能容纳的范围。 LLM 评测模型只能读取长轨迹的一小部分窗口。轨迹的大部分内容都在评测模型可读范围之外。评测模型遗漏的内容包含输入、轨迹其余部分和输出，其 LLM 上下文窗口只能容纳其中一小段。长期 Agent 的轨迹长度可能超出 LLM 评测模型的上下文容量。将整个轨迹粘贴到一个提示词中很可能直接失败；而截断或切片则会遗漏重要部分。- **状态性操作。** 生产环境中的 Agent 不仅仅是生成文本。它们会查询数据库、调用 API、更新记录、发送消息并触发工作流。一个后台销售 Agent 可能会更新你的潜在客户状态，而评估者必须查看 CRM 来确认该变更是否已生效。 只有 Agent Judge 能够访问持有真相的系统。LLM 评测模型只能看到轨迹，而 Agent Judge 则能检查生产状态所在的系统。LLM 评测模型（GitHub、AWS IAM、Secrets Manager、CloudWatch）只会查看轨迹，看不到对应的环境，因此状态变更无法得到验证。Agent Judge 会查询 Agent 操作过的相同系统，并检查该操作是否真的发生了。- **行为变化。** 随着 AI 系统的改进，模型、工具和用户工作流也在演变。上个月还适用的评估标准可能已经过时，可能遗漏新的失败模式，可能过度惩罚已改进的行为，或者在错误的地方寻找证据。在生产环境中，评分标准必须随着查询分布和 Agent 的变化而演进，以保持评估的准确和有用。 评分标准静止不动，而 Agent 却在变化。固定的评分标准定义了一个容忍带，但生产行为会偏离这个范围。随着时间的推移，模型、工具和用户工作流的变化改变了 Agent 的行为方式。固定的评分标准继续按照旧标准评分，导致评估者无法捕捉到相关的新失败模式。**评估不再是对最终答案的判断。它是对整个轨迹的调查。**评估者必须检查 Agent 看到了什么、做了什么、改变了什么、以及依赖了什么。 ## Agent Judge 我们设计了 Agent Judge 作为一个基于 Agent 的评估框架，通过三种不同的能力来处理上述三种失效模式：搜索 (Search)、验证 (Verification) 和适应 (Adaptation)。 - **搜索：** 通过使长轨迹变得可导航来处理长轨迹问题，使得深藏的证据无需手动审查轨迹即可被找到。 - **验证：** 通过检查工具证据和环境状态来处理状态性操作，从而检查 Agent 操作的实际效果。 - **适应：** 通过将评估结果与人类反馈和生产信号在多个生产轨迹上进行对比，来处理动态的人类和 Agent 行为，使得评分标准能够随着 Agent、工具和产品的变化而演进。 Agent Judge 以多 Agent 系统的方式运行：阅读器 Agent 检查目标证据，派生的工作 Agent 分担搜索或验证工作，分叉的 Agent 则跟进第一轮审查提出的新问题。 ### 搜索 **在长轨迹中，失败模式往往是细微的，很少只出现在一个地方。** 错误可能源自早期的检索结果、一次失败的重试、后续的工具调用，或者最终的答案。评估这些情况通常需要多跳推理：一次搜索发现一条线索，该线索又引发一个新问题，评估者必须顺着这条链条追查下去。 Agent Judge 将长期轨迹转化为一个可查询的对象。消息、工具调用、检索到的文档、数据库响应、日志、重试和状态变更都成为可导航的证据，而不仅仅是塞进单个提示词的上下文。 只提取相关的片段。Agent Judge 会选择决定结果的步骤——其余部分则排除在上下文之外。例如一个编码 Agent 轨迹包含 `read`, `grep`, `edit`, `read`, `read`, `bash`, `read`, `bash`, `read`, `test`, `test`, `read`, `git`, `msg`, `edit`, `bash`, `git` 等步骤。证据片段则被 Agent Judge 在轨迹中搜索，以寻找与评分标准相关的证据。轨迹的其余部分则不会进入工作 Agent 的上下文。Agent Judge 在两个维度上进行搜索：在当前轨迹内部和跨历史轨迹。它可以在情况模棱两可或复杂时花费更多算力：读取目标证据片段，生成工作 Agent 来检查运行中的特定部分，或者在第一次搜索暴露出新信息时分叉进行后续搜索。 - **轨迹内部：** 工作 Agent 检查特定的步骤、工具调用链、检索到的记录、日志或状态变更。一个工作 Agent 可能追踪 Agent 使用了哪条记录，而另一个则检查后续的答案是否依赖于过时或不正确的证据。 - **跨轨迹：** 其他工作 Agent 可以搜索类似的运行记录、先前的标签、之前评测的不一致之处，或重复的失败模式，以了解当前案例是否与系统之前遇到的情况匹配。 协调者收集相关的跨度、工具调用和状态变更，然后将它们组合成一份评估报告，或者在证据不完整时发起后续搜索。 ### 验证 Agent Judge 验证环境状态是否与 Agent 声称的操作一致。Agent 是否更新了正确的记录？API 调用是否成功？生成的 PR 是否修改了正确的文件？工作流是否真的触发了？ 在已记录或实时的运行中，Agent Judge 会检查捕获的工具证据，例如 API 响应、数据库结果、日志、更新确认、检索到的记录和 GitHub 事件。当底层系统暴露了持久的证据（如审计日志、事件流、时间戳或版本化记录）时，Agent Judge 还可以根据只读的真相来源系统（如数据库、服务 API、GitHub、工单系统或 MCP 服务器）来验证状态性操作。 声称的操作与真相来源进行比对。Agent Judge 将每个声明与记录的状态对齐，并标记两者不一致的地方。例如，Agent 声称“已编辑授权文件”、“文件已更改”、“已运行测试”、“已打开 PR”、“Bug 已修复”，但真相来源显示：“仓库差异存在”、“测试已运行”、“CI 系统显示”、“PR #1247 已打开”、“GitHub 显示 1 个测试失败”、“未修复”。Agent Judge 将每个声称的操作与系统的记录状态进行对齐。三项匹配；最后的“Bug 已修复”声明不一致——CI 仍然显示失败测试。Agent Judge 直接评估状态性工作：不是看 Agent 是否描述了正确的操作，而是看该操作是否实际发生。 ### 适应 Agent Judge 通过 Rubric Builder（评分标准构建器）进行适应，这是一个反馈循环，能将经过评估的轨迹和人在回路中的信号转化为下一个评分标准版本的改进。目标是确保人类反馈体现在未来评估所使用的标准中。 评分标准的更新是具体的：添加缺失的标准，使用示例使模糊的语言更精确，减少反复出现的误报或漏报，或者告诉评测模型应更仔细地检查哪些证据。 这个循环会重复进行。Agent Judge 会重新运行更新后的评分标准，直到 Rubric Builder 耗尽对改进的搜索： - **评估：** Agent Judge 使用当前评分标准评估困难或高信号案例。 - **校准检查：** 将评估结果与反馈信号（如人类专家标签、成对偏好、生产结果、环境检查、评测模型之间的分歧，或结果不同的类似运行）进行比较。 - **评分标准精炼：** 一个分析 Agent 审查模式间的差距（而不仅仅是孤立的错误），并提出一个有针对性的评分标准修改。 - **迭代：** 将精炼后的评分标准重新输入 Agent Judge，随着更多生产数据的到来，该过程重复进行。 评分标准逐次收敛。每次重新运行都会对评分标准进行有针对性的修改。准确率上升，然后随着收益耗尽而趋于稳定。通过连续的精炼轮次——每次对评分标准进行有针对性的修改——Agent Judge 的准确率会上升，然后随着 Rubric Builder 耗尽对改进的搜索而趋于平缓。随着时间推移，评分标准成为一个活的、版本化的评估工件：经过生产轨迹的测试，根据反馈进行更新，并随着你的 Agent 一起成长，而不是每次行为变化时都要手动重写。 ## 在内部流量上进行评估 我们使用内部生产流量，针对编码 Agent 和 LLM 评测模型，在轨迹级幻觉检测上测试了 Agent Judge。我们将轨迹级幻觉定义为相对于轨迹、工具证据或真实来源环境状态而言，无根据的声明或操作。 人类专家为每条轨迹标注了是否存在幻觉。我们使用编码 Agent 框架、LLM 评测模型、带有初始评分标准的 Agent Judge，以及经过 Rubric Builder 精炼后的 Agent Judge，对标注集进行了评估。 | 方法 | 设置 | 准确率 | 召回率 | 精确率 | F1 | |---|---|---|---|---|---| | Agent Judge，精炼后评分标准 | 自定义 Agent 评估框架，含 Rubric Builder | **0.86** | **0.88** | **0.71** | **0.79** | | Agent Judge，初始评分标准 | 自定义 Agent 评估框架，含初始评分标准 | 0.76 | 0.80 | 0.58 | 0.67 | | Claude Code | 编码 Agent 框架中的 Claude Opus 4.6，配备 `rg` 和 `jq` | 0.73 | 0.53 | 0.56 | 0.54 | | Codex | 编码 Agent 框架中的 GPT-5.4，配备 `rg` 和 `jq` | 0.69 | 0.63 | 0.49 | 0.55 | | GPT-5.4 LLM Judge | 基于轨迹和评分标准的 LLM 评测模型 | 0.74 | 0.80 | 0.54 | 0.65 | | GPT-5.4-mini LLM Judge | 基于轨迹和评分标准的 LLM 评测模型 | 0.65 | 0.51 | 0.43 | 0.47 | 经过五次精炼迭代后，采用 Rubric Builder 的 Agent Judge 在准确率、召回率、精确率和 F1 分数上均优于初始评分标准。 为了衡量困难案例，我们使用了一个由五个 LLM 评测模型组成的集成基线来评估难度。我们将该基线分别与使用初始评分标准的 Agent Judge 和经过 Rubric Builder 精炼后的 Agent Judge 进行了比较。 按难度十分位数划分的准确率。在轨迹难度启发式下，较高的十分位数表示更困难。横轴为难度十分位，纵轴为准确率 (%)。Agent Judge w/ Rubric Builder 在困难尾部表现最强，而五重 LLM 评测集成基线随着轨迹难度增加而急剧下降。在大多数难度十分位上，采用 Rubric Builder 的 Agent Judge 匹配或超越了基线，而五重 LLM 评测集成的一致性随着难度增加而显著下降。 长期 Agent 的评估应使用具有动态评分标准的 Agent 完成，而不是固定的 LLM 评测提示。高质量的评估需要访问完整的轨迹上下文、Agent 修改过的环境状态，以及随着生产行为演变所需的反馈来适应。 ## 下一步 下一步是进行失败诊断。随着 Agent Judge 评估越来越多的轨迹，它不应仅仅分配分数；它应该分析失败原因，识别涉及的代码路径、工具、提示词或工作流，并揭示最有可能改进 Agent 的变化。 Agent Judge 将评估转变为一个生产改进循环：更好的评测模型产生更好的失败分析，更好的失败分析产生更好的评分标准和训练示例，而同样的循环最终可以反过来向代码库、工具、提示词和工作流提出有针对性的修改建议。