Jev 是 TypeSafe AI 的决策模型：输入状态，输出带有校准概率的类型化答案，不生成文本。本文介绍三个核心原语、适用的用例、首批独立基准测试和 Laya 对比的结果、已记录的失败模式，以及 FDE 应如何将其嵌入客户的流水线。
作者：MEI LIN · FDEINTERVIEWS 编辑部 · 更新于 2026 年 9 月 21 日 · 阅读时长 18 分钟
实践要点：System One 决策模型的概念 · LLM 与 GenAI 问题 · RAG 与 Agent 设计问题 · FDE 必知问题
Jev 是 TypeSafe AI 推出的一款托管 AI 模型，它做出类型化的决策，而不是撰写文本。你向它发送一个状态（一张支持工单、一条客户记录、一段文本、一个 JSON 对象）以及一个或多个类型化的问题。它会返回你的代码可以直接分支处理的答案：是/否问题的概率、从封闭集合中做出的选择（附完整概率分布），或者沿你定义的评分标准量级给出的分数。TypeSafe 于 2026 年 9 月 15 日在隐身运营两年后正式发布该模型，称其为首个“System One 模型”，目前提供早期访问。由于没有生成步骤，因此无需解析任何内容，模型也不可能凭空发明一个你没有提供的选项。对前沿部署工程师来说，关键在于它的定位：它嵌入在普通软件内部，作为一个快速、廉价、带置信度的判断，而工作流、算术运算和副作用都留在代码中。
Jev 是什么，不是什么
这个名字源自 Daniel Kahneman 的 System 1，即快速、直觉式的思维模式，TypeSafe 的文档强调其重点是快速、聚焦的判断。该模型采用公司称为“校准决策强化学习”（RLCD）的方法训练，与催生聊天模型的 RLHF 以及推理模型背后的可验证奖励训练形成对比。根据公司自己的发布文章，TypeSafe 的创始人 Diogo Almeida 曾在 OpenAI 参与 RLHF 研究，其主张是：聊天形态的模型并不是自动化的正确接口。
| 聊天与推理 LLM | Jev（依据 TypeSafe 的发布文章和文档） | |
|---|---|---|
| 训练目标 | 人们偏好的回复（RLHF），或可验证的答案（RLVR） | 带有校准概率的决策（RLCD） |
| 输出 | 字符串：散文、代码、需要解析和验证的 JSON | 限定在你所提供选项范围内的类型化值 |
| 采样方式 | 逐个 token 生成 | 所有答案在一次并行处理中完成 |
| 置信度 | 被问及时过度自信且不一致 | 每个答案都附带概率分布，Choice 和 Score 还附带置信度值 |
| 最擅长 | 人机协作工作、可验证的问题、原型 | 知识渊博的人一秒钟内做出的判断，嵌入在软件中 |
| 不适用于 | 廉价、高吞吐量的结构化决策 | 任何形式的生成、算术、日期、多跳推理 |
在设计问题之前，有两点澄清很重要。TypeScript 和 Python SDK 采用 MIT 许可证并在 GitHub 上公开；模型由 TypeSafe 的 API 提供服务，我们没有找到公开的权重发布。此外，Jev 请求是一个函数调用，而不是工作流：持久化状态、重试、事务和重放属于你的应用程序或工作流引擎。
三个原语，一个请求
每个请求携带一个状态和一组问题。每个问题看到的是同一个状态，被独立且并行地评估，并以你选择的键返回结果。
| 原语 | 问题形态 | 返回内容 | 限制（jev-1.13） |
|---|---|---|---|
| Noul | 这是否为真？“客户是否请求退款？” | noul，一个 0 到 1 之间的概率 | 无单独的置信度 |
| Choice | 其中哪一个？“哪个团队应该处理此事？” | choice，每个选项的概率，置信度 | 最多 255 个选项 |
| Score | 哪个级别？“客户有多沮丧？” | score，沿你的级别、图例、概率、置信度 | 2 到 10 个有序级别 |
文档明确说明了粒度：请求的是在给定适当上下文的情况下，一个有知识的人在一秒钟内做出的判断。“这条消息是否传达了紧迫性？”是一个好问题。“分析这个并决定该怎么做”则不是，这是一个信号，提示你应将任务拆分为小问题，并在代码中组合它们。这种拆分不会产生额外的往返开销，因为针对同一状态的问题会并行运行。
一张工单，两种方式
看清差异的最清晰方法，是让同一张工单经过两种形态处理。工单内容为：“嘿，我这个月被扣了两次款。有人能处理一下吗？”生成式模型通过推理来路由它：它注意到重复扣款，考虑这属于账单还是一般支持，回忆起账单团队处理退款，然后写出“账单”。这是几百个输出 token、一秒或更长的延迟，以及一个你的代码必须解析并信任的字符串。而 Choice 问题通过评分来路由它。请求将工单作为状态，并携带一个包含五个选项及其判定标准的问题，响应是这五个选项上的一个分布、一个命名首选选项的 choice 字段，以及一个由整个分布的形状推导出的置信度值。
choice
field naming the top one, and a
confidence
value derived from the shape of the whole distribution.
图表中的数字是示意性的，用于展示一个高置信度答案的形状，而非从 API 记录的实际数据。阈值来自 TypeSafe 自己的置信度路由模式的示例：低于 0.6 时，案例转给人工处理；在 0.6 到 0.85 之间时，代码对低风险决策采取行动，对中等风险决策请求确认；高于 0.85 时，它也对高风险决策采取行动。生成式版本口头推理的所有内容，现在要么存在于你为每个选项编写的判定标准中，要么存在于你的代码根据置信度所走的分支中。这就是全部的权衡：你放弃了解释，换来的是一个分布、一个阈值，以及一次毫秒级、成本不到一美分几分之一的调用。
| 生成式模型来路由 | Choice 来路由 | |
|---|---|---|
| 你发送的内容 | 包含分类体系和推理指令的提示词 | 以工单作为状态，五个选项各配一行判断标准 |
| 返回的内容 | 以 "Billing" 结尾的文本，需要解析和验证 | choice、五个选项上的概率分布、置信度 |
| 由什么决定 | 模型的推理过程，你无法对其设置阈值 | 你的代码，基于一个可以按操作设置阈值的置信度 |
| 出错时 | 你从客户那里才知道 | 低置信度在任何人出错之前就路由给人工处理 |
| 每张工单的成本 | 数百个输出 token | 几百个输入 token，输出几乎免费 |
适用场景：AI 在代码之内，而非代码在 Agent 之内
TypeSafe 描述了三种架构。传统软件是由可靠原语构成的决策树。Agent 循环自行选择下一步，这有人在监督时可行，无人监督时则会漂移。AI 驱动的软件——也就是这里的目标——将控制流、确定性规则和副作用保留在代码中，只在系统需要对非结构化数据做出语义判断的地方插入模型。这正是前沿部署工程师实际交付的大多数企业自动化的形态。
置信度门槛是让这一切可以安全自动化的关键。TypeSafe 自己的银行示例使用 0.6 的下限，低于该值的一切都交给人工；余额查询在 0.6 时即可放行，因为最坏情况只是读错了屏幕；而批准转账则要求高于 0.85。阈值由你决定；让阈值随错误操作的代价而调整，才是设计的核心。
符合这一形态的用例
最强的用例有一个共同特征：难点是一个有边界的语义判断，而后果重大的操作仍留在代码中。以下内容来自 TypeSafe 公布的用例图谱和模式页面。
| 用例 | 相关问题 | 留在代码中的部分 |
|---|---|---|
| 工单分诊 | 用 Choice 判断队列，用 Score 评估情绪，用 Noul 判断“是否要求退款”，全部在一次调用中完成 | SLA、路由表、写入工单系统的操作 |
| LLM 护栏与验证 | 对每个 LLM 输入、输出和工具调用运行 Noul：注入、违反政策、与上下文矛盾、敏感数据 | 允许列表、授权检查、账号的正则匹配 |
| 模型路由 | Choice：确定性处理器、快速模型、推理模型、人工 | 预算、延迟目标、回退顺序 |
| RAG 相关性与重排序 | 每个段落一个 Noul，扇出执行；用成对 Choice 进行重排序 | 检索、分块、top-k 截断 |
| 在有界空间内做抽取 | 在枚举的组件上运行 Choice，并带有显式的“未提及”选项 | 组装各部分、每一次比较和计算 |
| 为传统机器学习提供特征 | 将多个窄域 Noul 的概率作为特征列 | 带有真实标签的模型 |
| 对语料库进行 map-reduce | 对每个文档运行同一套问题 | 分区、聚合、存储 |
| Agent 中的工具与技能选择 | 在封闭的工具列表中做出选择；每个参数一个 Noul，用于“用户是否声明过这一点？” | 循环本身、工具注册表、参数校验、执行 |
| Agent 的停止与升级检查 | Noul：结果是否满足请求；提取的字段是否错误；这一步是否需要更强的模型 | 验收标准、重试预算、回退模型、人工队列 |
最后两行值得单独用一段来讨论，因为流行的说法是“让 Jev 控制你的 agent”，而 TypeSafe 自己的指导则比这更为谨慎。它的构建指南说，一个自行选择下一步的 agent“在有人监督流程时效果良好，但每一次循环都引入了另一个偏离轨道的机会”，并且它推荐的设计将“控制流、确定性规则和副作用保留在代码中”。因此，决策模型并不运行循环，而是回答循环提出的问题。函数调用 cookbook 将一个请求路由到十个交易函数之一，使用一个 Choice，其选项就是这些函数；用关于含义而非参数名的问题来填充每个参数；并将调用的置信度报告为这些判断中最不确定的那个，“因为一个错误的参数就足以毁掉整个结果”。技能推荐 cookbook 用两个请求对 182 个 agent 技能进行排序，最多推荐一个，并设有 0.30 的下限，低于此值则保持沉默；它诚实地报告了这一设计的代价：错误加载从 16.8% 降至 7.3%，不必要的加载从 9.8% 降至 4.0%，但有七个原本已经正确的请求变得更糟了，因为“一个自信的错误建议比没有建议更有说服力”。而提取级联 cookbook 则是“这是否需要更聪明的模型”这一模式的具体化：一个廉价模型负责提取，每个字段一个 Noul 询问该值是否错误，任何高于 0.7 的字段都会将整个条目发送给推理模型。每次都是同样的形态：代码拥有循环，模型在循环内回答狭窄的问题，而阈值决定由谁行动。
做一些算术，仅使用标价。一个分诊流水线每月为一百万张工单各发送一个 300 token 的状态，将使用 3 亿输入 token。按标价每百万 0.042 美元计算，约为 12.60 美元，输出免费。发布博文将前沿 LLM 的输入价格定为每百万 token 0.20 至 10 美元（不含输出），因此同样的输入量仅输入成本就在约 60 美元到约 3,000 美元之间。这就是为什么用例地图会谈到对每一条 agent 轨迹进行分类并扫描海量语料库：在以前贵得跑不起的任务，在这个价位上变成了例行工作——前提是这种判断属于 System One 那一类。
截至 2026 年 9 月 20 日的数据
| jev-1.13.0，来自 TypeSafe 的模型页面 | |
|---|---|
| 价格 | 每百万输入 token 0.042 美元；输出 token 免费 |
| 上下文 | 每次请求 64k token；状态加上最长的问题共 32k |
| 速率限制 | 每秒 250,000 个 token，每分钟 1,200 次请求，动态调整 |
| 延迟 | 文档称大多数查询约 100 ms；通过公共互联网的独立实测，p50 为 236 至 276 ms 和 422 ms |
| 输入 | 仅文本：字符串、JSON 对象或文本数组。英语效果最佳；其他语言可接受，但准确率较低 |
| 别名 | jev-latest 和 jev-preview 目前都解析为 jev-1.13.0；发布新版本时别名会随之变动 |
| 数据 | 请求不用于训练；为企业客户提供零数据保留 |
在向客户引用这些数据之前，请先与文档核对。早期访问阶段的数字随时可能变动。
首批基准测试结果说明了什么，以及如何解读那张流传的图表
五天时间足以催生出一个基准测试生态，而且它已经讲述了两个故事。第一个故事来自一张正在流传的图表：Laya 是 ConvAI Innovations 在 Jev 发布四天后以 Apache 2.0 许可发布的 421M 参数开放权重模型，该图表显示 Laya 以 83.8% 对 67.8% 的总成绩“击败”了 Jev。在转述之前，请先看清坐标轴。Laya 的 83.8 是其作者在微调后的检查点上、针对十一个任务族的 23,024 个问题自行运行的评测结果。Jev 的 67.8 则完全是另一个数字：那是 TypeSafe 自己的工作流评测，其中 67.8% 是 Jev 在四个业务工作流中与两个前沿 LLM 组成的集成模型的平均一致率，每个案例耗时 0.4 秒、成本 0.0004 美元；相比之下，Opus 5 的一致率为 73.1%，耗时 37.8 秒、成本 0.1761 美元。这两个数字除了百分号之外毫无共同之处——这正是 Hugging Face 数据集卡片在自行重新运行两个模型之前所强调的一点。
第二个故事是在同一套冻结协议下会发生什么。一项独立的零样本基准测试在四个公开数据集上，给 Jev、Laya 和一个开源 NLI 分类器提供相同的文本、相同的指令和相同的标签名称，且协议在推理之前就已冻结。
同一冻结协议下的独立零样本准确率（elcronos，2026 年 9 月 20 日）。Jev 在两个主题数据集上领先 16 至 33 个百分点，在情绪数据集上与 Laya 完全持平。在对话情绪数据集上，所有零样本系统都低于 0.82 的多数类基线。带轮廓的柱形是在各数据集自身标签上训练的逻辑回归或 LightGBM 模型：在有标签的情况下，一个普通的监督模型在每个数据集上都击败了所有零样本系统。
该仓库中有三项发现比排名本身更重要。任务类型胜过模型家族：同一个 Jev 提示词形态在情感分类上得分为 0.587，在推文主题上为 0.793，其校准误差在四个数据集上介于 0.063 到 0.281 之间，因此 API 中的任何信息都无法告诉你它在你的数据上会有怎样的表现。与训练模型相比的盈亏平衡点只需几百到几千条标注：500 条标注推文足以让基于句子嵌入的逻辑回归追平 Jev，金融主题需要 1,000 条，情感分类约需 5,000 条。而 Laya 宣传的胜出成绩在零样本下并未复现：显示 83.8 的同一张模型卡也指出，基础模型在其类型化决策基准上得分接近随机，直到在该基准的训练集上微调之后才有所提升。
第三个来源范围较窄，但对 FDE 而言却是最令人安心的。一项可复现的基准测试将 Jev 用于把 Agent 工具调用分类为只读、破坏性、特权或数据外泄，在 60 个手工标注的案例（包括 12 个被包裹在良性语言中的对抗性案例）上，测得 91.7% 的准确率，12 个对抗性案例中捕获了 11 个，在刻意设置模糊性的切片上为 71.4%，且校准结果在多次重复运行中保持一致：每一个错误答案都伴随着保守的置信度，模型从未在置信度 1.000 时出错。通过住宅网络连接在客户端测得的延迟为 p50 422 ms、p95 542 ms，远高于文档中的“约 100 ms”，在你自己实测之前，应以这个数字来做规划。
| 来源 | 测量内容 | 核心数据 | 如何解读 |
|---|---|---|---|
| TypeSafe 工作流评测 | 在四个厂商构建的工作流上与双 LLM 参考的一致性 | Jev 67.8%，成本 0.0004 美元、耗时 0.4 秒；Opus 5 73.1%，成本 0.1761 美元、耗时 37.8 秒 | 厂商自测；其主张在于成本和速度差距，而非准确率 |
| Laya 模型卡 | 其自有的 23,024 题测试套件，微调后的检查点 | 总体 83.8%；在 T4 上每题 32.8 至 39.5 ms | 自我报告；与并列展示的 67.8 不可比 |
| elcronos，冻结协议 | 四个公开数据集上的零样本准确率和 ECE | Jev 0.79 / 0.67 / 0.71 对 Laya 0.63 / 0.34 / 0.61；情感分类上以 0.59 打平 | 独立测试；任务类型占主导；标注胜过零样本 |
| themsquared 工具调用风险 | 60 个标注的 Agent 工具调用，准确率、延迟、校准 | 91.7%，ECE 0.07，置信度 1.0 时零失误，p50 422 ms | 独立测试，样本量小，原始结果已提交；校准主张成立 |
| Luni 数据集卡 | 钓鱼检测和类型化决策，两个模型均重新运行 | 钓鱼检测：Jev 原始 0.626，Laya 原始 0.505、经 Platt 缩放后 0.611，Claude Haiku 4.5 为 0.813 | 独立测试；还显示 Laya 在问题加否定上的得分总和为 0.09 和 1.73 |
图表中唯一真正有用的面板是选择性自动化曲线：自动化决策的准确率与自动化流量占比的关系。Laya 报告的数据是：50% 覆盖率下准确率为 92.2%，而全覆盖下为 83.8%。无论具体数字如何，任何决策模型都应该拿出这样一条曲线，因为它就是画成图形式的置信度门槛：覆盖率由你来选择，而不是由供应商替你选择，而且绘制这条曲线所用的标注集，正是用来设定阈值的同一套数据。
TypeSafe 自己指出的失效之处
文档中保留了一页关于 jev-1.13 的已知缺陷清单，最后审阅日期为 2026 年 9 月 17 日。前沿部署工程师应该划重点的一句话是：模型“回答的是你写下的问题，而不是你真正想问的问题”。限定词、否定句和隐含条件都会被字面解读。
| 失效模式 | TypeSafe 建议的替代做法 |
|---|---|
| 字面解读 | 写出确切的判断条件；把边界情况写进 criteria |
| 算术与计数 | 把数学运算放在代码里；逐项迭代，每项只问一个 Noul，然后在代码中求和 |
| 日期与时间比较 | 将各部分提取为 Choice；在代码中组装并比较日期 |
| 间接引用与多跳推理 | 减少跳数；把问题指向状态中相关的部分 |
| 包含无关细节的大状态 | 先做过滤；文档将由此造成的准确率损失称为 context rot |
| 对抗性内容 | 状态不会被当作恶意内容处理；在 criteria 中明确说明，并测试边界情况 |
| 结构性恒等关系 | 一个问题与其否定式的得分之和不一定为 1；不要跨原始类型沿用阈值 |
| 生成类任务 | 使用生成式模型 |
恒等关系这一行值得单独举例说明，因为它会让那些把输出当作教科书意义上概率来推理的人感到意外。在 TypeSafe 的示例案例中，同一个工单上，“客户是否在要求退款”返回了 0.72，而“客户是否在要求退款以外的事项”返回了 0.47，两者之和为 1.19。每个决策只用一种方式提问，并在代码中强制校验恒等关系。
前沿部署工程师应该如何思考
把它设计成一个聪明的 if 语句，因为它本质上就是如此。把判断拆解为原子化的问题，把所有计算、日期比较、授权决策和不可逆的副作用都保留在代码中，然后用客户能读懂的显式权重或规则来组合答案。当优先级发生变化时，你只需调整一个权重，而不必重写提示词。
校准是总体层面的属性，所以你仍然需要一个黄金集。校准后的 0.8 意味着，在大量预测中，输出为 0.8 的结果大约有 80% 的时间会成真。它并不能保证任何单个答案正确。上面的独立运行让这一点变得具体：同一个提示词形态，在不同数据集上产生的准确率从 0.59 到 0.79 不等，校准误差从 0.06 到 0.28 不等。用客户自己的数据构建一个带标签的集合，绘制置信度与准确率的关系图，为每个操作选择阈值，并在模型版本变更时重新运行扫描。同时运行基准测试作者做过的那种对比：用同样几百个标签训练一个线性模型，在留出行上打分，因为一旦标签存在，它可能是更划算的选择。固定使用 jev-1.13.0 而不是别名，并在每次决策时记录响应返回的 model 字段。
jev-1.13.0
rather than the alias, and log the
model
field the response returns with every decision.
它只有五天历史，所以要像对待任何外部依赖一样加以封装。速率限制是动态的，SDK 版本为 0.6.0，文档也没有公布 SLA。把调用放在超时和回退机制之后，在执行操作之前先把决策记录到 outbox 中，并设计重试机制，确保重复调用不会导致重复操作。该站点关于回退与提供商故障转移以及幂等性的概念文档是这两方面的参考。
把状态视为不可信输入。模型无法自我防御那些旨在操纵它的文本，因此让 Noul 问一句“这是不是提示词注入”只是一层防线，而不是全部。保留已有的确定性检查，对于受监管的客户，要在合同中写明零数据保留条款，而不是想当然。
在项目中寻找那些已经在为草率判断消耗 LLM token 的步骤。分诊、路由、验证、相关性过滤、追踪分类。这些是首批候选场景，而且它们也是错误答案最容易通过阈值加人工队列低成本捕获的场景。
在编码 Agent 中五分钟完成设置
尝试这种形态最快的方式是在你已经在用的编码 Agent 中进行，因为 TypeSafe 发布了一个 Agent skill，将 API 的三种问题类型、其模式及其评测建议带入 Agent 的上下文。以下内容均来自截至 2026 年 9 月 21 日的文档和 skill 仓库；在依赖之前请同时核对两者，因为早期访问产品变化很快。
- 获取密钥。在 TypeSafe 控制台中创建一个，并将其导出为 TYPESAFE_API_KEY。这是 SDK 和快速入门 curl 示例读取的变量名。
- 安装 skill。在一个项目中运行 npx skills add typesafe-ai/skills --skill typesafe-ai，并在被询问时选择你的 Agent；加上 -g 可为所有项目安装。文档中提到的有 Claude Code、Codex 和 Cursor。Claude Code 还有插件方式：先运行 claude plugin marketplace add typesafe-ai/skills，再运行 claude plugin install typesafe@typesafe-ai。
- 为 Agent 编写的代码安装一个 SDK。Python 版本通过 pip install typesafe-sdk 安装；TypeScript 包是 @typesafe-ai/sdk。两者均采用 MIT 许可证。
- 让 Agent 处理一个真实的步骤。让它找出代码库中某个提示词加解析（prompt-and-parse）调用或脆弱规则集实际上属于封闭集决策的地方，并将该步骤重构为带置信度门槛的类型化问题。该技能本身的经验法则是：当“一个 LLM 提示词加解析步骤可以变成结构化决策”时，就使用模型，并且“每个问题只提出一个狭窄、连贯的判断”。
两点提醒。该技能是给 Agent 的指导，而不是你仓库的策略，因此如果你希望 Agent 默认优先使用类型化决策，请用自己的话写进你自己的项目指令中，而不是照搬社交媒体帖子里的模板。另外，安装了技能并不会降低把往返流程搞错的代价：上一节中的标注数据集、阈值扫描和固定的模型版本，仍然适用于 Agent 重构的每一个步骤。
这对 FDE 和应用 AI 面试意味着什么
可以预期设计环节会在“规则还是模型”之外增加第三个选项：规则、生成式模型，或决策模型。他们想要的答案包含四个部分：说出判断的形态（快速直觉判断还是推理链）、说明哪些部分保留在代码中、把置信度阈值与错误行动的代价挂钩，并描述在版本变更前后如何基于客户数据进行评测。我们新增了一个关于 System One 决策模型的概念页面和两道练习题，一道是关于用决策模型替换 LLM 分类器，另一道是关于用它构建护栏层。更广泛的准备工作与之前相同：LLM 和 GenAI 问题、RAG 和 Agent 设计问题，以及该角色的技能指南。
把它转化为 offer。练习这些内容所对应的真实问题和概念：
FAQ
Jev 是 TypeSafe AI 于 2026 年 9 月 15 日发布的托管 AI 模型，它返回类型化决策而非生成的文本。你向它发送一个状态（一张工单、一条记录、一段文本）和类型化问题，它会返回一个是/否问题的概率、封闭集合中的一个选项（附带完整的概率分布），或沿你定义的评分量规给出的分数。TypeSafe 将这类模型称为 System One 模型。
不，至少在设计意义上不是。Jev 像 LLM 一样理解自然语言输入，但它不生成文本、代码或解释。它的输出被限制在你提供的选项内，并附带校准过的概率。TypeSafe 使用一种称为“校准决策强化学习”（Reinforcement Learning for Calibrated Decisions）的方法来训练它，而不是聊天模型所用的 RLHF。
截至2026年9月20日，TypeSafe 将 jev-1.13.0 的价格定为每百万输入 token 0.042 美元，输出 token 免费。请求预算为 64k token，其中 32k 用于状态加上最长的问题。速率限制为每秒 250,000 token 和每分钟 1,200 次请求，TypeSafe 提醒在早期访问期间这些限制会动态调整。
这是 Jev 的三种问题类型。Noul 是一个是/否判断，以 0 到 1 的概率返回。Choice 从最多 255 个选项的封闭集合中选取一个，并返回完整的概率分布以及一个置信度值。Score 根据状态对照 2 到 10 个有序评分等级进行评级，返回一个概率加权的位置以及置信度。同一请求中的所有问题看到相同的状态，并且独立、并行地评估。
TypeScript 和 Python 的客户端 SDK 采用 MIT 许可证。模型本身由 TypeSafe 的托管 API 提供，我们没有发现其权重的公开发布。请将其视为外部推理服务，并像对待任何托管模型一样，提出相同的回退和数据处理问题。
就目前的证据来看，并非如此。显示 Laya 达到 83.8% 而 Jev 为 67.8% 的图表比较的是两个不同的基准：Laya 在微调后检查点上的自有测试套件，以及 TypeSafe 的工作流评测与 LLM 集成的一致性。在四个公开数据集上采用同一套冻结的零样本协议时，Jev 在其中三个数据集上领先 Laya 10 到 33 个百分点，在第四个上持平，而且 Laya 自己的模型卡也说明，其基础模型在微调之前在其类型化决策数据集上的得分接近随机。Laya 是开放权重、Apache 2.0 许可，在本地 GPU 上大约快十倍，这使它在你拥有标注数据且无法将数据外发时成为微调的强力基础。它不是零样本替代品。
它可以回答这些问题，但不应该运行循环。TypeSafe 自己的构建指南将控制流、规则和副作用保留在代码中，并警告说，在没有人员监督的情况下，让 Agent 自行选择下一步会偏离轨道。它的 cookbook 展示了可行的工作形态：对封闭的工具列表使用 Choice，每个参数对应一个问题；对每个提取的字段使用 Noul，询问其是否错误，超过阈值时升级到推理模型；以及一个两阶段的技能排序器，低于下限时保持沉默。代码拥有循环；模型在循环内回答狭窄的问题。
使用 npx skills add typesafe-ai/skills --skill typesafe-ai 安装 TypeSafe 发布的 Agent 技能（加 -g 可用于所有项目），或在 Claude Code 中添加 typesafe-ai/skills 市场并安装 typesafe 插件。从在 TypeSafe 控制台中创建的密钥导出 TYPESAFE_API_KEY，安装 Python 或 TypeScript SDK，然后让 Agent 将一个提示加解析的步骤重构为带置信度门槛的类型化问题。该技能会将三种问题类型、模式和评测建议带入 Agent 的上下文中。
没有回退方案就不要放在关键路径上。它在本文发布前五天才上线早期访问，速率限制是动态的，而且 TypeSafe 自己的文档为 jev-1.13 列出了九种失败模式。它很适合作为工作流中由代码控制的置信度门控判断，在客户自己的标注数据上进行评估，模型版本固定，并在置信度低时提供转人工或 LLM 的路径。
讨论（5）
我发现向客户的平台团队解释这一点最清晰的方式是：这是分类器的回归，但你不需要训练它。微调过的 BERT 给你一个标签和一个在训练分布之外不可信的 softmax。而在这里，你在请求中写出选项和标准，拿回一个经过校准的分布，并通过编辑一个映射而不是重新训练来修改分类体系。
而让它超越分类器的关键在于扇出。一次调用中对同一个状态提出十二个独立问题，然后由你的代码将它们组合起来。这就是一棵叶子节点上带模型的决策树，而这正是大多数企业自动化实际需要的形态。
读者提问：置信度值和直接读取 Choice 的最高概率有什么区别？如果账单是 0.88，那不就是置信度吗？
接近但不相同。置信度是 TypeSafe 从整个分布的形状推导出的统计量，所以一个 0.88 且其余概率稀薄地分散在十个选项上，与一个 0.88 对阵单个 0.12 竞争者，读起来是不一样的。Noul 的回答完全不携带置信度，只有概率。他们文档中的实用规则是：不要把在 Noul 上调好的阈值搬到 Choice 上，也不要期望一个问题与其否定形式的概率之和为一。
他们的失败模式页面中我会为任何 FDE 划重点的一句话是：状态就是数据，模型默认不会将其视为敌意内容。一份为自身分类结果而辩护的工单可以改变答案。因此防护层仍然必须是分层的，允许列表、授权检查和 PII 正则表达式应该留在代码中，它们本来就该在那里。