System One模型与微推理架构

# System One模型：智能体软件之后的下一步

TypeSafe本周发布了Jev——一个专为快速语义决策而构建的模型，而非用于生成内容或长链推理。你向它提供状态和带类型的问题，它返回选择、分数或概率。TypeSafe报告的延迟低至70ms，定价也低到足以比我们今天围绕其构建应用的前沿模型频繁调用得多。(https://typesafe.ai/) (https://typesafe.ai/blog/introducing-system-one-models-and-jev)

Jev的出现正值AI架构的一个有趣节点。智能体时代已全面到来，其解锁的关键在于模型在推理多步骤问题和可靠调用工具方面已足够出色。我们都正在围绕这些能力重新组织自己的应用程序，构建长周期智能体循环、执行框架和软件工厂。

但System One模型并非为构建智能体而设计。它们的价值或许在于将少量语义智能分布于整个应用程序，而非将其集中在智能体内部。(https://typesafe.ai/blog/introducing-system-one-models-and-jev)

这引出了一个更大的问题：它们将使哪些新类别的AI软件成为可能，我们又将如何构建它们？

## 新的微推理时代？

大多数智能体架构将非确定性集中在一个循环内部。周围的系统负责组装上下文并暴露工具。模型解读当前情况，决定下一步行动，执行动作，观察结果，然后继续。

这形成了一个相当清晰的架构边界。确定性软件管理智能体周围的环境，而非确定性决策则发生在循环内部。近期大量智能体基础设施的重心，正是通过权限控制、结构化输出、状态管理和确定性编排来管控这一边界。

System One模型允许推理跨越这一边界移动。路由与验证现在可以包含语义判断。状态转换和依赖解析可以依赖模型输出。应用程序无需将一大块工作送入模型循环，而是可以在代码各处单独且细粒度的决策点上调用智能。

这为我们提供了一种组合AI软件的不同方式。智能体将智能打包进一个接收任务并决定如何执行的工作单元；而"微推理"则能更原生地将智能编织进围绕它的整个系统中。

## 更精细的确定性边界

AI构建者已花费大量时间决定什么归属于代码、什么归属于模型。路由、权限、重试、依赖和状态转换正越来越多地迁移到确定性基础设施中。模型则用于系统需要解释或判断的地方。

System One模型将这种分离推向更细粒度的层面。应用逻辑中的单个分支可以依赖语义判断，或者验证器可以包含推理。你也可以构建依赖于概率的状态转换。

这意味着代码库本身可能包含更多的非确定性。不再是确定性代码与大体量模型调用之间有一条清晰的边界，我们将开始看到更小的模型调用散布于整个代码库之中。

在系统层面，情况将恰恰相反。应用程序将明确定义更多自身的控制流，并掌握更多编排工作，因为它们不再需要将大量决策面交给推理模型处理。例如，模型可以判断某个需求是否得到满足，而由软件来决定相应的后果。

换句话说，更多的单项决策可以引入推理，而更多的应用行为则仍以软件的显式建模来表达。

## 推理融入架构之中

Jev 的设计围绕 TypeSafe 所称的"系统一"任务展开。它做出快速决策，而非执行我们日益期待前沿模型完成的那种较慢的深思熟虑式推理。广泛使用这一模型类别，会引发一个关于推理在哪里发生的架构层面的问题。

如今，我们通常将整个语义问题交给一个推理模型，让它自主完成问题分解、采取行动并给出解决方案。

一个围绕廉价决策模型构建的系统，需要在更高的代码层级完成这种分解。应用程序不再询问某个模型某一实现是否满足规范，而是可以将规范拆解为单个需求，再询问较小的模型每项需求是否得到满足。随后，代码可以汇总这些答案，标记出存在分歧的部分，并将少数未解决的需求发送给推理模型处理。

在这一架构中，推理模型仍有其用武之地。它可以处理模糊情况、调查缺失证据，或执行那些无法拆解为更小判断的工作。只是它不再需要承担整个计算过程。

这为 AI 架构带来了另一个维度。构建者可以选择有多少推理发生在前沿模型内部，有多少通过软件与较小模型的组合来表达。

## 对微推理基础设施的需求

需要做出数千个小型语义决策的应用程序，将需要围绕截然不同的推理模式构建基础设施。在应用程序的每个分支中直接调用模型 API，很快就会在延迟、成本、一致性和可观测性方面造成问题。

我预计围绕这一微推理层将会涌现出相应的库和运行时（一切就绪，出发）。它们可以将独立判断批量处理为针对共享状态的操作，在输入未发生实质性变化时缓存结果，并并行执行大量决策。它们还可以维护置信度阈值，并判断某项决策何时需要上报升级。

模型路由也被下沉至该层。廉价的决策模型处理常规判断，而不确定的情形则转交给更强的模型。推理模型可以成为需要分解或调查的决策的上报路径。高风险判断可在应用程序采取行动之前，经由多个模型或确定性检查进行处理。

编程抽象可以不再局限于调用特定模型。开发者定义具有类型化输入输出的语义操作，由运行时决定这些操作如何执行。

## 通用语义模型进入控制循环

将推理嵌入应用程序执行过程中，其实由来已久。自动驾驶汽车在运行过程中持续调用感知与预测模型，同时由传统软件负责协调规划、安全约束与控制。Waymo 将其当前架构描述为以 ML 为主导，异构神经网络与负责编排及其他非 ML 工作的传统计算并行运行。(https://waymo.com/blog/2026/08/look-under-our-trunk/)

这类架构通常依赖于专用模型。感知模型识别某一特定类别的对象，欺诈模型预测某种特定风险。每个模型都围绕相对单一的操作构建。

语言模型为开发者提供了更为广泛的语义能力，但其延迟和成本促使人们倾向于更大粒度的推理单元。我们围绕生成调用构建聊天应用，围绕推理循环构建智能体，因为这些都是封装昂贵通用智能的自然方式。

System One 模型将通用语义判断能力拉近到了嵌入式 ML 的运行特性范围之内。开发者可以通过输入和类型化输出来定义新的语义决策，而无需为每个决策专门训练一个分类器。

因此，自动驾驶系统中常见的架构模式，如今也开始出现在普通的商业和开发者应用中。

## The Doom Demo Shows the New Execution Model

TypeSafe 演示了 Jev 以大约每秒十次模型调用的频率运行《毁灭战士》。应用程序提供结构化的游戏状态，并反复要求模型选择行动。其中值得关注的架构特性，在于通用语义模型参与应用程序控制循环的频率。(https://typesafe.ai/blog/introducing-system-one-models-and-jev)

这种模式与智能体接收任务后持续工作直至完成的方式截然不同。游戏持续运行，推理则反复贡献细粒度的决策。智能成为执行路径的一部分，而非作为独立工作单元被调用的外部工作者。

同样的结构也可以出现在与游戏相去甚远的应用中。开发系统可以在变更发生时持续评估哪些需求和制品受到影响；安全系统可以在行为发生的同时，依据意图和策略对其进行解读；业务应用可以随着底层状态的变化，持续重新审视已有的工作成果。

这些系统在需要完成大量工作时，仍可调用智能体。而判断工作是否需要发生的决策，则可以来自已经贯穿应用程序运行的更细粒度的智能层。

## What Comes After Agentic Software

智能体时代源于模型可靠能力的转变。一旦模型能够跨多个步骤进行推理并使用工具，构建者便围绕这些能力创建了相应的架构。智能体循环成为当前这一代 AI 软件最具代表性的抽象之一。

System One 模型赋予我们一组不同的属性来围绕其进行设计。由此产生的应用程序，其模型推理的调用量可能远超今日的智能体系统，但对智能体控制行为的依赖却会减少。智能体将成为更大智能架构中的一个组件，而非架构本身。

聊天软件围绕生成来组织。智能体软件围绕推理和工具使用来组织。像 Jev 这样的模型为开发者提供了另一种围绕其组织软件的模型原语，而我们才刚刚开始看清那种软件的面貌。