Jev 详细介绍：TypeSafe AI 的第一个 System One 模型

官方博文在这里，感兴趣的话可以自行移步阅读。

目录

1. 一句话概述

Jev 是 TypeSafe AI 于 2026 年 9 月 15 日发布的第一个 “System One 模型”——一个不生成文本、专门做快速结构化决策的前沿模型。它接收非结构化的"状态（state）“和一组类型化的"问题（questions）”，单次查询并行返回带校准概率的类型化答案，可以直接被软件代码使用，官方称之为"前沿智能的函数调用"：非结构化状态进，带概率的类型化决策出。

2. 背景：为什么需要 Jev

发布博客开篇就提出了作者的"灵魂拷问"：

“模型在聊天上早已超越人类多年，那么，自动化在哪里？”

现有 LLM（GPT、Claude 等）本质上是为人与人机对话设计的：它们输出自由字符串，供人阅读。但当代码需要消费 AI 的判断时，就产生了根本性的错配：

• 你要"胁迫"一个文本生成系统输出结构化决策；
• 然后再把结果解析、校验回代码能依赖的形式；
• 即便如此，模型仍可能幻觉、产生类型错误、或者干脆"脱轨"。

在 agent 场景中，一次幻觉的工具调用只是不便；但在有延迟保证的生产系统里、在依赖链深处，幻觉和类型错误是致命的。此外，LLM 逐 token 顺序生成的方式导致端到端响应时间长达 3–329 秒，对人来说够用，对代码集成来说是巨大瓶颈。

TypeSafe AI 的判断是：大规模自动化将由 AI-to-AI 和 AI-to-software 的交互主导（预计 99% 是机器对机器、1% 是人机交互），因此"机器接口"比"聊天接口"更重要。 围绕这个判断，他们放弃在现有 LLM 路线上修修补补，而是从模型架构、采样器到训练方法全部重建。

3. 公司与团队

值得注意的戏剧性细节：RLHF 的共同发明人，现在公开论证 RLHF 的局限（见第 8 节），并提出第三条后训练路线 RLCD。

4. 核心思想：从"聊天智能"到"机器原生智能"

TypeSafe 把他们的设计哲学称为 Machine Native Intelligence（机器原生智能）：AI 应当具备类似软件的性质——

• 结构化（structure）：输出是预定义类型的值，不是自由文本；
• 可靠（reliability）：数学上不可能产生类型错误；
• 可观测（observability）：每个答案都带概率分布和置信度；
• 可测试（testability）：相同输入倾向给出一致答案；
• 快速（speed）：毫秒级响应；
• 一致（consistency） 与 低成本（low cost）。

他们用一句话概括自己的路线：“Building prod, not God”（造生产系统，而不是造上帝）——不追求一个无所不能的模型，而是造一个在生产系统里能被代码检查、组合、依赖的窄决策组件。

核心取舍非常清晰：放弃字符串生成（通用性），换取类型安全、校准置信度、极致速度。 字符串极其强大和通用，但代价高昂；“放弃字符串"反而带来一系列"超能力”：并行采样、无幻觉、输出免费、毫秒级延迟。

5. 什么是 System One 模型

5.1 定义

System One 模型是一类为软件做快速结构化决策的 AI 模型。和 LLM 一样，它能理解自然语言输入；不同的是，它评估一个 state（状态） 并返回类型化答案和概率，而不是生成文本。

工作方式：

5.2 命名

名字取自丹尼尔·卡尼曼《思考，快与慢》中"系统一"（快速、直觉）与"系统二"（缓慢、审慎）的区分。传统上"系统一思维"也意味着容易出错，但 TypeSafe 认为 System One 模型可以做得比替代方案更可靠（理由将在未来公布）。

5.3 与 LLM 的本质区别

6. Jev 模型规格一览

当前版本为 Jev 1.13（jev-1.13.0）：

关于别名：别名会随新版本发布而移动，响应中的 model 字段会返回实际的版本化 ID。如果你针对某个版本调好了置信度阈值，应当 pin 住具体版本号（如 jev-1.13.0）而不是用别名。

7. 三种 AI 原语（Primitives）

TypeSafe 提供三种"AI 原语"——类似软件原语，模块化、可组合、结构化、可靠、快速。每个原语 = 一个问题（定义一次判断）+ 一个类型化答案。

“Noul” 是 TypeSafe 自造的术语，表示一个是非判断的概率。

7.1 问题的结构

每个问题包含：

• ID：你自己选的键（如 refund_requested），仅用于代码，不发送给模型；
• type：choice / score / noul；
• instructions：评估逻辑所在——清晰、具体的问题或待判断的陈述；
• criteria（Choice/Score 必填，Noul 可选）：可选答案空间——Choice 的选项映射、Score 的有序等级列表、Noul 对"是/否"含义的澄清。

7.2 如何选择原语类型

• 答案是无序已知集合之一 → Choice（建议加一个 other / "以上皆非"选项兜底）；
• 答案在一个连续谱上、且每一级可以明确定义 → Score；
• 干净的是非判断、概率本身就是有用信号 → Noul；
• 如果两种都合适，选代码能直接消费的那个：Choice 映射到分支、Score 映射到阈值、Noul 映射到 if。

一个常见陷阱：Noul 返回 0.5 表示"是/否概率相等"（模型不确定），不表示"程度中等"。想测程度请用 Score。

7.3 并行与独立

一次请求中的所有问题针对同一个 state 并行、独立评估：

• 增加问题几乎不增加响应时间（成本只是多几个问题的输入 token，很便宜）；
• 问题之间相互独立，不会产生 context-rot（上下文腐化），增删问题不影响其他问题的结果；
• 官方建议：“问一个你可能不需要的问题，成本接近于零。”

7.4 原子化问题，代码中组合（最重要的方法论）

System One 模型的最佳实践是：每个问题只问一件具体、范围明确的事——一个知识丰富的人几秒钟内能做的那种"直觉判断"。需要长篇推理或多因素权衡的问题，应当拆成多个原子问题，然后在代码里加权组合。

例如不要问"给这个创业 pitch 打分"，而是分别问市场规模、技术可行性、差异化，再用自己的公式合成。优先级变化时，改代码里的系数，而不是重写 prompt。

问题还可以用反引号路径引用 state 中的特定字段，例如：

{
"refund_requested": {
"type": "noul",
"instructions": "Does `ticket.messages[0].text` request a refund?"
}
}

8. 训练方法：RLCD 与校准决策

8.1 三种后训练路线

预训练语言模型之后，业界有两条主要后训练路线，TypeSafe 提出了第三条：

8.2 RLHF 的问题（RLHF 共同发明人的自我批判）

• RLHF 训练模型说"人们喜欢听的话"——这对聊天机器人有效，但也会奖励谄媚（sycophancy）和听起来自信的幻觉；
• 偏好优化导致 mode dropping（模态掉落）：模型偏向某种风格（如指令遵循），压低其他可能输出的概率——这是 GAN 中"模态崩塌"的温和版本；
• 一个对人来说"读起来有说服力"的输出，未必可靠到可以无人值守地自动化。人类偏好与机器可信是两个不同的优化目标。

8.3 校准（Calibration）是什么

RLCD 优化的输出契约：模型不生成文本，只返回决策和概率，且概率应当认知诚实——

• 被赋予 0.2 概率的结果，应在约 20% 的情况下发生；
• 被赋予 0.8 概率的结果，应在约 80% 的情况下发生；
• 被赋予 1.0 概率的结果，应 100% 发生。

注意：校准是对成组预测的统计性质，不是对单个答案正确的保证。

为什么这对自动化是"入场券"：如果一个模型能以 95% 的准确率完成任务、但不说自己什么时候在那 5% 里，这个任务就无法被自动化。LLM 即使被要求输出置信度，也往往过度自信且不一致。

9. 置信度（Confidence）体系

9.1 定义

• Choice 和 Score 的答案都带 probabilities（选项/等级上的完整概率分布）；
• 分布的形状说明确定性：集中在一个结果上 = 自信；平坦摊开 = 不确定；
• confidence 是把分布形状折叠成的 0–1 单值统计量，方便直接设阈值（Noul 没有单独的 confidence，其概率本身就是信号）；
• 官方提供 confidence 只是"稳妥的默认值"——响应里永远带着完整 probabilities，你可以按自己的场景定义更好的确定性度量。

9.2 "我不知道"是有用的信号

如果一个智能系统（无论人还是机器）无法表达诚实的不确定性，这个系统就不可信。

置信度让代码可以针对不同确定程度实现不同行为，这是构建可靠系统的基础。

9.3 三段式使用模式

• 高置信度 → 自动执行；
• 中置信度 → 谨慎推进：请用户确认、标记待审、或先收集更多信息；
• 低置信度 → 不行动：路由给人工、请求澄清、或回退到其他系统。

9.4 阈值应随风险分级

置信度阈值不是一个数字：同一系统中不同操作应按出错后果设置不同门槛。官方示例：查余额（低风险，confidence > 0.5 即可执行）vs 批准转账（高风险，confidence > 0.9 才自动执行，否则让用户确认）。具体阈值需结合你自己的数据实测调整。

10. API 与 SDK 使用方式

10.1 HTTP API

curl -X POST https://api.typesafe.ai/v1/systemone \\
-H "Authorization: Bearer $TYPESAFE_API_KEY" \\
-H "Content-Type: application/json" \\
-d '{
"state": "Hi, I'\\''ve been trying to connect my Stripe account for 3 days and it keeps failing. I'\\''m losing sales. Please help ASAP.",
"model": "jev-latest",
"questions": {
"urgency": {
"type": "noul",
"instructions": "Does this message express urgency?"
}
}
}'

响应示例（真实格式）：

{
"model": "jev-latest",
"answers": {
"department": {
"type": "choice",
"choice": "billing",
"probabilities": { "billing": 0.84, "technical": 0.159, "sales": 0.001 },
"confidence": 0.596
},
"frustration": {
"type": "score",
"score": 1.035,
"legend": { "0": "Calm, just stating facts", "1": "Frustrated but civil", "2": "Very angry, strong language" },
"confidence": 0.842
},
"is_urgent": { "type": "noul", "noul": 0.999 }
},
"usage": { "input_tokens": 312, "output_tokens": 48 }
}

10.2 Python SDK

pip install typesafe-sdk # 需要 Python >= 3.10

from typesafe_sdk import Choice, Noul, Score, TypeSafeClient

client = TypeSafeClient() # 从环境变量 TYPESAFE_API_KEY 读取密钥，默认调用 jev-latest

response = client.system_one(
state=ticket,
questions={
"department": Choice(
instructions="Which team should handle this",
criteria={
"billing": "Payment or subscription issues",
"technical": "Bugs or integration problems",
"sales": "Pricing or account questions",
},
),
"frustration": Score(
instructions="How frustrated the customer appears",
criteria=["Calm, just stating facts", "Frustrated but civil", "Very angry, strong language"],
),
"is_urgent": Noul(instructions="The message conveys urgency or time-sensitivity"),
},
)

print(response.answers["department"].choice) # "billing"
print(response.answers["frustration"].score) # 1.035
print(response.answers["is_urgent"].noul) # 0.999

此外还有 JavaScript SDK、GET /v1/models 模型列表接口、以及面向编程 agent 的官方 Skill（Claude Code 插件或 npx skills add typesafe-ai/skills）。

10.3 试用入口

• Playground（免写代码）：console.typesafe.ai/playground
• API key 申请：console.typesafe.ai/keys（early access，需排队）

11. 官方评测：Workflow Evals

TypeSafe 专门建立了一类新评测（evals.typesafe.ai），衡量 AI 嵌入代码工作流中的表现，而非孤立 benchmark：

11.1 方法

• 假设存在一个正确的计算图（用代码表达的"工作流"），把任务分解为程序化规则 + 若干独立的原子问题（Noul/Choice/Score）；
• 参照标签：用当时最大最贵的模型——GPT-6 Astra 和 Claude Fable 5.1（均开高档思考）对每个问题作答后取平均；
• 其他模型以各自默认推理档位跑同一工作流；
• 对比"工作流方式"与"单一大 prompt（让模型在思维链里做全部逻辑）"两种方式。

11.2 结论

• 每个模型用工作流方式都比用大 prompt 更准确、更便宜、更快——“结构总是更好”；
• Jev 位于帕累托前沿，在相近智能水平下速度/成本领先约两个数量级——官网"快 193.6 倍、便宜 444.6 倍"的说法即来源于此（官方自评，非独立审计）；
• 四个公开工作流：安全事件处置、Agent 轨迹可观测性审查、发票处理、客户服务。

11.3 官方自曝的偏差（"Nuance"小节，值得称道）

• 193.6x/444.6x 属于真实世界收益的偏高端估计；
• 工作流由其模型能力团队成员编写，虽非刻意美化、也不在训练分布内，但偏差可能存在；
• 参照答案取 OpenAI 与 Anthropic 模型的平均，可能低估了 Jev 与 DeepSeek 的相对表现；
• LLM 通过官方的 System One adapter 包装来输出结构化决策——官方认为这是从 LLM 获取决策最准的方式，但比"不带概率直接给答案"更慢更贵；
• 速度/成本声明无法证明没有补贴，可持续性需长期验证。

12. 幻觉与类型安全

TypeSafe 的核心主张之一：幻觉与类型安全本质相关，后者是自动化的入场券。

• Jev 放弃字符串生成，输出被约束在预定义的答案空间内——schema 匹配是数学保证，不是经验比率（官方评测图中 0% 类型错误率就是这么来的：直接写 0，因为不可能出现反例）；
• 现有模型无论多聪明，仍然会幻觉、会产生类型错误（OpenRouter 数据佐证，官方也承认该数据有路由偏差）；
• 需要注意的精确含义："无法幻觉"指无法返回格式错误或 schema 外的答案，但仍然可能在 schema 内选错——一个格式良好的错误答案依然是错的。只不过此时你有校准概率告诉你它有多确定。

13. 演示案例

13.1 实时玩 Doom

用 Jev 玩 Doom：游戏状态以结构化数据（文本形式，非图像）喂给模型，每秒约 10 次查询（成本约 $7/小时）。官方承认非 AI 的 Doom bot 可以玩得更好，但重点在于展示实时智能 + 对不同状态表示的响应能力 + 指令遵循。官方计划发布深度教程并举办黑客松。

13.2 Wikiracing（维基竞速）

从一个维基百科页面出发、只沿链接跳到目标页面，每步要在成百上千个链接中选择。这个任务同时展示：

• 每秒智能（intelligence-per-second）；
• 高基数选择下不幻觉的复利优势（每步都选对链接，错误会指数级放大）。

官方说明：该对比中 LLM 跑的是非推理模式（为了演示可观性），所以 LLM 显得比开推理时差；Jev 完成的步数更少（智能更高的信号）。超过 255 个选项时，Jev 用"先独立打分、再显式选择"的两阶段方案。

14. 典型应用场景

反过来说，Jev 不适合：写散文、聊天、写代码、生成工具调用字符串、任何需要自由文本输出的场景——它根本不是为此设计的。

15. 局限性与注意事项

16. 开源情况与社区生态

• Jev 本身完全闭源：无权重、无自托管路径、无本地部署。官方也从未承诺会开源。
• 官方唯一开源物：system-one-adapter-python（GitHub: typesafe-ai/system-one-adapter-python）——一个 TypeSafeClient 的"drop-in 替换"，底层调用 OpenAI/Anthropic 等 LLM API，把普通 LLM 包装成符合 System One API 的结构化决策输出。用途是让开发者自行对比 Jev 与 LLM 在成本/速度/智能上的差异。支持 structured outputs 模式、概率/离散两种回答模式、概率归一化、畸形输出纠正重试、完整 attempt 调试记录等。
• 社区复现：Hugging Face / GitHub 上出现了 OpenJev、jevlike 等独立项目，复刻"单次前向传播对 N 个选项各出一个概率"的接口形态（例如用冻结的 Qwen2.5-0.5B 编码器 + 可训练的 option-attention 打分类头，在 8 选项任务上比小型自回归解码器快约 100 倍）。这些是独立实现，与 TypeSafe 无关，没有 RLCD 校准训练和并行采样器，质量也远不及 Jev。
• 本地化"平替"思路：用 llama.cpp / Ollama + 小模型 + 语法约束解码（grammar-constrained decoding）也能实现"schema 内不可能幻觉"的效果（该能力 2023 年起本地运行时就有）；Jev 真正额外卖的是 RLCD 校准的概率和真·并行多问题。

17. 与传统 LLM 的全方位对比

18. 命名由来与愿景

• System One：致敬卡尼曼《思考，快与慢》——快速直觉的"系统一"思维。官方认为 System One 模型可以比替代方案更可靠。
• Jev：致敬经济学家 William Stanley Jevons（杰文斯悖论：蒸汽机效率提升反而增加了煤炭总需求）。TypeSafe 预期机器智能会走同样的路——智能成本每下降一个数量级，就会解锁数量级更多的应用场景。
• 创始愿景：“AI 需要一个软件可以依赖的接口”——让新用例在社区和经济中持续扩散（continuously diffuse）。

19. 参考资料