Jev：当模型不再生成文本，Agent 的决策链会发生什么？

在多数 Agent 系统中，大语言模型承担了两类不同任务：一类是理解目标、制定计划和生成内容；另一类是工具选择、状态判断、风险分级等结构化决策。后者通常只有有限答案，却仍要经过自回归生成、JSON 解析和字段校验。Jev 试图解决的，正是这部分工程冗余。

从“生成答案”转向“计算决策”

TypeSafe AI 将 Jev 定义为 System One 模型。它接收文本或 JSON 形式的 state，以及一组预先声明的问题，不生成自由文本，而是直接返回受类型约束的概率化结果。

公开接口包含三种决策原语：

Choice：从候选集合中选择一项，同时返回概率分布和置信度；
Score：在有序等级上评分，返回加权分数、等级分布和置信度；
Noul：判断一个命题成立的概率，结果位于 0～1 之间。

一个简化请求可以写成：

<span>{</span>
  <span>"model"</span><span>:</span> <span>"jev-latest"</span><span>,</span>
  <span>"state"</span><span>:</span> <span>{</span>
    <span>"ticket"</span><span>:</span> <span>"用户反馈付款成功但订单仍未创建"</span><span>,</span>
    <span>"retry_count"</span><span>:</span> <span>2</span>
  <span>}</span><span>,</span>
  <span>"questions"</span><span>:</span> <span>{</span>
    <span>"route"</span><span>:</span> <span>{</span>
      <span>"type"</span><span>:</span> <span>"choice"</span><span>,</span>
      <span>"instructions"</span><span>:</span> <span>"选择后续处理路径"</span><span>,</span>
      <span>"criteria"</span><span>:</span> <span>{</span>
        <span>"retry"</span><span>:</span> <span>"重新执行订单创建"</span><span>,</span>
        <span>"manual_review"</span><span>:</span> <span>"转人工核查"</span><span>,</span>
        <span>"close"</span><span>:</span> <span>"直接关闭工单"</span>
      <span>}</span>
    <span>}</span><span>,</span>
    <span>"risk"</span><span>:</span> <span>{</span>
      <span>"type"</span><span>:</span> <span>"score"</span><span>,</span>
      <span>"instructions"</span><span>:</span> <span>"评估操作风险"</span><span>,</span>
      <span>"criteria"</span><span>:</span> <span>[</span><span>"低"</span><span>,</span> <span>"中"</span><span>,</span> <span>"高"</span><span>]</span>
    <span>}</span>
  <span>}</span>
<span>}</span>

这与要求通用 LLM “严格输出 JSON”并不完全相同。后者仍在生成字符串，结构约束通常由解码器或调用层补充；Jev 的产品接口从一开始就将输出空间限定为声明过的类型和候选项。它不会返回候选集之外的字符串，但仍可能选错，因此“不会产生非法输出”不能等同于“不会产生错误决策”。

Jev 在 Agent 架构中的位置

Jev 更适合被放在执行层，而不是替代规划模型：

用户目标
   ↓
通用 LLM：理解、规划、拆解任务
   ↓
Jev：工具路由、动作选择、风险评分
   ↓
策略层：阈值判断、权限校验、人工复核
   ↓
工具或业务系统执行

这种分层的价值主要体现在三个方面。

第一，减少不必要的文本生成。工具路由、意图分类等任务的答案空间有限，自回归生成并不是必需条件。第二，降低接口适配成本。调用方可以直接消费概率分布，而不是反复处理 JSON 格式错误、字段缺失和枚举越界。第三，为“停止执行”提供依据。高置信结果可自动处理，中等置信结果可要求确认，低置信结果则转人工或回退到通用模型。

需要注意，Jev 的 confidence 是由概率分布集中程度计算出的汇总指标，不代表“0.9 就必然有 90% 的准确率”。阈值必须在具体业务数据上验证。支付、删除、权限变更等不可逆操作，也不应仅凭模型置信度直接执行。

性能数字应该怎样看

TypeSafe 公布的典型延迟为 70～500 毫秒，并给出最高约 193 倍加速、444 倍成本优势等结果。但这些数字来自厂商工作流评测，任务、输入长度、对照模型和结构化适配方式都会影响结论，不能外推为通用 AI 能力对比。

更有意义的评估方式，是在自己的决策链上同时测量：

端到端 P50、P95 和 P99 延迟；
决策准确率、NLL、Brier Score 与校准误差；
不同置信阈值下的自动化率和误执行率；
输入增长、候选项增多及非英语场景下的性能变化；
与“小模型分类器”和“LLM 结构化输出”的总成本差异。

公开信息仍存在边界

目前 Jev 的底层架构、参数量、训练数据和 RLCD（Reinforcement Learning for Calibrated Decisions）的具体算法尚未公开。社区已经出现基于开源模型的 Jev 风格复现，但其中的输出头、损失函数和缓存分叉设计属于复现者的工程假设，不能视为官方实现。

此外，Jev 当前只接受文本模态输入；state 可以采用字符串、对象或数组表达，但 JSON 结构本质上仍会计入文本 token。单次请求的总上下文上限为 64K token，state 与最长问题合计另受 32K token 限制；Choice 最多支持 255 个候选项。官方也提示，非英语能力和长输入下的准确率波动需要在真实业务数据上单独验证。它不能生成解释、代码或摘要，更不适合承担需要多步推理和动态发现答案空间的任务。

结语

Jev 的关键意义，不在于提出了一个可以取代 LLM 的新模型，而在于重新划分 Agent 的模型职责：通用模型处理开放问题，决策模型处理封闭选择，业务策略负责最终约束。

对于工程团队而言，是否采用 Jev 不应由“快多少倍”决定，而应先回答三个问题：系统中是否存在大量高频、有限候选的判断；这些判断是否需要可消费的概率输出；错误决策能否通过阈值、权限和人工复核被控制。只有答案明确，Jev 这类模型才可能从概念变成可落地的基础组件。

参考资料

TypeSafe AI：《Introducing System One Models and Jev》
TypeSafe AI Docs：System One API Reference
TypeSafe AI Docs：Confidence
TypeSafe AI Docs：Models and Limits