TypeSafe AI 与 Jev：一种面向软件决策的 AI 模型

大语言模型很擅长写东西，却不一定擅长成为软件系统里的一个稳定零件。

当程序只是想知道“一封邮件应该分到哪个队列”“这条消息有没有退款诉求”“这次操作风险有多高”时，常见做法仍然是让大语言模型生成一段文字或 JSON，再由程序解析、校验和重试。TypeSafe AI 选择了另一条路线：不让模型生成文字，而是让模型直接返回一个受类型约束的判断。

这个模型叫 Jev。TypeSafe AI 将其称为第一个 System One 模型。

Jev 是什么

Jev 是一个通过 API 提供的文本判断模型。一次请求由两部分组成：

state：模型需要判断的文本或 JSON 状态；
questions：程序预先定义的问题、候选项和评分标准。

模型不会写回复、解释理由或生成代码，只会针对每个问题返回固定结构的答案和概率。TypeSafe AI 当前提供三种问题类型：

Choice：从一组候选项中选择一个，例如把工单分到 billing、technical 或 sales；
Score：按照给定等级评分，例如平静、沮丧、愤怒；
Noul：回答一个是非问题，并返回“为真”的概率，例如这条消息是否明确提出退款。

多个问题可以共享同一份 state，由模型并行判断。程序拿到的不是一段需要继续解释的自然语言，而是可以直接用于条件分支、排序和路由的值。详细定义可以查看 TypeSafe AI 的原语文档。

可以把两类模型的差别简化成这样：

通用 LLM：输入 → 生成文字或 JSON → 解析和校验 → 执行动作

Jev：状态 + 预定义问题 → 类型固定的答案和概率 → 执行动作

因此，Jev 并不是另一个聊天机器人，也不是通用 LLM 的完整替代品。它更像一个能理解自然语言的分类器、评分器和路由器。

一个更直观的说法是：Jev 是一个聪明的 if 语句。普通代码可以判断 order.total > 100，却很难直接判断“这条消息是否愤怒”“这个请求该交给哪个部门”。Jev 被放在这些需要语义理解、但答案范围明确的分支条件里。

它填补了哪块空白

在 Jev 之前，软件通常用三种办法处理这类判断：

if、正则表达式或决策树很快、便宜且可预测，但遇到自然语言和模糊语义时容易变脆；
专用分类器也很快，却需要标注数据和训练，而且每个任务通常要维护一个单独模型；
通用 LLM 的结构化输出不需要重新训练，但底层仍在逐 token 生成内容，应用还要处理延迟、成本和校验。

Jev 位于它们之间：像 LLM 一样理解运行时提供的自然语言和问题，又像分类器一样，只在预先定义的答案空间中返回概率。它不是产品界面，也不接管整个 Agent 循环，而是隐藏在应用内部的一次判断调用。

这种位置也解释了它与 Agent 的关系。编程 Agent 仍然负责读代码、调用工具和完成任务；Jev 可以在执行命令前判断它是只读、可撤销还是破坏性的，或者在多个模型与子 Agent 之间选择下一条路径。模型负责判断，权限、动作和后果仍由代码控制。

类型安全不等于判断永远正确

TypeSafe AI 使用“零幻觉”描述 Jev，理解这句话的边界很重要。

如果一个 Choice 只允许 billing、technical 和 other，Jev 不会突然返回第四个不存在的部门。从接口层面看，它确实消除了自由文本模型常见的格式错误、无效枚举值和 JSON 修复问题。

但模型仍然可能在三个合法选项里选错一个。它解决的是输出结构的确定性，而不是语义判断永远正确。

Jev 会为 Choice 和 Score 返回完整概率分布及一个 confidence 值，Noul 则直接返回“是”的概率。置信度的价值在于让程序设计不同的处理路径：

高置信度、低风险 → 自动处理
中等置信度       → 补充信息或交给更强模型
低置信度或高风险 → 人工审核

这些概率是统计意义上的校准结果，并不保证单次预测正确。官方也建议从保守阈值开始，用自己的业务数据进行测试和调整，具体可参考置信度说明。

三种原语还有几个容易忽略的细节：

Noul 返回 0.5 表示模型认为“是”和“否”概率相同，也就是无法分辨，不表示对象处于“中等程度”；需要衡量程度时应使用 Score。
Choice 无论如何都要选择一个候选项。如果列表可能不完整，应提供 other、none_of_the_above 或 needs_review。单个 Choice 最多支持 255 个选项。
Score 至少需要 2 个、最多支持 10 个有序等级。返回的 score 是各等级编号的概率加权位置，可以用于阈值或排序，但不应被当成精确测量值。
问题 ID 只用于程序映射，不会发送给模型。即使字段名已经叫 refund_requested，完整问题仍然必须写进 instructions。
Score 的等级最好描述可以观察的情形，例如“功能损坏，但存在替代方案”，而不是只写“中等严重”。

具体限制和响应字段见 Choice 文档与 Score 文档。

适合放在哪些地方

Jev 最适合答案空间有限、需要大量重复执行的快速判断，例如：

客服工单、邮件和文档分类；
用户意图识别和工作流路由；
垃圾信息、个人信息或风险信号检测；
Agent 的工具选择和下一步动作选择；
RAG 文段相关性判断；
按明确规则评估情绪、严重程度或内容质量；
先做低成本筛选，再把不确定样本交给通用 LLM 或人工。

它不适合生成文章、回复、摘要和代码，也不适合开放式问答与复杂规划。当前版本只接受文本、JSON 对象和文本数组，不支持图片、音频或视频。

官方公开的 Jev 1.13 已知局限还包括：

对指令的理解比较字面化；
不擅长数学、精确计数和日期比较；
多层间接推理会降低准确率；
状态中无关内容过多时会受到干扰；
对提示注入和其他对抗性内容并非天然免疫；
不保证分别提出的正命题与反命题在概率上严格互补。

这些限制也说明了一种更合适的分工：能由代码精确计算的事情继续交给代码，开放式生成与复杂推理交给通用 LLM，Jev 只负责其中边界明确但需要语言理解的判断。

一次把独立问题问完

Jev 有一个与常见 LLM 工作流不同的设计习惯：只要多个问题依赖同一份 state，就尽量放在一次请求中并行计算，即使其中一些答案最后可能用不上。TypeSafe 将这种模式称为 speculative fan-out。

例如客服分诊可以同时询问所属部门、退款诉求、Bug 严重程度、复现步骤和用户情绪。如果工单最终被判断为功能建议，代码直接忽略 Bug 严重程度即可。这样做会增加各问题自身的少量 token，但不需要反复发送相同的长 state。

官方当前展示的一个特定长文档实验中，13 个问题合并请求比 13 次独立顺序请求便宜 11.5 倍、快 9.6 倍，答案没有发生实质变化。这个倍数高度依赖共享状态的长度和对比方式，不能当成所有工作流的固定收益；真正值得采用的是“共享状态只发送一次”的设计原则。并行问题说明

只有后一个问题确实依赖前一个答案时，才需要第二次请求，例如先选出候选文档，再读取候选全文进行判断。如果问题本来就能针对原始状态提出，应优先在第一次请求中一起完成。

价格、速度与当前成熟度

截至 2026 年 9 月，公开模型为 Jev 1.13。官方标价是每百万输入 token 0.042 美元，输出免费；单次请求总上下文上限为 64K token，其中 state 加最长问题不得超过 32K。公开限流为每秒 25 万 token 和每分钟 1,200 个请求，但官方说明这些限制仍可能动态调整。模型与价格页面提供了最新数值。

TypeSafe AI 在官网给出的最高对比结果是速度提高 193.6 倍、成本降低 444.6 倍。不过这些数字来自公司自己的特定工作流评测，不应该直接外推到所有任务。

一项在 Jev 发布后进行的第三方小规模测试得出了更温和的结果：Jev 在测试任务中确实比几个小型通用模型更快、更便宜，准确率与其中的小模型接近，但没有超过参与比较的更强模型。由于产品和外部评测都刚刚出现，这些结果更适合作为线索，而不是最终结论。

Jev 于 2026 年 9 月 15 日正式发布。产品上线时间很短，SDK、服务容量、模型行为和生态仍在快速变化。生产环境最好固定具体版本，例如 jev-1.13.0，而不是始终跟随 jev-latest。移动别名升级后，同一请求的答案和置信度分布可能改变。

TypeSafe AI 同期宣布获得由 DCVC 领投的 4000 万美元种子轮融资。DCVC 的公告能说明团队有资金继续建设模型和推理基础设施，但融资规模本身不能证明模型准确或服务已经成熟。

数据如何处理

TypeSafe AI 表示不会使用客户输入训练或微调模型，也不会把输入披露给服务提供商以外的第三方。但普通账户的隐私政策没有承诺统一的即时删除期限，只表示会在提供服务或业务所需的合理期限内保留数据。服务在美国托管和处理。

零数据保留是企业客户可申请的选项。涉及个人信息、商业机密或受监管数据时，应在接入前确认具体合同、数据处理协议和保留策略，而不能只依据“不用于训练”这一项承诺。

用 Python 调用 Jev

先在 TypeSafe Console 创建 API Key，然后安装官方 Python SDK：

pip install typesafe-sdk
export TYPESAFE_API_KEY="你的密钥"

官方包名是 typesafe-sdk，不是 typesafe-ai。后者在 PyPI 上是第三方创建的重定向包。

下面的例子同时判断工单所属部门、是否要求退款以及紧急程度：

from typesafe_sdk import Choice, Noul, Score, TypeSafeClient

ticket = {
    "message": "我被重复扣款了，请尽快退款。",
    "customer_tier": "standard",
}

with TypeSafeClient(model="jev-1.13.0") as client:
    result = client.system_one(
        state=ticket,
        questions={
            "department": Choice(
                instructions="哪个部门应该处理 `message`？",
                criteria={
                    "billing": "付款、扣款或退款问题",
                    "technical": "产品故障或技术问题",
                    "other": "以上均不符合",
                },
            ),
            "refund_requested": Noul(
                instructions="`message` 是否明确要求退款？",
            ),
            "urgency": Score(
                instructions="`message` 表达的紧急程度如何？",
                criteria=[
                    "不紧急，可以正常排队",
                    "比较紧急，希望尽快处理",
                    "非常紧急，需要立即处理",
                ],
            ),
        },
    )

department = result.answers["department"]

if department.confidence < 0.70:
    route_to_human(ticket)
elif department.choice == "billing":
    send_to_billing(ticket)
else:
    send_to_queue(department.choice, ticket)

任何语言也可以直接调用 POST https://api.typesafe.ai/v1/systemone。完整请求格式和错误响应见 HTTP API 文档。

直接调用接口时，常见错误包括密钥错误的 401、请求校验失败的 422、触发限流的 429，以及服务过载的 529。后两种情况应该执行有上限的指数退避重试；官方 SDK 的默认重试策略已经处理了它们。生产系统仍应设置超时、总重试预算和最终降级路径，避免服务过载时无限等待。

通过 Vercel AI Gateway 使用

Jev 也可以通过 Vercel AI Gateway 调用，模型 ID 是 typesafe-ai/jev。截至 2026 年 9 月 21 日，Gateway 提供三种接入方式：

使用 AI SDK 的 experimental_evaluate；
从任意语言调用原生 POST /v1/evaluate；
把现有 TypeSafe 客户端的 baseURL 指向 Gateway，保留原来的 systemOne 调用和响应格式。

这条路径适合已经使用 AI Gateway 的项目：调用记录、预算和其他模型可以放在同一个系统中管理，也能在支持的套餐中按请求开启 Zero Data Retention。需要注意，请求仍会经过 Vercel 和实际模型提供方；Gateway 的数据保留选项、套餐与价格也可能和 TypeSafe 直接 API 不同，接入前应分别核对。Vercel 接入说明

接入生产系统前怎么验证

一个类型正确的响应仍然可能是错误判断，所以 Jev 的接入重点不只是把 API 调通，还要验证它是否适合具体数据分布。

比较稳妥的流程是：

从真实业务抽取一批经过人工标注的数据；
先以影子模式运行，只记录结果，不改变原有业务流程；
分别统计准确率、误报、漏报，以及不同置信度区间的真实正确率；
在候选项中设置 other、unknown 或 needs_review；
对提示注入、否定句、混合语言、空字段和超长输入进行专项测试；
按动作风险设置不同阈值，而不是整个系统共用一个阈值；
记录模型版本、问题版本、完整概率和最终人工结果；
新模型发布后先回放验证集，再决定是否升级。

尤其是中文任务。官方说明英文是主要训练语言，其他语言虽然可以处理，但效果并不相同。中文工单或文档分类应建立独立验证集，不能直接套用英文任务的阈值。

怎样看待这种模型

TypeSafe AI 值得关注的地方，不只是速度或价格，而是它对 AI 软件接口的重新划分：模型不必包办整项任务，也不必总是生成文本。程序可以把一个工作流拆成许多小判断，把确定性规则写在代码里，再让专门模型处理需要语言理解的部分。

在这个意义上，Jev 更接近软件中的一个智能原语，而不是一个无所不包的智能代理。

目前最合适的使用方式，是把它当作一个快速、低成本、能够表达不确定性的判断组件。对于分类、路由和预筛选，它可能比调用通用 LLM 更自然；对于开放式生成、复杂推理和不可逆的高风险决策，则仍然需要其他模型、确定性规则和人工审核共同完成。