最近 AI 模型领域出现了一个比较特别的新模型——Jev。

第一次看到它时，很容易把它理解成另一个 GPT、Claude 或 DeepSeek：是不是又一个新的大语言模型？参数多大？推理能力怎么样？能不能拿来写代码？

实际上都不是。

Jev 最值得关注的地方，恰恰在于它并不试图成为另一个聊天模型。

GPT、Claude 这类模型擅长的是：

输入内容 → 思考 → 生成一段内容

而 Jev 的目标是：

输入当前状态 → 直接做出结构化判断

比如给模型一段客服信息：

I have been trying to connect my Stripe account
for three days and it keeps failing.
I'm losing sales. Please help ASAP.

传统大语言模型可能返回：

This appears to be an urgent technical support issue...

而 Jev 更希望直接给程序这样的结果：

department = technical
confidence = 0.78

frustration = 1.0

urgent = 1.0

没有长篇解释。

没有自然语言包装。

程序可以直接读取结果，然后决定下一步执行什么。

这就是 Jev 最核心的定位。

---

一、Jev 到底是什么？

Jev 是 TypeSafe AI 在 2026 年 9 月 15 日公开的首个 System One Model，目前处于 Early Access 阶段。

TypeSafe 对这类模型的定义是：

面向软件内部决策，而不是面向人与 AI 对话的模型。

其官方给出的一个非常准确的描述是：

Unstructured state in, typed probabilistic decisions out.

也就是：

非结构化状态
      ↓
     Jev
      ↓
结构化概率决策

官方文档也明确指出，Jev 接收一个 state 和一组已经定义好的问题，然后直接输出程序能够使用的结构化结果，而不是先生成文本再进行 JSON 解析。

这里其实体现出了 Jev 与传统 LLM 一个很根本的设计差异。

传统 LLM 的核心接口是：

Prompt
  ↓
LLM
  ↓
Tokens
  ↓
String

哪怕最后要求模型：

{
  "result": true
}

本质上，它还是在生成字符。

只是我们通过 Prompt、JSON Schema、Function Calling 等方法，尽量约束它按照指定格式生成。

Jev 的思路则完全不同。

它从模型层面就不是围绕“生成字符串”设计，而是围绕：

Decision

来设计。

---

二、为什么叫 System One Model？

System One 这个名字来源于 Daniel Kahneman 在《Thinking, Fast and Slow》中提出的 System 1 / System 2 概念。

可以粗略理解为：

System 1
快速判断
↓
“看到情况马上作出判断”

System 2
复杂推理
↓
“分析、计算、逐步思考”

TypeSafe 借用了这个概念，把 Jev 定位为：

System One Model

它并不希望替代复杂推理模型，而是专门解决大量软件系统中不断出现的小型判断任务。

例如：

这是不是垃圾邮件？

当前用户是不是准备流失？

这个请求应该交给哪个部门？

这个回答是否需要审核？

当前 Agent 下一步应该调用哪个工具？

是否需要继续搜索？

是否应该升级到更昂贵的模型？

这些问题往往并不需要模型写 500 字推理过程。

真正需要的是：

Yes / No

A / B / C

0 / 1 / 2 / 3 / 4

以及对应概率

这就是 Jev 所针对的问题。

TypeSafe 还为此提出了自己的训练方法 RLCD（Reinforcement Learning for Calibrated Decisions），目标不是优化人类喜欢什么样的回答，而是优化结构化决策以及相应的不确定性估计。

---

三、Jev 最核心的三个能力

Jev 当前最重要的概念其实非常少。

官方把它的基础能力抽象成了三个 Primitive：

Choice、Score 和 Noul。

1. Choice：从多个选项中选择

这是最容易理解的一种。

例如一个 Agent 当前有四种动作：

Search
Zoom-in
Verify
Answer

可以问 Jev：

根据当前状态，下一步应该执行哪个动作？

模型可能得到类似：

Search    0.08
Zoom-in   0.72
Verify    0.15
Answer    0.05

最终：

choice = Zoom-in

Choice 特别适合：

• Agent Tool Routing

• 用户意图分类

• 工单分类

• Workflow 路由

• 多策略选择

• 模型路由

也就是说：

多个动作摆在面前，让模型决定走哪一条。

---

四、Score：对当前状态进行评分

第二种能力是 Score。

比如判断一个客服用户目前的情绪：

0 = Calm
1 = Frustrated
2 = Very angry

Jev 可以输出：

score = 1

0: 0.03
1: 0.91
2: 0.06

这不仅告诉程序：

用户属于等级 1

同时给出了不同等级的概率。

因此它很适合：

风险等级
紧急程度
质量等级
相关性评分
审核等级
优先级判断

---

五、Noul：判断一个命题成立的程度

第三个比较特殊，叫做 Noul。

它可以理解成：

某件事情到底有多大程度是真的？

例如：

当前证据足以回答这个问题。

Jev 返回：

0.87

就表示模型非常倾向于认为这个命题成立。

再比如：

This message expresses urgency.

可能得到：

noul = 1.0

官方把 Noul 定义为一个 0～1 的判断结果。

这种东西在 Agent 中其实非常有用。

例如：

当前证据是否充分？

是否存在事实冲突？

是否需要重新执行？

是否存在安全风险？

是否应该交给人工？

是否需要进一步搜索？

这些本质上全部是 Noul 类问题。

---

六、三个判断可以一次完成

Jev 还有一个比较重要的特点：

Choice、Score 和 Noul 可以放在同一个请求里同时执行。

例如给一个客服消息：

state
  ↓
Jev
  ├── department → Choice
  ├── frustration → Score
  └── urgent → Noul

一次调用之后得到：

department = technical

frustration = 1

urgent = 1.0

官方文档指出，这些问题会针对同一个 State 独立、并行地进行判断。

这和传统 LLM 有一个明显区别。

使用传统 LLM 时，我们很容易写成：

请分析以下内容：

1. 判断属于哪个部门
2. 判断用户情绪
3. 判断是否紧急
4. 综合以上判断给出结果

这时候多个判断都混在同一个生成过程里。

而 Jev 更鼓励：

Question A
Question B
Question C
Question D

每一个问题都尽量保持原子化。

然后：

Model → 判断
Code  → 组合

这其实是一种非常值得注意的设计思想：

不要把整个业务逻辑全部塞进 Prompt，让模型完成，而是让模型只负责无法硬编码的模糊判断，其余逻辑继续由程序控制。

---

七、Jev 和 GPT、Claude 到底有什么区别？

可以简单总结成下面这张表。

能力	GPT / Claude 等 LLM	Jev
自然语言生成	强	不是目标
写文章	强	不适合
写代码	强	不适合
长链推理	强	非核心
分类	可以	核心用途
评分	可以	核心用途
路由	可以	核心用途
Yes/No 判断	可以	核心用途
概率化输出	非核心接口	核心设计
软件内部决策	可以实现	主要目标
输出形式	Tokens / String	Typed Decision

可以把二者简单理解为：

LLM
负责：
“想什么、说什么”

Jev
负责：
“选哪个、做不做、是多少”

所以 Jev 并不是 GPT 的替代品。

更合理的关系其实是：

LLM + Jev

---

八、为什么不直接让 GPT 输出 JSON？

看到这里，一个很自然的问题就是：

GPT、Claude 本来就支持 Structured Output 和 Function Calling，为什么还需要 Jev？

区别主要不是：

“能不能输出 JSON”。

而是：

模型从一开始到底为什么而设计。

传统 LLM：

语言建模
↓
Token generation
↓
再约束成 JSON

Jev：

状态理解
↓
Decision
↓
Typed Result

TypeSafe 的设计目标就是把这种决策作为模型原生输出，而不是让生成模型模拟一个分类器。

官方文档甚至直接指出：

传统 LLM 在这种场景下，相当于先生成文本，再把文本重新解析成软件需要的决策结构；System One Model 则直接输出结构化结果。

---

九、Jev 怎么使用？

目前最简单的方式有三种。

第一种：Playground

如果只是想看看 Jev 是什么，直接使用 TypeSafe Playground 即可。

流程非常简单：

输入 State
   ↓
增加 Question
   ↓
选择：

Choice
Score
Noul
   ↓
Run

官方 Quick Start 也是首先推荐通过 Playground 体验。

---

十、第二种：直接调用 API

Jev 提供 System One API。

请求形式大致是：

POST /v1/systemone

指定：

state
model
questions

例如：

{
  "state": "The current answer lacks direct evidence.",
  "model": "jev-latest",
  "questions": {
    "need_verify": {
      "type": "noul",
      "instructions": "Does the current answer require additional verification?"
    }
  }
}

返回：

{
  "need_verify": {
    "type": "noul",
    "noul": 0.82
  }
}

官方当前 Quick Start 使用的默认模型名称就是：

jev-latest

API 地址、请求格式及响应示例均已经在官方文档公开。

---

十一、第三种：Python SDK

如果真正做项目，Python SDK 会更方便。

首先：

pip install typesafe-sdk

目前官方 SDK 要求：

Python >= 3.10

然后配置：

TYPESAFE_API_KEY

最简单的 Python 示例：

from typesafe_sdk import Choice, Noul, Score, TypeSafeClient

client = TypeSafeClient()

response = client.system_one(
    state="The current answer lacks direct visual evidence.",
    questions={
        "next_action": Choice(
            instructions="What should the system do next?",
            criteria={
                "zoom": "Inspect a local image region",
                "verify": "Verify the existing conclusion",
                "answer": "Return the final answer",
            },
        ),
        "enough_evidence": Noul(
            instructions="The current evidence is sufficient."
        ),
    },
)

print(response.answers["next_action"].choice)
print(response.answers["enough_evidence"].noul)

官方 Python SDK 本身已经开源，并采用 MIT License。

需要注意：

SDK 开源不等于 Jev 模型权重开源。

截至本文写作时，TypeSafe 官方提供的主要使用方式仍然是 Playground、API 以及 SDK；官方公开 GitHub 仓库主要包含 SDK、Adapter 和相关开发工具，并没有提供像 Qwen、Llama 一样直接下载 Jev 权重进行本地推理的官方方案。

---

十二、Jev 到底适合什么场景？

真正判断 Jev 是否值得用，可以记住一句话：

如果最终需要的是“内容”，使用 LLM；如果最终需要的是“决定”，可以考虑 Jev。

比如下面这些任务就非常适合。

1. Agent Router

Agent 当前拥有：

Search
Database
Calculator
Browser
Code

过去我们可能让 LLM：

分析问题
↓
生成 Tool Call

现在可以让 Jev 专门判断：

当前状态
   ↓
Jev
   ↓
应该调用哪个 Tool？

例如：

Search      0.06
Database    0.74
Calculator  0.04
Browser     0.13
Code        0.03

然后程序直接：

if action == "database":
    call_database()

---

十三、Verifier

另一个非常适合的场景是：

Verifier。

例如一个 LLM 已经生成结果。

我们并不需要另一个模型重新写一遍答案，而只是想知道：

这个答案是否存在问题？

可以把：

Question
Answer
Evidence

作为 State。

让 Jev 判断：

answer_supported

answer_complete

contains_conflict

然后：

if supported < 0.6:
    verify()

if conflict > 0.8:
    reject()

这样 Jev 就变成整个系统内部的一个判断节点。

---

十四、模型路由

现在很多系统实际上会同时拥有多个模型。

例如：

小模型
中等模型
强推理模型

并不是所有问题都需要直接调用最贵的模型。

可以先判断：

当前任务复杂吗？

如果：

difficulty < threshold

调用便宜模型。

否则：

→ Frontier Model

于是整个架构就变成：

User Request
     ↓
    Jev
     ↓
┌────┼────────┐
Small   Medium   Frontier
Model   Model    Model

这类 Model Routing 正是 System One Model 很自然的应用方式。

---

十五、大规模数据处理

Jev 还有一个很容易被忽略的用途：

大量、小型、重复判断。

比如有：

10 万条评论

需要判断：

是否投诉
是否有退款意图
所属产品
紧急程度
用户情绪

如果每条数据都让一个大型生成模型：

生成几百 Token

大量计算其实浪费在了我们根本不需要的自然语言输出上。

而 Jev 的设计目标正好是：

Input
↓
Judgment

因此 TypeSafe 官方也把：

• classify

• route

• score

• extract

• branch

• 大规模数据处理

列为主要使用场景。

---

十六、实时应用

Jev 另一个非常重要的方向是实时系统。

TypeSafe 官方目前给出的 Jev 端到端延迟范围大约为：

70 ms ～ 500 ms

其公开 Workflow 测试还报告过非常明显的速度和成本优势。

不过这里需要特别注意：

目前这些主要还是 TypeSafe 自己发布的测试结果。

官方自己也明确承认：

• Workflow 由其团队设计；

• 可能存在一定设计偏差；

• 官方展示的巨大加速属于比较有利的一端。

因此现阶段更合理的态度是：

Jev 在低延迟结构化决策上的设计方向非常有意思，但它刚刚进入 Early Access，真实生产表现仍需要更多第三方测试。

---

十七、Jev 不适合干什么？

理解一个模型，不仅要知道它擅长什么，还要知道它不应该做什么。

下面这些任务就不适合 Jev：

帮我写一篇论文

帮我生成一个程序

帮我分析一道复杂数学题

帮我总结这篇长论文

帮我写小说

帮我进行复杂多步推理

这些问题最终需要的是：

内容生成。

而 Jev 的核心输出是：

Decision。

所以：

任务	更适合
写文章	LLM
写代码	LLM
长推理	Reasoning Model
总结	LLM
分类	Jev
路由	Jev
判断	Jev
打分	Jev
是否执行	Jev
Workflow 控制	Jev

---

十八、Jev 也不是“绝对不会判断错”

TypeSafe 在宣传中强调 Jev 不进行自由文本生成，因此不会出现传统生成模型那种 Schema 外输出和类型错误。

但这里必须区分两个概念：

输出格式正确
≠
判断一定正确

例如：

Jev 输出：

risk = high

这个字段一定可以满足事先规定的数据结构。

但：

risk 到底是不是真的 high？

模型仍然可能判断错误。

所以程序更合理的做法是结合概率设置阈值：

if confidence > 0.9:
    auto_execute()

elif confidence > 0.6:
    ask_for_review()

else:
    escalate()

TypeSafe 官方本身也强调利用 confidence 和概率，让代码决定什么时候自动执行、什么时候升级处理。

---

十九、Jev 最有意思的地方其实是 Agent

如果只拿 Jev 做：

情感分类

当然可以。

但我认为它真正值得关注的地方还是 Agent 系统。

传统 Agent 经常是：

User
 ↓
LLM
 ↓
Reasoning
 ↓
Tool Call
 ↓
Observation
 ↓
LLM
 ↓
Reasoning
 ↓
Tool Call

也就是说：

所有事情都交给同一个大模型。

它既负责：

理解
推理
生成
判断
路由
停止条件
验证

而 Jev 提供了另一种可能：

              ┌─────────────┐
              │     LLM     │
              │ Reasoning   │
              └──────┬──────┘
                     ↓
              Current State
                     ↓
              ┌─────────────┐
              │     Jev     │
              │  Decision   │
              └──────┬──────┘
                     ↓
         ┌───────────┼───────────┐
         ↓           ↓           ↓
       Tool        Verify      Answer
         ↓
      New State
         ↓
        Jev

于是职责变成：

LLM：
负责复杂理解和推理

Jev：
负责快速判断和控制

Code：
负责真正执行 Workflow

这可能才是 System One Model 最值得观察的地方。

---

二十、举一个主动视觉 Agent 的例子

假设现在有一个视觉 Agent。

用户问：

图片右侧红色汽车旁边的人正在做什么？

VLM 第一次看完整图：

Image + Question
       ↓
      VLM
       ↓
可能有人站在汽车附近，
但图像太远，看不清动作。

此时并不需要再让一个大模型写几百字分析。

可以把当前状态给 Jev：

Current Reasoning:
人物存在，但动作证据不足。

Available Actions:
Zoom-in
Answer
Verify
Search

然后询问：

当前证据是否足够？

是否需要局部观察？

下一步应该执行哪个动作？

得到：

enough_evidence = 0.18

need_zoom = 0.91

next_action:
zoom = 0.86
verify = 0.09
answer = 0.04
search = 0.01

Agent 于是：

Zoom-in
   ↓
获得局部图像
   ↓
VLM 再次推理
   ↓
更新 State
   ↓
Jev 再次判断

最后当：

enough_evidence = 0.94

程序再允许模型生成最终答案。

这时候 Jev 的角色就非常明确：

它不负责看图，也不负责回答问题，而是负责控制整个推理过程什么时候继续、什么时候观察、什么时候验证以及什么时候停止。

---

二十一、价格怎么样？

Jev 当前最大的特点之一就是价格。

TypeSafe 官方目前公布的输入价格是：

$0.042 / 1M input tokens

也就是：

$42 / 1 Billion input tokens

官方当前将输出部分标记为免费计费。

之所以能够这样定价，一个重要原因就是：

Jev 根本不需要像传统 LLM 那样自回归地生成大量文本 Token。

当然，Jev 当前仍属于比较新的产品，价格和服务策略未来都有可能变化。

---

二十二、它开源吗？可以本地部署吗？

这里需要区分：

TypeSafe SDK

和：

Jev Model

目前官方 Python SDK 和 JavaScript SDK 都已经公开，其中 Python SDK 使用 MIT License。

但是：

SDK 开源并不意味着 Jev 模型本身已经开源。

截至本文写作时，官方主要提供：

Playground
API
Python SDK
JavaScript SDK
Agent Skill

并没有像 Llama、Qwen 那样公开 Jev 模型权重供用户直接下载运行。

所以现在使用 Jev，最现实的方式仍然是：

Your Application
       ↓
TypeSafe SDK / API
       ↓
      Jev

而不是：

Download Jev
     ↓
Local GPU
     ↓
Inference

---

二十三、什么时候应该使用 Jev？

最后可以用一个非常简单的方法判断。

先问自己：

我到底需要 AI 给我什么？

如果答案是：

一段文字
一段代码
一个解释
一个推理过程
一个总结

使用：

GPT / Claude / Gemini / Qwen / DeepSeek ...

如果答案是：

Yes / No

A / B / C

0 ～ 5

做 / 不做

继续 / 停止

调用 Tool A / Tool B

那么：

Jev

就值得考虑。

进一步可以总结为：

需要“生成”
    ↓
   LLM

需要“复杂推理”
    ↓
Reasoning Model

需要“快速判断”
    ↓
   Jev

而对于复杂 Agent：

          LLM
           +
          Jev
           +
          Code

可能会成为一种很有意思的组合。

---

总结

Jev 最值得关注的地方，并不是它又创造了一个“更强大的聊天机器人”。

恰恰相反。

它选择放弃聊天。

传统 LLM 的目标是：

让 AI 更会说话、更会推理、更会生成。

Jev 所代表的 System One Model，则在尝试解决另一个问题：

如何让 AI 像一个普通程序函数一样，
快速、便宜、结构化地做判断？

因此可以把 Jev 的定位压缩成一句话：

Jev 不是一个负责回答问题的 AI，而是一个负责在软件内部不断回答“下一步该怎么办”的 AI。

它目前还非常新，也仍然需要更多实际应用和第三方评测验证。

但它提出的这个方向本身很值得关注：

过去我们一直在研究：

如何让大模型完成越来越多的事情？

而 System One Model 提出的另一个问题是：

是不是有很多事情，根本没有必要让一个大模型从头到尾全部完成？

让大型模型负责真正困难的推理，

让专门的决策模型负责大量高频判断，

再让代码掌握整个 Workflow。

这可能是 Jev 比单纯的“又一个新 AI 模型”更值得关注的原因。