Jev：把智能体监督从抽样审计变成全量遥测的决策接口

Jev 是 TypeSafe 在 2026 年 9 月推出的类型化概率决策接口：你把"状态 + 一组问题"发过去，它一次性并行返回每个问题的类型化答案、各选项概率和置信度。官方宣传里它有多快多便宜，我们后面会逐条核验。这篇文章想讲的是它真正改变的一件事：当"判断"便宜到可以为每一条 trace（一次 agent 运行的完整记录，工程上叫遥测（telemetry））反复调用时，智能体监督就从抽样审计升级成了全量遥测。随之转移的还有真正的瓶颈，从推理成本转到规则质量、校准与升级机制。

驱动全篇的是一个问题：判断这件事又贵又不稳定，团队只能抽样审计，罕见故障天然漏检。那么，把判断本身改造成一种便宜、快速、类型化的接口，会发生什么？

一、一个标签也要生成一整段：LLM judge 怎么把评测逼成抽样

1.1 报出来的准，是被机会抬高的

你的 agent loop（代理循环：模型思考、调用工具、观察结果、再思考的迭代）里几乎一定挂着这样的评审：每次任务结束，把 trace 塞给一个大模型，请它判断"这次完成得好不好"。它逐 token（词元：模型生成文本的基本单位）自回归地往外吐一整段评语，然后你从里面抽取那一个 pass/fail 标签。这就是 LLM judge（大模型评审：用大模型给另一个模型的输出打分的做法）。

这个习惯动作埋着三个账：为一个标签付整段生成的延迟与费用；每次采样结果都不一样；报告的一致性与"正确答案"的真实一致性相差甚远。

加州大学伯克利分校的 Norman 等人在 2026 年 6 月的论文 Reliability without Validity 里，把这份直觉摊成了统计底盘：21 个 judge（评审模型）、9 家 provider、3 个 benchmark（评测基准）、118 轮运行、约 54 万次判断。结论有两条，都值得记住。

第一条叫 kappa deflation（kappa 坍缩）。kappa 这个术语指机会修正的一致性：把"瞎蒙也能对上"的部分扣掉之后，剩下的一致才反映真本事，具体指标叫 Cohen's κ。论文发现，在 MT-Bench 上 21 个 judge 无一例外都犯了同一个毛病：exact-match（字面一致率）比 κ 高出 33.8 到 41.3 个百分点。你的评测报告写着"judge 和人工 85% 一致"？机会修正之后大概只剩一半。为什么这么普遍？因为当两个候选都不好、或者任务本身偏向某一方时，随机一致本来就高，exact-match 把你的运气也算成了能力。Reliability without Validity

第二条叫一致性-偏差悖论（consistency-bias paradox）。test-retest reliability（同一个 judge 对同一输入重复测、结果稳不稳）和 position bias（位置偏差：答案 A 排在前面是不是更容易赢）是两个数学上正交的量。一个 judge 完全可能每次都坚定地选 A 位，于是重复性满分，但这是因为它偏爱位置而不是内容。论文里有现成的实例：Qwen 3 8B 的重复一致性高达 0.992，位置偏差却高达 0.192；Gemini 2.5 Flash 是 0.988 和 0.125。又稳又偏，真实存在。换个 benchmark 情况只会更糟：judge 的排名会剧烈漂移，比如 Llama 3.3 70B 在 MT-Bench 排第 5，到 JudgeBench 掉到第 19；21 个 judge 里有 11 个跨 benchmark 漂移至少 4 位。Reliability without Validity

把这两条结论放一起，你才看得懂这张双面板图：

图注：左面板是 kappa deflation：21 个 judge 每人的字面一致率（橙点）都高出机会修正后的 κ（蓝点）一大截，中间的灰线就是被随机性抬高的部分。右面板是一致性-偏差悖论：横轴是重复一致性、纵轴是位置偏差，Qwen 3 8B 和 Gemini 2.5 Flash 落在右上角"又稳又偏"的象限。读图时看整体形态，不要逐个数去抠单个 judge 的数值。Reliability without Validity

也就是说，你的评审器可能同时"很准"（重复性高）和"很不准"（内容偏好强）。这两个面板合起来，把"LLM judge 不够可靠"从个人体验升级成了 21 个模型的统计事实。

1.2 同一个 judge 问 50 次，翻案 13.6%

如果你觉得换个大一点的模型就能解决，单 judge 的深挖数据会浇上一盆冷水。阿贝尔·亚古比安在 2026 年 4 月的论文 The Coin Flip Judge? 里，把两个 OpenAI judge（GPT-4o-mini 和 GPT-4.1-mini）放到 29 个任务上，每个任务重复 50 次。结果平均 pairwise flip rate（成对翻转率：同一对候选前后两次判出相反胜者的比例）高达 13.6%，28% 的任务翻转率超过 20%，最严重的一个达到 56%。The Coin Flip Judge

把温度设成 0（让采样近似确定）能大幅压住翻转：GPT-4o-mini 从 13.3% 降到 2.8%，但 GPT-4.1-mini 仍残留 7.9%，而且分布在 29 个任务中的 7 个上。作者的判断是，残余来自 API 层的不可确定性：确定性解码是必要条件，不是充分条件。

那到底要问几次才稳？论文画了一条 reliability curve（可靠性曲线）：对同一个判定做 K 次多数投票，要恢复到与"50 次参考裁决"95% 一致，平均需要 11 次；简单题 3 次就够，难题 50 次都不够。这张图是"单次判断不可靠"最直观的工程表达：

图注：左面板是 K 次多数投票与 50 次参考裁决一致的概率曲线：容易的题约 5 次收敛，全部题目要 10 到 15 次，难题层即使到 50 次也达不到完全一致。右面板统计每个题目需要多少次才能达到 90% 保真度，末尾拖着一条需要 15 到 50 次以上的长尾。The Coin Flip Judge

顺带一句提醒：judge 要防的不只是自然随机性。阿尔·马苏德等人的安全综述（LaaJ SoK，即 LLM-as-a-Judge 安全系统化综述）梳理了 2020 到 2026 年的 45 篇文献，指出 judge 既是被攻击的对象，也能被当成攻击工具，而评测协议本身缺乏统一标准。LaaJ SoK

1.3 三个问题同源：自回归输出范式

上面的三件事，要拆成两层来读。第一层是输出机制本身，可以直接确定：LLM judge 是自回归（autoregressive）模型，只能一个 token 一个 token 地往外吐，判断"过/不过"这种二元标签，也得先编完一整段话；采样让每次编出来的都不一样，而你要为整段生成付钱。对自由文本 judge 来说，逐 token 生成直接增加成本、延迟和采样波动，这是机制层面的必然。第二层是偏差与有效性问题：前文的 kappa 坍缩、一致性-偏差悖论、单次判定大量翻案，都是需要另行验证的风险，类型接口消除不了它们，不能靠这种接口自动消除。

TypeSafe 在发布帖里把这种错配说得最直白：传统 LLM 的输出是字符串，总有跑偏的风险，采样是逐 token 串行的；而它们推出的 Jev 属于一类新模型。对一个"过/不过"的判定，传统做法要付 3 到 329 秒的端到端延迟和每百万 token 数美元的输入费用（这是 TypeSafe 转引 Diego Romero 的 llm-benchmarks 实测区间，属厂商口径）。TypeSafe 在这样的价位上，你能承受的判定次数极其有限。

于是团队只能抽样评测：在 5% 的 trace 上、离线、事后打标签。两个后果随之而来：罕见故障天然漏检，因为抽样本身就意味着绝大多数 trace 根本没人看；更糟的是，你根本不知道哪些 trace 值得被抽。抽样不是选择，是被迫。所以，如果判断本身可以更便宜、更稳定、更快呢？下一章看 Jev 给出的回答。

二、不生成文字、只回概率：Jev 把判断变成了什么

2.1 一次请求，并行回答 N 个问题

Jev 的机制核心一句话就能说清：在请求里把所有要问的问题一次声明好，模型并行评估，返回类型化的答案和概率。

先看请求/响应契约。你发一个 state（状态，结构化程序状态或一段短文本），带上若干个 questions（问题，每条声明 type、instructions，以及可选的 criteria 评分标准），一次请求发过去。模型对同一个 state 并行评估每一个 question，响应里按你自定义的 question id 返回一组类型化答案：Choice、Score、Noul 三者之一，附带概率，Choice 和 Score 还附带 confidence（置信度）。TypeSafe

工程师自然会问：这和让 LLM 输出 JSON 有什么不同？三个字：不一样。LLM 输出 JSON 仍然是逐 token 自回归生成，要解析、要校验，总有跑偏的可能；Jev 的答案被强制限制在预先声明的类型里。"类型安全"的字面意思就在这里：它来自声明的枚举与输出结构之间的强制约束，而不是来自"模型很聪明"。这张官方流程图把这个一次请求、一次响应的循环画得很清楚：

图注：从左到右的请求/响应契约：调用方把 state 和多个 question 装进一次请求，模型对同一个 state 并行评估每个问题，一次响应返回类型化答案加概率加置信度（Choice 和 Score），你的代码再基于这些类型化值分支、排序、路由。Jev API

2.2 三个原语：Choice / Score / Noul

• Choice（选择题）：从你声明的选项里选一个。选项最多 255 个；返回选中的 option、每个选项的概率（加起来等于 1）和 confidence。
• Score（打分题）：一组有序档位，2 到 10 级；返回按概率加权的位置（比如 1.3 表示"大约 1 档、略倾向 2 档"）、level 的文字说明和 confidence。
• Noul（判断题）：yes/no 二选一，返回一个 0 到 1 的概率。注意它没有 confidence 字段，概率本身就是答案；Noul 等于 0.5 表示"真不知道"，不是"中等"，读它的 .confidence 会拿到 undefined。Jev API

confidence 特别值得说清楚。它不是"选对"的概率，而是概率分布形状的浓缩：分布越集中在某个选项上，confidence 越高，分布越平，越低。官方文档的原话是，confidence 描述的是模型的答案，不是答案正确的保证。这一点请先记下，它是全篇要拆穿的那件事的第一层。

2.3 对照表：LLM 输出字符串，Jev 输出类型化概率

TypeSafe 发布帖里的官方对照表（"Frontiers, Old and New"），把 Jev 和传统 LLM 的差异按行摊开（全部为厂商自报口径，价格是早期访问列表价）：

这里出现一个术语需要先解释：校准（calibrated）。一个判断器说某答案有 80% 概率，长期看确实约 80% 是对的，就叫校准良好。Jev 的训练目标 RLCD（Reinforcement Learning for Calibrated Decisions，为校准决策的强化学习）优化的就是这件事：给出诚实的概率，而不是只顾猜一个最可能的答案。TypeSafe

光有抽象定义没有体感。LangChain 在 2026 年 9 月 17 日发布的 harness 博客里，把 Jev 接进了自己的 agent 中间件，并贴出三原语在同一个 state 上实际并行输出的样子：

图注：同一段用户消息 state 上，三个问题并行返回：Choice 把问题归类为 billing（权重 0.84）、Score 把用户情绪打在三档刻度上（Score 值 1.035、confidence 0.842）、Noul 给出紧急度概率 0.999。图中的数字是一次示例请求的输出，不是评测结果。LangChain Harness

LangChain 把它封装成了两个中间件：ModelRouterMiddleware 在每次 run 开始前用 Choice 决定"这次用哪个模型"，AutoModeMiddleware 在每次工具调用前用 Noul 判断"这个动作危不危险"，高风险直接阻断。两个 API 目前都标注 experimental（实验性，接口可能变动），但"在 agent 框架里把判断抽出来当独立中间件"这条路，已经被主流框架官方盖章了。LangChain Harness

这里必须守住一个分寸：Jev 消除了输出空间和解码成本，这是真实的机制变化；但它没有把自然语言规则变成确定性程序。规则（criteria 和 instructions）仍然在每次请求时被解释，模型可能按字面理解歧义，在选项没覆盖真实意图时被迫挑一个。schema（结构契约：声明了返回什么类型的那份定义）保证的只有一件事：它不会输出你未声明的类型。第一章的 kappa 坍缩、位置偏差、校准失真，在 Jev 上依然可能存在，只是形态不同。这一点，下一章用证据展开。

怎么用才不会出事？先不急着回答。因为"怎么用"取决于"证据有多硬"。

三、0.44 秒、500/500 全对——但这组证据的边界在哪里

3.1 一个只有 5 条 trace 的实验

这一章我们对比着读两组厂商和集成方自报（first-party）的证据，练的是同一件事：怎么读"数字很好看"的实验。

先看 LangChain 的评测实验（2026 年 9 月 20 日发布）：目标 agent 用 Deep Agents 0.7.15 搭建，测试集是 5 条天气请求的 trace，每条 trace 的响应被冻结成固定快照；4 个 judge（Jev、GPT-5.6 Luna、GPT-5.6 Terra、Claude Sonnet 4.6）对同一组快照分别评判，每条重复 100 次；同时人工审阅者按同一评分标准给出固定标签，作为 oracle（人类基准）。

二元"过/不过"判定上，结果是这张图：

图注：4 个 judge 在二元判定上与人工 oracle 的一致率：Jev 100.0%（对应正文的 500/500）、Terra 99.8%、Luna 96.4%、Claude 80.0%。柱顶的 100% 要和"5 条 trace 各重复 100 次"的样本量对齐读，不要单独理解成零失败率。LangChain Eval

连续打分部分，Jev 的方差是 0.0000149；同样一条 trace 重复 100 次，Luna 的方差是它的 433 倍，Terra 是 913 倍，Claude 是 92 倍。成本与延迟：Jev 平均 0.44 秒一次、每次约 0.00035 美元；Claude 跑完同一组实验总共花了 28.17 美元。LangChain Eval

"低方差"的形态长什么样？看这张四面板折线图：

图注：5 个冻结 case 上 100 次重复的 does pass 均值，四个面板共享同一缩放后的纵轴：Jev 的线完全水平，Luna 的线频繁上下尖峰，Terra 基本平直但中部有一次下跌，Claude 完全水平。图中没有标具体百分比，数字以正文为准。LangChain Eval

3.2 但是：这组数字的前提

数字好看，恰是因为我们还没读实验的边界。LangChain 自己在文末把这些边界一条条列了出来：

• 只有 5 条 weather trace，领域极窄；
• LLM judge 的 temperature、top-p、seed、max tokens 全部用 provider 默认值，没有固定；
• Jev 的服务版本没有写进实验 metadata（元数据）；
• 原文原话是：结果只是观察性的（observational），不能证明是 Jev 的训练目标造成了低方差，实验也回答不了"为什么"；
• 最重要的一句：低成本可以放大错误（low cost can amplify mistakes），一个稳定犯错的评审器在规模化之后只会产生更多坏反馈。

把"0.44 秒、500/500、92 到 913 倍方差差"和这五条边界放在一起，正确的读法是：Jev 快、稳、便宜，在这个特定实验环境下成立；把这些数字当普适基准，就把窄实验的证据越界使用了。另外注意口径：0.00035 美元/次是 LangChain 实测的单次请求成本，0.042 美元/百万 token 是 TypeSafe 的定价口径，量纲不同，不可互换。

3.3 同一个接口，搬到文档路由：DocJev

Jev 是不是只能用来评 trace？DocJev 给出了反证。这是 LlamaIndex 作者 jerryjliu 开源的文档分类与切分库（Apache-2.0 协议，明确不调用 LlamaIndex 的 Classify/Split API）：你传一份 PDF 加一份用自然语言写的分类规则，它返回整篇文档的类别和概率；传一个多文档包，它返回带类别和页码的段落切片。数据换成了文档，用的还是同一个 state + questions 契约。DocJev 它的管线长这样：

图注：DocJev 的管线：OCR 适配器（本地 liteparse 或云端 LlamaParse）先抽出文本，parse_document 把文本和规则打包成 state 和问题，engines.jev 用类型化概率问题做分类或边界判定，最后导出带类别和页码的段落。OCR 与决策引擎解耦，是接口层与实现层分离的体现。

它在 40 份真实公共部门 PDF 和 8 个组装文档包上跑出了一组数字（均为 first-party）：Jev 1.13.0 对比 GPT-5.6 Luna，分类决策时间 138.6 毫秒对 794.3 毫秒（约 5.73 倍快），切分 209.6 毫秒对 1352.3 毫秒（约 6.45 倍快）；双方分类都是 40/40 全对，切分 Jev 7/8、Luna 8/8，Jev 多切了一刀。实测成本 Jev 0.011663 美元、Luna 0.046894 美元。仓库自己的说明反复强调：8 个包不足以建立普适准确度，决策时间不含 OCR，样本共享模板。这篇专题要记住的是 DocJev 更大的价值：同一个接口既评 agent trace 又切文档包，说明它是一个接口机制，不是一个单点应用。DocJev

3.4 反转：0% 是类型保证，不是实证准确率

最后回到 TypeSafe 自己的营销材料，练一个关键眼力。发布帖里有一张对比图：11 个模型在"结构化输出错误率"和"工具调用错误率"两个指标上，Jev 是 0%，其他模型从 0.58% 到 45.5% 不等。这张图常被当作"Jev 零错误"来传播。

厂商自己的小字才是重点。TypeSafe 在文末自陈：LLM 的数字来自 OpenRouter，本身有偏；"我们的数字不是实证的。schema 匹配是保证的，所以我们有把握在图上加 0%"（Our number is not empirical. Schema matching is guaranteed）。换句话说，0% 说的是"声明了 Choice 就不会返回 Choice 之外的答案"，这是类型系统层面的保证，不是"Jev 判断总是对"的实证结果。把类型保证当成准确率，正是"类型安全等于正确"这套说法里最普遍的误读。TypeSafe

图注：TypeSafe 发布帖中的厂商对比图：左右两栏分别是结构化输出错误率和工具调用错误率，各 11 个模型按错误率从低到高排列，Jev（图中记作 jav）排在最左、两个指标都是 0%。这是 schema 强制保证的 0%，不是语义准确率的结论。TypeSafe

这一章值得带走的不是"Jev 有多好"，而是读证据的方法：快、稳、便宜的证据是真的，但全部来自 first-party 窄实验；把窄实验的数字当普适基准，才是我们真正要反对的错误。0% 同理，它是类型系统的保证，不是真理的保证。

四、记录每一笔判断之后：全量遥测如何放大单个坏判断器

4.1 决策接缝：Jev 在 runtime 里的正确位置

前面三章回答了"Jev 是什么、证据到哪"。这一章回答"把它接进系统之后，系统会发生什么"。

先把位置放对。Bloss0m 的工程分析（2026 年 9 月 18 日）把 agent runtime 切成五层职责：Planner（规划：理解目标、提出步骤，交给前沿 LLM 或现有 agent）、Decision layer（决策层：判断意图、风险、置信度和是否需要审查，交给 Jev 或其他类型化分类器）、Tool broker（工具网关：检查权限、schema、超时、幂等和重试行为，交给代码）、Side-effect executor（副作用执行：写数据、发消息、部署、删资源，交给代码加策略）、Review boundary（审查边界：低置信度、冲突或高风险结果升级给人）。Bloss0m

图注：自上而下的五层职责：Planner、Decision Layer、Tool Broker、Side-Effect Executor、Review Boundary，右侧虚线把审查边界回环接到 Planner。Jev 的正确位置只占决策层那一格，它不是一个替代 planner 的新 agent。Bloss0m

这个分层点出两个容易忽略的事实。第一，Jev 不是"另一个会聊天的 agent"，它不拥有整个工作流，只回答一小撮可校准、可审计的问题，供代码组合。第二，模型可以提议意图，但自然语言本身永远不能授权一个不可逆动作：即使 Jev 返回高置信度，工具网关仍然要校验 actor、资源作用域、重试语义。判断器和权限系统是两层，混在一起是把风险升上去最快的方式。

4.2 监督密度：从抽样审计到全量遥测

位置放对之后，再算经济账。单位判断成本从"一整个 LLM judge 调用"降到"几十到几百毫秒、几分之一美分"，能带来什么？答案是监督密度（supervision density）的跃迁。

抽样审计时代的做法是：离线、事后、抽一小部分 trace 抽查。全量遥测时代，你可以给每一条 trace、每一次工具调用打上多个原子标签：这是什么意图、风险多高、需不需要人工审查、要不要放行。Bloss0m 还给出了 fan-out（扇出：一次并行问一堆问题的模式）的三个前置条件：问题共用同一份 state 且不依赖前序答案；选项和评分标准稳定到可以离线测试；被丢弃的答案不能被当成已验证的答案，日志要区分 unused、rejected、policy-conflict。Bloss0m

注意到措辞的变化：监督从此不再是"你运气好抽中了那条坏 trace"，而是"每一条都在被评估"。这看起来是纯收益。但监督密度翻倍不会自动带来正确。它放大。

4.3 覆盖率越高，单个坏判断器越致命

把上一章 LangChain 自陈的"低成本可放大错误"翻译成结构性语言：当每个判断都便宜到可以被调用一万次，判断器自身的错误就不再是抽样里的偶发噪声，而是全量上的系统性偏差。一个校准失真（confidence 高但经常错）或规则写错（criteria 描述不当）的判断器，会把同一种错误重复施加到每一条 trace 上。第一章的一致性-偏差悖论在这里露出獠牙：又稳又偏的 judge 在全量覆盖下最危险，因为它的"稳"会让监控系统误以为它可靠。对抗性维度同理，LaaJ 综述里那些操纵 judge 的攻击面不会因为判断器变快、变类型化就自动消失。LaaJ SoK

4.4 分数反哺训练：Goodhart 定律的结构性版本

更隐蔽的风险在反哺训练这一步：把判断分数拿回去当训练信号。这里登场的定律叫 Goodhart：当一个度量变成目标，它就不再是好度量。它的机器学习版本有一个可测量的表述，来自 Gao 等人 2023 年的论文 Scaling Laws for Reward Model Overoptimization。先解释两个词：reward model（奖励模型：给输出打分、用来指导训练的模型）和 proxy（代理者：任何学出来的 judge 本质上都是某个"真相过程"的代理，代理与真相之间的差距叫 proxy-gold gap）。

论文的实验设计是这样的：真实 RLHF（用人类反馈训练模型的流程）里，人类标注的比较数据训练出一个 proxy 奖励模型，再用强化学习或 best-of-n 去优化它；论文用一个人造的 gold RM（金标准奖励模型）扮演不可直接测量的"真相"。测量结果是：优化越用力，gold 分数先升后降，形成一个峰值。两条 scaling law：best-of-n 下 gold 分数约等于 d(α−βd)，强化学习下约等于 d(α−β·log d)，其中 d 是优化前后策略的 KL 距离。关键在于：曲线的形状由代理的属性（参数量、数据规模）决定，而不是由优化算法决定。Goodhart

图注：左"Real RLHF"：人类标注产生比较数据，训练 proxy RM，再被 RL/BoN 优化；右"Synthetic"：用一个固定的 Gold RM 代替人类标注，其余管线完全相同。无论标签来自人类还是金标准模型，proxy 都是其真相过程的代理，proxy 与 gold 的差距在构造上就存在。Goodhart

翻译回 Jev 的语境：如果你把 Jev 的分数当作奖励信号反哺训练另一个模型，Jev 分数就成了优化目标，策略会学会迎合 Jev 而不是提升真实质量。更反直觉的是，加 KL 惩罚（惩罚策略漂移太远的正则项）在这篇论文里并不移动 gold 分数前沿，效果近似早停，救不了 Goodhart。Goodhart

这一章的总账：覆盖率上升只会更快放大一个失真或错误的判断器；判断变便宜带来的不是错误更少，而是错误更密。瓶颈从推理成本，转移到了规则质量、校准与升级机制。

五、怎么用才不会出事：硬规则 + 低置信度升级 + 持续校准的分层方案

5.1 三条工程警示

前四章拆完了问题，这一章给方案。核心一句话：Jev 负责高频、可复核的判断，把"不确定"诚实地交回给更贵或更慢的裁决者，而不是假装自己永远正确。

动工之前先立三条警示，都来自 Bloss0m 的 runtime 分析：confidence ≠ permission（置信度不等于授权：模型信号不能证明 actor 已被授权，身份、租户、资源作用域、审批仍然要 runtime 自己校验）；type safety ≠ semantic safety（类型安全不等于语义安全：结果满足 schema 也可能误读文档、漏掉新上下文、在罕见情形下过度自信）；no answer ≠ low score（无答案不等于低分：当选项集没覆盖真实意图，模型被迫在错选项里挑一个，置信度门控修不好破碎的概念体系，runtime 要暴露 unknown、needs_more_context 并升级给人，而不是加更多选项）。Bloss0m

5.2 按后果严重度分级设阈值

TypeSafe 官方推荐的起始模式就是三档：高置信度直接执行；中置信度谨慎执行或请用户确认；低置信度不执行，路由给人工或另一套系统。注意 High/Medium/Low 不是 TypeSafe 的强制值，而是政策阈值，要团队用 golden set 和风险模型自己校准。Jev API

图注：Confidence-Gated Routing 示例决策表：billing 意图下，高置信度放行只读查账，中置信度先出草稿等人审，低置信度升级给前沿模型或人工且禁止对外写；底部还有"其他意图一律回通用分流"的兜底条，右侧按敏感度把动作分成不可逆、可恢复、只读三档。High/Medium/Low 是政策阈值，不是厂商强制值。Bloss0m

阈值不该全局统一，而该按"动作后果有多严重"分级。Maxime 的工程清单（另一篇独立分析）给出了一套可直接照抄的 cookbook 数字（TypeSafe first-party 口径）：

Decision Seams

哪些判断点值得交给 Jev？Maxime 的分析给出一个干净的判定单位：decision seam（决策接缝），也就是"代码必须先做一个判断才能决定下一步"的那个连接点。判定测试是两条：能否在见到具体输入之前预先列出全部可能答案？每个答案是否触发不同的下游动作？缺一条就不算 seam。上下文生成这类"需要整段的活"不是 seam，留给 LLM。Decision Seams

图注：一段 5 节点工作流 Input → Retrieve → Context → Generate → Act 中，3 个红色菱形（INTENT、ADMIT、GRADE）是值得类型化的决策接缝，由 Jev 承接；Context 和 Generate 之间的灰色圆点标注 not a seam，表示这段留给 LLM。价值在接缝处，不在那些方框里。Decision Seams

5.3 保留可审计字段，别只存 0.82

如果你把多个 Jev 判断合成一个工作流分数（composite scoring），有一条硬约束：保留原始维度、权重版本、问题 schema 和最终路由。如果只存一个 0.82，日后想查"为什么这条 trace 放行了"，一无所获。0.82 无法区分"高相关低风险"和"低相关被权重推高"：

图注：Composite Scoring 的滥用风险：Relevance、Risk、Overall priority 三个维度被压成一个 composite = 0.82 之后，无法分辨高相关低风险还是低相关被权重推高；底部警示条要求保留原始维度、权重版本、问题 schema 和最终路由。Bloss0m

Jev 响应里本来就有可审计的原料：每个答案带概率和 confidence，响应里还回带真实模型版本号（jev-1.13.0 这种，不是 alias）。把它们连同 question id、state 快照、政策版本一起落进 trace，你才拥有"出问题能追到具体一个判断"的能力。Jev API

5.4 上线前与上线后：校准、漂移、反哺训练的门

上线前，给判断器设一组验收门。第一章那篇 21 judge 论文顺带给出了一个 Minimum Viable Validation Protocol（最简可用验证协议），五项：用机会修正的指标（κ 而不是 exact-match）作报告口径；用 AB+BA 交换法测位置偏差；在 temperature=0、关缓存下至少跑 3 次独立重复测一致性；至少用 2 个覆盖偏好型与正确型标签分布的 benchmark；当重复一致性超过 0.95 时，必须验证位置偏差低于 0.10。第五条是最反直觉的：高稳定性加高偏差是失败模式，不是优点。Reliability without Validity

上线后，用独立标注持续测量校准与漂移：另换一拨人、按同一套标准抽查 Jev 的判定与真实标签的差距，差距爬升说明规则失效或分布漂移了。若分数要反哺训练，必须 pin 版本（把 alias 钉死成固定版本号，别让静默升级悄悄改变判定分布），并接受上一章说的那个现实：proxy 与 gold 的差距是结构性均衡，不是校准能修复的。Jev API

5.5 收束

回到主线一句话：Jev 的价值，是把"概率性语义判断"变成便宜、快速、类型化的接口，让监督从抽样审计变成全量遥测；但在全量覆盖下，判断器自身的质量、校准与升级机制成了新的瓶颈。所以正确的用法是分层：硬规则守住不可违反的边界，Jev 处理高频模糊判断，低置信度和高风险升级给 LLM 或人工，独立标注持续测校准与漂移。判断越便宜，你就越应该把"不确定"当一回事，而不是当它不存在。类型安全保证了接口，只有校准、复核与升级机制能保证接口的诚实。

参考文献

本专题引用的核心资料如下，建议深入学习时阅读原文：

1. Introducing System One Models & Jev — https://typesafe.ai/blog/introducing-system-one-models-and-jev
2. Jev API Reference — https://docs.typesafe.ai
3. Building a Harness with Jev — https://www.langchain.com/blog/building-a-harness-with-jev
4. Can Jev Be a Better Agent Evaluator? — https://www.langchain.com/blog/jev-agent-evals-langsmith
5. Jev in the Agent Runtime: Confidence-Gated Routing, Fan-Out, and Community Experiments — https://www.bloss0m.com/en/blog/108-jev-confidence-gated-agent-runtime/
6. How To Use Jev In Your AI Agent: A Map Of Decision Seams — https://www.maximem.ai/blog/how-to-use-jev-in-your-ai-agent-a-map-of-decision-seams
7. DocJev — https://github.com/jerryjliu/docjev
8. Reliability without Validity: A Systematic, Large-Scale Evaluation of LLM-as-a-Judge Models Across Agreement, Consistency, and Bias — arXiv:2606.19544
9. The Coin Flip Judge? Reliability and Bias in LLM-as-a-Judge Evaluation — arXiv:2606.13685
10. Scaling Laws for Reward Model Overoptimization — arXiv:2210.10760
11. Security in LLM-as-a-Judge: A Comprehensive SoK — arXiv:2603.29403