从 TypeSafe AI 的 System One Model，看 LLM 应用架构与软件工程的下一步

核心命题：如果程序只需要一个决定，为什么要先让 AI 写一段话？

过去几年，我们习惯了一种 AI 应用模式：把问题交给大语言模型，让它生成一段文字，再把文字解析成程序能够使用的结果。

但很多业务根本不需要文字。

一张工单应该分给哪个团队？一次工具调用是否应该放行？一组候选答案中哪个更好？这些问题真正需要的，是类别、分数，以及可供程序使用的不确定性信息。

TypeSafe AI 推出的 Jev，就是围绕这类任务设计的。官方将其称为 System One Model：接收上下文与结构化问题，返回带类型的决策及概率，而不是生成开放式文本。Pydantic 的相关文档也明确强调：Jev 不是一个用来写文本的语言模型。

它值得关注的地方，不只是"又出现了一个更快的模型"，而是一个更根本的问题：

如果程序只需要一个决定，我们为什么要先让 AI 写一段话？

一、先理解 Jev：它不是聊天助手，而是语义决策组件

假设我们正在开发客服系统，收到这样一条消息：

"上周买的会员重复扣费了，机器人一直让我重试，我要人工处理。"

使用 LLM 的常见方式是：

阅读这条消息，判断应该转交哪个团队。
只能输出 billing、technical、account 或 other。
请返回 JSON。

应用再读取：

{"department": "billing"}

而 Jev 所代表的交互方式更接近：

输入：用户消息
问题：应该转交哪个团队？
答案空间：billing / technical / account / other
输出：选择结果及相关概率

示例：一条"重复扣费"消息被直接映射为 billing（92%），附带完整的概率分布，而不是先生成一段文字再解析。

关键变化在于："答案属于什么类型"成为模型接口的一部分，而不只是提示词中的要求。

官方与相关开发者文档将 Jev 的输出组织为三类基本形式：Choice、Score 和 Noul，分别覆盖选择、评分和带概率的二元判断。

可以把它们理解为：

Jev 的三种输出原语：Choice（选）、Score（评）、Noul（判），覆盖了大多数自动化决策的表达需求。

这意味着，Jev 更适合成为软件内部的一个决策节点，而不是直接面向用户的通用对话入口。

二、"System One"究竟意味着什么？

1. 它强调的是快速判断，而不是长篇生成

"System One"借用了快思考与慢思考的类比。TypeSafe 用这个概念描述 Jev 所面向的快速、结构化决策任务；相关公开介绍也将 Jev 描述为非自回归模型。

理解这个区别，可以先看两个抽象过程。典型自回归语言模型生成文本时，会依次预测输出 token：

输入 → token 1 → token 2 → token 3 → …

而决策模型的产品接口更像：

上下文 + 问题 + 答案约束 → 决策结果

慢思考：逐 token 生成长文本；快思考（System One）：一步直达决策结果。注意"非自回归"描述的是计算方式，不自动代表"不会出错"。

下面这个数学表达只是帮助理解的抽象，并非 Jev 已公开的内部网络结构：

fθ(x, q, A) → P(y ∣ x, q, A)

其中：

• x：待判断的上下文；
• q：问题；
• A：允许的答案集合或评分标准；
• P(y∣x,q,A)：对候选结果的不确定性表达。

工程上的吸引力很直接：如果最终只需要一个类别，就有机会避免为一段不必要的生成文本付出成本。

但需要注意： · 非自回归描述的是计算方式，不自动代表"不会出错"；System One 是产品定位，也不能直接当作模型内部认知机制的证明。 · 现有公开介绍足以解释产品行为，但不足以据此还原其完整网络架构、训练目标或推理实现。

2. 这和传统分类器有什么区别？

分类、排序、评分，本来就是机器学习的老问题。因此，Jev 的意义不应被理解为"发明了分类"，而应从产品形态上理解：

• 传统分类器通常围绕相对固定的标签体系训练；
• LLM 可以通过自然语言描述临时任务，但常以文本生成作为交互方式；
• Jev 则把"上下文理解、自然语言问题和有类型决策"组合成一个面向自动化的模型接口。

演进路线：固定标签的模具（传统分类器）→ 先写作再解析的作家（LLM）→ 直接举牌的裁判（Jev）。Jev 没有发明分类，它发明的是一种面向自动化的接口形态。

它真正需要接受的检验是：

在不为每个任务单独训练模型的情况下，这种通用决策接口，能否在目标业务上同时满足质量、成本、延迟与可靠性要求？

这比争论"它是不是一种全新的 AI"更有工程价值。

三、它与 LLM 的关系：不是全面替代，而是重新分工

1. 先把"LLM 也能返回 JSON"说清楚

LLM 并非只能自由输出文字。结构化输出、函数调用和约束解码，都可以让 LLM 返回程序可消费的结果。

因此，Jev 与 LLM 的区别，不能简单归结为：Jev 有类型，LLM 没类型。更合理的比较维度是：

表中 Jev 的定位来自官方及开发者文档；这不是对两者所有能力的穷尽比较。

2. 更有价值的组合：LLM 提方案，决策模型做筛选

一种值得试验的架构是：

用户请求
   ↓
任务分类与路由
   ├─ 简单明确 → 确定性业务流程
   ├─ 需要生成 → LLM
   └─ 高风险或不确定 → 更强模型 / 人工

对于 Agent，还可以进一步分工：

LLM 生成候选行动
        ↓
决策模型评估候选行动
        ↓
确定性权限与业务规则校验
        ↓
执行工具

推荐分工：LLM 负责开放式理解、规划和生成（提方案），决策模型负责局部、边界明确的判断（做筛选），最后永远保留一道确定性校验。

这里，LLM 负责开放式理解、规划和生成，决策模型负责局部、边界明确的判断。

但必须保留最后一道确定性校验：模型认为"应该执行"，不等于系统已经获得"执行权限"。

例如，模型可以判断"这看起来是一笔正常退款"，但退款金额上限、账户权限、审批状态与幂等性，都不应该交给概率判断来决定。

四、它真的快几百倍、便宜几百倍吗？

关于 Jev 的传播中，最醒目的数字是性能和成本。

LangChain 的介绍转述了 TypeSafe 的宣称：在分类任务上，相比可比较的 LLM，推理速度最高可达约 200 倍、成本最高可降低至约四百分之一。Browserbase 的介绍则给出了 20—200 倍速度和 40—400 倍成本差异的范围，并明确将这些数字归于 TypeSafe 的基准测试。

这些数字应当加上三个限定：

• 它们是厂商宣称或对厂商基准的转述。
• 它们对应特定任务与对比条件。
• 模型调用的收益，不等于整个应用的收益。

宣传数字很醒目，但别忘了 Amdahl 定律：模型决策只占链路的一小部分，整体加速要按全链路来算。

举个纯假设的例子：

一个工作流中，模型决策占总耗时的 20%，剩下 80% 是数据库、网络和工具执行。即使决策环节加速 100 倍，整体加速也只有：

S = 1 / (0.8 + 0.2/100) ≈ 1.25

因此，采购或迁移前应比较的不是单一宣传数字，而是：

• 相同业务测试集上的准确率、误报率和漏报率；
• 达到相同质量门槛时的成本；
• P50、P95 和 P99 延迟；
• 并发、超时、重试和回退行为；
• 整条链路的最终成功率。

真正有意义的是**"每完成一个合格业务结果的成本"**，而不只是"每次调用的价格"。

五、"类型安全"和"概率输出"，究竟能保证什么？

这是理解 Jev 时最容易混淆的地方。

1. 类型正确，不等于判断正确

假设允许的结果只有：

ALLOW / REVIEW / BLOCK

模型返回 ALLOW，在类型上完全合法。但如果这笔操作实际上应该被拦截，系统依然发生了严重错误。

所以至少要区分三层正确性：

有类型的接口主要解决第一层（结构正确）。第二层需要评测，第三层需要系统设计。不能把"不会生成答案集合之外的文本"扩大成"不会发生业务误判"。

有类型的接口主要解决第一层。第二层需要评测，第三层需要系统设计。

不能把"不会生成答案集合之外的文本"，扩大成"不会发生事实错误或业务误判"。

2. 有概率，不等于概率已经可靠

官方与相关介绍强调 Jev 返回概率，并使用了"校准"这一描述。但在你的业务中，这些数值是否可靠，仍然需要验证。

例如，模型给出：

P(可以自动处理) = 0.95

这不意味着当前个案必然有一个可直接保证的"95% 正确率"。概率校准通常关注的是：在大量相似预测中，被模型赋予约 0.95 概率的事件，是否确实以接近 95% 的频率发生。

概率校准看的是群体频率而非个案保证：被赋予 0.95 概率的事件，在大量样本中是否真的以接近 95% 的频率发生？落地前请看可靠性图与 Brier Score。

因此，落地时应关注：

• 可靠性图；
• Brier Score 等概率质量指标；
• 不同业务分组的校准表现；
• 自动处理覆盖率与错误率之间的关系；
• 数据分布变化后的性能。

概率最有用的用途，不是给用户一个看似精确的数字，而是帮助系统决定：什么时候自动执行，什么时候升级处理，什么时候拒绝作答。

六、哪些场景最值得落地？

下面是基于 Jev 接口形态提出的应用设计建议，不是已经被统一验证的客户效果。

四个值得试点的方向：客服分流、Agent 动作审核、RAG 相关性筛选、研发局部评审。共同点是：高频、边界清楚、可评测、可回滚。

场景一：客服、邮件与工单分流

输入是非结构化文本，输出是有限的部门、意图或优先级。可以采用：

高置信度 → 自动分流
低置信度 → LLM 进一步分析
敏感类别 → 人工复核

这是一个适合试点的方向：标签明确、历史数据较容易整理、错误通常可回滚，也容易与现有系统做对比。

需要防止的问题是：如果选项中没有"其他"或"无法判断"，系统可能把陌生问题强行归进已知类别。

场景二：Agent 的动作审核与工具路由

Agent 准备调用工具前，可以提出局部问题：

• 这个动作是否回应了用户请求？
• 当前信息是否足够执行？
• 是否应该升级为人工审批？
• 多个候选工具中哪个更匹配任务？

建议把它作为辅助判断层，而不是安全边界本身。

语义判断
   +
确定性权限、金额、资源范围校验
   =
是否允许进入执行阶段

即使输出只允许"是或否"，恶意输入仍可能诱导模型选错；答案空间受限，并不自动解决提示注入。

场景三：RAG 的相关性判断与候选筛选

在检索增强生成中，可以试验让决策模型负责：

• 判断检索片段是否相关；
• 为候选证据按标准评分；
• 判断是否需要继续检索；
• 从多个候选答案中选择较合适的一项。

一个可能的流程是：

检索 → 相关性筛选 → LLM 生成 → 证据检查 → 输出或回退

这里有一个容易忽略的陷阱：分别得到的分数，未必天然适合跨查询、跨评分标准比较。排序效果仍应通过专门的检索评测验证。

场景四：软件研发中的局部评审

可以探索的任务包括：

• 判断 PR 是否涉及数据库迁移；
• 为变更选择评审团队；
• 按明确清单检查发布条件；
• 对测试失败进行初步分类。

更稳妥的定位是：补充人工和确定性工具，而不是取代编译器、测试、安全扫描与代码评审。

"模型认为变更风险低"不应成为跳过测试的理由。

七、怎么真正接进生产系统？

不要一开始就重构整个 Agent。更好的方式是挑选一个高频、边界清楚、可评测、可回滚的决策点。

落地四步：定义决策契约 → 建立多方基线 → 把输出包进业务策略 → 影子运行再逐步放量。工程重点不在那一行模型调用，而在阈值、降级、审计与漂移监控。

第一步：定义决策契约

至少明确：

输入：模型能看到哪些信息？
输出：允许哪些标签或评分？
规则：每个标签的业务含义是什么？
弃权：何时算无法判断？
回退：转给谁处理？
后果：误判会造成什么损失？

这比单纯优化提示词更重要。

第二步：建立多方基线

不要只比较 Jev 和一个昂贵 LLM。至少考虑：

• 确定性规则；
• 传统分类器或小模型；
• LLM 结构化输出；
• Jev。

否则，可能只证明了"原来的实现过度使用了大模型"，却没有证明 Jev 是最优方案。

第三步：把模型输出包进业务策略

以下是架构伪代码，不是 Jev 官方 SDK 调用方式：

def route_ticket(ticket):
    result = decision_adapter.evaluate(
        context=ticket.text,
        question="这条工单应交给哪个团队？",
        choices=["billing", "technical", "account", "other"],
    )

    # 阈值必须来自业务验证，而不是拍脑袋设定
    threshold = policy.threshold_for(result.choice)

    if result.choice == "other":
        return fallback_queue(ticket)

    if result.confidence < threshold:
        return deeper_analysis(ticket)

    if policy.requires_review(ticket, result.choice):
        return human_review(ticket)

    return assign_ticket(ticket, result.choice)

工程重点不在那一行模型调用，而在：

• 阈值如何确定；
• 不同类别是否需要不同策略；
• 失败时如何降级；
• 如何审计和回滚；
• 如何发现性能漂移。

第四步：先影子运行，再逐步放量

建议顺序是：

离线评测
  → 影子运行，不影响真实决策
  → 低风险流量灰度
  → 分类别扩大自动化范围
  → 持续监控与复评

同时记录模型版本、问题模板、答案集合、策略版本和最终业务结果。否则，模型或提示变化后，很难判断到底是哪一层导致性能退化。

八、它可能怎样影响软件工程？

如果这类产品被证明有效，AI 软件可能拆成四个职责清晰的组件：生成模型负责表达、决策模型负责选择、检索系统负责证据、确定性程序负责约束与执行。

1. AI 能力将不再只有"聊天接口"

如果这类产品在真实业务中证明有效，AI 软件可能进一步拆成不同组件：

生成模型：负责表达和方案
决策模型：负责选择与评分
检索系统：负责获取证据
确定性程序：负责约束与执行

这是一种架构判断，而不是已经完成的行业结论。它的价值在于：不必让一个模型包办所有事情，而是让每个组件承担更清晰、可测量的职责。

2. API 契约将开始容纳"不确定性"

传统函数往往返回：

function classify(input: string): Category

概率性决策组件则可能需要：

type Decision<T> = {
  value: T
  confidence: number
  policyVersion: string
}

这不是 Jev 的实际 API 定义，而是一种工程封装建议。

变化在于：调用者不再只处理"成功或异常"，还必须处理"合法但不够确定"的结果。不确定性会从模型内部的问题，变成应用接口必须明确表达的状态。

3. 测试将从单点断言扩展到统计保证

传统测试可以断言：

输入 A，必须输出 B。

概率性组件还需要回答：

• 在哪些样本上错误最多？
• 特定类别的漏报是否超出容忍范围？
• 自动化覆盖率提高后，错误是否同步上升？
• 新版本是否破坏了旧业务的关键指标？

因此，黄金测试集、分组评测、影子发布和线上反馈，会成为 AI 软件测试的重要组成部分。

4. 工作量会从"解析输出"转向"治理决策"

结构化决策接口有望减少一部分 JSON 修复、格式重试和文本解析工作。但它不会消除工程复杂性，而是改变复杂性的分布：

从"让模型按格式说话"，转向"定义正确的任务、验证概率、管理风险，并控制执行后果"。

这一变化，可能比单次调用便宜多少更深远。

结语：Jev 真正挑战的，是"所有 AI 任务都应该交给 LLM 生成"

Jev 的公开定位很清楚：它不生成开放式文本，而是面向结构化问题返回有类型的决策和概率。

它是否适合你的系统，最终取决于业务评测，而不是"System One"这个名称，也不是最高几百倍的性能数字。

更值得记住的是三点：

• 不需要生成文字的任务，未必应该通过文字生成来完成。
• 类型约束能改善接口可靠性，但不能代替语义正确性与业务安全。
• LLM、决策模型与确定性软件，更可能形成分工，而不是彼此完全替代。

对于工程团队，最好的起点不是"全面换掉 LLM"，而是找出系统里那些一天执行成千上万次、最终只需要一个类别或判断的节点。

然后问一个简单的问题：

这里真的需要一个会写作的模型，还是只需要一个能够被测量、被约束、会在必要时交还决定权的决策组件？