类型安全（Type Safety）

一句话定义：类型安全（Type Safety）指模型可能输出的”结构”在请求发出前就被你定死了——它只能从你给的选项或档位里挑，返回值天然符合你代码期望的类型与 JSON schema，代码不必再从”生成的散文”里把值抠出来。

“System One is type-safe by construction. Decisions and probabilities conform to the structured software types and JSON schema your code expects, so it never has to recover a value from generated prose.”

中文：系统一模型从构造上就是类型安全的。决策与概率符合你代码所期望的结构化类型与 JSON schema，因此代码永远不需要从”生成的散文”里恢复一个值。

1. 输出结构提前定义

类型安全的第一步是先把答案空间写完再提问。官方发布博客的措辞：

“Type-safe structured values. Possible outputs and structure are defined in advance. The model never makes type errors. All answers are accompanied with calibrated probabilities and confidence scores.”

结构由三类原语（Primitives）承担：Choice 给出选项表（最多 255 个），Score 给出有序档位（至少 2 档、API 最多 10 档），Noul 给出”是 / 否”两种结果。模型返回的是在你给的选项上的一份概率分布：

“Every answer is constrained to the options you supplied. The model returns a probability distribution over your options or levels, never a value outside them. Your code never has to recover a value from generated prose.”

“Because every output is constrained to the supplied options, the model returns a full probability distribution over those options rather than inventing a value outside the schema.”

配套的最佳实践是给出完整列表并保留一个 other / none of the above 选项，让模型在列表覆盖不到输入时有地方落：

“Add an other or none of the above option when the list might not cover every input, so the model can say none of the others fit.”

2. 为什么”类型错误数学上不可能”

官方把”没有类型错误”列为可以被单条反例证伪、但实际证不了的硬声明：

“No type errors: This would be an easy thing to falsify with just a single counter-example, but it is mathematically impossible.”

原理是输出空间被约束住了：模型不是”生成一段文字再被解析”，而是直接在给定选项集合上输出概率。既然不存在”集合之外的值”这个输出通道，也就不能产生类型错误。官方在评测图上直接画了 0%：

“Our number is not empirical. Schema matching is guaranteed, thus we can confidently add 0% into the plots.”

首页把这条宣传成一句更口语的话：“Zero Hallucinations”（零幻觉）。

3. 与幻觉的关系

官方把两者直接挂钩，并认为类型安全是自动化的入场券（table stakes）：

“Hallucination and type-safety are intrinsically related, and we think the latter is table stakes for automation. Having a hallucinated tool call is inconvenient in an agent, but is an absolute deal-breaker if it’s part of a system with latency guarantees or it’s buried several layers deep in a dependency chain. Existing models, no matter how smart, still hallucinate and have type errors.”

中文：幻觉与类型安全本质相关。一个幻觉出来的工具调用在智能体里只是”不方便”，但如果它处在一个有延迟保证的系统里、或埋在依赖链的好几层深处，那就是绝对致命的。现有模型无论多聪明，仍会幻觉、仍会有类型错误。

生成模型那边的对照描述是：字符串”can be anything: chat responses, code, hallucinations, refusals…”，而且”To be used by software, responses need to be parsed + validated. There is also always some risk that the AI goes off the rails.”——因为能写出任意文本，所以幻觉是可能的；判别式路线把输出收窄到选项上，切断了这条路（见判别式模型）。

4. 类型安全 ≠ 答案正确（必须区分的两件事）

官方自己把边界划得很清楚，这是本页最容易误读的地方：

不编”格式”，不等于不答”错”。 模型可以在你给的选项里挑错一个，也可能被材料里的对抗内容带偏。缺陷清单里明确写着：“State is data, and jev-1.13 does not treat it as hostile by default. Content written to adversarially steer the model… can move the answer.”
字面理解也是错的来源：“jev-1.13 answers the question you wrote, not the one you meant.”
不要指望”结构不变式”：同一个退款问题，用 Noul 问是 0.22，用 Choice 问”是”却是 0.01；问”要退款吗”与问”要的不是退款吧”，两个概率加起来是 1.19（本该接近 1）。官方结论：不要依赖这种想当然的自洽。
校准不保证单条：校准是在一群预测上度量的，“it does not guarantee that an individual answer is correct.”

所以类型安全保证的是接口层面（结构、类型、能不能被代码安全消费），不是语义层面（这次判断对不对）。后者要靠你自己的数据测阈值、靠置信度门控来兜（见系统一模型）。

5. 为什么它对 Jev 是”能不能用”的前提

Jev 的价值主张是”像代码一样可靠”：

“LLMs produce words for people. Jev produces typed decisions and is more like code: reliable, fast, self-consistent, and type-safe.”

只有输出是类型化的，代码才能直接 branch / sort / route，才谈得上”在后台跑一百万次、不需要人盯着”。官方文档里那句”design AI-powered software”的整个设计流程——原子化提问、代码里做确定性的分支与副作用、用概率与置信度决定放行还是升级——都建立在”答案是类型化值”这个地基上。一旦需要从散文里解析，这层地基就没了。

Agent 系统性学习

探索

类型安全（Type Safety）

类型安全（Type Safety）

1. 输出结构提前定义

2. 为什么”类型错误数学上不可能”

3. 与幻觉的关系

4. 类型安全 ≠ 答案正确（必须区分的两件事）

5. 为什么它对 Jev 是”能不能用”的前提

相关来源

关系图谱

目录

反向链接