Jev模型评测教程：智能体系统分类和评分场景成本优化实战指南

#AI智能体Agent #Jev分类模型 #AI基础设施

2026-09-19 16K banq

一家叫TypeSafe的公司刚发布了一个连完整句子都写不出来的AI模型！

它比GPT便宜400倍，速度快200倍，却敢跟Claude掰手腕！

TypeSafe公司在2026年推出了一款名为Jev的专用判别模型，专门处理分类、路由、评分这类只需要“选答案”的场景。Jev放弃了文本生成能力，换来了极致的速度和成本优势，官方数据显示比前沿大模型便宜40到400倍。这篇文章会拆解Jev的三种问题类型、真实评测数据、致命短板以及和Langfuse联动的实战代码。

Jev连一句话都写不出来却敢叫板Claude

先抛一个反直觉的事实：TypeSafe公司在2026年9月发布的Jev模型，连“今天天气不错”这种句子都写不出来。它不是精简版的GPT，也不是蒸馏版的Claude，而是一个从骨子里就放弃了写作能力的怪胎。

按照常识，一个AI模型如果连文字都生成不了，那它基本等于废铁。市面上从OpenAI的GPT-5.6 Luna到Google的Gemini 3.8 Flash，再到Anthropic的Claude Fable 5.1，比拼的都是谁能写出更流畅的代码、更准确的报告、更细腻的对话。TypeSafe却反其道行之，把生成能力全部砍掉，只留下一个动作：做判断。

但是Jev发布几天内就在开发者社区炸开了锅。Good Start Labs这家研究机构做了一次硬核对比，用6003个评分任务同时喂给Jev和五个主流大模型，结果Jev跟Claude Fable 5.1的判定一致率达到91.5%，而每百万次判定Jev只花160美元，Claude Fable 5.1花了33000美元。差距超过200倍！

这就怪了，一个不会写字的模型，凭什么在“判断题”这个赛道上把顶级选手按在地上摩擦？答案藏在一个被大多数团队忽视的场景里。

agent系统每天在浪费天量的Token做选择题

要理解Jev为什么存在，得先搞清楚过去三年里各家公司搭建的AI agent（智能体/代理）系统到底在干什么。

一个典型的agent工作流程是这样的：用户提出一个需求，agent先判断该调用哪个工具，再判断工具返回的结果是否可用，然后判断要不要升级到人工处理，最后还要判断本次任务是否完成。这一连串判断题，每一次都在调用GPT或Claude这样的生成式大模型，每一次都要付生成Token的钱。

问题在于，这些判断题的答案空间是有限且已知的。“该调用搜索工具还是数据库工具”，答案就在几个工具名里选一个；“用户是否表达了不满”，答案只有是和否；“这次运行的严重程度”，答案在“完美完成、路径绕远、结果错误、造成破坏”几档里挑一档。

但是过去开发者的做法是：写一段几百字的prompt，让GPT-4理解这个判断题，然后用JSON Schema强制它输出结构化答案，最后花生成一整段代码的钱，换回来一个yes或no。TypeSafe创始团队看到了这个荒诞的浪费，Jev就是针对这个空白设计出来的。

Jev用三种原生问题类型压死LLM-as-a-judge的成本

Jev的核心机制建立在三个原生问题类型上，官方叫做primitives（原语/基本单元）。这三种类型覆盖了agent和评测（evaluation）场景里几乎所有的判断需求。

第一种叫做Choice：从预设的选项集合里挑一个，最多支持255个选项，返回被选中的选项、每个选项的概率分布，还有一个整体置信度数值。这个类型专门用来处理agent的工具路由、错误归因分类、文档分类这类多选一场景。

第二种叫做Score：按照有序的评分标准给状态打分，最多支持10个等级，返回一个概率加权的最终得分、完整的概率分布和置信度。这个类型适合评估运行质量、内容风险等级、任务完成度这类需要“分档”的场景。

第三种叫做Noul：只回答是或否，返回“是”的概率值。特别注意Noul没有独立的confidence字段，因为对于二元判断来说，概率本身就等于置信度。如果开发者写的代码习惯性地读取answer.confidence，遇到Noul就会崩溃！

一次请求塞多个问题延迟几乎不变的机制

Jev有一个让人眼前一亮的设计：一次API请求里可以塞进多个问题，每个问题都针对同一份状态数据独立评估，评估过程并行执行，互不干扰。

这意味着什么？举个具体的例子。一个agent完成了一次任务，开发者想同时判断三件事：这次运行是否需要人工审核；这次运行的严重程度是几级；如果出错了是哪种失败模式。传统做法是发三次API请求，或者写一个巨大无比的prompt让LLM一次性回答三个问题（回答质量还经常互相干扰）。

Jev的做法是：把三个问题打包进一次请求，每个问题在同一份状态数据上独立并行运算，返回三个独立的结构化答案。响应时间几乎等于最慢的那一个问题，而不是三个问题的总和。

下面这段JSON请求就是这种“一次多问”的实际形态：

json
{
  "model": "jev-latest",
  "state": {
    "task": "{{task}}",
    "tool_calls": "{{tool_calls}}",
    "final_output": "{{final_output}}"
  },
  "questions": {
    "needs_review": {
      "type": "noul",
      "instructions": "Does this run need a human to look at it?"
    },
    "severity": {
      "type": "score",
      "instructions": "How badly did this run go?",
      "criteria": [
        "Completed the task cleanly",
        "Completed it, but took a wasteful or confusing path",
        "Delivered a wrong or incomplete result",
        "Took a destructive or unsafe action"
      ]
    },
    "failure_mode": {
      "type": "choice",
      "instructions": "What went wrong, if anything?",
      "criteria": {
        "tool_error": "A tool returned an error or unusable output",
        "missing_context": "The agent lacked information it needed",
        "wrong_approach": "The agent chose an unsuitable strategy",
        "user_abandoned": "The user left before the task finished",
        "none": "Nothing went wrong"
      }
    }
  }
}

返回的结果同样保留了完整的概率信息：

json
{
  "model": "jev-1.13.0",
  "answers": {
    "needs_review": { "type": "noul", "noul": 0.88 },
    "severity": {
      "type": "score",
      "score": 1.89,
      "confidence": 0.44,
      "legend": {
        "0": "Completed the task cleanly",
        "1": "Completed it, but took a wasteful or confusing path",
        "2": "Delivered a wrong or incomplete result",
        "3": "Took a destructive or unsafe action"
      },
      "probabilities": { "0": 0.02, "1": 0.21, "2": 0.63, "3": 0.14 }
    },
    "failure_mode": {
      "type": "choice",
      "choice": "missing_context",
      "probabilities": {
        "tool_error": 0.11,
        "missing_context": 0.58,
        "wrong_approach": 0.24,
        "user_abandoned": 0.05,
        "none": 0.02
      },
      "confidence": 0.51
    }
  },
  "usage": { "input_tokens": 1840, "output_tokens": 27 }
}

注意看那个output_tokens字段：只有27。相比之下，用GPT做同样的三项判断，即便强制结构化输出，也要消耗几百上千个生成Token。Jev靠着“不写字只输出概率”这个死磕的定位，把成本压到了地板上！

6003次评分实测数据Jev跟Claude的一致率91.5%

光讲机制没用，得看真实评测。Good Start Labs在Jev发布几天后就做了一次严肃的横向对比，用相同的评分标准和相同的输入数据，让Jev和五个主流模型独立打分，然后以Claude Fable 5.1的判定作为基准，统计其他模型跟Claude的一致率。

Claude Fable 5.1作为基准模型，处理6003次评分的成本折算下来是每百万次33000美元。Google的Gemini 3.8 Flash每百万次1600美元。OpenAI的GPT-5.6 Luna每百万次400美元。开源模型DeepSeek V4.1 Flash每百万次260美元，一致率93.5%。

TypeSafe的Jev：每百万次160美元，一致率91.5%。

从数据看有两个明显的信号。第一个信号：DeepSeek V4.1 Flash的性价比其实非常猛，多花100美元买回来2个百分点的一致率提升，在某些高风险场景值这个价。第二个信号：Jev在“判断题”这个赛道上，跟顶级闭源模型的差距只有8.5个百分点，成本差距却是206倍！

但是这里有个必须警惕的解读陷阱：一致率高不等于绝对正确率高。Claude Fable 5.1本身不是绝对真理，它自己也会判错。Jev跟Claude一致，只说明两者在大部分case上想法接近，并不代表Jev在客观意义上就是对的。真正严肃的场景，一致率之外还得看Jev跟人类标注员的一致率，这个数据目前还没有公开的第三方验证。

Jev不能弃权不会解释还会context rot的三大死穴

Jev官方文档里有一个叫做model-jaggedness（模型锯齿状缺陷）的页面，一个版本一份，专门列出Jev在哪些地方会翻车。这份清单必须在动手前读透，否则设计出来的评估器会掉链子。

第一个死穴：Jev不能主动弃权。面对强制二元选择的Noul问题，即便Jev内心毫无头绪，也会硬着头皮挑一个“错得更少”的答案，而不会说“我不知道”。这个特性在筛选高风险内容时特别危险，因为一个纯粹的猜测会被包装成一个带概率的“判断”。解决办法是在criteria里显式加入escape hatch（逃生舱口），比如在Choice里塞一个“unknown”选项，或者用Score把“无法判断”单独列成一档。

第二个死穴：Jev不生成任何解释文字。当一条trace（追踪记录）被Jev打了低分，开发者永远拿不到“为什么”。debug（调试）方式只能是回头读自己写的criteria，看看是不是标准本身写歪了。任何需要审计留痕、需要向客户解释判断依据的场景，都必须在Jev之后再挂一个生成式大模型来补充说明文字。

第三个死穴：Jev有严重的context rot（上下文腐烂）现象。TypeSafe文档里原话就是Jev suffers from context rot。当输入的state数据里塞满了跟当前问题无关的内容，Jev的准确率会明显下降。这个特性让开发者被迫回到GPT-3.5时代的手艺活：认真设计每一次输入的上下文，只塞跟问题直接相关的信息。官方文档上说Jev支持单次请求64k Token，其中state加上最长的一个问题不能超过32k Token，但是OpenRouter上标注的却是32K，用之前得自己核对清楚！

用户异议评估从prompt写作变成criteria设计的范式转移

拿一个真实的评估场景来对比：判断用户在对话里是否表达了对AI回复的异议。这是聊天机器人质量监控里最常见的一个指标。

传统的LLM-as-a-judge（大模型充当评委）做法是这样：写一段几百字的prompt，把“什么算异议”、“什么不算异议”、“边界case怎么处理”全部塞进去，然后要求模型输出{"disagreement": true | false}这样的结构化结果。示例prompt长这样：

plaintext
You are evaluating a conversation between a user and an AI assistant.
Read the conversation history and the last user message. Decide whether the
user is disagreeing with the assistant's prior response.
The user IS disagreeing if they reject, correct or challenge the assistant's
answer, say it misunderstood them, or ask it to start over. The user is NOT
disagreeing if they ask a neutral follow-up, politely clarify, debug
collaboratively, report an unrelated product problem, or express general
frustration not aimed at the assistant. If there is no prior assistant
response, the answer is false.
Judge what the user believes, not whether the assistant was actually wrong.
Return only JSON: {"disagreement": true | false}
Conversation history: {{conversation_history}}
Last user message: {{last_user_message}}

Jev的做法则彻底不同：把整个判断拆解成结构化的question对象，Noul类型明确列出“true应该包含哪些情况”、“false应该包含哪些情况”，让Jev在结构层面就完成语义边界的划定：

``json { "model": "jev-latest", "state": { "conversation_history": "{{conversation_history}}", "last_user_message": "{{last_user_message}}" }, "questions": { "user_disagreement": { "type": "noul", "instructions": { "question": "Doeslast_user_messageclearly communicate that the user believes the assistant's prior response, reasoning, assumption, work, or approach was mistaken or proceeding in the wrong direction?", "inspect": "last_user_message", "scope": [ "Evaluate the user's expressed perception, not whether the assistant was objectively wrong.", "Useconversation_historyonly to identify the relevant prior assistant response and resolve references.", "If there is no prior assistant response, the answer is false." ] }, "criteria": { "true": { "definition": "The user clearly rejects, corrects, challenges, asks to undo, or repeatedly redirects the assistant's prior response or approach.", "includes": [ "Directly saying the answer, assumption, or interpretation is wrong", "Saying the assistant misunderstood the request", "Questioning why the assistant made a particular assumption", "Requesting that the assistant revert, restart, or abandon its approach", "Repeated steering that indicates the assistant is still following the wrong direction" ] }, "false": { "definition": "The user does not clearly indicate that the assistant made a mistake or took the wrong approach.", "includes": [ "A neutral follow-up or request for more detail", "A polite clarification that does not reject the prior response", "Collaborative debugging without criticism of the assistant's approach", "Reporting an external product or system problem", "General frustration not directed at the assistant", "An ambiguous reaction", "No prior assistant response" ] } } } } }


看出差别了吗？传统prompt靠的是“自然语言劝说模型”，Jev靠的是“结构化定义边界”。Jev返回的是一个概率值比如0.93，开发者可以自己在业务逻辑里设定阈值，甚至可以设定“三段式分流”：高概率自动处理、中间模糊带走人工、低概率忽略。这就把评估从一个非黑即白的二值决策，变成了带风险分层的概率决策！

Jev跟Langfuse联动自动化打分Trace的完整代码
Jev的价值必须落到具体的工程实践里才能量化。TypeSafe官方提供了Python和JavaScript的SDK，也在OpenRouter和Vercel AI Gateway上线，开发者不用单独跟TypeSafe建立商务关系就能试用。
一个高频场景是：用Langfuse这样的LLM可观测平台记录所有对话trace，然后用Jev定期扫描这些trace，自动打上评估分数。下面这段Python代码演示了完整链路：从Langfuse拉取trace数据，喂给Jev判断用户异议，再把结果写回Langfuse作为分数。

python
#!/usr/bin/env python3
"""使用 TypeSafe Jev 和 Langfuse 对用户异议进行打分。
将一个布尔判定写入 Langfuse，并在评分注释中包含 Jev 的概率分布。
此示例假设每个候选生成的输入结构如下：
    {"messages": [{"role": "user", "content": "..."}, ...]}
安装和配置：
    pip install -U langfuse typesafe-sdk
    export LANGFUSE_PUBLIC_KEY="pk-lf-..."
    export LANGFUSE_SECRET_KEY="sk-lf-..."
    export LANGFUSE_BASE_URL="https://cloud.langfuse.com"
    export TYPESAFE_API_KEY="..."
    export TRACE_ID="..."
    python score_user_disagreement_v2.py
"""
import json
import os
from langfuse import get_client
from typesafe_sdk import Noul, NoulCriteria, TypeSafeClient
TRACE_ID = os.environ["TRACE_ID"]
MODEL = "jev-1.13.0"  # 固定模型版本，因为判定使用固定阈值。
THRESHOLD = 0.7
langfuse = get_client()

USER_DISAGREEMENT = Noul( instructions=( "Doeslast_user_messageclearly communicate that the user believes " "the assistant's prior response or approach was mistaken or proceeding " "in the wrong direction? Evaluate the user's expressed perception, not " "objective correctness." ), criteria=NoulCriteria( true=( "The user clearly rejects, corrects, challenges, asks to undo, or " "redirects the assistant's prior response or approach." ), false=( "The user does not clearly reject the prior response. This includes " "neutral, additive, or ambiguous follow-ups." ), ), )


def parse_json(value):
    """观测 V2 可能将 input 和 output 作为 JSON 字符串返回。"""
    if isinstance(value, str):
        try:
            return json.loads(value)
        except json.JSONDecodeError:
            pass
    return value
def latest_user_message(observation):
    """返回最新的用户消息，如果没有则返回 None。"""
    observation_input = parse_json(observation.input)
    messages = observation_input.get("messages", [])
    for message in reversed(messages):
        if message.get("role") == "user":
            return message.get("content")
    return None

def main(): #api.observations是当前 Python SDK 中的观测 V2 API。 response = langfuse.api.observations.get_many( trace_id=TRACE_ID, type="GENERATION", fields="core,basic,io", limit=50, )


    # 只保留输入中包含用户消息的生成。
    turns = [
        (observation, user_message)
        for observation in response.data
        if (user_message := latest_user_message(observation)) is not None
    ]
    turns.sort(key=lambda turn: turn[0].start_time)
    # TypeSafeClient 从环境变量读取 TYPESAFE_API_KEY 和 TYPESAFE_BASE_URL。
    # 上下文管理器在运行结束后关闭 HTTP 客户端。
    with TypeSafeClient(model=MODEL) as jev:
        # 用户消息 N+1 是对助手回复 N 的反应。
        for (reply, _), (_, reaction_message) in zip(turns, turns[1:]):
            result = jev.system_one(
                state={
                    "conversation_history": parse_json(reply.input),
                    "assistant_reply": parse_json(reply.output),
                    "last_user_message": reaction_message,
                },
                questions={"user_disagreement": USER_DISAGREEMENT},
            )
            # Noul 返回的是 P(true)，因此 P(false) 是其补数。
            p_disagreement = float(result.nouls["user_disagreement"].noul)
            p_no_disagreement = 1.0 - p_disagreement
            langfuse.create_score(
                score_id=f"{reply.id}-user-disagreement",
                trace_id=reply.trace_id,
                observation_id=reply.id,
                name="user_disagreement",
                value=1 if p_disagreement >= THRESHOLD else 0,
                data_type="BOOLEAN",
                comment=(
                    f"TypeSafe {result.model}; "
                    f"P(disagreement)={p_disagreement:.2f}; "
                    f"P(no disagreement)={p_no_disagreement:.2f}; "
                    f"threshold={THRESHOLD}"
                ),
            )
            print(
                f"{reply.id}: P(disagreement)={p_disagreement:.2f}, "
                f"P(no disagreement)={p_no_disagreement:.2f}"
            )
    # 在这个短生命周期脚本退出之前，刷新缓冲的评分事件。
    langfuse.flush()

if name == "main": main()`

这段代码的关键操作是langfuse.create_score`那一步：Jev返回的概率值先跟阈值0.7比较得到一个布尔判定，然后把布尔值和原始概率一起写入Langfuse。这样后续的BI分析既可以按“是否异议”做二值统计，也可以基于原始概率做更细的分层分析。

Jev触碰到了System 1和System 2分工的深水区

Jev在TypeSafe官方文档里被归类为system-one models（系统一模型），这个命名不是随便起的。心理学家丹尼尔·卡尼曼（Daniel Kahneman）在《思考，快与慢》里把人类认知分成两套系统：System 1负责快速直觉判断，System 2负责慢速逻辑推理。

过去几年AI行业默认走的是System 2路线：把GPT、Claude这样的大模型堆算力堆参数，逼它们做深度推理、写复杂代码、生成长篇内容。每一次调用都在跑一个完整的System 2流程，即便任务本质上只是一个System 1的直觉判断。这就好比让一个哲学教授全神贯注地读三分钟文献，就为了回答“这杯水是热的还是冷的”！

TypeSafe押注的方向是把System 1和System 2解耦。Jev就是那个专门干System 1的模型：快、便宜、只输出直觉判断和概率。而GPT、Claude这些System 2模型继续负责生成、推理、创作。开发者搭建agent系统时，把两类模型按职责分层，成本和延迟都能压到一个新的量级。

但是这条路线也存在反对声音。有一批研究者认为，System 1和System 2的分工在人类身上是自然演化的结果，硬要复刻到AI架构里会造成新的复杂度：开发者要维护两套模型的调用逻辑，要处理两套API的错误模式，要设计两套模型之间的信息传递机制。这些工程成本能不能被节省下来的Token成本覆盖，目前还没有大规模生产环境的验证数据。

DeepSeek V4.1 Flash那组数据其实已经暗示了另一种可能性：如果开源模型能把成本压到每百万次260美元、一致率还比Jev高2个百分点，那System 1专用模型的护城河能守多久，是一个必须打问号的事情。TypeSafe接下来是靠迭代模型能力扩大领先，还是靠工程生态锁定客户，2027年的评测数据会给出答案！