Jev 在 9 月 15 日发布，几天之内就出现在我关注的开发者讨论里。TypeSafe AI 把它称为第一个公开的 System One 模型。它接收一段状态和一组带类型的问题，返回选择、评分或是非概率，让程序直接使用。它不负责写一段给人阅读的答案。
真正留在我脑子里的，其实不是这些参数。让我反复想到的是这个架构设计思想，System One 来自 Daniel Kahneman 的《思考，快与慢》。我当时读它就是当成心理畅销书来读的，没想到居然由此能涉及到大模型以及具身智能的架构设计思路。书里讨论了快速、自动的判断怎样和缓慢、审慎的推理相互作用。Jev 当然不等于人类认知系统，但是这个比喻依然能带出一个很好的工程问题。哪些工作应该快速、重复地完成，哪些工作需要停下来认真想一遍？
放进工作流里的判断模型
软件里到处都是小判断。浏览器 Agent 要选下一个按钮，编码 Agent 要决定某条工具输出有没有用，客服系统要给消息分流，评估器要判断一个 Agent 到底有没有完成任务。
现在这些事情经常全部被交给通用语言模型。模型读取状态，用 token 推理，再输出一段字符串，周围的程序还得把字符串解析回来。Jev 改变了这次交互的形状，应用先把可能的答案写清楚，Jev 返回带类型和概率的结果。
这个吸引力很好理解，从一个列表里选一项，不需要先写一段解释。多个互相独立的问题可以一起发送，置信度可以变成普通代码里的规则，结果足够可靠时自动继续，拿不准时交给更强的模型或人。
这里也要把那些宣传数字放回原来的范围，TypeSafe 目前公布的价格是每百万输入 token 0.042 美元，输出 token 免费。针对 System One 形状的问题，官方报告的端到端延迟在几十到几百毫秒之间。更大的速度和成本比较来自特定工作流，对照模型还加了结构化封装。Jev 自己的文档也列出了按字面理解、数字精度、日期比较、多步间接推理、无关长上下文和对抗性内容等已知不足。
带类型的输出可以消除一类接口错误，却不能保证判断正确，它完全可能从一份合法的选项列表里选错答案。
早期案例比口号更有意思
Jev 周围已经出现了一些项目，它们让 System One 的思路更容易看清楚。
jev-ultrafast 把网页整理成带编号的控件。Jev 选择下一步动作和目标，另一个模型在表单需要文字时负责生成输入。这个分工之所以合理，是因为动作空间已经被浏览器状态限制住了。项目展示的 7 秒航班搜索有明确的计时排除项，不能直接当成相对于 Codex 的通用加速证明。
jev-browser-use 更接近我现在使用浏览器工具的方式。Codex 给出目标和边界，Jev 在已有浏览器连接里连续完成观察、选择和执行。置信度低、页面没有进展、状态过期，或者需要视觉解释时，控制权再交回 Codex。这里可能省下的是慢模型回合。如果每次 Codex 动作前都额外加一次 Jev 请求，账就要重新算。
Foreman 展示了另一种分工。Codex worker 继续自己的编码循环，旁边的监督循环读取输出、差异、测试和耗时等有限证据。Jev 估计 worker 是否卡住、偏离或已经需要验证，普通代码再决定继续、引导、停止、重试还是验证。项目自己把它称为架构实验，这个判断很稳妥。
具身智能里的案例把这件事说得更清楚。Figure 的 Helix 报告描述了两套异步系统，慢的视觉语言系统以每秒 7 到 9 次的频率更新语义 latent，快的视觉运动策略读取最新观测和最近的 latent，以 200 Hz 输出连续动作。快系统不需要等慢系统完成一次新的解释，仍然可以根据正在变化的世界调整动作。GR00T N1 论文也把这种双系统设计与 Kahneman 联系起来，并让视觉语言模块和动作模型通过学习到的特征协作。
这些案例没有证明 Jev 适合所有控制回路，它们共同展示了一个更宽的工作模式。快速行为需要新鲜观测和较小的动作空间，慢速推理负责改变目标、表示或策略，直到当前的熟练动作不够用了。
我为什么决定观望
Jev 公开还不到一周。它处于早期访问阶段，服务本身很新，周边生态也在快速堆出各种演示。一个新想法刚出现时，最容易被第一波热度放大。
我想等热闹过去以后再看几件事。低置信度结果有多少真的进入了有效的后备流程？面对脏数据、长上下文、非英语文本和不断变化的网页，阈值还能不能保持稳定？看起来省下的时间有多少来自减少慢模型往返，又有多少会重新花在观察、OCR、网络延迟、重试和最终验证上？
我找到的第一个 Codex 对照实验，正好说明了我希望以后看到的证据。一个小项目在几组每组 64 条的合成标注任务中，报告了更少的 Codex 输入和更短的耗时。它也保留了早期失败结果，承认数据干净而且带模板，并提醒读者把额外的 TypeSafe 推理计入成本。这样的披露让结果更可信，哪怕它还不能回答所有问题。
所以我现在的态度很简单。我对这种架构感兴趣，但还没有准备把它接进每天的工作流，我愿意先让子弹飞一会儿。
接下来我会看什么
在 Codex 里，我想观察快模型能不能完整接管一小段边界清楚的工作，比如批量分类或重复的证据筛选。一个只介绍 API 调用方式的 skill，价值主要在文档层面。真正的 System One 层需要减少慢模型工作，同时留下可复核的证据和安全的回退路径。
在浏览器和桌面操作里，浏览器更适合先做验证。DOM 或无障碍树能提供比较明确的候选动作，通用桌面仍然高度依赖截图、OCR、无障碍覆盖和视觉理解，只换一个判断模型，解决不了这些部分。
Jev 让我重新看见了一个早于这个模型的问题。智能系统不必在每一步都使用最昂贵的推理方式，但它需要知道什么时候快速判断已经够用，什么时候状态已经过期，以及什么时候该慢下来。
眼下，我更愿意先把这种分工看明白，再决定要不要安装与使用它。