不生成文本的 AI怎么给 Agent 当裁判认识 Jev 与结构化决策模型判断一段 Agent 轨迹是否泄露隐私、有没有正确使用工具、用户是不是已经很生气我们通常有两种办法写规则或者再调用一个大语言模型当裁判。规则便宜、稳定但很难覆盖自然语言中的多种表达。LLM 能理解开放文本却要经历生成、解析和评分结果还可能随调用发生变化。2026 年 9 月TypeSafe AI 发布的 Jev 引出了第三种思路模型不负责生成解释而是读取状态直接返回有类型的答案和概率。LangChain 将它接入 Agent harness并在 9 月 21 日宣布 Jev 可用于 LangSmith Evals。LangSmith 发布说明它会替代 LLM-as-a-Judge 吗现在下这个结论还太早。更值得研究的问题是Agent 中哪些判断真的需要生成式推理哪些可以变成更窄、更稳定的结构化决策1. Jev 到底是什么按照 TypeSafe AI 与 LangChain 的表述Jev 是一种 “System One model”。它接收两部分输入state需要判断的上下文可以是消息、Agent 轨迹或结构化数据questions针对这份状态提出的一组判断标准。输出不是一段分析文字而是结构化结果。当前公开材料介绍了三类问题类型适合的问题主要输出Noul是否发生某件事是的概率Choice属于哪个类别各选项概率与置信信息Score在有序等级中的程度连续分数、分布与置信信息例如判断一条故障消息是否紧急fromlangchain_typesafeimportNoul,TypeSafeClassifier classifierTypeSafeClassifier()responseclassifier.invoke({state:(生产环境连续两次部署失败用户正在遇到 500 错误请立即处理。),questions:{urgent:Noul(instructions这条消息是否需要立即处理)},})urgent_probabilityresponse.nouls[urgent].noul这段接口用法来自 LangChain 在 9 月 17 日发布的集成介绍运行需要安装langchain-typesafe并配置 TypeSafe API Key。Building a Harness with Jev这里的 “System One” 是 TypeSafe AI 对该模型类别的产品与技术表述。它借用了快速判断的直觉但不应仅凭名称把它理解为认知科学中已经统一定义的一类机器学习架构。2. 它和结构化输出有什么不同传统 LLM 也可以返回 JSON输入状态 ↓ LLM 生成推理或答案文本 ↓ 结构化输出约束 / JSON 解析 ↓ { urgent: true, confidence: 0.91 }Jev 的产品定位则是直接做决策输入状态 有类型的问题 ↓ 决策模型 ↓ 概率、选项或分数差别不只是最终格式都能不能变成 JSON。传统自回归模型通过逐 token 生成完成任务Jev 被设计为针对状态回答结构化问题不承担长文本生成。这带来一个工程上的吸引力如果 Agent 循环里有大量“是否继续”“风险属于哪一类”“该走哪条路”之类的窄判断就不一定每一步都需要生成一段自然语言分析。但输出一个小数并不自动说明它值得信任。0.93是模型给出的概率是否真的意味着一百个相似案例中约有九十三个为真需要在目标数据上做校准检验。结构化接口减少了解析环节不会自动消除模型偏差。3. Agent 评测原本有哪些选择把 Jev 放进现有方案中比较会更容易理解它的位置。方案优点局限适合场景代码规则确定、便宜、容易审计难覆盖开放语义字段存在、格式、工具名、引用数量LLM-as-a-Judge能理解复杂文本可给理由成本、延迟和波动更高开放式质量、解释充分性、复杂标准Jev 类决策模型直接返回有类型结果面向批量判断新模型证据有限通常不给完整理由意图、风险、状态分类和连续打分人工评审能结合业务背景追问慢、贵也存在评审差异高风险争议、抽检、建立金标准它们并不是只能四选一。一个 RAG 评测流程可以先用代码检查“引用字段是否存在”再用语义模型判断“回答是否被证据支持”最后让人工复核高风险样本。判断标准越确定越应该优先写成普通代码。比如“是否调用了search_law工具”直接检查轨迹即可没有必要让任何模型猜测。需要解释“为什么得出低分”时生成式 Judge 仍有价值。Jev 更适合把问题压缩成明确、原子的判断它不是一个能替你撰写完整评审意见的通用模型。4. LangChain 的实验测了什么LangChain 在 9 月 20 日公开了一次 Jev-as-a-Judge 实验并提供了复现仓库。理解这个结果时先看实验范围比先看倍数更重要。Jev-as-a-Judge for Agent Evals实验对象是一个天气 Agent测试集只有五条已经固定的运行轨迹。每个 Judge 对两项信号评分does_pass二元的通过或不通过quality连续质量分数。研究者让每个 Judge 对相同轨迹重复评判一百次并与一位人工评审给出的标签比较。文章报告在这组五条天气任务上Jev 的 500 次二元判断都与人工标签一致连续分数的观测方差也低于所比较的三个 LLM Judge单次平均耗时和记录成本同样更低。这些结果支持一个有限结论在这组固定天气轨迹和评分标准下Jev 表现出了较高的一致性并值得继续测试。它还不能证明 Jev 在法律、医疗、长链路代码 Agent 或中文任务中同样有效。原文也明确承认这是一次窄实验并提醒“稳定地判断错误”仍然是错误。复现信息里还有几个值得注意的细节测试只有五条固定轨迹重复调用增加的是稳定性样本不是任务多样性人工 oracle 来自一位评审者不能衡量多人之间对开放质量标准的分歧对比中的 LLM 没有显式设置 temperature、top-p、seed 或 max tokens而是使用提供方默认值实验元数据没有记录 Jev 服务的具体版本。因此文中的速度、费用与方差数字都应写成“这次实验的观测结果”不能直接当成模型在所有业务上的固定性能。5. 为什么“低方差”不等于“判断正确”假设一个裁判面对同一条答案十次都给 0 分。它确实很稳定但如果这条答案本来正确稳定只意味着错误容易复现。评测模型至少要从三个维度检查一致性相同输入重复判断结果是否稳定 有效性判断与可靠人工标签是否一致 校准性输出 0.8 的案例长期来看是否约有 80% 为真如果应用要根据概率设阈值还要考察阈值两侧的误报和漏报。对于隐私泄露、危险工具调用等问题漏报的代价可能远高于误报单看总体准确率会掩盖真正风险。而且Judge 的输入决定了它最多能知道什么。如果只给最终回答不给检索证据它就无法可靠判断回答是否忠于证据如果轨迹被截断模型也可能把“没有看到工具调用”误判为“没有调用工具”。6. 放进 RAG 系统时我会怎样分工以一个法律 RAG 问答为例可以把评测拆成四层第一层代码可以确定的事实直接检查是否返回引用、引用 ID 是否存在于检索结果、响应格式是否完整、工具是否报错。这些规则可复现也最容易定位失败原因。第二层窄而高频的语义判断把每个标准写成单独问题例如回答是否包含无法从证据推出的具体金额 回答是否把一般信息写成了确定的个案结论 用户是否明确要求查询某一条法律这类问题适合拿 Jev 与小型分类模型、LLM Judge 做对照。不要把“回答整体好不好”塞进一个模糊分数否则失败后仍不知道该改检索、生成还是提示词。第三层需要理由的复杂评审例如“回答是否完整处理了多个相互冲突的请求”不仅需要分数还需要解释遗漏了哪一点。这里可以使用 LLM Judge 产生理由但应抽样人工核对理由是否真的对应证据。第四层高风险人工复核模型低置信、不同 Judge 意见冲突、涉及重大权益的案例进入人工队列。模型输出用于排序和提醒不直接成为最终裁决。这种分层方式的重点不在于一定要使用 Jev而在于不让同一种评测方法承担所有问题。7. 如果自己验证我会这样设计实验我不会先拿厂商数字估算收益而是从一批已经人工标注的真实轨迹开始。第一步冻结输入。保存问题、检索片段、工具调用和最终答案确保每个 Judge 看到完全相同的内容。第二步拆分标准。把事实支持、任务完成、引用正确和风险提示分别标注避免用一个“总体质量”掩盖差异。第三步建立人工金标准。至少让两名评审者独立判断先计算人与人之间的一致性有争议的样本经过讨论再形成最终标签。第四步比较四组方案代码规则、Jev、一个固定配置的 LLM Judge以及组合方案。每种模型重复调用记录与人工标签的一致率各类别的精确率、召回率和混淆矩阵重复调用的一致性单条延迟、费用和失败率模型版本、提示词、阈值与日期。第五步单独检查错例。尤其关注高置信错误、中文表达、长上下文截断和不同领域术语。总体分数相近时错在什么地方比平均值更能决定是否上线。我现有的 RAG 评测集可以用于设计这一实验但需要新增 Judge 标签和人工复核后才能给出结果。本文没有运行 Jev也没有把上述方案描述成已完成实验。8. 现阶段最值得关注的边界首先是可解释性。概率适合驱动路由却很难单独支撑事故复盘。重要判断最好保留输入、问题定义、模型版本、阈值和最终动作必要时再调用能给理由的评审器。其次是数据边界。LangSmith 9 月 21 日的接入说明指出TypeSafe 当时不提供 zero data retention发送给评测服务的提示和输出可能被保留。包含真实用户数据时需要先确认隐私要求和服务条款而不是直接上传完整 Agent 轨迹。LangSmith Jev 配置说明最后是供应商与版本变化。当前 LangChain 实验使用的是langchain-typesafe0.0.1a2版本号本身也说明集成仍处于早期阶段。上线前要锁定依赖记录服务版本并准备降级到规则或其他 Judge 的路径。Jev 真正有启发性的地方不是一句“比 LLM 快多少倍”而是它迫使我们重新审视 Agent 的每一次模型调用这个步骤需要生成新的语言还是只需要针对已知状态做一个明确判断如果问题足够窄、有清楚标签而且调用量很大结构化决策模型可能成为规则与生成式 Judge 之间的新选择。如果标准模糊、必须给出理由或后果重大生成式评审和人工判断仍然不可省略。