「模型已经超级会聊天好几年了，自动化在哪里？」——TypeSafe AI 创始人 Diogo Almeida 用这个问题开场。他曾参与构建让语言模型学会遵循指令与对话的方法，相关工作成为 ChatGPT 背后的研究基础。他的判断是：聊天模型很强，但缺了一块关键东西。
缺的那块，他认为是输出的类型。
一、主张：把智能做成函数调用
TypeSafe 在隐身两年后发布了第一类 System One Model，第一个公开模型叫 Jev，目前是早期访问。核心主张可以用项目方自己的一句话概括：
Jev 是一个前沿智能级别的函数调用：非结构化的状态输入，类型化的概率决策输出。
它明确放弃了字符串生成。换来的能力是：
- 不可能有类型错误——所有可能的输出与结构在调用前由 schema 定义好；
- 每个输出都附带校准过的置信度与不确定性分数；
- 不能幻觉——因为它无法构造 schema 之外的东西。
代价也很直接：它不能写代码、不能写文档、不能做开放式对话。这不是一个更强的通用模型，是一个被换掉了输出空间的专用模型。
二、与现有 LLM 的对比
项目方给出的对照表，信息密度比宣传语高得多：
| 维度 | 现有 LLM | System One 与 Jev |
|---|---|---|
| 优化方法 | RLHF / RLVR | RLCD（面向校准决策的强化学习） |
| 优化目标 | 人类偏好、可验证奖励 | 认识上诚实的概率 |
| 输入侧重 | 顺序排列的消息 | 结构化的程序状态 |
| 输出 | 字符串（需解析与校验） | 类型化的结构化值 |
| 采样 | 顺序，逐 token | 并行，一次查询产出全部输出 |
| 输入成本 | 每百万 token 0.20 到 10 美元 | 每百万 token 0.042 美元 |
| 输出成本 | 约为输入的 5 倍 | 不计费 |
| 端到端延迟 | 3 到 329 秒 | 70 到 500 毫秒 |
延迟那一行是整张表里最有冲击力的。它不是把同一个任务做得更快，而是换掉了任务的形态：不再需要生成一段文字再解析，而是直接产出决策。
三、评测方法值得单独看
那组「193.6 倍更快、444.6 倍更便宜」的数字来自一套自建的 workflow evals。方法设计得比常见做法讲究：
1. 假定存在一个正确的计算图（用代码写出的工作流）
2. 所有模型放进完全相同的工作流，不允许各自改 harness
3. 以最贵最强的外部模型的预测概率作为参考
4. 比较各模型输出与参考概率之间的差距关键在于第 1 与第 2 步：它不优化某个标准答案的分类准确率，也不允许模型改自己的 harness。这一点很重要，因为如果允许改 harness，评测很容易变成 harness 工程能力的比拼而不是模型能力的比拼。
项目方也主动交代了几处偏差，这在产品发布里不常见：
- 参考概率取的是两个特定前沿模型的平均，因此偏向 OpenAI 与 Anthropic；
- 因此这一设定很可能低估了自家模型与 DeepSeek；
- 工作流由自家能力团队构造，虽然不在训练分布内，但可能仍存在偏好；
- 声称的倍数来自首页宣传，项目方判断「属于真实收益中偏高的一端」。
四、两个演示暴露了适用边界
Doom 演示：用结构化游戏状态作为输入的实时 bot，每秒约 10 次查询，成本约每小时 7 美元。这个数字之所以有意思，是因为它标出了实时 AI 应用的可行成本线——项目方的工程师原本担心 10 QPS 会太贵，结果低于预期。同时项目方也承认：非 AI 的 bot 能打得更好，他们想要的是「对不同状态表示作出反应且遵循指令」的 bot。
Wikiracing 演示：在维基百科页面间只靠链接跳转，每一步要在几百到几千个链接里选。这个任务测的不是「智能每秒」，而是高基数选择下不幻觉带来的复利收益——一次虚构的链接会让整条路径作废。项目方提到 Jev 支持的最高基数是 255，更高的基数走两阶段（先独立打分再显式选择），这也就是演示里偶发变慢的原因。
两个演示共同划出了它的主场：高频、结构化、单步决策、且错误代价高的场景。
五、该保留的怀疑
第一，评测是自建的，参考系也是自选的。项目方对偏差的披露很诚实，但诚实披露偏差不等于偏差被消除。193 倍与 444 倍应当在自家工作流上复核，而不是当作可迁移的数字。
第二，「不可能幻觉」是一个受限的真命题。它成立于「输出空间由 schema 完全定义」这个前提之下。一旦你的 schema 里有一个自由文本字段（比如「备注」），这个保证就不覆盖那个字段。实际使用时，把 schema 设计得足够窄是获得这个保证的前提，宽 schema 会把它稀释掉。
第三，类型安全与价格可持续性都没有长期证据。类型安全是构造性的，可信度高；但输出不计费这条定价策略，项目方自己也承认「需要长期来证明其可持续性」。在依赖它做容量规划之前，这一点应当计入风险。
第四，放弃字符串是硬约束。任何一个下游环节需要「让模型解释一下为什么这么判断」，在这个架构里都得不到——你能拿到的是概率分布，不是理由。需要理由的场景得另外找地方生成。
第五，早期访问 + 单一区域服务。项目方说明服务目前位于美国西海岸，其公布的延迟数字也是在那边测的。跨区域使用的实际延迟需要自己实测。
六、不选它也可能用得上的东西
即使不采用 Jev，这个项目里也有一个可以直接用的产出：项目方开源了一个把通用 LLM 约束成结构化决策输出的适配器（system-one-adapter-python），并说明用它来让 LLM 输出兼容的概率决策，是他们得到的「最准确的方式」，代价是比不输出概率更慢更贵。
这实际上是一份免费的对照工具：在同一套 schema 下同时跑你的现有模型与 Jev，比较准确率、成本与延迟。项目方发布的工作流示例、分歧案例与完整查询都是公开的，可以据此复现而不是只看结论。
结语
Jev 真正值得关注的不是那些倍数，而是它提出的一个分类问题：你现在跑的这个 LLM 调用，到底是一次「生成」还是一次「判断」？
如果答案是后者——分类、路由、打分、抽取、在写死的代码逻辑太脆的地方当一个模糊 if——那么这个世界里逐 token 生成字符串确实是一种昂贵的浪费，模型输出还得被解析和校验一遍。如果答案是前者，那它就不在你的候选列表里。
这个划界动作本身，比多一个模型选项更有价值。