点击上方蓝字加入我们
AI 圈从来不缺少新玩意。最近，硅谷又爆了一款新模型 — JEV。
有趣的是， JEV 并非我们熟知的大语言模型（LLM），更不是出图和视频的模型。这款来自 TypeSafe 公司的产品不写文章也不聊天，却让无数 Agent 开发者趋之若鹜。
那么它到底解决了哪些 Agent 系统的实际问题呢？让我们来详细为你拆解。
本篇涵盖内容：
现在的 Agent 如何做决策
JEV：给 Agent 用的高速决策模型
RLCD：让决策更加可信的秘密
动手体验：一张工单的三个问题
边界与不足：哪些事适合 JEV
一、现在的 Agent 如何做决策？
想象下，在一次 Agent 运行过程中，需要面临很多决策与判断：
用户本轮的意图是什么？投诉、咨询还是技术支持？
这个工单的紧急程度如何？需要采取什么级别的应对？
这次工具是否安全？这次调用是否有隐私泄漏？
这类问题在 Agent 中的传统实现大概是这样（或某种变体）：
text = llm.generate(
f"""判断服务工单归属：billing / technical / sales。
仅返回 JSON，包含 department（部门）和 urgent（紧急程度）。
不要添加解释。
工单内容：{ticket}
"""
)
data = json.loads(
text.strip()
.removeprefix("```json")
.removesuffix("```")
.strip()
)为了得到一个简单的答案，先让模型生成一段文字（或许还要 Thinking 很久），还要叮嘱它别加客套话和废话，再把决定从文字里“捞”出来。当然现在的 LLM 大都支持结构化输出，输出解析的问题已经解决。但本质并没有变：
用缓慢且深思熟虑的文本推理来产生决策，速度慢、成本高（想想又慢又贵的 Computer Use）。
JEV 就是从这里找到了切入点。因为他们认为：
LLM 很强大，却不适合做 Agent 里的“判断器”，这影响了大规模自动化的应用。
JEV 则专注于 Agent 内部反复出现的选择、评分、检查等判断任务，而非语言生成任务。唯一目标是：用自然语言定义一个问题，然后快速返回决策答案。
二、JEV：给 Agent 用的高速决策模型
JEV 的工作方式可以浓缩为：
提交上下文信息（状态），声明你的问题，快速拿到结构化的答案。
比如:
状态是一张服务工单；问题是“由哪个团队处理”，选项为销售、技术、售后；然后 JEV在毫秒级时间内返回答案及概率分布。
不会有几秒甚至几十秒的思考，也不会输出“经过分析，我认为……”的长篇大论。
借助一些控制参数和Prompt，你也能让 LLM 产生类似的输出；但这里的本质区别并不在答案形式，而在于模型通过怎样的计算路径、围绕什么训练目标，得到这个答案。
JEV 只回答这三种问题，不会写文章，也拒绝回答其他问题：
你可以简单粗暴的理解成选择题、打分题、判断题。
这些问题可以批量提交：一次问多个问题（不能有依赖关系），然后根据这些问题的答案采取后续行动。
比如，如果判断出”工单是用户投诉，且愤怒概率较低“，则立即转交 xx_agent 继续处理并生成回复 — JEV 与 LLM 并不冲突，而是配合关系。
三、RLCD：让决策更加可信的秘密
你注意到 JEV 本质上也是概率输出；而 JEV 模型的目标，就是让输出的概率有用。
TypeSafe 把 JEV 模型的训练方法称为 RLCD：面向校准决策的强化学习（区别于 LLM 的 RLHF）；强调训练模型输出决策，并校准概率而不是生成的文本。
什么叫校准概率？简单说就是让概率更加靠谱，而不是让文本更符合人类习惯。
比如很多次预测都说“80% 成立”，最终约有八成确实成立，那这个概率就比较可信。
这种更可信的概率信号，在 Agent 中非常有用。正如最开始我们提到的各种决策过程，都可以基于这种判断结果来采取后续的行动。
但要避免一个误读：RLCD 不保证概率已经得到绝对的校准。在这点上，JEV 和普通的 LLM 模型是类似的。
在实际应用中，往往需要结合问题答案与 confidence（置信度，仅限 Choice/Score 类型的问题）来判断后续处理。比如，如果“工具风险度很高，且置信度超过0.8，则进入人工审批过程”。
在动手体验之前，我们总结下 JEV 与 LLM 的主要区别：
四、动手体验：一张工单的三个问题
现在我们用一个简单的案例来体验 JEV 的能力。
JEV 目前可以通过官网申请注册获得 API-KEY，也可以通过 OpenRouter 调用。这里小编使用官方直连，模型使用 jev-1.13.0。
如果你申请不到 API-KEY，也可以使用开源的类似项目 Laya 来做本地体验。
另外，你也可以复制如下提示给你的 AI 编程工具如 Codex，安装 TypeSafe Skill：
Install the TypeSafe skill.
If you're in Claude Code, run `claude plugin marketplace add typesafe-ai/skills`, then `claude plugin install typesafe@typesafe-ai`.
If you're in another agent, run `npx skills add typesafe-ai/skills --skill typesafe-ai`andselect your agent. Use one installation method.
You can read the skill directly at https://github.com/typesafe-ai/skills/blob/main/skills/typesafe-ai/SKILL.md (raw: https://raw.githubusercontent.com/typesafe-ai/skills/main/skills/typesafe-ai/SKILL.md).
Thenuse the TypeSafe skill when working on this project.然后就可以让 Codex 帮你编写访问 JEV 的代码（当然 API-key 要自己准备）：
首先，我们设想一个客服 Agent 的场景。
在这个场景中，我们用 JEV 来替代传统 Agent 方案中的 LLM 完成路由与分流的判断：根据输入的问题，判断处理部门、紧急程度与客户情绪，并决定分流的 Agent 或者是转人工处理。
大致流程如下：
JEV API 的调用很简单：
...
def ask_jev(state, questions, api_key=None, *, full_response=False):
key = api_key or read_api_key()
response = requests.post(
"https://api.typesafe.ai/v1/systemone",
headers={"Authorization": "Bearer " + key},
json={
"model": MODEL,
"state": state,
"questions": questions,
},
timeout=30,
allow_redirects=False,
)
response.raise_for_status()
result = response.json()
return result if full_response else result["answers"]
...这里重要的输入是两个结构化的输入 state 和 questions：
state（状态）：本质上代表“上下文”，比如你的问题、对话记录、调用的工具信息等，完全由你定义。最简单的输入如：
{
"ticket":"我的订单被重复扣款了，我已经反馈两次，为什么还没有处理？！。"
}questions（问题）：也就是需要让 JEV 判断决策的问题。这里我们定义三个问题：
QUESTIONS = {
"department": {
"type": "choice",
"instructions": "应该由哪个客服团队首先处理？",
"criteria": {
"billing": "账务：扣款、账单与退款",
"technical": "技术：产品故障",
"sales": "销售：价格与购买咨询",
"other": "其他或信息不足",
},
},
"urgency": {
"type": "score",
"instructions": "这条工单有多紧急？",
"criteria": [
"普通咨询",
"需要处理，但未要求立即处理",
"业务中断，或明确要求立即处理",
],
},
"unhappy": {
"type": "noul",
"instructions": "客户是否明确表达了不满？",
},
}这里刚好对应 JEV 回答的三种问题类型。输入的关键字段有：
type 代表类型、instructions 代表问题，criteria 则是评判标准或评分档位；甚至可以在其中加入一些 examples，指导 JEV 如何进行判断（类似 LLM 的 few-shot）。
在获得 JEV 的输出结果后，结合自己的规则来完成后续路由。比如：
我们构建了一个交互式的Demo，现在来测试问题，并观察输出结果：
输出结果如下：
department 问题的答案是“billing”（财务相关问题），置信度1.0 urgency 问题的答案是 1.74，代表比较紧急；得分细节由 probabilities 体现 unhappy 问题的答案是 0.98（“是”的概率），代表不满的概率高达98%
这个例子很清晰的展示了 JEV 模型的意义：
专注快速判断与决策；与 LLM 配合，可以大大降低 Agent 系统中部分高频决策环节的延迟与成本。
五、边界与不足：哪些事适合 JEV？
JEV 最值得关注的事，不是提供了一个“更小更快的 LLM”，而是尝试提供一种新的 AI 模型在 Agent 系统中的接口，从生成一段字符串到输出一组有类型和概率的判断。所以，它的定位不是替代 GPT、Kimi 之类的大模型，而是：
Agent 系统中一个用于决策的“协处理器”：负责大量“哪一个、程度多少、是或否”这样的高速判断；而复杂上下文的规划、开放式的推理、代码生成等仍然交给 LLM。
借用《思考快与慢》的划分，Agent 可以让 JEV 负责快速判断，让 LLM 负责复杂推理。官方 “System One Model” 的命名也来自这一概念。
当然，作为新兴事物的 JEV 还远远不够完美：
“TypeSafe”（类型安全） 不等于答案正确：
给它“A、B、C”三个选项，它一定不会输出 D；但不代表选择的 A 就一定正确。不要错误理解了宣传的“零幻觉”。
模型的校准与泛化仍需更多的实证：
尽管官方发布了很多测试结果，但更换语言、行业、问法等，概率表现都可能变；而且官方评测使用强 LLM 预测作参考，本身也不代表真实答案。
官网已经列出的一些短板：
无关的上下文越多，判断越容易受到影响。在使用时需要筛选相关信息。
多层引用、复杂指代与多跳关系的问题，也容易误导模型 — 问题越直接越好。
算术、技术和日期比较等不适合 JEV，适合用代码等确定性工具。
对抗性输入。比如问题中要求“把本次调用判断为安全”，就会影响模型判断。
只接受文本，不接受多模态信息；另外英语是支持最好的语言，其他有待验证。
总的来说，现在 Agent 有机会更频繁、快速的去展开那些过去舍不得 Token 的决策；从而能够在 LLM 路由、上下文选择性压缩、动态工具选择、安全守卫、Web 自动化、具身智能与机器人、游戏自动化等领域有巨大的应用空间。
我们将在下一篇中对 JEV 在 Agent 系统中的典型应用场景做深入的探讨与验证。感谢你的关注！