了解 Jev 之后，我开始重新思考 AI 是否总要生成文字

Jev 是什么？它能做什么？#

Jev 是 TypeSafe AI 推出的第一个 System One Model，定位为面向软件工作流的结构化决策模型。调用方提供当前上下文（state）和预先定义的问题，Jev 返回程序可以读取的答案及概率，供代码继续分支、排序或路由。它面向有限、明确的判断任务；TypeSafe 尚未公开 Jev 的完整模型架构和训练配方。

直观地说，Jev 回答的是应用预先定义好的有限问题：例如用户更可能需要哪类帮助、某项风险处于什么等级，或多个候选中哪一个更合适。对应到公开 primitive，可以用 Choice 做有限选项判断、Score 给有序等级评分、用 Noul 判断一个条件是否成立；应用再据此做意图路由、风险分流、候选重排，或把低置信度请求交给人工复核。

它的价值在于让结构化判断和概率直接进入程序，减少生成一段自然语言后再解析答案的步骤。但它不代替权限校验、业务规则或人工确认，也不保证每个判断正确；是否适用仍要用具体任务的数据验证。

最近读 TypeSafe AI 关于 Jev 和 System One Models 的资料时，我反复想到一个问题：如果软件最后只需要“选哪个”“风险多高”或“要不要转人工”，为什么我们常让模型先写一段话，再从文字里把答案解析出来？

我不是想给 Jev 做产品评测，也没有调用它或复现官方 benchmark。这篇文章是一次阅读后的学习笔记：我想把生成式模型、决策模型和 Agent 里的确定性代码放在同一张图上，看看它们分别适合承担什么工作。读完官方资料后，我更愿意把 Jev 看成一种不同的模型接口与优化方向，而不是“更小的 LLM”，也不是可以替换所有 LLM 的答案。

软件要的是判断，还是一段文字？#

LLM 的通用接口是文字。即使调用方要求 JSON，模型仍要把答案序列化成文本，软件再解析字段、校验格式、处理缺失值，然后根据结果执行分支。生成式模型很适合解释、写作、代码生成和开放式推理；但如果调用方最终只需要一个有限选项，这条路径可能绕了一圈。

TypeSafe 把 Jev 描述为面向软件决策的模型：给它一份 state（当前待判断的上下文）和带类型的问题，得到程序可以读取的结构化答案与概率。下面这张图比较的是两种外部接口路径，不是对两类模型内部网络结构的描述。

生成式接口把答案写成文本后再解析；决策接口将有限问题的类型化答案交给代码消费。

图 1：根据 TypeSafe API 的外部输入与输出契约整理。区别在于答案如何交给软件使用，不代表 LLM 不能输出 JSON，也不揭示 Jev 的内部网络。

LLM 的结构化输出能力确实在进步。JSON Schema、受约束解码和工具调用，都能让文本接口更可靠。Jev 所代表的差别，是 TypeSafe 把“返回预先定义的问题答案及其概率”当作产品接口的中心，而不是把自由生成的文字当成默认中间表示。两种接口可以共存，选择哪种应由下游真正需要什么来决定。

System One Models：TypeSafe 如何定义这类模型？#

TypeSafe 官方把 System One Models 定义为面向软件的快速、结构化决策模型；Jev 是它的第一个公开模型。它读取 state，对调用方定义的问题作答，结果可以由代码分支、排序或路由。官方文档说明当前 Jev 接受文本、JSON 对象或文本数组；图像、音频和视频输入尚不支持。System One 文档和产品介绍把它定位为软件工作流里的判断组件。

“System One”借用了 Daniel Kahneman《思考，快与慢》中快速、直觉式判断的命名。这里应该把它理解成 TypeSafe 对任务形态的类比：窄范围、低延迟、可被软件使用的判断；不能据此推断模型与人类的 System 1 认知机制相同。

TypeSafe 还用 **Machine-Native Intelligence（机器原生智能）**描述它的设计方向：让模型输出更像软件可以依赖的接口，重视结构、可靠性、可观察性、可测试性和速度。这是公司的产品主张，不是已经形成共识的学术分类。

目前官方资料公开了 API 契约和模型使用方式，但没有公开 Jev 的参数规模、完整网络结构、训练语料或完整训练配方。我不会据此猜它是 BERT 分类器、GPT 套壳、某种 Transformer 变体或蒸馏模型。API 不生成自由文本，也不等于内部计算没有语言表示或 Token；这些实现细节并未由当前公开资料证明。

三种训练目标，不等于三份完整配方#

TypeSafe 的 AI Primer 从三类 post-training（预训练后的训练方式）讲起。它把 RLHF 概括为根据人类偏好优化回答，把 RLVR 概括为使用可验证奖励训练可程序验证的输出，并把 RLCD——Reinforcement Learning for Calibrated Decisions，面向校准决策的强化学习——描述为训练模型返回决策和概率，而不是生成文本。

这三者适合用来比较“优化目标”，而不是推断网络结构。TypeSafe 的说明也没有给出足以复现 Jev 的 RLCD 数据、奖励/损失公式、采样细节或消融结果。下图是对官方 Primer 中训练目标关系的重绘，刻意停在这一层。

预训练语言模型之后，RLHF、RLVR 与 TypeSafe 所述 RLCD 分别突出不同的后训练目标。

图 2：根据 TypeSafe AI Primer 整理 / 重绘；这里只比较官方概述的优化目标，不表示三条路线互斥，也不描述未公开的训练流程。

这个区分对我有用，因为它把讨论从“Jev 是不是一个分类 API”推向了更深一层的问题：模型训练时被奖励的究竟是什么？如果目标是让人更愿意读模型回答，生成流畅文字自然重要；如果软件只需要一项可操作判断，那么概率、可校准的不确定性和固定输出空间可能更直接。

这并不说明 RLHF 或 RLVR 不适合自动化。RLVR 可以让模型在可验证任务上生成、检查并迭代；RLHF 仍是对话产品的重要目标。TypeSafe 的主张是，为某些机器内的判断任务，值得研究另一种目标。它是否在具体业务中更可靠，要由对应任务的数据和评测来回答。

Noul、Choice、Score：问题类型先被限定#

Jev 当前公开的三个 primitive（基础问题类型）是 Noul、Choice 和 Score。它们分别回答“是否”“选哪个”和“在有序量表上处于什么等级”。调用方要先定义问题与可能答案；模型在这个范围内返回判断。

Noul、Choice 和 Score 分别覆盖是否判断、有限选项选择和有序等级评分，并以不同字段返回结果。

图 3：按官方 primitives 与 confidence 文档整理。Noul 返回“是”的概率；Choice 和 Score 返回各选项或等级的概率分布及其 confidence。

这里有个值得小心的细节：Noul 返回的是命题为真的概率，例如 0.7 表示模型给“是”的概率，不另带 confidence 字段。Choice 返回候选选项的概率分布和被选选项；Score 则针对调用方定义的有序等级返回分布、评分和 confidence。官方提醒，Score 的数值是由等级分布得到的量，不应被误读成精确测量值。Primitives 文档给出了各类型的具体结构。

一项复杂决定往往包含多种子问题。与其让单次 prompt 同时判断意图、风险、权限、工具和是否升级，不如先问几个有边界的问题，再由代码组合结果。官方把这种模式称为 Atomic Questions, Composed in Code：模型提供判断，程序决定权重、规则、权限与动作。

举例来说，客服分流可以分别问“用户在请求什么”“是否涉及退款”“语气是否明显不满”。但如果第二个问题必须依赖第一个答案，代码就要决定依赖关系：可以一次预先问完，也可以等第一项结果回来再发第二个请求。分解得更细，确实更容易单项测试和调整；同时也增加了问题设计、策略代码和维护成本。

概率能帮助决策，但不是正确率保证#

概率输出对我来说是这套接口中最有意思的部分。普通业务代码通常只拿到 true/false 或一个标签；自然语言答案则可能说“我倾向于……”，但这个措辞本身不容易稳定接入程序。一个明确的概率分布给了应用更多选择：低风险时自动处理，接近边界时增加检查，高风险时要求人工确认。

不过需要区分两个术语。

**Calibration（概率校准）**谈的是一批预测的统计对应关系：如果许多预测都给出约 0.8，长期看相应事件应大约有 80% 发生。它不是说每一条 0.8 的答案都有八成把握，更不是正确性承诺。
Confidence在 TypeSafe 的 Choice 和 Score 响应里，是从概率分布形状计算出的摘要值；分布越集中，confidence 通常越高。它不是独立于概率分布之外的一项“正确率”。Noul 的 noul 本身就是“是”的概率，不另有 confidence 字段。Confidence 文档解释了这些字段的关系。

官方示例会用不同门槛处理查余额和批准转账，但示例数字不是通用默认值。门槛应该按错误代价、领域数据和实际验证结果来定。同一个 confidence，在“显示一个页面”和“执行资金转账”里不该代表相同的风险。

因此，“Probability First”并非把信任交给一个概率字段，而是把不确定性变成应用可以显式处理的输入。校准会不会随数据分布变化而漂移，非英语文本上的效果怎样，遇到开放集或故意构造的输入还能不能可靠表达未知，都仍需针对具体系统验证。TypeSafe 当前模型说明也提醒，英语是主要训练语言，中文等 CJK 输入需要在自己的内容上测试。当前模型说明

Speculative Fan-Out：并行不等于依赖消失#

一个 Agent 工作流如果按“先分类、再判断风险、再选工具、最后决定是否转人工”逐个调用模型，延迟会受到串行往返层数影响。TypeSafe 的 Speculative Fan-Out 模式建议把同一 state 上可能用到的独立问题放进一次请求，让它们并行回答，再由代码只采用当前路径相关的结果。

串行调用按依赖逐步等待；Speculative Fan-Out 将共享 State 上的独立问题放进单次请求，再由代码选取相关结果。

图 4：作者根据官方 Speculative Fan-Out 模式整理。并行问题各自独立；若问题真实依赖前一答案，应让代码发起后续请求。

它减少的是“必须等前一步返回才能提出后一步问题”的往返层数，不会消除业务依赖，也不会自动让所有判断同时适用。某些问题只有在特定意图下才有意义，可以先问但在代码里忽略无关结果；真正依赖前一答案的步骤仍要等结果。官方文档还提示，问题数增加会影响 Token 使用，只是响应时间通常变化不大。Fan-Out 文档

这让我把 Agent 的“智能”拆成了不同的工程职责：模型判断什么可能发生，代码决定可以做什么、何时做、失败时走哪条路。Confidence-Gated Routing可以把低置信度送去澄清或人工；Composite Scoring可以让代码按业务权重组合多项评分；Intent Routing可以把简单问题交给确定性逻辑、复杂问题送给专门 LLM。官方文档还展示了用类似方式为 LLM 输入输出加 review/block 路径、给检索候选重新评分的 cookbook 示例；这些是工程模式，不是安全保证或排序质量证明。

我现在怎样理解 Agent 和 AI Infra#

下面这张图不是 TypeSafe 的官方架构，而是我读完这些资料后对 Agent 职责的一种拆分。图想表达的不是“每个 Agent 都应该加一个 Jev”，而是：当系统里存在稳定、频繁、答案空间有限的判断时，决策模型可能成为 LLM 与普通代码之间的一个可替换部件。

作者对 Agent 系统中 LLM、决策模型、确定性代码、工具和人工升级关系的理解。

图 5：这是我对 Agent 系统职责分工的理解，不代表 TypeSafe AI 的官方架构。代码仍持有状态、权限、策略和执行控制。

我会把 LLM 留给开放式生成、解释、复杂推理和代码草拟；把决策模型考虑用于意图路由、风险评分、候选排序或 guardrail 初筛；把权限校验、金额计算、状态变更和高风险确认留在确定性代码与人工流程里。边界不是“哪种模型更聪明”，而是这一步的输出空间能否事先说清、错误代价如何承担、结果是否可测。

对 AI Infra 来说，这个视角也会改变观测重点。除了模型名、Token 和耗时，我希望系统还能记录：使用了哪个版本、问了什么类型的问题、返回的分布如何、应用用什么阈值做路由、最后执行了什么。这样的记录要遵守隐私边界，不等于把完整用户状态都写进日志。它能让排查问题时看见“模型判断”和“代码策略”各自做了什么。

从这个角度看，AI Gateway 未来也许不只管理模型调用，还要管理不确定性如何穿过系统：何时自动继续、何时切换模型、何时请求更多信息、何时交给人。这是我对架构演进的推测，不是行业已经确定的路线。

官方证据能说明什么，不能说明什么#

TypeSafe 在 2026 年 9 月 15 日发布 Jev 的早期访问公告，并公开了 workflow evals。官网宣传的 193.6 倍更快、444.6 倍更便宜，指向其自建的 System One 任务工作流评测，不应写成任何场景下都成立的性能结论。

官方评测页比较四种工作流，并使用 GPT-6 Astra 与 Claude Fable 5.1 生成的共识/平均结果作参考；TypeSafe 也披露了评测来自模型能力团队设计、比较对象与 wrapper 会影响结果等限制。它是厂商给出的证据，说明“结构化工作流值得测试”，但不是独立机构复现后的通用基准结论。发布文章与Workflow Evals都提供了评测方法与说明。

“Zero hallucinations”也需要限定语境。有限 schema 可以让返回值保持在约定类型和选项空间内，减少格式错误或凭空生成不存在的字段；但一个格式完全正确的 Choice 仍可能选错，概率也可能不适用于新的数据分布。Typed 不等于 correct，confidence 也不是事实核验。 对高风险操作，我仍会要求独立规则、权限检查、确认步骤和可回退路径。

我仍然保留的问题#

问题集合由谁定义？ 如果团队遗漏了“其他”“无法判断”或需要升级的选项，模型再稳定也只能在错误边界里回答。
校准能维持多久？ 新客户、新产品和新措辞会改变输入分布。阈值需要按线上数据持续检查，不能只在初始样本上调一次。
开放世界的未知如何表达？ 有限选择对已知类别很方便；当真实输入不属于任何候选时，模型需要一个设计良好的拒答、未知或转人工出口。
哪些问题真的适合 fan-out？ 同一状态上的独立判断可以并行，因果依赖和权限条件仍应由程序显式表达。
复杂推理由谁处理？ 数学、长程规划、代码生成、研究和解释仍可能需要通用生成式或推理模型。官方文档也建议把精确算术、日期逻辑交给代码，并为当前产品形态的局限做针对性测试。
实现细节仍未公开。 我目前能评价的是接口契约、产品主张和公开示例，不能评价 Jev 的完整模型架构、训练数据或 RLCD 配方。

不是所有智能都必须说出来#

我现在更愿意把 Agent 理解成一套由不同能力组件组成的软件：生成模型负责表达和开放式推理，决策模型给出有限问题的概率判断，确定性代码持有状态与控制权，工具完成外部动作，人工承担无法自动化或风险太高的部分。

Jev 让我重新注意到，语言是重要的智能接口，却不必是所有软件决策的中间表示。一个窄而清楚的判断，有时只需要返回类型、概率和不确定性，再让程序以可测、可审计的方式组合它们。至于这条路线能覆盖多少任务，仍要靠更多独立评测、真实工作负载和公开细节来回答。

不是所有智能都需要被说出来。有些智能，只需要做出一个足够可靠、可被软件使用的判断——并让系统知道什么时候不该照它行动。

JaisonG1n