aboutJev

Jev的定义

Jev是TypeSafe AI推出的一种 System One模型。

与ChatGPT、Claude等传统LLM不同，Jev的核心目标不是：

生成自然语言文本

而是：

根据输入状态，对预先定义的问题进行结构化决策，并返回可以直接被程序使用的结果。

简单来说：

传统LLM：

输入
 ↓
LLM
 ↓
自然语言

Jev：

输入状态
 ↓
Jev
 ↓
结构化决策
 ↓
程序执行

例如：

输入：

“客户要求退款，并表示商品存在质量问题。”

问题：

客户是否要求退款？
→ 0.97

客户的主要诉求是什么？
→ refund

客户情绪等级？
→ concerned

这些结果可以直接被程序使用。

Jev的官方生态资料将其定位为面向软件的“System One”模型，通过 Choice、Score 和 Noul 等类型返回结构化判断，而不是生成普通文本。

---

为什么需要Jev？

传统LLM非常擅长：

• 写文章
• 写代码
• 总结
• 对话
• 推理
• 内容生成

但是很多软件任务实际上不需要“写一段话”。

例如：

这个工单应该交给哪个部门？

真正需要的可能只是：

技术支持

又或者：

这个请求是否存在风险？

真正需要：

0.91

而不是：

经过分析，我认为这个请求可能存在较高风险……

因此：

很多软件任务需要的不是生成，而是判断。

Jev就是针对这一类问题设计的。

---

LLM与Jev的区别

对比维度	LLM	Jev
核心能力	文本生成与推理	结构化决策
输出	自然语言	Typed Decision
输出格式	不固定	预先定义
是否生成长文本	可以	核心设计不是
适合人类阅读	是	主要面向程序
适合程序分支	需要额外解析	直接使用
典型任务	写作、代码、问答	分类、评分、判断
核心价值	Generation	Decision

因此可以简单理解：

LLM：
“告诉我你的分析结果。”

Jev：
“帮我做这个决定。”

---

Jev的核心思想

传统：

Input
 ↓
LLM
 ↓
Text
 ↓
程序解析Text
 ↓
执行

问题在于：

LLM输出：

“我认为这个问题应该交给技术部门处理。”

程序还需要从文本中解析：

技术部门

而Jev：

Input
 ↓
Jev
 ↓
Choice
 ↓
technical_support

因此：

让模型输出本身就成为程序可以消费的数据。

---

Jev的三种核心输出

Jev目前主要围绕三种决策类型：

Choice
Score
Noul

---

1. Choice

Choice用于：

从多个选项中选择一个。

例如：

问题：

这个客户应该交给哪个部门？

选项：

A. 售前
B. 售后
C. 技术支持
D. 财务

Jev返回：

Choice：

技术支持

同时可以得到不同选项的概率分布。

例如：

售前       0.03
售后       0.12
技术支持   0.81
财务       0.04

因此Choice非常适合：

• 分类
• 路由
• 意图识别
• 工具选择
• Agent任务分配
• 工单分类

---

2. Score

Score用于：

按照预先定义的标准，对输入进行等级评分。

例如：

问题：

这个客户的紧急程度是多少？

1 → 不紧急
2 → 较低
3 → 一般
4 → 较高
5 → 非常紧急

Jev可以输出：

Score：

5

或者结合概率信息：

1：0.01
2：0.03
3：0.08
4：0.28
5：0.60

因此Score适合：

• 风险等级
• 紧急程度
• 质量评价
• 优先级
• 满意度
• 严重程度

---

3. Noul

Noul可以理解为：

针对一个判断题输出0~1之间的概率。

例如：

问题：

这个用户是否要求退款？

返回：

0.96

可以理解为：

这个判断成立的概率约为96%

因此适合：

• 风险判断
• 是否满足条件
• 是否需要人工审核
• 是否触发某个流程
• 是否存在某种意图

例如：

Noul：

是否需要人工审核？
→ 0.87

程序就可以：

if result > 0.8:
    human_review()

---

三种类型总结

类型	解决的问题	示例
Choice	选哪个？	哪个部门处理？
Score	有多严重？	风险等级是多少？
Noul	是不是？	是否需要审核？

可以记成：

Choice
= 选谁？

Score
= 多严重？

Noul
= 是不是？

---

Jev的基本工作流程

Jev的调用模式可以简单理解为：

准备State
   ↓
定义Questions
   ↓
发送给Jev
   ↓
得到Typed Decision
   ↓
程序根据结果执行

例如：

State：

“用户说我的商品坏了，我要求退款。”

Questions：

1. 是否要求退款？
2. 用户主要诉求是什么？
3. 是否需要人工处理？

Jev：

refund = 0.98

request = refund

human_review = 0.72

程序：

if request == refund:
    start_refund_process()

if human_review > 0.8:
    transfer_to_human()

于是：

Jev
 ↓
Decision
 ↓
Code
 ↓
Action

---

Jev与传统分类模型的区别

传统机器学习分类：

输入
 ↓
训练好的分类模型
 ↓
分类结果

Jev：

输入State
 +
自然语言Question
 +
Options / Criteria
 ↓
Jev
 ↓
结构化Decision

Jev的特点之一是：

可以通过问题、选项和评价标准定义当前任务，而不是针对每一个新任务重新训练一个分类器。

因此它更接近：

通用决策模型

而不是：

单一分类模型

---

Jev与LLM的配合

Jev并不是一定要替代LLM。

更合理的方式通常是：

         用户请求
            ↓
     ┌──────┴──────┐
     ↓             ↓
   Jev            LLM
     ↓             ↓
结构化判断       文本生成
     ↓             ↓
     └──────┬──────┘
            ↓
          Agent

例如一个客服Agent：

用户：

“我的订单坏了，而且我已经等了两周，
我非常生气，要求退款。”

Jev：

意图：
退款

紧急程度：
5

是否需要人工：
0.91

LLM：

根据这些结果生成最终回复。

因此：

Jev负责判断，LLM负责表达。

---

Jev在Agent中的作用

Agent通常需要不断做决策：

用户请求
   ↓
应该调用哪个Tool？
   ↓
需要人工吗？
   ↓
任务是否完成？
   ↓
结果是否符合要求？
   ↓
下一步做什么？

传统方式：

全部交给LLM

而使用Jev：

             Agent
               ↓
      ┌────────┴────────┐
      ↓                 ↓
     LLM               Jev
      ↓                 ↓
生成内容             做判断
      ↓                 ↓
      └────────┬────────┘
               ↓
             Tool

因此Jev特别适合Agent中的：

• Tool Routing
• Intent Classification
• Risk Detection
• Guardrails
• Human Escalation
• Result Evaluation
• Task Routing

---

Jev + Harness

如果把前面介绍的Harness和Jev放在一起，可以看到两者承担的是不同职责。

                    Agent
                      │
          ┌───────────┴───────────┐
          ↓                       ↓
        Harness                  Jev
          │                       │
   管理Agent运行              负责决策
          │                       │
 ┌────────┼────────┐              │
 ↓        ↓        ↓              ↓
Context  Tools   Memory       Choice/Score/Noul

更加完整：

用户
 ↓
Harness
 ↓
LLM
 ↓
需要做判断？
 ↓
Jev
 ↓
结构化Decision
 ↓
Harness
 ↓
执行Tool
 ↓
获得结果
 ↓
LLM
 ↓
……

所以：

Harness解决“Agent怎么运行”。

Jev解决“某些任务应该怎么判断”。

---

Jev在RAG中的应用

Jev也可以与RAG结合。

传统RAG：

Query
 ↓
Embedding
 ↓
Vector Search
 ↓
Top-K Documents
 ↓
Rerank
 ↓
LLM

加入Jev之后：

Query
 ↓
RAG召回
 ↓
多个候选文档
 ↓
Jev判断相关性
 ↓
选择 / 评分
 ↓
Context
 ↓
LLM生成

例如：

问题：

“公司的年假政策是什么？”

RAG召回：

Document A
Document B
Document C
Document D

Jev可以判断：

A：相关
B：不相关
C：相关
D：不相关

或者：

A：0.92
B：0.13
C：0.84
D：0.06

然后程序：

保留A、C
 ↓
交给LLM
 ↓
生成答案

因此Jev可以承担：

分类、过滤、路由、评估等非生成任务。

---

Jev在代码Agent中的应用

例如Coding Agent收到：

“帮我修复这个登录Bug。”

Harness负责整个执行流程：

读取代码
 ↓
搜索文件
 ↓
修改代码
 ↓
执行测试

Jev可以负责判断：

测试结果是否通过？

或者：

当前错误是否与原始Bug有关？

或者：

代码修改是否需要人工Review？

例如：

测试结果
 ↓
Jev
 ↓
是否通过？
 ↓
0.98

程序：

if result > 0.9:
    finish_task()
else:
    continue_debugging()

这样可以形成：

Harness
负责执行

Jev
负责判断

LLM
负责理解与生成

---

Jev的优势

1. 输出结构化

传统LLM：

“我认为这个问题属于技术支持部门。”

Jev：

{
    "department": "technical_support"
}

程序可以直接使用。

---

2. 更适合程序分支

例如：

if decision == "refund":
    refund()

elif decision == "replacement":
    replace()

else:
    human_review()

不需要从自然语言中解析结果。

---

3. 可以一次提出多个问题

例如：

State：

用户投诉内容……

同时询问：

Q1：主要意图？
Q2：紧急程度？
Q3：是否需要人工？
Q4：是否存在风险？

然后得到多个结构化判断。

这种设计非常适合Agent中的批量判断和路由场景。社区资料也将“一次状态、多问题”的调用方式作为Jev的重要使用模式。

---

Jev的局限

Jev并不是LLM的完全替代品。

它的核心定位是：

Decision，而不是 Generation。

例如：

适合Jev

这个请求属于什么类别？
是否需要人工审核？
哪个Tool最适合？
风险等级是多少？

不适合只使用Jev

写一篇文章
写一个完整的Java项目
解释什么是RAG
生成一封邮件

这些任务依然更适合生成式LLM。

---

Jev + LLM + Harness

三者可以形成一个比较完整的Agent架构：

            User
              ↓
           Harness
              ↓
      ┌───────┴───────┐
      ↓               ↓
     LLM             Jev
      ↓               ↓
理解 / 生成        判断 / 分类
      ↓               ↓
      └───────┬───────┘
              ↓
            Tools
              ↓
       外部系统 / 数据
              ↓
            Result
              ↓
           Harness
              ↓
             LLM
              ↓
          Response

三者职责可以总结成：

组件	核心职责
LLM	理解、推理、生成
Jev	判断、分类、评分、路由
Harness	编排、执行、状态、权限、工具管理

因此可以理解为：

LLM
= 思考和表达

Jev
= 快速判断

Harness
= 组织整个Agent

---

Jev的核心思想

如果只记住一句话：

LLM擅长生成内容，而Jev擅长把非结构化信息转化成程序可以直接使用的决策。

进一步：

传统AI：

Input
 ↓
Model
 ↓
Text
 ↓
Parser
 ↓
Code

Jev：

Input
 ↓
Jev
 ↓
Typed Decision
 ↓
Code

最终形成：

非结构化信息
      ↓
     Jev
      ↓
结构化决策
      ↓
   程序执行

这使Jev特别适合作为：

Agent、RAG、自动化工作流、风控系统、路由系统中的“决策层”。

---

相关英文翻译

• 状态 / 输入上下文：state

• 问题：question

• 选择：choice

• 评分：score

• 概率判断：noul

• 结构化决策：typed decision

• 分类：classification

• 路由：routing

• 人工介入：human escalation

• 决策模型：decision model

• 生成模型：generative model

• 智能体：agent

• 智能体运行时：agent runtime

• 工具调用：tool calling