Jev 是什么？可以解决哪些问题？

2026-09-22公众号文章

Jev 是什么？可以解决哪些问题？

文 | AI编程实践

一个售后 Agent 准备调用退款工具。真正执行前，Harness 需要确认用户是否明确授权、金额是否一致、证据是否充分、这次动作要不要人工审批。工具返回后，还得判断“请求已接收”究竟算成功，还是仍要等待支付渠道回执。

这些判断交给规则，覆盖不了自然语言中的含糊地带；全部交给 LLM Judge，又会增加延迟、成本和波动。线上系统往往只好抽样评测，真正危险的那次调用却可能没被抽中。

2026 年 9 月，TypeSafe AI 发布了 Jev。它不写解释，也不生成下一段文字，只接收运行状态和类型化问题，返回选项、分数或是非概率。这个设计提供了一种新的可能：把 Judge 从离线报表移进 Agent 循环，让它参与路由、工具风险判断和结果验收。

但先把边界说清楚。Jev 不是不会犯错的裁判，公开资料也不足以还原它的神经网络结构。它真正值得讨论的地方，是把“生成一段评语”改成了“计算一个可以被软件直接消费的决定”。

一、LLM Judge 的问题不只是贵

LLM-as-a-Judge 解决了很多传统指标解决不了的问题。它能理解“2 美元”和“2.00 USD”语义相同，也能判断一段回答是否引用了证据、有没有漏掉用户约束，甚至能比较两条不同的 Agent 路径谁更合理。

代价也很具体。

第一，同一份 Trace 和 Rubric 重复运行，分数可能变化。温度设为零也不能保证供应商后端、模型版本和并行执行完全不变。上线准出如果卡在 0.8 分，一次 0.79、一次 0.82 会让相同版本得到不同结论。

第二，Rubric 越写越长。团队想同时检查事实正确性、证据完整性、语气、工具选择和安全风险，常见做法是把五项标准写进一个大 Prompt，再让 Judge 生成理由和 JSON。每多一个维度，都要承担输入与输出 Token；多个维度还可能相互干扰。

第三，在线评测很难覆盖全部流量。几秒钟的 Judge 延迟可以接受用于夜间回归，却不能轻易放进每次工具调用之前。生产系统最后只评 1% 或 5% 的 Trace，得到的是观测样本，不是运行时控制。

还有一个经常被忽略的问题：谁来评测 Judge？一个解释写得很像样的模型，仍可能稳定偏爱更长的回答，受候选顺序影响，或对同模型生成的答案更宽松。Judge 的输出不是标签真值，它也是一个需要校准和监控的模型结果。

二、Jev 到底是什么

TypeSafe 把 Jev 称为 System One Model。借用“快思考”的名字容易让人产生心理学联想，工程接口其实更简单：一次请求包含共享状态 state和若干问题 questions；每个问题提前声明答案类型；返回值直接落在该类型允许的空间中。

model: jev-latest
state:
  user_request: 请把这笔订单原路退款
  order_amount: 899.00
  proposed_tool_call:
    name: create_refund
    amount: 899.00
  evidence:
    - user_confirmed_at: 2026-09-22T10:31:00+08:00
questions:
  authorization_clear:
    type: noul
    instructions: 用户是否明确授权执行这次退款？
  risk_level:
    type: choice
    criteria:
      low: 信息完整，且动作可安全执行
      medium: 存在可澄清的不确定信息
      high: 可能越权、重复退款或造成不可逆损失
  evidence_quality:
    type: score
    levels:
      - 不足
      - 基本充分
      - 充分且来源一致

Jev 暴露三种问题原语：

类型	返回什么	适合什么判断
Noul	“是”的概率	是否泄露 PII、是否获得授权、回答是否有证据支撑
Choice	给定选项及各自概率	意图分类、模型路由、风险等级、下一动作
Score	有序等级上的分数、分布和置信信息	回答质量、用户挫败程度、证据完整度

它最适合答案空间有限、判断带有语义、调用频率又很高的问题：

场景	Jev 可以判断什么	Harness 怎样使用结果
模型路由	请求属于查询、写作还是复杂推理	选择小模型或强模型
工具安全	用户授权是否清晰、动作风险属于哪一级	放行、补确认或人工审批
Agent 验收	回答是否有证据、工具结果是否满足目标	继续执行、补取证据或结束循环
在线评测	每条 Trace 是否出现 PII、幻觉或失败征兆	生成反馈键、告警和回归样本
运营分流	工单意图、紧急程度和用户情绪	路由队列与确定优先级

长文本生成、开放式规划和需要多步推导的问题不适合直接交给 Jev。权限、金额和 Schema 这类可以精确计算的硬条件也应继续使用代码。

多个问题共享同一份 State，并在一次请求中求值。对 Harness 来说，这一点比“少写几行解析代码”更重要：同一条 Trace 可以同时产生多个独立反馈键，不必让一个生成式 Judge 依次写完五段分析。

三、怎样开始使用 Jev

Jev 的调用并不复杂，真正费功夫的是定义问题。先判断任务是否适合：答案空间能否提前列出？一个熟悉业务的人能否在几秒内作出判断？程序拿到概率后，是否知道下一步该做什么？三个答案都是“是”，才值得继续。

“分析退款申请并决定最佳处理方案”太宽了。可以拆成几项：用户是否明确要求退款、订单属于哪类退款原因、证据充分度处在哪个等级。规划方案和向用户解释原因仍交给生成式模型。

3.1 从 Playground 到第一次 API 调用

TypeSafe 提供 Playground，可以先粘贴一段 State，再添加 Noul、Choice 或 Score 问题。确认返回结构符合预期后，从控制台取得 API Key，把它放进 TYPESAFE_API_KEY环境变量。

REST 接口是：

POST https://api.typesafe.ai/v1/systemone
Authorization: Bearer <API_KEY>
Content-Type: application/json

Python SDK 需要 Python 3.10 或更高版本：

pip install typesafe-sdk

下面的例子复用退款场景。state使用结构化对象；每条 instructions都明确指出要读取的字段。Question ID 主要供代码索引，不能用缩写代替完整问题。

from typesafe_sdk import Choice, Noul, Score, TypeSafeClient

state = {
    "user_message": "行，就按你说的原路退回吧。",
    "proposed_refund": {
        "amount": 899.0,
        "method": "original_payment",
    },
    "evidence": {
        "order_paid": True,
        "previous_refund_receipt": None,
    },
}

with TypeSafeClient() as client:
    response = client.system_one(
        state=state,
        questions={
            "authorization_clear": Noul(
                instructions=(
                    "Does `user_message` clearly authorize the refund "
                    "described in `proposed_refund`?"
                ),
            ),
            "risk_level": Choice(
                instructions=(
                    "What is the execution risk of `proposed_refund`, "
                    "given `evidence`?"
                ),
                criteria={
                    "low": "Evidence is complete and no conflicting effect exists.",
                    "medium": "Some information needs confirmation.",
                    "high": "The action may be unauthorized or duplicated.",
                    "other": "The state does not fit the listed conditions.",
                },
            ),
            "evidence_quality": Score(
                instructions="How complete is `evidence` for this refund?",
                criteria=[
                    "Insufficient",
                    "Usable but incomplete",
                    "Complete and internally consistent",
                ],
            ),
        },
    )

3.2 读取结果时，不要混淆概率与 confidence

Noul 直接返回“是”的概率，没有单独的 confidence字段。Choice 和 Score 会返回完整概率分布，并提供由分布形状计算出的 confidence。一个 Choice 的最高选项是 low，但概率分散在 low、medium和 high之间时，代码仍应把它视为不确定。

authorization = response.answers["authorization_clear"].noul
risk = response.answers["risk_level"]
evidence = response.answers["evidence_quality"]

# 以下阈值仅用于说明分流方式，生产值必须用自己的标注集校准。
if authorization < 0.95:
    route = "ask_user_to_confirm"
elif risk.choice == "high" or risk.confidence < 0.80:
    route = "human_review"
elif evidence.score < 1.5:
    route = "collect_more_evidence"
else:
    route = "continue_to_deterministic_checks"

这段代码没有直接执行退款。它只把模型判断转换成 Harness 分支，金额、权限、幂等键等硬约束仍由确定性代码检查。

3.3 Question 设计比 Prompt 技巧更重要

一条 Question 只判断一件事。Choice 的选项要覆盖真实输入空间；无法穷举时加入 other或 none_of_the_above。Score 的每个等级要能被业务人员区分，不能只写“差、一般、好”。Noul 中 0.5表示是与否接近，不表示程度居中；衡量程度应改用 Score。

同一请求里的 Questions 相互独立，都读取原始 State。若第二个问题必须依赖第一个答案，例如先识别退款类型，再读取对应政策，则由代码发起第二次请求。没有真实依赖的判断应放在一次请求中并行完成。

3.4 接入生产前，先让它只观察

上线顺序可以很保守：先在 Playground 验证结构；再用历史 Gold Set 调整 Question 和阈值；接着进入 Shadow Mode，只记录建议分支；最后选择低风险意图做小流量控制。每一步都保留旧 Judge 或人工结果用于对照。

四、所谓“原理”，公开到哪一层

讲 Jev 原理时，需要把可观察的系统行为和模型内部结构分开。

4.1 可以确认的工作方式

Jev 不做自回归文本生成。传统 LLM Judge 要逐 Token 生成分析、分数和结构化结果；Jev 的输出空间事先由问题类型限定，多个问题通过 TypeSafe 所称的 Parallel Sampler 并行返回。

TypeSafe 还公布了一种名为 Reinforcement Learning for Calibrated Decisions（RLCD）的训练方向。厂商称，它的优化目标是让预测概率与真实命中率相符，而非追求更讨人喜欢的回答。如果一批 0.8概率的判断最终约有 80% 正确，这组概率才具有可用的校准意义。

类型约束也改变了失败方式。Choice 不会突然返回选项集合之外的一篇散文，Noul 不会因为 JSON 少了一个括号而解析失败。程序可以直接消费结果，不需要从自由文本中再提取一次决定。

4.2 目前不能确认的内部结构

截至本文写作时，TypeSafe 没有公开 Jev 的参数量、网络层数、基础架构、模型权重、完整训练数据或可复现的 RLCD 算法论文。因此不能根据“非自回归”“并行输出”就断言它是 Encoder、BERT 变体、Reward Model，或某种蒸馏过的 LLM。

厂商使用了“不会 hallucinate”的说法，也必须缩小解释范围。更准确的表述是：Jev 不会生成类型之外的答案。它仍可能在允许的类型里选错。例如工具调用其实高风险，它完全可能返回 low；这个结果格式正确，语义却错了。

类型安全解决接口可靠性，校准描述概率质量，准确率衡量判断对错。三者不能互相替代。

Jev 的公开资料足以讨论怎样接入系统，却不足以完成一次模型架构复现。文章中的“原理图”因此只画请求、求值和输出契约，不画未经公开的神经网络层。

五、Jev 给 LLM Judge 带来了哪些新参考

比推理速度更值得关注的是，Jev 迫使团队重新设计 Judge。

5.1 把大 Rubric 拆成原子问题

“请综合判断这个 Agent 是否表现良好”很难校准。表现不好可能因为检索错了、工具选错了、回答没引用证据，也可能只是语气生硬。一个总分掩盖了错误来源。

类型化 Judge 更适合把 Rubric 拆开：

feedback_keys:
  grounded: 回答中的事实是否都能在证据中找到？
  authorization_clear: 用户是否明确授权了写操作？
  tool_selection: 所选工具是否适合当前意图？
  effect_confirmed: 工具回执是否证明外部动作已经完成？
  user_goal_met: 最终结果是否满足用户目标？

拆开以后，每项可以有不同阈值、负责人和升级策略。grounded=0.72也许只触发重查证据，authorization_clear=0.72则应阻止退款执行。

5.2 从抽样报表变成全量反馈键

低延迟、低单次成本让“每条 Trace 都打分”成为可讨论的方案。生产看板不再只有平均成功率，还能按意图、工具、模型版本和风险等级观察每个反馈键。

这不代表一上线就把 Jev 放进同步阻断链路。更稳妥的顺序是先做异步全量评分，验证吞吐和漂移；再把已经校准的少数指标放入实时告警；最后才考虑让高置信度结果控制执行分支。

5.3 Judge 评测要分开看准确、稳定和校准

LangChain 公布的一次 Jev-as-a-Judge 实验冻结了五条天气 Agent Run，让四种 Judge 各重复判断 100 次。Jev 在这组样本上与一位人工评审者的二元标签全部一致，连续分数方差也明显更低。

这个结果只能算早期信号。五条 Run、单个人工 Oracle 不足以证明 Jev 在退款、代码、安全或多语言任务上同样领先。它倒是示范了正确的 Judge 测法：先冻结被评对象，再分别测标签准确率和重复评分方差；否则 Agent 和 Judge 同时变化，很难知道波动来自哪里。

概率模型还需要校准曲线。把样本按预测概率分桶，比较每个桶的实际正确率；一旦业务、语言或攻击方式变化，原来的 0.8未必仍代表 80% 的命中率。

5.4 允许 Judge 明确“不够确定”

生成式 Judge 常被 Prompt 逼着给出一个结论。概率输出让系统可以保留灰区：高于 0.95 自动通过，低于 0.2 自动拒绝，中间区域交给 LLM 或人工。

阈值不能全局统一。退款漏放一次的代价远高于把普通查询误送人工，Harness 应根据动作影响、可逆性和补偿能力设置成本敏感阈值。

六、Jev 与 BERT 到底有什么不同

“不生成文本，只做判断”很容易让人想到 BERT。这个联想有一半正确：两者都适合把输入映射到有限输出。另一半需要谨慎，因为 Jev 的内部架构没有公开，不能从产品行为倒推它就是一种 BERT。

6.1 传统 Fine-tuned BERT：一个任务训练一个判别器

BERT 是双向 Transformer Encoder。常见用法是在预训练模型上增加分类头，再用业务标注数据微调。例如训练一个退款意图分类器，标签固定为 refund、exchange、consult。

它的优势是模型与数据都可以掌握在自己手中：本地部署、延迟稳定、成本可控。缺点也明显。任务、标签或输入结构变化后，团队通常要重新准备数据、训练、验证并发布模型。一个 PII 检测器不会自动变成证据充分性 Judge。

6.2 BERT-as-a-Judge：为“答案是否正确”训练通用 Encoder

2026 年的 BERT-as-a-Judge 论文把 Judge 做成了专用 Encoder。输入由 Question + Candidate Answer + Reference Answer组成；输出是候选答案是否正确的概率。

论文从 EuroBERT 210M 初始化，使用约一百万条合成标注三元组做二分类微调。训练标签由 Nemotron-Super-v1.5 生成，并用 3,212 条人工标注检查，人工与合成标签平均一致率为 97.5%。论文报告该模型在 Apple M1 CPU 上约 200ms 处理一个样本，并在多项客观答案任务上达到接近更大生成式 Judge 的准确率。

它解决的是一个明确问题：答案语义正确，却因为格式不符合正则而被错判。适用边界同样明确。论文主要研究英语、有参考答案、正确性可以客观定义的多选、阅读理解和数学任务；开放式写作、代码生成、指令遵循、多模态和无标准答案的 Agent 行为不在已验证范围内。

6.3 四类 Judge 放在一起看

维度	确定性规则	BERT-as-a-Judge	Jev	生成式 LLM Judge
输入	明确字段	问题、候选、参考答案	State、类型化问题	Trace、Rubric、候选答案
任务适配	写代码	需要专项训练数据	运行时定义问题	运行时写 Prompt
输出	布尔或固定值	正确概率	Noul、Choice、Score 概率	分数、标签、解释文本
参考答案	按规则决定	通常需要	不一定需要	不一定需要
解释	规则本身可读	无自然语言解释	无自然语言解释	可以生成理由
部署	自有系统	可本地部署	当前为托管服务	云 API 或自部署
合适场景	Schema、金额、权限硬约束	客观答案正确性	高频语义分类、评分、门控	开放质量、复杂比较、错误分析

BERT-as-a-Judge 和 Jev 的共同点，是把许多评测问题从文本生成改回判别。差别在于前者是公开可训练的参考答案 Judge，后者提供运行时可组合的类型化问题接口。生成式 LLM 则保留了解释和处理开放任务的能力。

没有一种方案应该独占整条评测链路。

七、Harness 会因此发生什么变化

过去的 Agent Loop 常把所有智能判断都交给同一个主模型：它理解 Query、选择模型、挑工具、判断结果、决定是否继续。主模型既是运动员又是裁判，Context 越积越长，每一个小判断都要付出一次生成成本。

引入快速决策模型后，Harness 可以拆成两个平面。

慢速认知面负责规划、开放推理、异常分析和面向人的文本。它允许调用更强的生成式模型，也接受较高延迟。

快速决策面负责频繁而边界清楚的判断：意图与模型路由、工具风险、授权是否清晰、证据是否足够、工具结果是否与预期一致、循环是否该停止。输出直接进入状态机。

引入 Jev 后，Harness 仍需要保留四级路径：

确定性代码先检查权限、金额上限、参数 Schema、幂等键和业务不变量；
Jev 处理授权语义、证据充分性、风险分类和结果一致性；
概率落在灰区、多个问题互相冲突，或需要书面理由时，升级给生成式 LLM；
高影响且不可逆的动作仍由人审批。

以退款为例，amount <= refundable_balance必须由代码判断，不该交给任何模型。用户那句“行，就按你说的办”是否构成对原路退款的明确授权，可以让语义 Judge 评分。但只要订单涉及大额、跨境或已经出现一次外部回执，Harness 就应提高阈值或直接进入人工审批。

八、实时 Judge 进入执行链路后，会增加哪些风险

离线 Judge 判错，通常污染一张评测报表；在线 Judge 判错，可能改变模型路由、阻止正常工具，甚至放行高风险动作。位置变化让它成为生产依赖。

8.1 稳定不等于正确

低方差只能说明相同输入得到相近结果。训练偏差、问题定义错误或新型攻击都可能让模型稳定地判错。因此每个反馈键都要与人工 Gold Set 比较，并按场景看假阳性和假阴性，不能只看总体准确率。

8.2 问题本身可能写错

“这个动作安全吗？”没有说明对谁安全、允许哪些副作用、以什么时间窗口判断。类型化输出减少了解析错误，却不会自动修好含糊的 Question。问题定义需要版本化、评审和回归测试，地位应接近一条生产规则。

8.3 State 可能被污染

如果把网页内容、工具回传和用户文本未经隔离地拼进 State，攻击者可以尝试用自然语言影响 Judge。Harness 要标注每个字段的来源和可信级别，问题说明与被评内容分区，敏感字段先裁剪，再调用外部服务。

8.4 概率不能直接当业务风险

risk_high=0.1是模型对标签的概率，不是“事故损失只有 10%”。最终分支还要结合金额、可逆性、用户等级、补偿能力和法规要求。模型给概率，代码计算决策。

8.5 托管服务带来数据与可用性边界

LangSmith 在 2026 年 9 月的接入说明中提醒，TypeSafe 当时没有提供 Zero Data Retention。把完整 Agent Trace 发给 Judge 之前，需要确认数据保留、地域、租户隔离和敏感信息策略。服务不可用时也要有降级路径：回到保守规则、生成式 Judge 或人工队列，而不是默认放行。

九、怎样验证 Jev 是否适合自己的业务

第一步先冻结一批真实 Trace，不改现有 Judge。样本要覆盖正常路径、已知 badcase、权限冲突、工具超时、重复副作用和恶意输入，并由至少两名业务评审者给出标签；有分歧的样本单独保留，不能强行制造唯一真值。

接着让规则、BERT-as-a-Judge、Jev 和现有 LLM Judge 在各自适合的任务上运行。不要拿 BERT-as-a-Judge 去评没有参考答案的创意写作，也不要让 Jev 代替代码计算金额。比较指标至少包括：

指标	说明
标签准确率	与人工 Gold Set 的一致程度
假放行率	高风险样本被错误通过的比例
重复评分方差	同一输入多次调用是否稳定
校准误差	预测概率与实际正确率是否匹配
覆盖率	在既定阈值下能自动处理多少样本
升级率	多少样本进入 LLM 或人工复核
P95 延迟	能否进入同步链路
每条 Trace 成本	全量运行是否可持续

上线采用影子模式。Jev 读取生产 Trace 并记录建议分支，但不影响真实执行。等到阈值在独立验证集上完成校准，再选择低风险意图做小流量控制。每一次自动决定都记录：Question 版本、State 来源、模型版本、概率分布、阈值、最终分支和后续真实结果。

有了结果回流，团队才能知道某个 0.92在退款场景里究竟有多可靠，也能在模型或流量变化后重新校准。

十、Jev 会取代 LLM Judge 吗

不会，也没必要。

需要一段可供人阅读的错误分析、需要比较两种复杂方案、Rubric 仍在探索阶段，生成式 LLM Judge 更合适。有稳定参考答案、任务长期不变且需要本地部署，BERT-as-a-Judge 或其他专用 Encoder 更容易掌控。权限、数值和状态不变量继续交给代码。

Jev 补上的是中间那块：判断带有语义，答案空间却可以提前定义；调用量很大，系统又需要概率和低延迟。模型路由、工具风险、结果验收、在线反馈键都属于这一类。

它给 Agent 工程带来的提醒很朴素：不要因为 LLM 能生成任何文本，就让它生成每一个决定。Harness 应根据问题形状分配计算。开放推理留给慢模型，明确判断交给快速决策层，无法承受的风险交给代码和人。

参考资料

TypeSafe AI：Introducing System One Models & Jev
TypeSafe AI：Quick start
TypeSafe AI：Primitives
TypeSafe AI：Confidence
BERT-as-a-Judge: A Robust Alternative to Lexical Methods for Efficient Reference-Based LLM Evaluation
BERT: Pre-training of Deep Bidirectional Transformers for Language Understanding
LangChain：Building a Harness with Jev
LangSmith：Jev is now available in LangSmith Evals
Jev-as-a-Judge reproducible experiment
Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena

前往微信阅读全文

内容来自公众号，可前往微信查看原文。