Skip to main content

Jev 模型是什么？System One 决策模型与 Agent 新基建

· 10 min read

Jev 是一种 System One 决策模型——不生成文本、只输出结构化决策,定位是嵌入 Agent 流水线做高频、低延迟的分类与路由。

  • 定位:TypeSafe AI 推出的非 LLM 决策模型,创始人 Diogo Almeida 是 ChatGPT/RLHF 共同发明人
  • 三种原语:Noul(yes/no 概率)、Choice(最多 255 项选一)、Score(有序评分),一次请求并行评估
  • 输出形状:schema-first 的 typed value + 概率分布 + 置信度,程序直接消费,零格式幻觉
  • 速度与价格:端到端 70-500ms,输入 $0.042/1M token,输出 token 免费
  • 不是 LLM 替代品:不能写代码、写文章、做复杂推理,只覆盖「已知答案空间的快速判断」
  • 典型场景:Agent 模型路由、Skill 选择、UI 元素定位、上下文压缩、工具调用前的风险评分
  • 评测边界:官方「193x 更快」来自自家工作流基准,独立复现有限,需在自己负载上验证
  • 已有接入:Vercel AI Gateway、Cloudflare、OpenRouter、LangChain 集成均已支持

为什么需要 System One 模型​

过去两年,Agent 流水线里有一个被严重浪费的开销——把 LLM 当成万能 if 用。

「这张工单该交给哪个团队？」「这段上下文要不要保留？」「这个工具调用该不该让 agent 执行？」「这条 LLM 输出是不是有 prompt 注入？」——这些问题的共同特征是:答案空间已知、需要快速判断、不需要创造性生成。但过去没有专门为这种决策设计的模型,只能用 LLM 写 JSON,等几秒 token 输出,解析,校验格式,重试。

Jev 的切入点就是这一层:把「已知答案空间的快速判断」从 LLM 流水线里切出来,给一个专门的、廉价的、低延迟的决策原语。模型名字取自经济学里的 Jevons Paradox(效率提升反而扩大总消耗)——TypeSafe 想表达的是:不是替换 LLM,而是让 LLM 更专注于它擅长的部分,从而让整个 AI 系统的「决策量」整体上升。

三种决策原语:Noul / Choice / Score​

Jev 把所有判断抽象成三种问题类型:

原语用途输出
Noulyes/no 判断(是否需要人工审核、是否有恶意输入、是否符合规则)0-1 的概率
Choice从已知选项里选一个(分类、路由、工具选择、模型选择)选中项 + 全分布概率 + 置信度
Score在有序刻度上评分(紧急度、风险等级、内容质量)分数 + 分布概率 + 置信度

三个原语的核心区别是「答案空间怎么描述」:

  • Noul:二元,概率即答案
  • Choice:离散,每个选项带概率,可看分布而不是只看 argmax
  • Score:有序连续,在自定义的 rubric 上落点

最关键的一点是一次请求可以并行问多个问题,对同一份 state 同时评估「分类」「紧急度」「是否需要人审」三个独立判断。TypeSafe 官方文档强调:加问题基本不增加响应时间,因为每个问题在同一轮平行采样里独立完成。这与传统 LLM 用 chain-of-thought 或多次 prompt 把多个判断串起来完全是两回事。

速度与价格:不是快一点,是快一个数量级​

官方公布的数字差异很大,要分清哪些是营销、哪些是结构性优势。

结构性优势(架构决定,基本可信):

  • 端到端响应 70-500ms:平行采样、不生成文本,不需要等 token 一个个吐出来
  • 输入 $0.042 / 1M token(约 $42 / 10 亿 token),输出 token 计量为零
  • 同一个 state 多问几个问题几乎不增加耗时

官方测试数据(需打折看):

  • 在 TypeSafe 自建的 4 个工作流上,Jev 比对照 LLM 快 193.6x、省 444.6x
  • 这 4 个工作流是 TypeSafe 团队自己写的,基准参考是 GPT-6 Astra + Fable 5.1 的平均预测
  • TypeSafe 自己承认「这些收益在实际负载里大概落在上限区间」
客观判断

架构层面的优势(快、平、低)是真的,因为 Jev 根本不生成 token。「193x 更快」这个具体数字别直接拿去做成本测算,先在自己的负载上跑几天,再决定要不要把 LLM 流水线里那批高频决策切过去。

不是 LLM 替代品:边界比能力更重要​

Jev 不能做的事,和它能做的事一样重要:

  • 不能生成文本:不能写文章、写代码、写邮件、回复用户——这些是 System Two 模型(传统 chat 模型)的活
  • 不能做精确计算:算术、日期比较、字符计数——交给代码
  • 不能跨多跳推理:不能链式思考、不能拆解复杂问题
  • 不能处理大量无关上下文:超过 ~32K token 后要先在代码里 retrieve / filter,不要把整页 HTML 塞进去
  • 不能直接吃图像/音频/视频:只接受文本和 JSON

所以 Jev 的正确定位是 Agent 流水线里的「决策层」,不是「取代 chat 模型」。在生产架构里:

LLM 负责「理解 + 规划 + 写」,Jev 负责「这一步要不要做 / 给谁做 / 有多紧急」,代码负责真正的执行。

嵌入 Agent 的五个高 ROI 场景​

Jev 现在已经接入 Vercel AI Gateway、Cloudflare、OpenRouter,LangChain 集成也已上线。结合 TypeSafe 文档和社区用例,真正高 ROI 的场景集中在五类:

1. 模型路由

把任务复杂度评分,根据分数路由到不同模型——便宜模型接 80% 简单请求,前沿模型只接疑难请求。LangChain 的 pi-jev-router 就是这个模式。

2. 工具调用前的风险门

agent 准备执行 shell、读写文件、发邮件前,先用一个 Noul 问「这个调用风险高吗」。高风险阻断,中风险让用户确认,低风险放行。这是把 prompt 注入防御从「事后审计」前移到「事前拦截」。

3. 上下文压缩

长 agent 会话里,历史工具结果要不要保留、要不要摘要、要不要丢——这本身是一个判断,而不是「全量丢给 LLM 总结」。

4. 客服工单分流

最经典的 Choice 场景:从「账单/技术/销售/退款」里选一个。

5. UI 元素定位(Browser Use)

Browser Use 已经出了 jev-ultrafast 模式,用 Jev 在几十个候选 DOM 元素里快速定位目标。比让 LLM 自己读 HTML 再选要快一个数量级。

置信度才是真正的产品​

Jev 每个 Choice 和 Score 都返回三个值:选中项、概率分布、置信度。这三者要分开看:

  • 选中项:argmax,代码直接用
  • 概率分布:用于「如果选了第二会差多少」的对比,用于兜底逻辑
  • 置信度:TypeSafe 从分布形状算出来,反映「选出来的有多稳」

实战用法:

result = jev.choice(state=ticket, options=["billing", "technical", "sales"])

if result.confidence > 0.9:
    auto_route(result.choice)       # 高置信度,直接自动执行
elif result.confidence > 0.6:
    send_to_llm_review(state, result)  # 中置信度,让 LLM 再看一眼
else:
    queue_for_human(result)         # 低置信度,排队人工

阈值不是固定的——转账这种高副作用场景要 0.95+,推荐分类 0.7 就够用。不要把同一个阈值套到所有决策上。

当前阶段该怎么用​

Jev 在 2026-09-15 公开发布,目前在 early access 阶段,价格未公开承诺不补贴,模型权重未开源。

实际接入路径有几条:

  • 直接调官方 API:拿到 console key,POST 到 api.typesafe.ai/v1/systemone
  • 走 gateway:Vercel / Cloudflare / OpenRouter 都已上架,不用绑官方账号
  • LangChain 集成:装 langchain-typesafe,有 TypeSafeClassifier 直接 invoke
  • Claude Code skill:TypeSafe 提供了 /typesafe skill,粘贴 prompt 到 agent 里就能自动学会调用

工程上要注意:

  1. 先量后切:把现有 Agent 流水线里 LLM 处理的所有「选择题」列出来,挑出调用量最大的 1-2 个,先用 Jev 跑 shadow mode,对比准确率和耗时
  2. 不要试图让 Jev 做 LLM 的事:发现 Jev 答不对,先想想是不是题出错了——是不是把开放问题塞进了 Choice
  3. 置信度门槛要按副作用分级:转账、删文件、对外通信是高副作用,0.95+;分类、推荐、排序是低副作用,0.7+ 就够

一句话判断​

Jev 不是「更便宜的 LLM」,是 Agent 流水线里一直被 LLM 勉强填的那块空白——快速、结构化、已知答案空间的判断层。LLM 还是用来理解世界、规划任务、生成内容,Jev 用来在每一步做小而快的决定。

这个分层如果成立,Agent 架构会从「一个 LLM 包打天下」走向「System Two + System One + 代码」三层协作。下次设计 Agent 流水线时,值得多问一句:这一步是不是本来就不需要 LLM？

References​

  1. TypeSafe launches Jev, claiming faster, cheaper alternative to LLMs for AI automation —— The Frame, 2026-09-16
  2. TypeSafe AI 推出 Jev:面向软件自动决策的 System One 模型 —— AIHub, 2026-09-18
  3. TypeSafe AI's Jev Is Not an LLM — And That May Be the Point —— Yahoo Tech, 2026-09-18
  4. Jev: The System One AI Model That Decides Instead of Chats —— Wikiprompt, 2026-09-19
  5. Jev AI: TypeSafe's model for typed decisions —— 独立开发者平台, 2026-09-21
  6. TypeSafe AI - Introduction —— 官方文档