# Jev：让 AI 直接参与程序判断

规范网页：https://devtookit.com/article/9

作者：Revio

发布时间：2026-09-24T03:56:24Z

更新时间：2026-09-24T08:12:43Z

摘要：从一条工单出发，介绍 Jev 如何通过类型化输出、并行求值与 RLCD 训练参与程序判断，并给出接口示例和应用场景。

---

“团队无法导出报表，明天上午要交付客户。”收到这样一条反馈，客服系统需要做几个判断：它属于技术问题还是账单问题？是否有明确的截止时间？应该交给谁处理？

这些问题需要理解语义，单靠关键词很容易分错。Jev 就是为这类判断设计的模型：输入一段信息和几个问题，直接返回程序可以使用的选项、分数和概率。

TypeSafe AI 在 2026 年 9 月 15 日发布 Jev，将它称为 System One 模型。根据目前（2026 年 9 月 24 日）的信息，下面看看它的实现思路、接入方式，以及可能的应用场景。[发布介绍](https://typesafe.ai/blog/introducing-system-one-models-and-jev)

## 从一句话，到程序里的一个分支

对于上面的工单，我们可以先定义三个去向：技术团队、账单团队，以及需要人工判断的其他问题。Jev 读取消息后，从这三个选项中作出选择，并返回各选项的概率。程序拿到结果，就能决定下一步把工单放进哪个队列。

这是一种面向软件的接口。普通大模型也能通过结构化输出完成分类；Jev 则把这类小而频繁的判断作为主要任务，围绕输出形式、推理方式和训练目标做了专门设计。它理解自然语言，输出的是决策值，不生成回复正文或推理解释。[System One 模型说明](https://docs.typesafe.ai/concepts/system-one)

## Jev 如何完成判断

### 用类型定义答案

一次请求包含两部分：`state` 放待分析的信息，`questions` 定义要回答的问题。Jev 提供三种[基础类型](https://docs.typesafe.ai/primitives)：

| 类型 | 工单中的例子 | 返回什么 |
| --- | --- | --- |
| Choice | 交给技术、账单还是其他团队？ | 选中的类别、各选项概率、confidence |
| Score | 按给定等级，问题有多严重？ | 分数、各等级概率、confidence |
| Noul | 用户是否给出了明确截止时间？ | 0 到 1 的肯定概率 noul |

Choice 的类别由开发者事先给出，模型不会临时编出一个不存在的团队。遇到描述不清或不属于现有分类的消息，可以通过 `other` 留出人工处理的入口。

Score 适合描述有次序的程度，例如“功能正常”“部分功能受影响”“核心功能无法使用”。它根据各等级的概率计算加权分数，因此也会返回小数。[Score 文档](https://docs.typesafe.ai/primitives/score)

限定答案范围解决了输出格式的问题，选对答案仍取决于模型的判断。这也是理解 TypeSafe 所说“类型安全”时需要保留的区别。

### 一次请求，处理多个独立问题

分类、截止时间和严重程度，都可以根据同一条工单分别判断。Jev 会共享这份输入，在一次请求中并行求值。按照 TypeSafe 的介绍，它通过并行采样输出决策概率，省去了逐 token 生成整段答案的过程。[实现介绍](https://typesafe.ai/blog/introducing-system-one-models-and-jev)

这样，应用可以把几个原本分开调用的判断合并起来。若后续问题需要新的信息，例如先查订单才能判断退款条件，就在查完订单后再发起下一次请求。独立问题一起算，有依赖的步骤按顺序执行。

### 用 RLCD 训练可用于决策的概率

Jev 的训练方法叫 RLCD，完整名称是 Reinforcement Learning for Calibrated Decisions。它的目标是让模型给出的概率与实际结果相符：如果一组事件都被赋予约 80% 的概率，那么这组事件实际发生的比例也应接近 80%。这就是概率校准。[训练思路](https://docs.typesafe.ai/introduction/machine-learning-primer)

校准的意义在于，软件可以根据不确定程度分配工作。信息明确的工单直接分流，模糊的消息转给人工；需要深入分析的问题则交给推理模型。它衡量的是一组预测的表现，不保证某一次判断一定正确。

目前公开资料还不足以复现 Jev 的完整网络结构、参数规模、训练配方和奖励函数，更多细节有待披露。

### 用 confidence 决定是否继续处理

Choice 和 Score 除了返回概率分布，还会返回 `confidence`。它是从分布计算出的确定性指标：概率集中在一个答案上时更高，几个答案难分高下时更低。Noul 已经直接给出肯定概率，不另设这个字段。[Confidence 文档](https://docs.typesafe.ai/confidence)

`confidence = 0.9` 不表示“正确率为 90%”。接入时，可以用一批已标注的工单试出合适的门槛，看看提高自动分流比例后，误分率会怎样变化。这样，门槛才对应实际的业务取舍。

## 一个工单分流示例

下面通过 [HTTP API](https://docs.typesafe.ai/introduction/quickstart) 提交两个问题：选择处理团队，以及判断消息中是否包含明确的交付时间。示例使用固定版本，密钥从服务端环境变量读取。

```python
import json
import os
import urllib.request

payload = {
    "model": "jev-1.13.0",
    "state": {
        "message": "团队无法导出报表，明天上午要交付客户。",
        "product": "企业报表工具"
    },
    "questions": {
        "team": {
            "type": "choice",
            "instructions": "选择最适合处理此反馈的团队。",
            "criteria": {
                "engineering": "功能异常或软件缺陷",
                "billing": "付款、发票或订阅问题",
                "other": "信息不足或不属于上述团队"
            }
        },
        "deadline": {
            "type": "noul",
            "instructions": "用户是否给出了明确的交付时间？"
        }
    }
}
request = urllib.request.Request(
    "https://api.typesafe.ai/v1/systemone",
    data=json.dumps(payload).encode("utf-8"),
    headers={
        "Authorization": "Bearer " + os.environ["TYPESAFE_API_KEY"],
        "Content-Type": "application/json"
    },
    method="POST"
)
with urllib.request.urlopen(request, timeout=15) as response:
    result = json.load(response)

team = result["answers"]["team"]
# 演示门槛，实际数值根据工单样本调整。
queue = "manual_review"
if team["confidence"] >= 0.85:
    queue = {
        "engineering": "engineering_triage",
        "billing": "billing_triage"
    }.get(team["choice"], "manual_review")
print({"queue": queue, "model": result["model"]})
```

这里的 `criteria` 写清了每个团队的职责，最后几行代码负责把类别映射到队列。信息不足或 confidence 未达到门槛时，工单会保留在人工队列。另一个问题的结果可以从 `result["answers"]["deadline"]["noul"]` 读取，用于后续排序。

真正接入工单系统时，再补上超时重试、限流处理和操作去重。Jev 负责理解消息，账号权限、订单金额等有确定规则的部分，继续交给业务代码。

## 哪些地方适合用 Jev

工单分流只是一个起点。许多软件里都有类似的小判断：输入是自然语言，输出却只有有限的几种可能。

| 场景 | 可以交给 Jev 的判断 | 后续处理 |
| --- | --- | --- |
| 客服系统 | 消息分类、紧急程度、资料完整度 | 分派工单或请用户补充信息 |
| Agent 调度 | 请求适合哪种工具或模型 | 调用对应工具，复杂问题升级处理 |
| 搜索与知识库 | 候选段落与问题是否相关 | 重排结果，再生成回答 |
| 数据整理 | 两条记录是否指向同一对象 | 合并候选记录，人工处理歧义 |
| 游戏交互 | 当前状态下选择哪种策略 | 状态机执行移动、攻击或交互 |

其中，Agent 调度是很自然的尝试方向。大量请求可能只是查询记录或简单分类，少部分才需要长时间推理。先做一次轻量判断，有机会减少昂贵模型的调用。是否值得这样拆分，可以比较整个流程的延迟、费用和误路由率。

游戏中的用法则更接近策略选择。例如，把角色血量、附近目标和任务状态整理成文本，让 Jev 在几个动作中作出判断。由于当前只支持文本输入，而且需要云端调用，它更适合低频决策；逐帧移动和碰撞仍由本地逻辑处理。[模型输入说明](https://docs.typesafe.ai/models)

## 速度和费用意味着什么

按 9 月 24 日的[官方模型规格](https://docs.typesafe.ai/models)，`jev-1.13.0` 的输入价格为每百万 token 0.042 美元，输出免费。假设每次请求包含 1,000 个输入 token，调用 100 万次的模型输入费用约为 42 美元。

单次请求总共支持 64k token，其中 `state` 加上最长的一个问题不能超过 32k。把多个独立问题放进同一请求，可以共享状态，但仍需要留意这两个长度上限。

TypeSafe 公布的端到端响应时间为 70–500ms，实际延迟会受网络、输入长度和负载影响。[官方测试说明](https://typesafe.ai/blog/introducing-system-one-models-and-jev)。中文项目还需要留出样本验证：官方目前以英语训练为主，不同语言的效果会有差异。

对于已有系统，可以先从工单分类或模型路由这样的单个环节接入，观察它能替掉多少重复判断。Jev 的吸引力也在这里：把语义判断做成一个足够轻的函数，让开发者愿意在更多地方调用它。