JEV 不陪你聊天，申请和接入都在这里

JEV 刚公开时，官网把一个数字顶在了最显眼的位置，单次工作流只用了 0.114 秒。

更奇怪的是，它不会陪你聊天，不写邮件，不生成代码，连一句解释都不给。你把一段状态和几个问题交进去，它只返回选择、分数和概率。

好家伙，一个主动放弃生成文字的模型，偏偏把自己叫成了新的模型类别。

TypeSafe AI 把它叫作 System One Model，可以先翻成人话理解，这是一个塞在软件流程里的判断函数。ChatGPT 和 Claude 擅长把话写出来，JEV 擅长回答哪一类、几分、是不是，然后让你的代码继续往下跑。

如果你正在做 Agent 路由、工单分流、内容审核、RAG 片段筛选，或者任何高频的小判断，这个方向确实值得看。本文不复读发布通稿，直接回答三件事，JEV 到底是什么，怎么申请，拿到权限以后怎么跑通第一条调用。

它不是一个更小的聊天模型

TypeSafe AI 的发布文把接口描述得很干脆，非结构化状态进，类型化概率决策出。

这里有三个关键词。

state 是要被判断的材料，可以是一封客服邮件、一段 Agent 运行轨迹、一条用户请求，也可以是整理过的 JSON 状态。

questions 是你预先定义的问题。JEV 不自由发挥，答案空间由你的代码先框好。

返回值不是作文，而是程序能直接消费的结果。目前官方提供三种问题类型。

• Choice 从固定选项里挑一个，同时返回每个选项的概率和置信度
• Score 按你定义的等级打分，也会返回概率分布和置信度
• Noul 判断一句话是否成立，返回 0 到 1 的概率

比如一封客户邮件进来，你可以在同一次请求里问它该交给售后、技术还是销售，客户有多着急，以及是否需要人工升级。三个问题彼此独立，并行得到答案。你的代码再根据业务规则决定下一步。

图中每个判断都很窄，最终动作仍由普通代码按规则组合。

这和让聊天模型输出 JSON 最大的差别，不是 JSON 长得更漂亮，而是答案类型在调用前就已经被限定。JEV 不会忽然写一段道歉信，也不会给你冒出一个 schema 之外的新部门。

但这里要替营销话术踩一脚刹车。

官网说零幻觉，严格讲指的是输出不会越过预定义的类型和选项，不是每个业务判断都绝对正确。类型安全保证的是接口，不是真相。一个格式完全合法的错误选择，照样是错误选择。

所以置信度才重要。官方文档建议把高置信度结果自动执行，中间区间进入确认或复核，低置信度直接交给人或备用系统。阈值不能抄示例，必须按动作风险和自己的数据校准。显示一个错误页面和批准一笔转账，显然不能用同一条线。

申请方式其实很直接

截至 2026 年 9 月 20 日，JEV 仍处于 early access。

申请入口在 TypeSafe AI 官网。点击 Join Waitlist 后会进入 Typeform 候补表。表单会询问你的使用场景等补充信息，提交后官方给出的提示是，他们会审核答案，并在可以提供访问权限时通过邮件联系。

这一步没有公开承诺固定审核时长，也没有一个付款后立刻开通的自助通道。申请时最值得写清楚的不是想体验新模型，而是你准备让 JEV 替软件做哪一种窄判断。

比较合适的描述是这样的。

我们有一个 Agent 工作流，需要把用户请求路由到搜索、数据库查询、人工确认三个处理器。希望用 JEV 返回固定选项和置信度，低置信度请求进入人工复核，并用历史标注数据评估准确率和阈值。

这个描述里有输入，有固定答案空间，有失败兜底，也有验证方法。它和 JEV 的产品形状是对得上的。

申请表里如果还有空间，可以再补三类信息。第一类是调用规模，大概每天多少条、每条状态多长、对延迟有没有要求。第二类是现有基线，你现在用规则、聊天模型还是人工做同一件事，成本和错误主要出在哪里。第三类是评估计划，准备拿多少条历史样本做离线回放，哪些错误可以容忍，哪些错误必须拦住。

这些内容不只是为了提高获批概率。它们会逼你提前回答一个更现实的问题，这个判断真的需要模型吗。金额计算、日期比较、字符串匹配能用普通代码解决，就别为了赶时髦多绕一层 API。只有规则写不干净、人工又能凭上下文快速判断的那一段，才是 JEV 最舒服的位置。

还有个容易被忽略的点，加入候补不等于已经拥有 API 权限。即使公开文档可以访问，Console 里的 Playground 和 Key 页面仍要以账号实际开通状态为准。没收到邀请前，不要照着第三方页面购买所谓的激活码，也不要把密钥交给代跑服务。新模型刚发布，名字周围通常比生态更早热闹起来，安全感还是得自己留着。

权限获批后，登录 TypeSafe Console，可以先在 Playground 里粘贴一段 state，添加一个 Noul 问题试跑。准备接入代码时，再到 Dashboard 创建 API Key，把它放进服务端环境变量 TYPESAFE_API_KEY。不要把 Key 写进前端代码或提交到 Git。

第一条 API 调用这样写

官方的 HTTP 入口只有一个。

export TYPESAFE_API_KEY="你的密钥"

curl -X POST https://api.typesafe.ai/v1/systemone \
  -H "Authorization: Bearer $TYPESAFE_API_KEY" \
  -H "Content-Type: application/json" \
  -d @- <<'EOF'
{
  "state": "用户要求删除生产数据库，但没有提供变更单号。",
  "model": "jev-latest",
  "questions": {
    "route": {
      "type": "choice",
      "instructions": "这条请求下一步应该走哪条处理路径",
      "criteria": {
        "allow": "低风险且信息完整，可以继续",
        "confirm": "需要用户再次确认或补充材料",
        "block": "高风险或缺少必要授权，必须阻止"
      }
    },
    "high_risk": {
      "type": "noul",
      "instructions": "这条请求是否包含不可逆或高风险操作"
    }
  }
}
EOF

返回里，route.choice 会是 allow、confirm 或 block 之一，route.probabilities 给出三个选项的分布，route.confidence 把分布压成一个 0 到 1 的置信度。high_risk.noul 则是高风险判断为真的概率。

真正的系统控制权仍在你的代码里。比如只有 route.choice 为 allow 且置信度超过你验证过的阈值时才继续，删除、转账、发外部消息这类动作即使高置信度也要保留确认。JEV 负责模糊判断，权限和副作用仍由确定性代码负责。

如果更习惯 Python，官方 SDK 要求 Python 3.10 以上。

pip install typesafe-sdk

from typesafe_sdk import Choice, Noul, TypeSafeClient

client = TypeSafeClient()

response = client.system_one(
    state="用户要求删除生产数据库，但没有提供变更单号。",
    questions={
        "route": Choice(
            instructions="这条请求下一步应该走哪条处理路径",
            criteria={
                "allow": "低风险且信息完整，可以继续",
                "confirm": "需要再次确认或补充材料",
                "block": "高风险或缺少必要授权，必须阻止",
            },
        ),
        "high_risk": Noul(
            instructions="这条请求是否包含不可逆或高风险操作",
        ),
    },
)

print(response.answers["route"].choice)
print(response.answers["route"].confidence)
print(response.answers["high_risk"].noul)

官方 Quick Start还提供了 Score 示例。第一次接入，我反而建议少问一点，先用一个 Choice 或 Noul 跑通全链路，再慢慢加问题。每一个问题都应该是一位熟悉业务的人看完状态后，几秒钟能做出的单一判断。

哪些事不要交给它

TypeSafe 自己给 jev-1.13 写了一页已知缺陷，这页比发布会数字更值得读。

它不擅长精确计算，不可靠地计数，不应该替代码比较日期，也不适合多跳推理。状态里塞太多无关内容会拖累准确率，对抗性内容也可能影响判断。它按字面回答你写下的问题，不会总能猜中你脑子里的真实意图。

还有一条很关键，它不负责生成文本。你可以硬把词表做成一次次 Choice，逼它一个词一个词往外选，但官方明确说这样效果差，也会很慢。想写邮件、代码、报告，继续用生成模型。

所以我更愿意把 JEV 看成聊天模型旁边的一层，而不是替代品。

生成模型负责提方案、写内容、调用复杂工具。JEV 放在旁边，负责路由、筛选、打分和门禁。普通代码负责权限、金额、日期、计数和最终副作用。三个角色各干各的，系统反而更容易控制。

至于官网的 193.6 倍速度、444.6 倍成本优势，TypeSafe 也写了限定条件。这些数字来自他们自己的四个 System One 工作流评测，而且官方承认属于真实收益的高位区间，评测又由自家模型能力团队设计，可能存在偏差。当前公开价是每百万输入 token 0.042 美元，输出免费，官方给出的端到端延迟范围是 70 到 500 毫秒。

图里的 JEV 位于左侧低成本区，但这仍是厂商自测，不是本文独立复现。

数字很漂亮，但先别拿它做预算承诺。等拿到权限，用你自己的状态长度、问题数量、并发量和人工复核率跑一轮，才知道这条新航线能不能进生产。

JEV 最有意思的地方，不是它又把模型做大了一圈。它反而砍掉了最显眼的能力，只留下软件最缺的那一小块判断。

有时候，少会一点，才更像一个可靠的部件。

如果让你把现有 Agent 流程里的一个判断先交给 JEV，你会选路由、风险门禁，还是上下文筛选？