每天吃透一个 AI 知识点 — Jev 模型是什么？怎么用？

转载：小红书 AI产品赵哥

前言 🔖

最近几天，如果你关注 AI 圈，你的信息流一定被一个叫 Jev 的新模型刷屏了。这玩意儿，可以说是平地一声大炸雷，火得一塌糊涂：

36 小时，超过 14 万开发者涌入候补名单 (waitlist)。
LangChain、Vercel、Cloudflare 这些顶级的技术框架，在 3 天内就火速完成了集成。
48 小时内，社区里就出现了 6 个开源的复刻版本。

一个 AI 模型，能引起如此大的轰动，一定有什么颠覆性的东西？但奇怪异的是：它根本不会生成任何文本。

你没听错，它不是 ChatGPT 那样的作家，也不是 Midjourney 那样的画家。而是个，嗯，裁判。

你给它一堆乱七八糟的信息，再给它几个预设的选项，它只会告诉你：“选 A 的概率是 85%，选 B 的概率是 12%，选 C 的概率是 3%。”

我花了几天时间，把 TypeSafe AI (Jev 的母公司) 的官方文档、DataCamp 的技术分析、以及 LangChain 的集成博客看了一遍。今天，咱来聊一聊，Jev 是什么，怎么用。

特别是对于做 Agent 开发的人来说，理解 Jev，可能会改变你对 Agent 架构的认知。

一、Jev 到底是什么？一个快思考的 AI 裁判 🔖

Jev 是由一家名为 TypeSafe AI 的公司，在 2026 年 9 月 15 日发布的模型。它的创始人 Diogo Almeida，是前 OpenAI 的核心研究员，亲身参与了 InstructGPT 和早期 RLHF 的研发 —— 也就是 ChatGPT 背后那套核心的训练方法。

Diogo 在旧金山秘密研发了两年，一出山就同时宣布了两件大事：一笔 4000 万美元的种子轮融资，以及 Jev 这个颠覆性的模型。

Jev 的官方定位，叫做 “System One 模型”。

这个概念，源自诺贝尔经济学奖得主丹尼尔・卡尼曼的经典著作《思考，快与慢》。他把人类的思维分为两个系统：

系统二 (System Two)：是我们的慢思考系统，负责理性的、深度的、需要集中注意力的逻辑推理。比如，计算一道复杂的数学题，或者规划一次长途旅行。我们现在熟知的 GPT‑5.1、Claude Sonnet‑4‑6 这类大语言模型，扮演的就是系统二的角色。
系统一 (System One)：是我们的快思考系统，负责那些快速的、直觉式的、毫不费力的判断。比如，看到一张愤怒的脸，你瞬间就知道对方不高兴；听到一声巨响，你会下意识地转头。

Jev 做的，就是系统一的活儿。它追求的不是深度思考，而是快速的、可靠的、结构化的判断。

Jev 的工作模式非常简单：

你给它一段非结构化的信息，再给它一个用 JSON Schema 定义好的、结构化的问题，它就会通过一次计算，直接在你的选项上，分配出各自的概率。

Jev 的三种核心决策类型：

Choice (选择)：从你预定义的多个选项里，选出一个或多个。
Noul (是否)：给出一个是或否的概率。Noul 是 No 和 Null 的组合词，代表着一种非此即彼的判断。
Score (打分)：给出一个在特定范围内的分数。

【案例解析：智能客服中心的分诊台】

场景：一家银行的智能客服中心，收到一条来自用户的投诉：“你们这个 App 太垃圾了！我上个月的信用卡账单一直出不来，打电话也没人接，我要销户！”

你需要 AI 做出一系列快速判断，来决定下一步该怎么处理。

输入给 Jev 的信息：

非结构化信息：就是上面那段用户的投诉原文。
结构化问题：

{
  "type": "object",
  "properties": {
    "intent": {
      "type": "string",
      "enum": ["账单问题", "技术故障", "服务投诉"]
    },
    "urgency": {
      "type": "string",
      "enum": ["低", "中", "高", "紧急"]
    },
    "churn_risk": {
      "type": "number",
      "minimum": 0,
      "maximum": 1
    },
    "requires_human": {
      "type": "boolean"
    }
  }
}

Jev 的输出，直接就是一个结构化的 JSON：

{
  "intent": {
    "账单问题": 0.85,
    "服务投诉": 0.13,
    "技术故障": 0.02
  },
  "urgency": {
    "紧急": 0.92,
    "高": 0.07,
    "中": 0.01,
    "低": 0.0
  },
  "churn_risk": 0.88, // 客户流失风险打分，0.88 意味着非常高
  "requires_human": {
    "true": 0.95,
    "false": 0.05
  } // 是否需要人工介入
}

整个过程，耗时可能不到 200 毫秒。有了这份结构化的判断结果，后续的自动化系统就可以立刻做出决策：将这个工单，以 “紧急” 状态，直接路由给 “信用卡账单处理” 和 “金牌客户服务” 两个人工坐席。

二、Jev vs. LLM vs. 分类器：凭啥这么火？ 🔖

但是，这种判断任务，传统的大语言模型 (LLM) 也能做，传统的机器学习分类器也能做，Jev 凭什么能脱颖而出？

我们来看看它们之间的根本性差异：

🔹1. 传统 LLM (如 GPT‑5.1) 的做法

你让 GPT‑5.1 去做上面那个判断任务，它会先进行一番慢思考，然后一个字一个字地 (token by token)，生成一段自然语言的回答：

根据用户的描述，该投诉的主要意图是关于 “账单问题”，同时带有强烈的不满情绪，属于 “服务投诉”。问题的紧急程度为 “紧急”。根据用户 “我要销户” 的表述，其流失风险很高，建议立即进行人工干预。

问题在哪里？

慢：从思考到逐字生成，整个过程可能需要 3‑10 秒。在高频调用的场景下，这个延迟是无法接受的。
贵：生成这么多 token，都是要花钱的。
格式幻觉：你需要写一堆正则表达式或解析代码，去从这段文字里，提取出 “账单问题”、“紧急” 这些关键信息。但 LLM 的输出格式，并不总是 100% 稳定。它今天可能多一个换行符，明天可能少一个逗号，你的解析代码就可能会挂掉。

简单说，用 LLM 做判断，就像请一个小说家，来帮你做判断对错的选择题。他能做，但他会给你写一篇长长的解题思路，而不是直接给你一个 “A” 或 “B” 的答案。杀鸡用牛刀，又慢又贵又不稳定。

🔹2．传统分类器 (如：BERT) 的做法

传统的机器学习分类器，比如一个用 BERT 训练的文本分类模型，也能做这个事。

优点在哪里？

快：它也是通过一次前向计算，直接输出结果，速度很快。
稳定：输出的格式是固定的，不会有格式幻觉。

问题在哪里？

死板，缺乏通用性：它的标签空间（Label Space）是在训练时就固定死的。你训练了一个 “账单问题 / 技术故障 / 服务投诉” 的三分类器，现在业务发展了，你想增加一个新的分类 “产品建议”，对不起，你必须重新找数据、重新标注、重新训练整个模型。它无法应对动态变化的业务需求。

简单说，用传统分类器，就像定制了一把专用钥匙。它开某一把锁（特定任务）很快，但你想换一把锁，就得重新配一把钥匙。

🔹3．Jev 的做法：介于两者之间的平衡

Jev 在 LLM 的通用性和分类器的高效性之间，找到了一个平衡点。

通用性：和 LLM 一样，Jev 是一个通用的预训练模型。你不需要为每个新任务去重新训练它。你想增加一个新的分类选项？只需要在你的 JSON Schema 里，增加一个 enum 的值就行了。
高效性与稳定性：和分类器一样，Jev 不生成任何文本。它内部的并行采样器（Parallel Sampler），通过一次前向计算，就同时产出了所有判断的概率分布。这从机制上，彻底消除了格式幻觉。

💡 根据官方数据：
- Jev 比同类 LLM 快 40 到 200 倍；
- 便宜 40 到 400 倍；
- 输入价格是每百万 token 0.042 美元；
- 输出甚至免费；
- 单次查询的延迟，稳定在 70 到 500 毫秒之间。

更核心的区别：为 “校准” 而生的训练方法

Jev 的创始人 Diogo 指出，ChatGPT 背后的 RLHF 技术，强化的是符合人类偏好的回答。这种回答，不一定准确，但会让你觉得舒服、有共情能力。

而 Jev 采用了一种全新的训练方法，叫做 RLCD（Reinforcement Learning for Calibrated Decisions，基于校准决策的强化学习）。

什么是可校准（Calibrated）？

简单说，就是说到做到。当 Jev 说，它有 90% 的把握认为这是一个高风险用户时，那么在大量的同类事件中，它的判断准确率，就真的无限接近 90%。

这种校准能力，对于企业级应用，价值巨大。你可以非常自信地在你的代码里写下这样的逻辑：

const result = await jev.decide(input, schema);

if (result.churn_risk > 0.8) {
  // 如果 Jev 判断流失风险高于 80%，直接触发人工介入
  escalateToHumanAgent(input.userId);
} else if (result.churn_risk > 0.5) {
  // 如果风险在 50%-80%，自动发送一张安抚优惠券
  sendCoupon(input.userId, "SORRY_10_OFF");
} else {
  // 风险很低，让普通 Agent 按标准流程处理
  defaultAgent.handle(input);
}

你代码的每一步决策，都有了可靠的、量化的概率依据，而不再是基于对 LLM 模糊文本的猜测。

三、我们该如何使用 Jev？它在 Agent 开发中的核心价值 🔖

讲了这么多，我们到底该怎么用 Jev？它能为我们的 Agent 项目，带来什么实质性的改变？

💡 答案是：把 Jev 用在你的 Agent 工作流中，所有需要进行高频、低思考决策的节点上。

一个 Agent 在执行任务的过程中，其实要做大量这类微决策：

这个用户的请求，应该路由给哪个子 Agent（Sub‑agent）去处理？
这段 AI 生成的内容，是否包含敏感信息，需不需要进入审核流程？
这个用户的行为，触发了风控规则吗？是通过还是拦截？
当前这个工具调用失败了，我是应该重试、上报错误，还是直接中止任务？

在过去，我们通常会用一个 LLM（比如 GPT‑5.1）来做这些判断。这就像请一个博士生，来当十字路口的交通警察。能干是能干，但是太浪费了。（这里没有职业歧视哈）

而 Jev，天生就是为这些 “AI 交通警察” 的岗位而生的。

【案例解析：重构一个 AI 内容创作 Agent】原始架构（纯 LLM）

用户输入：写一篇关于 “AI 伦理” 的文章；
主 Agent（GPT‑5.1）：接收任务，开始思考，调用搜索引擎工具；
主 Agent（GPT‑5.1）：拿到搜索结果，开始写文章初稿；
主 Agent（GPT‑5.1）：写完初稿，再调用自己，进行一次自我审核；
主 Agent（GPT‑5.1）：审校完成，输出终稿。

这个架构的问题：每一步都依赖昂贵且缓慢的 GPT‑5.1，特别是第 4 步的 “自我审校”，效果往往不佳。

引入 Jev 后的新架构

用户输入：写一篇关于 “AI 伦理” 的文章；
Jev（路由判断）：接收任务，快速判断 →

{"topic": "严肃学术",
"requires_fact_check": true}

主 Agent（GPT‑5.1）：根据 Jev 的判断，接收到任务，并被告知这是一个需要进行事实核查的严肃话题。它专注地进行搜索和写作；
Jev（质量初筛）：主 Agent 写完初稿后，将初稿喂给 Jev，Jev 快速进行一次质检打分 →

{"clarity_score": 0.8,
"has_sensitive_content": false,
"plagiarism_risk": 0.1}

决策节点：如果 Jev 的打分都通过了阈值，任务结束。如果某项分低（比如 clarity_score <0.7），则触发一个更专业的 “编辑 Agent”（可以用 Claude Sonnet）来进行润色。

新架构的优势：

分工明确：
- 复杂推理和创作，交给昂贵的系统二 LLM；
- 高频的、结构化的判断（路由、质检），交给便宜、快速的系统一 Jev。
成本和效率大幅优化：大量的 LLM 调用，被 Jev 的廉价调用所取代。
可靠性提升：引入了独立的、基于概率的质检环节，而不是让 Agent 自己检查自己。

我记得一位 AI 领域的大佬曾说：“让模型生成自然语言，然后软件再去解析这段文字来提取结果，这种交互方式，本质上可能就是一种错误。”

Jev，可能正是对这种错误的修正。它提供了一种模型与软件之间，更直接、更高效、更可靠的沟通方式。

四、Jev 不会取代 LLM，但它会成为 Agent 的神经系统 🔖

最后，我们来做个总结：

Jev 是什么？ 一个极快、极便宜的 “系统一” 的 AI 模型。
它和 LLM / 分类器的区别？ 它兼具了 LLM 的通用性和分类器的高效性，并专为可校准决策而优化。
我们该怎么用它？ 不要再拿昂贵的通用大模型，去做那些高频、简单的分类和路由任务了。在你的 Agent 工作流中，所有需要快速做判断的业务节点前面，都放一个 Jev，把它当作你的 AI 交通警察。

92IT

Just love IT.

每天吃透一个 AI 知识点 — Jev 模型是什么？怎么用？