最近，TypeSafe AI 发布的 Jev 引发了开发者社区的集中讨论。它的定位并不是“又一个更小的聊天大模型”，而是一种面向软件系统的 System One（系统 1）模型 ：接收当前状态和一组预先定义的问题，快速返回类型化答案、概率分布与置信度，让程序可以直接据此分支、路由或触发动作。
这篇文章综合 TypeSafe 官方文档、Eigent 的技术解读，以及社区对 Jev 的端侧复现和应用观察，系统说明 Jev 是什么、为什么快、如何减少结构化输出错误、适合哪些场景、有哪些局限，以及如何把它放进 Agent 和自动化系统中。需要特别说明的是：Jev 目前是闭源服务，具体模型结构、训练数据和 RLCD 的完整实现尚未公开；本文会把官方事实、厂商自报指标和社区推测分开表述。
一、Jev 是什么：把“判断”从文本生成中剥离出来
传统 LLM 的基本接口是“输入文本，生成文本”。即使我们只想知道“这个工单应该交给哪个部门”，也往往需要模型逐个 token 生成 JSON，再由程序解析、校验和兜底。Jev 采用了相反的设计：调用方先声明问题和合法答案空间，模型只在这个空间内进行判断。
可以把一次 Jev 调用抽象为：
\( (s, Q) \xrightarrow{\text{Jev}} (a, P, c) \)
其中，s 是应用提供的状态（字符串、JSON 或文本数组），Q 是类型化问题集合，a 是答案，P 是答案空间上的概率分布，c 是供程序使用的置信度。Jev 不负责写解释、代码或回复，而是把判断结果交还给确定性代码。
二、System One 与 System Two：Jev 在 AI 栈中的位置
“System One”借用了 Daniel Kahneman《思考，快与慢》中的概念。System 1 代表快速、直觉式判断；System 2 代表慢速、审慎的推理。映射到 Agent 架构中：
System 2（传统前沿 LLM） ：理解复杂目标、规划多步任务、生成代码和自然语言、处理开放式推理。System 1（Jev） ：分类、选择、评分、风险判断、工具路由、完成检测等高频且边界明确的局部决策。因此，Jev 不是 GPT、Claude 等模型的替代品，更像是软件里的“智能 if 语句”或快速决策层：复杂问题交给 System 2，局部判断交给 System 1。
三、Jev 的三种基本原语
TypeSafe 官方文档将 Jev 的问题接口归纳为三种原语。它们看起来简单，但正是“可约束、可校验、可被代码直接消费”的基础。
原语 回答的问题 典型输出 适合场景 Choice 从有限选项中选一个 选项、各选项概率、置信度 部门路由、工具选择、下一步动作 Score 在文字定义的量表上评分 连续或离散分数及分布 情绪、复杂度、风险、优先级 Noul 一个是/否问题 0 到 1 的概率 是否退款、是否危险、是否完成
Choice 的答案空间通常由调用方显式提供，官方资料提到最多可配置 255 个选项；Score 则允许模型在量表之间给出更细的数值，例如 1.4，而不是被迫四舍五入到某一档。多个问题可以在一次请求中并行评估，例如同时询问“应该由哪个团队处理”“客户有多生气”“是否明确要求退款”。
四、为什么 Jev 可能更快：从自回归生成到受限决策
1. LLM 的瓶颈：逐 token 生成
自回归 LLM 生成长度为 T 的答案时，需要重复进行多轮解码：
\( P(y_{1:T}\mid x)=\prod_{t=1}^{T}P(y_t\mid y_{<t},x) \)
每一步都要从完整词表中选择下一个 token。输出越长，延迟越高；如果还要求 JSON，就必须生成括号、键名、引号和字段值，任何一步出错都可能导致解析失败。
2. Jev 的思路：一次前向传播，直接对答案空间打分
在受限决策中，答案集合是已知的。模型可以对候选答案直接计算 logits，再在候选集合上做归一化：
\( p_i=\frac{e^{z_i}}{\sum_{j=1}^{K}e^{z_j}},\quad i\in\{1,\ldots,K\} \)
这里的 K 是候选答案数量，z_i 是对应分数。程序拿到概率最高的候选即可执行下一步，不必等待模型生成一段文本。
社区对 Jev 的端侧复现进一步提出了一个工程假设：可以把多个问题共享的 KV-Cache 广播给各个问题头，再对候选 token 做词表切片，从而将“多个字段的判断”并行化。这个解释与受限分类器的常见实现相符，但由于 Jev 权重和内部架构没有公开，它属于合理的逆向推测，不应当当作官方实现细节。
在底层逻辑上，Jev 彻底重构了模型的输入与输出范式：
输入端 ：结构化上下文（JSON） + 决策需求定义。Jev 的定位不是处理自然语言闲聊，而是接收结构化的上下文与调用方严格定义的决策需求（例如：从有限的候选动作集合中单选、判断某个布尔条件是否满足、或输出特定区间的分数等）。推理端 ：隐状态直接打分。Jev 彻底跳过了一个 Token 一个 Token 的自回归生成文本的过程 。它并不输出自由文本去拼出一个 JSON 字符串，而是直接利用模型内部隐状态对预设的类型化输出空间进行直接投影打分，一步到位输出结构化判定。训练端 ：RLCD（校准决策强化学习）。传统大模型普遍采用 RLHF（基于人类反馈的强化学习）一类的对齐训练，偏向于迎合人类的对话审美，常常导致模型为了“显得有说服力”而盲目自信、甚至编造胡话；而 Jev 采用的 RLCD（Reinforcement Learning for Calibrated Decisions） ，其核心思想是概率校准（Probability Calibration） ，让模型输出的得分具备严格的置信度含义，我们只要设定一个置信度的阈值，就可以筛除不确定的答案。由于 Jev 未公开具体的训练方案与技术架构的细节，这里尝试用开源的 Qwen3.5 9B 模型进行了复现。核心点：在结构化决策与分类场景中，字段候选值通常是有界的。所以我们无需让模型逐 Token 自回归生成文本，可以通过“KV-Cache 广播 + 词表切片”，将所有字段候选值的选择并行化为O(1)次批量前向传播，这样就可以成倍提升吞吐与响应速度。
传统 LLM 自回归生成在每一步都会在全词表（以 Qwen 3.5 为例，全词表包含 248,320 个 Token ，约 24.8 万）上进行采样，这赋予了模型“胡说八道”的自由度。Jev 模型将自由文本生成转化为封闭决策，仅在调用方提供的选项中进行选择 ，决策空间被严格约束在预定义集合内，模型从数学上就不可能产生未定义选项的幻觉。
传统 LLM 输出一个 JSON，需要逐 Token 吐出 {、"field_name":、, 等语法字符。模型一旦出现注意力衰减，就会漏掉字段、写错括号或者自行脑补多余的 Key。我们将模型的能力边界严格限定为“特征分类器”，剥离了其组织语法的职责；最后的 JSON 结构由宿主程序以确定性代码直接填装，使得 JSON 语法有效率 100% 保证，字段缺失率与语法错误降为绝对的 0。
传统 LLM 在自回归解码中，生成第 10 个字段时，输入不仅包含原始文档，还包含了前 9 个字段生成的输出。如果前面的字段存在微弱偏差，这个偏差就会污染 KV-Cache，引发自回归级联误差。通过 KV-Cache 广播 将各字段解耦，每一个字段的决策都是直接基于原始输入和 Schema 定义进行评估，字段与字段之间互不干扰，这样就切断了自回归误差放大链条。
3. 结构化输出错误为什么接近于零
如果模型负责生成 JSON，它需要同时承担“判断”和“语法组织”两项工作。Jev 则只负责在合法候选中做选择，最终 JSON 由 SDK 或宿主程序按照 Schema 组装：
\( \text{JSON}_{\text{final}}=\text{Serialize}(\text{Schema},\text{TypedAnswer}) \)
因此，“未定义选项”“漏字段”“括号不匹配”等语法型错误可以从生成环节被消除。这里的“0% 类型错误”是由输出约束和确定性序列化保证的；它不等于 0% 语义错误，模型仍可能在合法选项中选错。
五、RLCD 与概率校准：Jev 的核心价值不只是快
传统 RLHF 往往围绕人类偏好、可读性和对话体验优化；Jev 所强调的 RLCD（Reinforcement Learning for Calibrated Decisions，校准决策强化学习）则把重点放在“概率是否具有实际意义”上。
理想的校准意味着：在所有给出约 0.8 置信度的预测中，长期平均约有 80% 是正确的。一个常见的评估指标是期望校准误差（ECE）：
\( \mathrm{ECE}=\sum_{m=1}^{M}\frac{|B_m|}{n}\left|\mathrm{acc}(B_m)-\mathrm{conf}(B_m)\right| \)
其中，样本按置信度划分为多个区间 Bm ，比较每个区间的实际准确率与平均置信度。ECE 越小，说明概率越接近“可解释的风险信号”。
Choice 和 Score 通常返回完整概率分布。分布越集中，置信度越高；越平坦，说明模型更不确定。也可以用熵描述这种不确定性：
\( H(P)=-\sum_{i=1}^{K}p_i\log p_i \)
TypeSafe 文档强调，校准是大量预测上的统计性质，并不保证某一次回答一定正确。因此，置信度应该被当作“是否自动执行”的控制信号，而不是绝对真理。
RLCD 的具体原理：把“答对”与“知道自己有多确定”同时优化
TypeSafe 官方的 AI primer 明确了 RLCD 的目标：模型不生成文本，而是返回决策和概率；更高的概率应该对应更高的正确概率。官方公开资料目前没有披露完整的奖励函数、训练数据、模型头结构或优化超参数，因此下面分为“官方已确认”和“基于概率预测训练的工程解释”两部分。
官方已确认的训练目标
输出契约不同： RLHF 主要优化人类偏好的自然语言回复，RLVR 主要优化可验证任务的结果，RLCD 则优化类型化决策和校准概率。概率必须可解释： 一批预测中，给出 0.2 概率的事件应大约有 20% 发生，给出 0.8 概率的事件应大约有 80% 发生。面向软件使用： 概率不是展示给用户看的装饰，而是让代码决定自动执行、请求确认或升级人工的控制信号。不是单次正确率保证： 校准描述的是一组预测的统计关系，不能保证某一个样本一定正确。一个可理解的 RLCD 训练流程
从机器学习角度，可以把 Jev 的决策模型抽象成 pθ (a|x,q) ：给定状态 x 和问题定义 q ，模型参数 θ 输出各合法答案的概率分布：
\( p_{\theta}(a\mid x,q),\qquad a\in\mathcal{A}(q) \)
一次训练样本不仅包含“正确答案” y ，还包含该答案是否真实发生、是否满足业务结果等可验证 outcome。训练过程大致可以理解为：
构造决策样本： 从历史工单、工具调用、网页状态或人工标注中得到状态 x 、问题 q 、正确答案 y 和最终 outcome。产生候选概率： 模型对有限答案集合计算 logits，并通过 Softmax 得到概率分布。同时评价准确性与概率质量： 正确答案应获得较高概率；错误答案或不确定样本不能被赋予虚高概率。用强化学习继续优化： 把“决策正确”“概率与长期结果一致”“答案符合类型约束”等信号组合成奖励，更新策略模型。在独立校准集上验证： 检查 ECE、Brier score、可靠性曲线、选择性风险和不同场景的升级率，而不仅是 top-1 accuracy。奖励信号可能如何组成
TypeSafe 没有公开 RLCD 的精确 reward 公式。对“校准决策强化学习”最合理的工程化理解，是同时使用正确性奖励和概率评分规则。常见的概率损失包括对数损失：
\( L_{\mathrm{log}}=-\frac{1}{N}\sum_{n=1}^{N}\log p_{\theta}(y_n\mid x_n,q_n) \)
以及 Brier score：
\( L_{\mathrm{Brier}}=\frac{1}{N}\sum_{n=1}^{N}\sum_{k=1}^{K}(p_{n,k}-\mathbb{1}[y_n=k])^2 \)
在二分类 Noul 问题中，Brier score 可以简化为：
\( L_{\mathrm{Brier}}=\frac{1}{N}\sum_{n=1}^{N}(p_n-y_n)^2 \)
一个用于理解的组合目标可以写成：
\( L_{\mathrm{total}}=L_{\mathrm{decision}}+\lambda L_{\mathrm{calibration}}+\beta L_{\mathrm{constraint}} \)
其中 Ldecision 衡量是否选对，Lcalibration 衡量概率是否与实际结果一致，Lconstraint 则惩罚非法选项、类型错误或违反 Schema 的输出。上式是解释 RLCD 的概念模型，不是 TypeSafe 已公布的内部公式。
RLCD 与 RLHF、RLVR 的区别
方法 主要优化对象 典型奖励 适合的输出 RLHF 人类偏好、可读性、遵循指令 偏好模型分数 聊天回复、解释、写作 RLVR 可验证答案或推理结果 数学/代码测试器是否通过 推理、数学、代码任务 RLCD 决策正确性与概率校准 结果正确、概率评分合理、输出受约束 Choice、Score、Noul 等软件决策
这也解释了为什么 RLHF 模型可能“说得很像正确答案”，却不适合直接承担自动化决策：它被奖励的是让人满意的表达，而不是让概率在长期统计上可信。RLCD 的目标是让模型在不确定时保留不确定性，而不是用流畅语言掩盖信息不足。
如何测量 RLCD 是否真的有效
准确率： 答案是否选对，适合衡量决策能力，但不能单独说明置信度是否可信。ECE： 概率分桶后比较平均置信度与实际准确率。Brier / Log loss： 同时惩罚错误答案和过度自信。可靠性曲线： 横轴是预测概率，纵轴是实际发生率，理想情况接近对角线。选择性风险： 只自动执行高置信度样本时，错误率是否显著下降。覆盖率—风险曲线： 在自动处理更多样本与保留较低错误率之间寻找平衡。例如，系统可以定义自动执行集合：
\( S_{\tau}=\{x:c(x)\ge\tau\} \)
然后计算该集合上的选择性风险：
\( R(\tau)=\Pr(\hat{y}\ne y\mid x\in S_{\tau}) \)
如果提高阈值 τ 后，自动处理覆盖率下降但风险稳定下降，说明置信度可以作为有效的治理开关。真正上线前，还应按业务动作分别校准阈值，而不是全系统共用一个数字。
六、最重要的工程模式：置信度门控与级联路由
一个可靠的 Jev 工作流通常不是“模型说什么就执行什么”，而是让代码根据置信度和操作风险分流：
准备状态：用户消息、页面元素、交易记录、策略规则或工具结果。 并行提出多个 Choice、Score、Noul 问题。 读取答案、概率分布和置信度。 由确定性代码执行阈值判断。 高置信度且低风险时自动执行；中等置信度时请求确认或补充信息；低置信度或高风险时升级人工或调用更强的 System 2 模型。 可以形式化为：
\( a=\begin{cases} \text{自动执行}, & c\ge\tau_{\text{auto}} \land r\le r_0 \\ \text{请求确认/补充信息}, & \tau_{\text{review}}\le c<\tau_{\text{auto}} \\ \text{升级人工或 System 2}, & c<\tau_{\text{review}} \end{cases} \)
阈值不应只有一个。只读操作可以使用较低阈值；删除、支付、下单、发送邮件等不可逆操作应使用更高阈值，并配合人工确认。
七、Jev 的典型应用场景
Browser Use / Computer Use： 先扫描真实存在且可交互的 DOM 或无障碍节点，再让 Jev 从候选动作中选择点击、输入、滚动或结束。模型不生成不存在的选择器，能显著减少“选择器幻觉”。邮件、工单和客服路由： 并行判断部门、紧急程度、垃圾邮件概率、退款意图和是否需要人工介入。Agent Harness： 判断任务是否完成、是否卡住、是否偏离目标、工具调用是否危险、哪些上下文应该保留。模型与工具路由： 在每个回合开始时选择便宜模型、强模型、搜索工具或专用子 Agent。内容审核和数据筛选： 对新闻、帖子、论文摘要、商品或文档进行高频分类、评分和过滤。实时控制和游戏： 对模拟器状态、游戏状态或设备状态进行低延迟动作选择。交易、支付等高风险场景必须采用 advisory 或人工确认模式。这些场景的共同点是：判断频率高、答案空间窄、延迟或成本敏感，而且最终动作可以由程序执行。它们不是开放式写作、代码生成或长链推理。
八、社区端侧复现说明：哪些可以复现，哪些仍是推测
APUS AI 实验室的文章基于 Qwen3.5-9B 等开源模型，尝试复现 Jev 的关键思想，并开源了 fast-browser-use。其路线包括：候选动作枚举、单 token logits 决策、KV-Cache 广播、受限动作空间和 Harness 防护。测试显示，在 Apple M2 Pro、MLX 和 4-bit 本地权重上，多个浏览器任务可以在数秒到几十秒内完成。
这类项目证明的是“受限决策模型”这一范式可以在开源模型上落地，并不等于复现了 Jev 的权重、训练配方或全部性能。社区文章中的速度、准确率和成本数字属于特定硬件、页面和实现下的实验结果，不能直接与 TypeSafe 的云端基准横向等同。
九、Jev 的优势
低延迟： 避免长文本自回归，适合实时循环和高频 Agent 步骤。低成本： 官方公开价格曾宣传为输入每百万 token 约 0.042 美元、输出免费；具体价格和可用性应以当前控制台为准。类型安全： 答案空间由调用方定义，JSON 由程序生成，结构化解析错误可被系统性消除。天然可并行： 一次调用可同时询问多个独立问题，适合扇出式评估。置信度可用于治理： 概率和置信度让自动执行、人工复核和升级模型之间有明确边界。便于审计： 问题定义、候选集合、模型答案、概率、阈值和最终动作都可以记录为 Trace。十、局限与风险：Jev 不是什么
不是生成模型： 不能替代对话、写作、代码生成或复杂解释。没有主动世界知识： 它只判断传入的状态，不会自动浏览互联网或调用工具；信息收集必须由外部程序完成。概率不等于正确： 校准是群体统计性质，单次预测仍可能错误。强依赖问题设计： 如果候选选项遗漏了正确答案，模型只能在错误的集合中做选择。必要时应加入“其他/不确定”选项。闭源与供应商依赖： 权重和完整训练细节未公开，延迟、价格和配额可能变化。高风险动作不能只看模型： 支付、交易、删除、外发消息等必须有确定性规则、幂等保护、二次确认和审计。十一、如何设计一个可靠的 Jev 问题
把问题写成一个原子判断，不要把规划、解释和执行混在一起。 显式列出合法答案，并加入 other、unknown 或 need_human 等兜底选项。 让状态尽量结构化，去掉与当前问题无关的上下文。 一次并行询问多个相互独立的问题，减少往返。 为每类动作建立独立阈值，并用离线标注集校准。 把 Jev 的答案、置信度和最终动作全部写入 Trace，便于回放和误差分析。 对副作用动作使用外部状态断言，例如 URL、页面标题、数据库状态或业务回执，而不是把模型返回的 DONE 当成事实。 十二、一个混合 Agent 架构示例
用户请求
↓
System 2：理解目标、制定计划
↓
程序收集状态（页面、工具结果、权限、策略）
↓
Jev：Choice / Score / Noul 并行判断
↓
确定性代码：阈值、权限、幂等、审计
├─ 高置信度 + 低风险 → 自动执行
├─ 中等置信度 → 请求确认或补充信息
└─ 低置信度/复杂情况 → 升级人工或 System 2
↓
外部状态断言与 Trace 记录这个架构的关键不是“让 Jev 接管 Agent”，而是把它放在最适合的位置：成为快速、局部、可审计的决策层。主 LLM 负责方向，程序负责边界，Jev 负责高频判断。
十三、Jev 技术架构细节：如何一次回答多个问题并提升吞吐
下面这套架构是根据 TypeSafe 对 System One 的公开描述，以及社区端侧复现文章所还原出的工程模型。TypeSafe 尚未公开 Jev 的权重和完整实现，因此其中涉及 KV-Cache 广播、Suffix Batch 和候选 token 映射的部分，应理解为“高度合理的实现路径”，而不是官方确认的内部代码。
1. 输入不是一段提示词，而是 Context + Schema
调用方首先准备两类数据：
Context： 当前业务状态，例如工单正文、用户资料、页面 DOM 摘要、交易记录或游戏状态。Schema： 要问的问题、问题类型和合法答案集合。例如 team ∈ {billing, technical, account}、risk ∈ {low, medium, high}，以及若干 Noul 和 Score 问题。可以形式化为：
\( Q=\{q_1,q_2,\ldots,q_M\},\qquad q_i=(\text{name}_i,\text{type}_i,\mathcal{A}_i) \)
其中 M 是一次请求中的问题数量，𝒜i 是第 i 个问题的合法答案空间。关键点是：这些问题可以相互独立地基于同一份 Context 判断，而不需要让第 2 个问题读取第 1 个问题生成的文本。
2. 单次 Prefill：Context 只编码一次
在普通自回归 LLM 中，每个字段的生成过程可能重复携带上下文，或者在生成后续字段时继续依赖前面字段的 KV-Cache。Jev 式架构把共享的 Context 前缀单独处理：模型先对 Context 做一次 Prefill，得到初始 Key/Value 缓存。
\( (K_0,V_0)=\mathrm{Prefill}(X_{\text{context}}) \)
如果有 M 个问题，最昂贵的上下文编码只发生一次。后续每个问题只追加自己的问题前缀、字段名和候选答案提示。
3. Suffix Batch：把多个问题组织成批次
为每个问题预先构造一个短的 suffix（后缀提示），例如 field="team":、field="urgent":、field="refund":。这些 suffix 的作用不是让模型生成完整 JSON，而是把模型引导到对应字段的决策位置。
随后将同一个 Context 的 KV-Cache 沿 batch 维度广播 M 份：
\( (K_0,V_0)\;\xrightarrow{\text{broadcast along batch}}\; (K_0^{(1:M)},V_0^{(1:M)}) \)
第 i 个 batch 样本只附加第 i 个问题的 suffix。这样做的效果是：共享上下文不重复计算，问题之间彼此解耦，同时又可以交给 GPU、NPU 或高效 CPU 内核进行批量矩阵运算。
4. Single Batched Forward Pass：一次前向得到 M 个问题的 logits
完成广播和 suffix 拼接后，系统执行一次批量前向传播：
\( Z=\mathrm{Forward}\left(\mathrm{Batch}\left[X_{\text{context}}+S_1,\ldots,X_{\text{context}}+S_M\right]\right) \)
输出 Z 包含每个问题在“下一个决策位置”上的 logits。传统做法可能需要为 M 个字段分别调用 M 次推理；批处理后，它们共享一次 kernel 调度和一次上下文计算，工程上可以显著提升吞吐。
需要准确理解“复杂度降低”的含义：它不是把所有计算神奇地变成常数，而是把最昂贵的共享前向从 M 次重复执行变成 1 次，并将问题特有的工作放入并行 batch。理想情况下，端到端延迟更接近一次前向加上批量宽度带来的并行开销，而不是 M 次串行延迟。
若串行方案的近似耗时为：
\( T_{\text{serial}}\approx M(T_{\text{prefill}}+T_{\text{decode}}) \)
而共享 Prefill、批量决策的方案近似为：
\( T_{\text{batched}}\approx T_{\text{prefill}}+T_{\text{batched\_forward}}+T_{\text{assemble}} \)
则理论加速比可以写成：
\( S=\frac{T_{\text{serial}}}{T_{\text{batched}}} \)
当 M 较大、Context 较长且硬件具备批处理能力时，S 会明显增大；当 Context 很短、问题数量很少或 batch 已经受限于内存带宽时，加速比则会下降。
5. 候选子词表 Logit 切片：不再扫描完整词表
普通语言模型的输出层通常面对完整词表 V 。但在 Jev 的 Choice 问题中，调用方只允许模型从 K 个候选中选择，其中 K≪V 。因此，系统可以先把每个合法选项映射到 tokenizer 中的候选 token，再只保留这些位置的 logits：
\( z_{\text{choice}}=Z[:,\mathcal{I}_{\text{valid}}],\qquad |\mathcal{I}_{\text{valid}}|=K\ll |V| \)
然后在候选集合内部重新 Softmax：
\( p(a_i\mid X,Q)=\frac{\exp(z_i)}{\sum_{j=1}^{K}\exp(z_j)} \)
这样可以避免让模型在数万或数十万 token 中自由采样，既减少输出层计算和内存搬运，也从结构上阻断“生成未定义选项”的路径。工程上应特别注意 tokenizer 校验：一个业务选项未必对应一个单独 token，必要时需要使用唯一的短标签（例如 A、B、C），再由程序把标签映射回业务值。
6. 多个问题的输出如何组装
Jev 或类似受限决策模型的核心输出通常不是一段完整 JSON，而是“每个问题一个结构化结果”。宿主程序负责把这些结果放回 Schema 定义的字段中。
可以把第 i 个问题的结果表示为：
\( r_i=\{\text{name}:n_i,\text{type}:t_i,\text{value}:a_i,\text{probabilities}:P_i,\text{confidence}:c_i\} \)
之后通过确定性映射函数把所有结果组装成最终对象：
\( R=\mathrm{Assemble}(\mathrm{Schema},r_1,r_2,\ldots,r_M) \)
// Schema（示意）
{
"team": { "type": "choice", "options": ["billing", "technical", "account"] },
"score": { "type": "score", "min": 0, "max": 2 },
"refund":{ "type": "noul" }
}
// 模型只返回各问题的决策分布
{
"team": { "choice": "billing", "probabilities": {"billing": 0.91, "technical": 0.06, "account": 0.03}, "confidence": 0.91 },
"score": { "value": 1.4, "probabilities": {"0": 0.08, "1": 0.22, "2": 0.70}, "confidence": 0.70 },
"refund": { "probability": 0.96 }
}
// 宿主程序再添加策略字段
{
"team": "billing",
"frustration_score": 1.4,
"refund_requested": true,
"route": "human_review",
"reason": "refund probability is high but operation is high-risk"
}最后三个字段 route、reason 和是否执行，并不是 Jev 自由生成的文本，而是程序根据概率、风险等级、权限和业务规则计算出来的。这样可以保证：模型负责判断，程序负责字段完整性、默认值、类型转换、阈值和副作用。
7. Choice、Score、Noul 的组装差异
类型 模型侧输出 宿主程序组装 Choice 候选标签或索引、候选概率分布 标签映射为业务枚举值，计算置信度和路由 Score 量表各等级的分布或期望分数 转换为业务分数、优先级或风险等级 Noul 条件成立的概率 按阈值转换为 true、false 或 need_review
例如 Noul 不应简单地写成“概率大于 0.5 就执行”。更安全的逻辑是把概率阈值和动作风险同时纳入：
\( \text{allow}=\left(p_{\text{allow}}\ge\tau_{\text{allow}}\right)\land\left(r_{\text{action}}\le r_{\text{max}}\right) \)
8. 为什么这套架构能减少级联误差
在传统 JSON 自回归生成中，第 i+1 个字段的输入往往包含第 i 个字段已经生成的文本。一旦前一个字段出现偏差，后续 KV-Cache 可能继续携带这个偏差，形成级联错误。
批量受限决策则让每个问题直接基于原始 Context 和自己的 Schema 分支：
\( a_i=f_i(X_{\text{context}},q_i),\qquad a_i\perp a_j\mid X_{\text{context}}\; (i\ne j) \)
这里的条件独立是架构目标，而不是说业务语义一定独立。程序仍然可以在第一批结果出来后，再有条件地发起第二批问题；但在同一批次中，一个字段不会因为另一个字段生成了错误文本而被迫污染。
9. 吞吐提升不只来自模型，还来自调度和内存布局
减少重复 Prefill： 长 Context 只编码一次。批量矩阵乘： 多个问题共享一次 forward 的 kernel 调度，提升硬件利用率。缩短解码长度： 从生成几十到几百个 JSON token，变成一次或少量决策 token。候选集合裁剪： 只处理合法答案对应的 logits，减少无关词表计算。字段解耦： 问题可以并行完成，不必等待前一个字段生成结束。宿主侧零 token 组装： JSON 序列化、默认值和字段映射由普通代码完成，几乎不占用模型推理时间。不过，实际吞吐仍受 Context 长度、batch 大小、设备显存、内存带宽、网络 RTT、SDK 序列化和业务后处理影响。因此“成倍提升”应通过真实任务基准验证，而不能仅由单次 logits 计算推导出来。
十四、速度与成本数据应该如何解读
TypeSafe 和社区资料中出现过 70–500 毫秒延迟、比传统 LLM 快几十到数百倍、成本低几十到数百倍等数字。这些数字很有吸引力，但应视为厂商或项目方在特定条件下的自测结果：硬件、网络、批量大小、输入长度、对比模型、是否包含编排和浏览器等待，都会显著影响结果。
工程上更可靠的做法是针对自己的任务建立基准：固定数据集，分别测量端到端延迟、模型延迟、准确率、校准误差、升级率、单位任务成本和副作用错误率。只有当 Jev 在真实流量和风险约束下仍然改善整体指标，才算产生了实际收益。
十五、结论：Jev 代表一种“决策优先”的 AI 工程范式
Jev 最值得关注的地方，不只是某个 API 有多快，而是它重新划分了 AI 系统中的职责：不是所有智能都需要通过生成文字来表达。大量软件任务真正需要的是“选哪个”“是否允许”“风险多高”“是否需要升级”，这些判断可以拥有受限的答案空间、显式的概率和明确的代码边界。
如果把传统 LLM 看作负责深思熟虑的 System 2，那么 Jev 就是负责快速分诊和局部控制的 System 1。最有前景的落地方式，是让两者形成级联：Jev 先以低延迟完成分类、路由和护栏检查；复杂、模糊或高风险任务再交给更强模型或人工。
现阶段，Jev 仍处于早期阶段，官方模型闭源，性能数据主要来自厂商和社区自测。建议从范围明确、可回放、风险较低的任务开始试用，例如工单路由、工具选择、Agent 完成检测和浏览器候选动作选择，并用自己的数据验证准确率、校准和成本。真正成熟的 Jev 系统，最终应当是“模型做判断，代码守边界，外部状态作验收”。
参考资料
