用 Jev 做裁判：Agent 评估新思路

作者：Daniel Shea 与 Seán Roche

关键要点：

• 1Jev 是一种本质不同的评估器。它直接返回类型化答案，而不是像 LLM 裁判那样生成文本。
• 2在连续打分上，Jev 的一致性大幅领先。其质量分方差比 GPT-5.6 Luna、Terra 和 Claude Sonnet 4.6 低 92–913 倍。
• 3Jev 也是最快、最便宜的。平均 0.44 秒、每调用 $0.00035（总计 $0.34，而 Claude 为 $28.17）。
• 4结果令人鼓舞，但仍属早期。尽管这是一次窄范围测试，Jev 的表现指向了 Agent 评估的一个有说服力的新方向。

如今，Agent 评估主要有两类：基于代码的评估，以及 LLM-as-judge。二者各有局限：基于代码的评估器只能用于输入固定的窄问题集；而 LLM 裁判可能慢、贵且不可靠。随着 TypeSafe AI 的 Jev 广受关注发布，我们想看看这种「System One」模型能否成为 Agent 评估器的第三种形态，以及对 Agent 工程可能带来的影响。

Jev 是 TypeSafe AI 发布的新模型。Jev 实际上并不是传统 LLM；它不生成文本。TypeSafe AI 团队称之为「System One」模型：

“📖 System One 模型是一类旨在做出快速、结构化决策、可供软件直接使用的 AI 模型。System One 模型评估一个状态，并返回类型化答案与概率。”

据 TypeSafe AI 称，这使 Jev 比 LLM 更快、更便宜：在分类任务上，推理速度最高可快约 200 倍，成本可低约 400 倍。

当今的 Agent 评估要么基于代码，要么是 LLM-as-a-judge，各自有一套收益、局限与权衡。

基于代码的评估几乎与代码本身一样古老。它便宜、快速、可靠，主要缺点是能力范围更窄。传统函数需要确定的输入，因此评估 Agent 行为这种随机世界的能力有限。例如，传统函数可以判断 Agent 是否在首次运行中调用了某个工具，却更难判断 Agent 是否随后利用工具结果成功回答了用户问题。在开放式任务中，同一工具结果可能有多种有效用法，要把每种可接受答案都编码成确定性逻辑，很快就会撞上基于代码评估的窄范围局限。

于是出现了 LLM-as-a-judge：用 LLM 对 Agent 轨迹中的非结构化输入进行推理并打分。LLM 裁判可以接受问题、轨迹与证据等非结构化输入，再通过提示词评估回复是否回应了用户请求。

但任何 Agent 工程师都会承认，LLM 裁判并非完美方案。它们本质是非确定性系统，难以成为可信测试装置的坚实基础；而且比传统基于代码的评估更慢、更贵。

Agent 评估是一项决策任务：给定 Agent 的状态与行为，给出可提供反馈的分数。Jev 正是为此模式而设计。它对照结构化状态评估类型化问题，并返回带概率的类型化答案。相比之下，自回归模型通过逐 token 生成才得出判断。在我们的实验中，这种「决策优先」的设计与更低延迟、更低成本、更低方差同时出现。

Jev 支持三类问题：

Choice 选择一个选项，并返回概率与置信度。

• 1示例：「最终答案是否基于检索到的证据？」
• 2响应：0.0 到 1.0 的浮点数，1.0 表示完全有据可依

Score 按有序评分标准为答案打分，并返回概率与置信度。

• 1示例：「这个答案有多有用？」
• 2响应：1（无帮助）到 5（非常有用）的量表分数，外加概率与置信度

Noul 返回某是/否判断为真的概率。

• 1示例：「哪种搜索结果最能描述这次运行？」
• 2响应：searched_appropriately、searched_unnecessarily 或 failed_to_search 之一，外加概率与置信度

多个原子问题可以针对同一状态并行评估。

当 Agent 行为、检索数据或轨迹上下文在各次运行间变化时，比较裁判很难。Deep Agents 与 LangSmith 让我们把单次 Agent 运行捕获为数据集，并在每个模型上重放。

为了检验 Jev，我们需要一个可打分的 Agent。我们用 Deep Agents（开源 Agent 框架）构建了目标 Agent，再把测试集定义为 LangSmith dataset，使每个评估器面对相同问题与期望行为。测试集包含五个天气请求：

对数据集中的每个样例，我们捕获天气 Agent 的回复，并将完整输出作为固定样例存入 LangSmith。每位裁判用两个信号评估这五次捕获运行：quality（连续分数）与 does_pass（二值判定）。

为将正确性与可重复性分开衡量，我们请人工评审员按同一评分标准为每个固定回复打标签。以人工标签作为金标准（oracle）分数，得以更丰富地分析精度与正确性对评估器整体有效性的影响。

准确率衡量与人工金标准的一致性。方差衡量裁判在相同 Agent 行为上是否稳定得出同一判断。方差更低并不自动等于准确率更高：裁判也可能稳定地错。但当裁判准确时，更低方差让这种准确在生产中更可依赖。

我们将 Jev 与 GPT-5.6 Luna、GPT-5.6 Terra 和 Claude Sonnet 4.6 对比，计算 100 次重复下的逐例方差，以及与人工金标准的一致性。

准确率

以人工评审员标签作为本次对比的金标准，我们计算了二值通过/失败判定的准确率。

对于二值 does_pass 分数，Jev 在全部 500 次重复判定中都与金标准一致。Terra 一致率为 99.8%，Luna 为 96.4%，Claude 为 80.0%。

精度

准确率告诉我们裁判是否与人工金标准一致。精度则问：在 Agent 行为不变时，它是否给出相同的质量分。我们用各裁判分数的观测方差来衡量精度。

Jev 的观测平均逐例方差最低：0.0000149。Luna 高 433×，Terra 高 913×，Claude 高 92×。

本实验无法说明为何 Jev 的分数波动更小。一种假设是：这些模型针对不同输出形态做了优化。TypeSafe 将 Jev 描述为训练来返回校准概率与类型化答案的决策模型；而自回归 LLM 裁判先生成文本，再由评估器把输出映射成分数。这种差异可能使 Jev 更适合这项有边界的评估任务，但该结果是观察性的，并不能证明其训练目标导致了更低方差。

成本与延迟

低成本意味着大规模运行 Agent 评估可以更现实。当评估调用昂贵时，团队不得不在覆盖面与预算之间取舍。在本实验中，Jev 每调用 $0.00035，使这一权衡不那么严峻。团队负担得起更多重复判定与更频繁的回归检查。这对在线评估尤为重要：更低的单次成本让团队能在更大比例的生产轨迹上跑更多裁判，从而得到更密的反馈信号。

对于每天产生 10,000 条轨迹的生产 Agent，观测到的单次调用成本会转化为显著的运营差异。

为衡量低成本调用是否真正有用，我们将信号价值定义为：二值金标准一致率 × 二值可重复性。可重复性是两次独立调用对同一轨迹返回相同裁决的概率。这奖励既准确又稳定的裁判，同时惩罚稳定出错的裁判。

像 Jev 这样高信号、低成本的裁判，有望为在线评估器释放更大价值。团队可以对更多生产轨迹生成反馈，更早发现质量变化，并在反馈开始朝错误方向趋势时设置告警。

如今，每次 Agent 评估都带着权衡。评估更多运行、更多维度，或测试更多变更，测试成本就会上升。这迫使团队评估得比他们希望的更少。

在我们的实验中，一次 Jev 判定成本为 $0.00035。除了低成本，Jev 还提供了高准确率与低方差，意味着裁判结果可靠且高信号。这个价位的优质裁判意味着构建者可以按多项聚焦标准评估每次 Agent 运行、衡量每一次 Agent 变更，并在需要置信度时重复判定。

这很重要，因为打造优秀 Agent 需要大量测试与监控。你评估 Agent 越频繁，进入开发循环的有用反馈就越多。

我们仍需观察本实验结果能否推广到其他 Agent 与生产工作流。此外，低成本也会放大错误——稳定出错的评估器可能大规模产出坏反馈。工程师仍需把人工评审与裁判对齐纳入工作流。

新型 System One 风格模型有望让高质量评估变得充裕。这可以加速整个 Agent 开发生命周期。Agent 工程师能把更多轨迹转化为反馈，更早捕获回归，并在构建、测试、监控与部署 Agent 时走得更快。解锁的不只是更便宜的评估，而是构建可靠 Agent 的更紧反馈闭环。

本项目的 GitHub 仓库可在此获取。

我们通过 LangSmith Gateway 运行 LLM 裁判：GPT-5.6 Luna、GPT-5.6 Terra 和 Claude Sonnet 4.6。Jev 通过 langchain-typesafe==0.0.1a2 访问。

为便于复现，本次运行使用 Deep Agents 0.7.15、LangChain OpenAI 1.6.2、LangSmith 0.12.6 和 Tavily Python 0.8.3。我们未为 LLM 裁判设置 temperature、top-p、seed 或 max tokens，因此使用各提供方默认值。实验元数据中未提供 Jev 服务版本。

若想进一步了解用 Jev 构建 Agent，LangChain 将在 9 月 22 日（周二）与 TypeSafe AI 团队举办直播。