开发 Agent 时，几十轮模型请求与工具调用会迅速累积成本与等待时间，把规划推理交给旗舰模型、简单判断交给小模型是常见做法。Jev 是专做分类、评分与条件判断的决策模型，文章从原理到用法讲清它能否承担这类工作。

我们在开发Agent的时候，总绕不开两个核心问题，成本和效率。

一次任务执行下来，可能要经历几十轮模型请求和工具调用判断，一个不小心，半个小时就过去了，特别是复杂的多步任务，Browser use和Computer use等，这类任务，反复读取数据，判断下一步，执行操作。

如果我们全部使用旗舰模型，既耗费时间，也会消耗不少的token，账单也不便宜。

为了减少成本和等待的时间，我们通常会让不同的模型做不同的事情，复杂的规划和推理交给旗舰模型，简单任务交给Flash这类更快，更便宜的模型，或者参数更小的模型。

其中有些步骤，需要的只是一个范围明确的判断，工具返回的信息够不够，这次失败要不要重试，这个命令有没有危险能不能执行，任务跑的越久，这类任务就会越多。

这类判断任务，除了交给 Flash 或者小模型，还有没有其他选择？Jev 就是一个专门做分类、评分和条件判断的决策模型。它能否承担 Agent 中的这些工作，减少调用成本和等待时间？下面我们来看看它的原理和用法。

一、Jev是什么

Jev 由TypeSafe AI 推出，官方把这类模型叫做 System one Model，把当前信息和一个明确的问题交给它，它会返回一个选项，一个分数，或者某一个条件成立的概率，程序拿到结果就可以判断后续执行什么样的流程。

System one 是什么

System one 的命名借用了丹尼尔·卡尼曼在 思考，快与慢 中普及的概念，系统一 偏向快速、直觉式的判断，系统二则是偏向需要投入注意力，逐步推敲思考。

例如，收到“帮我查一下明天北京的天气”，你几乎立刻就能判断，这是一个查天气的请求，这个判断通常不用刻意推敲，更接近系统一，但是如果收到“根据我的预算和偏好，帮我安排下周去北京的三天行程”，你就需要搜集信息，比较交通和酒店，权衡时间和花费，再一步一步的给出计划，这个过程需要持续投入注意力，更接近系统二.

TypeSafe 借用System one 这个名字，强调的是一种快速，范围明确的判断能力，Jev就是它首个公开的产品。

为了训练这类判断能力，TypeSafe 采用了一种叫RLCD的方法，全称是 Reinforcement Learning Calibrated Decisions，即面向校准决策的强化学习。

按照官方的说法，这种训练既关注模型有没有判断准确，也关注模型给出的概率是否可靠。这里的校准可能有点抽象，我们来看一个例子。

用户发来一句话：“这个鞋子不太合适，我不要了。”我们让 Jev 判断用户是否想申请退货。假设它给出的结果是：“用户想申请退货的概率为 95%。”

这个 95% 准不准，我们不能只看这一条消息。我们需要再收集更多的消息，把模型都判断为“95% 可能想退货”的放在一起，然后由人工核对用户的实际意思。如果每 100 条里，大约有 95 条确实在表达退货意图，就说明模型报出的概率与实际情况比较吻合，如果只有 60 条，就说明模型估得太高了。

Jev和LLM的区别

LLM 和 Jev 都能完成分类任务，但它们输出结果的方式不同。以客服工单为例，用户反馈：“昨天导出的报表缺了两列，我重新下载了一次，还是一样。”系统需要从使用咨询，产品故障，账号问题，其他”中选择一个类别，LLM 和 Jev 都可能给出“产品故障”的结果。

但两者得到这个答案的方式不同。Jev 和常见生成式 LLM 的一个关键区别，是它放弃了自由文本生成。

常见生成式 LLM 会把“产品故障”当作一段回答，根据输入和已经生成的内容，一个 token 接一个 token 地自回归生成出来。即使只输出一个类别，通常也需要逐 token 生成。程序需要读取返回的文本，或者通过结构化输出接口取得类别。

Jev 则不同。按照 TypeSafe 的介绍，开发者给定问题和候选类别后，Jev 会并行输出各个类别的概率，并返回选中的类别。对这条工单，它直接在“使用咨询 / 产品故障 / 账号问题 / 其他”这个候选集合上打分，程序根据返回的类别，把工单分配到对应处理流程。

这个取舍决定了 Jev 的定位，它专注于分类、评分和条件判断，更像程序里的判断层，而分析故障原因、撰写客服回复、多轮对话这些需要生成文字的工作，继续由 LLM来完成。

可以用一张表概括两者的区别。

那 Jev 判断得准不准，速度有多快，又能省多少钱？我们来看看官方的评测结果。

TypeSafe 公布了一组工作流评测，覆盖安全事件处理、Agent 执行记录检查、发票处理和客户服务。它把任务分成模型判断和程序规则，让不同模型运行相同的流程。参与比较的 LLM 使用服务商默认推理设置，通过适配器返回结构化决策和概率。

官方先让 GPT-6 Astra 和 Claude Fable 5.1 在高推理设置下回答这些问题，将两者给出的概率取平均，生成一份参考答案，再据此给参与测试的模型打分。图中的 accuracy 表示模型结果与这份参考答案的吻合度，不能直接当作真实业务中的准确率。这些结果用于比较模型在判断型任务上的表现、耗时和费用，评测范围不涉及撰写回复、多轮对话等生成能力。

Cost 图把评测分数和费用放在一起。Jev 的位置很靠左，在接近 Terra 和 Sonnet 5 分数的位置，花费明显更少。

横轴为每个案例的费用，纵轴为评测分数，越靠左上表示费用越低、分数越高。菱形代表工作流方式，圆形代表单独提示词方式。

切换到 Time 图，比较的就是完成任务需要多久。在这四类工作流中，Jev 的平均耗时约为 0.4 秒，Terra 为 10.1 秒，Sonnet 5 为 78.1 秒。

横轴为每个案例的耗时，纵轴为评测分数，越靠左上表示耗时越短、分数越高。

下面是图中的部分数据，均为工作流方式下四类任务的等权平均，模型名称沿用图中简称。

Jev 的分数是 67.8%，Terra 是 67.9%，两者接近。Sol 和 Opus 5 的分数更高，分别达到 74.1% 和 73.1%。在这组评测中，Jev 以更低的费用和更短的耗时，取得了接近 Terra 的评测分数。

上表统计的是一个工作流案例的耗时，其中可能包含多次判断。单看一次请求，TypeSafe 公布的端到端响应时间为 70～500 毫秒，

价格也可以直接算一笔账。Jev 1.13 每百万输入 token 收费 0.042 美元，输出免费。假设一次判断输入 1,000 个 token，包含上下文、问题和候选项，调用 100 万次，模型调用费就是 42 美元

回到文章开头的 Agent 场景，一次任务里可能反复出现分类、筛选、检查结果这些步骤。Jev 可以承担其中的分类、筛选和结果检查，把范围明确的判断交给它，复杂分析和内容生成继续由 LLM 完成。

这里有一点需要注意，除了速度和成本，实际使用时还需要关注模型的规模和上下文限制。目前，官方尚未公开 Jev 的参数量。Jev 1.13 每次请求最多支持 64K tokens，但还有一项限制，共享的 state 加上最长的一个问题，不能超过 32K tokens。

因此，这里的 64K 指的是上下文与所有问题合计的预算，不能全部用来放正文。同时官方也提到，输入中无关内容越多，判断准确率可能越低，实际接入时应先筛选信息，只保留当前判断需要的内容。

二、Jev 怎么用？从三种输出到代码示例

开发者使用 Jev 时，需要提供当前信息、要回答的问题，以及允许返回的答案类型。下面分别用三个例子，看看 Choice、Score 和 Noul 怎么接入程序。

先在终端安装 Python SDK，并配置 API Key，三个例子共用这一步准备：

python -m pip install typesafe-sdk

export TYPESAFE_API_KEY=”替换成你自己的 API Key”

每段 Python 代码都可以单独保存为文件运行，客户端会从环境变量读取密钥。下面结合这三个示例的实际运行截图，看看返回结果怎么读，以及程序如何使用这些结果。

第一种：选择一个答案

这种能力叫作 Choice，适合答案来自固定选项的场景。

假设客服助手收到一句话：“帮我查一下订单 12345 的包裹到哪了。”我们希望它从“查订单，查物流，查售后政策，其他”中选出对应流程。

state 放用户消息，instructions 写要判断的问题，criteria 定义候选项及其含义。这里的 route 是我们给这个问题起的名字，程序用它取回结果。

这次运行返回的处理流程是 shipping，各选项概率如下：

处理流程： shipping

各选项概率： {‘after_sales’: 0.0, ‘order’: 0.0, ‘other’: 0.0, ‘shipping’: 1.0}

用户虽然提到了订单号，但要问的是包裹到了哪里，所以这次结果对应查物流流程。程序读取 choice 中的 shipping，就可以据此调用物流查询工具；probabilities 则列出各候选项的概率。

这样的写法也可以用于选择工具或子 Agent等，只需把候选项换成对应的能力说明。

第二种：按照标准评分

这种能力叫作 Score，适合衡量程度。

例如，用户问“试用期间能不能导出数据”，知识库返回了一段试用说明。我们可以让 Jev 判断，这段资料在是否在回答用户问题。

这里的 state 同时放入用户问题和检索资料。criteria 按相关程度从低到高列出四个等级，对应编号 0～3，返回的 score 是各等级编号按概率加权得到的分数，因此不一定是整数。

这次运行输出的是：

资料相关性： 2.99

2.99 已经很接近最高分 3，对应的标准是“直接提供了回答问题所需的信息”。资料明确说明试用账号可以导出 CSV，并补充了每天最多 100 条的限制，能够回答用户的问题。这里的 2.99 是按这四档标准得到的相关性分数，不是概率，也不是百分制分数。拿到多段资料时，程序就可以按同一套标准评分、排序，优先把高分内容交给大模型组织回答。

第三种：判断某个条件是否成立

这种能力在官方接口中叫作 Noul，返回一个介于 0 和 1 之间的数值，表示回答为“是”的概率。

例如，客服助手收到“这个问题请帮我转人工确认一下”，就可以判断用户是否明确要求联系人工客服，再进入对应流程。

Noul 的问题直接写在 instructions 中。返回值越接近 1，越倾向于“是”，越接近 0，越倾向于“否”。这里判断的是用户是否明确提出转人工。

这次运行输出的是：

要求转人工的概率： 0.98

下一步：进入转人工流程

模型返回 0.98，表示它判断这条消息有 98% 的概率是在明确要求转人工。示例中设置的阈值是 0.8，0.98 大于这个阈值，所以程序执行了 if 分支，打印“下一步：进入转人工流程”。这段代码演示到分支判断和打印结果；接入业务系统时，可以在这个分支中调用客服接口，完成实际转接。

一次调用也可以同时问几个问题。比如，对同一条客户消息，分别判断“用户是否申请退款”和“用户是否提到了重复扣费”。这两个问题都能直接根据消息作答，可以放在一次调用里并行处理。

Jev 适合承担分类、路由、相关性筛选、质量评分和条件判断等工作。每次只需完成一项分类、评分或条件判断，但在自动化系统中，这些步骤可能反复执行。

它适合的问题通常有三个特点：上下文已经准备好，判断范围比较明确，输出能对应到具体程序动作。

三、Jev 在 Agent 中，可以放在哪些位置？

Agent 可以理解为一个围绕目标持续工作的系统：接收任务、制定计划、调用工具、检查结果，再决定继续还是结束。

Jev 可以接入其中的多个判断节点，下面看几个应用设计示例。

接收任务时：判断请求应该交给谁

假设一个企业助手能够查询订单、检索制度、分析报表，还能处理技术问题。

用户输入：

“帮我看看这笔订单为什么一直没有发货。”

此时，可以先让 Jev 根据用户表达和已有对话，判断请求属于哪个业务方向。程序据此进入订单处理流程，再由大模型分析需要查询哪些信息。

在这个位置，Jev 接收的是用户请求和候选能力说明，输出的是业务类别或候选处理对象，作用是缩小后续处理范围。

检索资料后：判断哪些内容值得继续使用

Agent 查知识库时，可能一次拿到很多段资料。有些直接回答问题，有些只是关键词相似。

例如，用户问：

“试用期间能不能导出数据？”

搜索结果中可能同时出现试用说明、导出操作指南等。

检索时先按来源和更新时间筛选资料，再让 Jev 根据用户问题，对每段资料的相关性评分。程序选出更有帮助的内容，交给大模型组织回答。

这个位置，它接收的是问题和候选资料，输出的是相关性判断，帮助减少后续需要阅读的无关内容。

工具执行前：辅助判断操作风险

Agent 准备执行操作时，可以增加一次针对具体行为的检查。

例如，用户要求是“整理项目文件”，Agent 却准备删除一个目录。判断这次操作是否符合用户意图，需要同时看用户原话、操作对象和拟执行动作。

Jev 可以辅助回答：

• 这项操作是否超出了用户要求？
• 操作对象是否存在歧义？
• 是否应该先让用户确认？

程序根据这些判断，选择放行、暂停或请求确认。

这个位置的输入是用户意图、拟执行操作及必要上下文，输出是风险信号或确认建议。

工具返回后：决定继续、重试还是补充信息

工具返回结果后，Agent 还要根据已有的信息决定下一步做什么。

例如，Agent 查询物流后，可能得到三类情况：

• 已查到完整物流记录
• 查询服务暂时不可用
• 缺少运单号，无法继续。

系统可以设置如“继续处理，重试，询问用户，结束”等候选分支，让 Jev 根据返回内容和任务状态辅助选择。

在这里，它接收的是工具的结果、当前目标和执行状态，输出的是下一步流程建议。

交付结果前：检查是否满足具体要求

Agent 写完回答或生成文件后，可以再做一轮有明确标准的检查。

比如，用户要求一份产品对比，必须包含价格、适用场景和使用限制。系统可以分别检查这三个要点是否覆盖，再决定是否需要补充。

在这个位置，Jev 接收的是用户要求、最终结果和必要依据，输出的是逐项判断或评分。

测试和复盘时：批量评估 Agent 的表现

Jev 还可以用于 Agent 的测试环节。

开发团队可以收集一批任务记录，按照统一标准检查：

• 回答是否准确
• 是否遗漏明确要求
• 是否出现无必要的重复操作
• 是否在信息不足时继续作出结论。
• ……

它接收的是任务记录和评价标准，输出的是分类结果或分项评分，帮助团队筛选需要重点复查的案例。

Jev如何参与到流程中

以“查询订单迟迟未发货的原因”为例，一条可能的处理流程是：

1. Jev 判断请求属于订单问题，程序进入订单处理流程。
2. 大模型确认需要哪些信息，生成查询计划和参数。
3. 程序检查权限，必要时由 Jev 补充判断操作是否符合用户意图。
4. 订单工具执行查询，返回真实业务数据。
5. Jev 辅助判断信息是否足够，程序决定继续查询还是向用户补充提问。
6. 大模型根据查询结果解释原因，系统再检查回答是否覆盖用户需求。

在这条链路里，Jev 承担边界明确的判断，大模型负责复杂分析和内容生成，工具执行实际操作，程序管理流程与权限。

回到开头的成本和效率问题，如果你的 Agent 经常需要判断请求该交给谁、检索结果是否相关、工具返回的信息是否够用，可以选其中一个环节试试 Jev。用同一批任务，比较它和现有模型的判断结果、耗时与费用，再决定是否接入。前面的官方评测提供了一个参考，能不能在自己的任务里省下时间和成本，还是要实际跑一跑才行。