最近，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 权重和内部架构没有公开，它属于合理的逆向推测，不应当当作官方实现细节。
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 系统，最终应当是“模型做判断，代码守边界，外部状态作验收”。