一个前 OpenAI 研究员，最近做了一个 AI。

这个 AI 有点特别：不会聊天，不会写文章，不会写代码，也不会陪你聊天。

你给它一段信息，再给它几个问题，它只负责告诉你：「是」还是「不是」；「A」还是「B」；「7 分」还是「8 分」。

这个看起来像「给大模型降维」的产品，最近却迅速获得了 AI 开发者社区的关注。

以客服系统为例：一条用户信息进来，程序需要确定的内容是：紧急程度如何？哪个部门对接？用户愤怒值有多高？

这些只需几个字段的答案，大模型往往先输出一大段的推理，最后还需要程序去长文本里提取结论，不仅增加了出错的概率，还消耗了大量推理时延与算力。

而 Jev 背后的公司，是前 OpenAI 研究员 Diogo Almeida 创办的 TypeSafe AI。

与主流趋势相反，Jev 砍掉了过去几年大模型最核心的能力——生成文字。它不会写文章、不会敲代码，甚至彻底放弃了生成自然语言。TypeSafe 给它的定义非常克制，「Decisions, not strings」——要决策，不要文本。

给它一段信息和几个提前定义好的问题，它可以直接返回选择、评分以及相应概率。例如收到一封客服邮件，Jev 可以同时判断应该分给哪个部门、紧急程度、退款风险以及是否需要人工介入。

这个给模型做减法设计的理念意外的爆火了，官方公布的数据很夸张：在特定工作流评测中，Jev 最高比对照大模型快 193.6 倍、便宜 444.6 倍，端到端延迟 70—500 毫秒，输入价格每百万 Token 0.042 美元，输出不按 Token 收费。

需要说明的是，TypeSafe 官方也明确强调，Jev 并不是通用 LLM 的替代品，而是要和生成式模型配合使用。

创始人 Almeida，曾是 OpenAI 研究员，也是 2022 年 InstructGPT 论文的主要作者之一，参与建立了后来广泛采用的 RLHF 训练流程。

OpenAI 在 GPT-4 贡献名单中也将他列入「Foundational RLHF and InstructGPT work」。

离开 OpenAI 后，Almeida 花了两年时间思考一个问题：如果大模型已经这么聪明，为什么世界上的大多数工作还没有被自动化？

Jev 就是 Almeida 给行业的答复，它不生成文字，不解释推理。你丢给它一个问题，它只回一个数字，但恰恰是这个数字，可能让 AI 从「聊天玩具」变成软件里真正能跑的决策引擎。

1、一个奇怪的问题：为什么 AI 已经这么聪明，软件还是不会自己干活？

回到 Almeida 那个问题：如果拆开一个 Agent 的实际运行过程，会发现它有大量工作根本不需要「思考」：比如是否要调用工具、是否转人工、这条信息是不是垃圾、这篇文章值不值得读、应该调用哪个模型、要不要继续执行……等等。

这些都是判断，不是生成。但今天几乎所有 Agent，都在用一个为「生成」而设计的模型去做「判断」。

TypeSafe 把 Jev 称为 System One Model，灵感来自卡尼曼的《思考，快与慢》：System 1 是快速直觉判断，System 2 是缓慢审慎推理。

Jev 并不是在证明自己「像人类的 System 1」，而是把 Agent 中大量低复杂度、高频率的判断任务：分类、路由、评分、二元判断单独抽出来，交给一个专门的模型。

因此 TypeSafe 的赌注是：当一次决策的成本降到可以忽略不计，开发者会把 AI 用在以前绝不会考虑的地方。

普通 LLM 用来做系统决策，真正麻烦的是三件事：

第一，输出太自由。系统明明只需要「urgent=true」，模型却可以写一段解释，程序还得去解析；加了约束也可能生成不符合 schema 的值、输出被截断，或编出不存在的字段。

第二，生成本身就是额外成本。哪怕最后只需要一个枚举值，也需要经过完整的文本生成过程：括号、引号、字段名、枚举值一个 Token 一个 Token 地吐，耗时从几秒到几十秒。

聊天场景人能等，程序里等不了——客服系统不可能让用户等 30 秒才分派工单。

第三，模型的「不确定」很难直接进入程序。程序真正需要的不是一句「我认为应该转人工」，而是一个可以直接用于阈值判断的信号：0.83，超过 0.8，自动转人工。

这就自然引出了 Jev。

Jev 的解法很直接：既然这些问题都源于「生成文本」，那就不生成文本。放弃字符串生成，专门优化决策，换来速度、可靠性和校准概率。

它提供了三类核心判断形式：Noul、Choice 和 Score。

Noul 负责 Yes/No 类型判断，Choice 从给定选项中选择答案，Score 根据预设标准进行评分。

每个结果都会附带一个数值：Noul 返回的是「是」的概率，Choice 返回各选项的概率分布，Score 则附带对该评分的置信度，多道问题还可以围绕同一份输入同时进行判断。

以用户发送消息给客服为例，当用户发来一条消息：「你好，打款连续 3 天失败了，请尽快处理！」

通用大模型的回答是：

根据消息内容分析，客户提到了「连续 3 天失败」和「请尽快处理」，表达了较强的紧迫感，因此可以判断这条消息是紧急的。建议优先处理……，然后程序得用正则或解析器从这段文字里把「紧急」这个结论提取出来。

但问题随之而来，这导致留给大模型的容错率会非常低，如果大模型写的是「比较紧急」，那么解析规则便直接挂掉，无法正确的提取到用户意图。

Jev 的回答是：{"noul": 0.92}，意思是这条消息有 92% 的概率是紧急的。

这就是 Jev 的核心逻辑：输入状态、并行决策、结构化输出。不废话、不写小作文，返回的就是置信数值，程序拿来就能执行。

Jev 的关键变化，不只是把输出格式从自然语言换成 JSON，而是连「生成」这件事都拿掉了。

普通 LLM 是一步一步生成答案，每个 Token 依赖上一 Token，像多米诺骨牌。

Jev 则把问题提前限定成有限的决策空间，让多个问题可以并行得到结果。

比如同一条客服消息，同时判断「是否紧急」、「应该分给哪个团队」、「客户情绪如何」，最终直接返回三个结构化结果。

它不是把一篇作文写得更短，而是从设计之初就没有打算写作文。

这意味着，系统即便临时追加数个判定维度，整体延迟也几乎不会改变——因为从一开始，它就不打算陪人类打字。

2、我们把它接进真实工作流：一个原本「鸡肋」的热点雷达被救活了

就在 Jev 推出了几天后，社区也衍生出了许多变体，Laya 、Kev 等开源项目。恰好硅基流动也一口气放出三款决策模型：diffusiongemma、Kev-4b、SemIf。

这类砍掉文本生成的模型，在基准测试上的数据还挺强。但我们最关心的是：在真实的业务场景里，它到底能不能跑通？又该怎么用？

我们结合豆包工作实测了几个案例，探一探它们的能力究竟如何。

先拿内部最头疼的一个高频场景开刀：科技热点监控与选题库自动化。

之前，我利用豆包工作搭配飞书多维表格，搭建了一个热点监控雷达，但实际跑起来后，这个系统处于半瘫痪状态。

抓取回来的新闻永远卡在「待筛选」状态，一条都推不进正式选题库。到最后，编辑每天依然得手动从头扒一遍信息。

为什么传统工程规则，在这套系统下会很「脆弱」？

复盘后我们发现，过去依靠「正则匹配 + 实体词提取 + 权重公式」搭建的传统自动化逻辑，在真实的编辑语境下非常脆弱：

• 机械加权缺乏语义理解：原系统靠公式算总分（信源 30% + 实体词 25% + 事件类型 25% + 传播度 20%）。但这套公式根本读不懂内容。比如「某大厂更新了客服话术」，会因为踩中了官方信源与大厂实体词，被送到高分榜；而真正有颠覆性的行业情报，却因标题语言精炼被埋没。
• 事实与观点严重混淆：「奥特曼称暂不考虑上市」是一句主观表态，「OpenAI 完成新一轮巨额融资」是客观事件。但两者标题都挂着「OpenAI」和「奥特曼」，关键词匹配完全失灵，导致大量行业预测、公关通稿甚至水文倒灌进原始池。
• 缺少发酵维度的终审判定：传统代码无法裁定「这条新闻到底具不具备深挖价值」、「事件是否还在持续发酵」，导致流程在分发前夕集体堵死，最终堆成了一座数字垃圾场。

如果要解决这些问题，靠普通大模型跑串行生成，延迟动辄几十秒，下游提取 JSON 还经常格式崩溃。

所以我们引入与 Jev 同范式的决策模型 diffusiongemma，将整套热点初筛重构为决策模型的统一范式：输入状态、并行决策、结构化输出。

重构的核心思路，是把原来那套僵硬的加权公式舍弃，把一个资深编辑筛选新闻的「直觉判断」，拆解为一组离散问题。

说得更通俗一点：我们没有让模型「理解一篇新闻」，而是让它连续回答五个编辑每天都会问自己的问题。

这五个问题分别对应 Noul、Choice 和 Score 三种输出方式。

当一条候选新闻被抓取进来，系统不再逐个环节串行跑规则，而是通过一次 API 调用，让模型在同一个前向传播周期内并行回答五个问题：

• 问题一（Noul 二元判定）：这是硬事件还是水文？
• 判断是真实发生的具体事实，还是观点、综述、传闻。概率低于 0.5 的内容，入口处直接丢弃，把泛滥的行业口水仗挡在门外。
• 问题二（Noul 二元判定）：值不值得内容团队跟进？
• 评估事件的行业冲击力与深挖价值，置信度低于 0.6 的自动拦截。
• 问题三（Choice 多选一）：属于哪类行业动作？
• 让模型从模型发布、产品更新、融资并购、政策监管等 9 个预设类型中选出唯一解。它看懂了上下文，即使标题没有「融资」字样，也能准确归入资本动作，吻合度直接达到 62.8%。
• 问题四（Score 评分）：行业重要性打几分？
• 给出一个 0 到 10 分的绝对重要性标尺。
• 问题五（Choice 评级）：综合价值定在哪个梯队？
• 直接在 S、A、B、C 四档中进行裁决，只有命中 S 或 A 的才有资格被推进。

这种做法把过去分散的多重过滤，压缩进了一次低延迟的并行判定中。在有速度的基础上，同时也保证了质量的可靠性。

在调优过程中，我们还得出一个结论：

在当前的决策模型中，「做选择（Choice）」的稳定性远高于「给打分（Score）」。实测中 Choice 评级的吻合率超过 60%，而连续打分的吻合率只有 51% 左右。因此，整个脚本采用「以 Choice 为硬门槛、Score 为辅助参考」的策略，避免了模型在连续数值上的打分漂移。

最终把整套流程跑通后，是一种克制而高效的状态：

[原始新闻流]
 ↓ 
(一次 diffusiongemma 并行判定)
 ├── is_real_event < 0.5? ──→ 丢弃（过滤纯观点/水文）
 ├── is_worth_recording < 0.6? ──→ 丢弃（过滤无价值杂音）
 └── Grade 属于 B/C 档? ──→ 丢弃（过滤平庸资讯）
 ↓ (仅存活 S/A 级硬核动态)
[人工四维加权算法] (仅用于最终列表的优先级排序)
 ↓ 
[自动推送至选题库 / 热点监控看板]

让决策模型去做它最擅长的事：基于语义直觉的实质把关（是不是事实、值不值得写、归哪一类）；

而原有的信源权重、关键词加分等传统算法，退回到第二梯队，专门负责在过滤后的池子里做最终排序。这也是 TypeSave 想要打造出的 System 1 引擎，由 AI 做定性裁决，规则做定量排序。

整套流程没有多余的自然语言，没有复杂的正则匹配链，更没有漫长的等待。这个不会打字的模型，确实能将我们从机械的人肉选题中解放。

但一个更大的问题来了：

决策模型真的比通用模型更适合做这件事吗？还是说，只要把通用模型的 Prompt 写好、加上 JSON 约束，效果其实差不多？

所以我们没有停在跑通这一步，而是把同样的 1000 条新闻，同时交给三类模型。

我们将 mimo-v2.6-flash 以及 deepseek-v4.1-flash 同时接入，在同样的 1000 个新闻筛选中，效果如何，看看对比数据。

测试结果的差距并不在于「谁更聪明」，而在于「谁的设计目标更适合做筛选」。

决策模型速度与成本是断层式领先。

diffusiongemma 的响应速度是 MiMo 的 11 倍、DeepSeek 的 12 倍；单千条成本仅 0.18 元，是 DeepSeek 的 1/37。对于需要实时监控信息的系统而言，3 秒以内的确定性响应，才具备真正可用的并发吞吐能力。

思考模式「想得多，但尺度容易摇摆」。

从响应时间与热度打分的散点分布来看，diffusiongemma 的散点高度集中在 0–10 秒区间，评分稳定收敛在 6–10分；而两款通用模型的耗时横跨 0–60 秒，评分从 1 到 10 均匀分散。更关键的是，MiMo 与 DeepSeek 之间的评级一致率仅有 62.9%——相当于每三条新闻就有一条各执一词。面对「这条新闻值不值得看」的判断，通用模型的开放式思考反而引入了不可控的主观性。

决策模型输出更稳定。

在我们的重复测试中，同一条新闻多次运行，决策模型的输出波动明显低于通用模型。而一旦依赖主观推理过剩的通用模型，就很难分辨到底是新闻本身的价值变了，还是模型当下的思考路径漂移了。

但是这次对比并不是否定通用大模型的作用，相反需要更注重系统职责的分层。我们最终并没有完全放弃通用模型，而是搭建了一套兼顾速度、成本与深度的三层判定架构：

• 第一层·初筛（diffusiongemma）：用极低成本与统一标准，把每天入库的 1000 条原始动态，在低延迟下压缩到 100 条以内；

• 第二层·复核（MiMo）：以极低单价对初筛结果进行语义再校验，过滤掉边缘资讯，收敛至 20 条；

• 第三层·深读（DeepSeek）：仅针对最终入围的 5 条核心大事件，调用高阶推理模型做深度背景挖掘与选题拆解

这套新系统把单日监控全流程的成本稳定控制在几块钱以内。

既彻底解决了通用大模型跑批量筛选时成本高、延迟长、格式脆的痛点，也把高阶模型的推理能力留给了真正需要「深度思考」的问题上。

3、写在最后：Agent 开始拥有判断层

实测下来，我们发现，针对一些规则写不死、却又不需要复杂推理的任务，Jev 这类决策模型，抓住了使用 Agent 的一个常见问题：很多调用只是为了做一个判断，却动用了完整的文本生成过程。

如果调用量小，并发量不大的情况下，大家不会太计较，因为无非就是多几毛钱的事情。等一个任务需要几十次模型调用，延迟和成本就很难忽略了。

它适合的位置，是 Agent 中那些高频、边界清楚的调用，比如选工具、筛选检索结果、判断下一步操作、决定是否升级到更强模型。

这些任务虽然需要语义理解，但输出空间小，若效果接近，用户自然会选择更快、更便宜的方案。

过去我们用 Agent，思路一直是复杂规划交给强模型，局部判断交给轻模型，遇到高风险再升级。

难点从来不在「要不要分层」，而在切换时机、阈值选择和回退机制。

这些没处理好，省下的推理时间会被重试和恢复抵消。

这次改造给我们的启发，并非通用大模型不适合自动化，而是自动化没必要让每一次判断都走完整的生成流程。

让通用大模型专注深度推理与长程规划，把高频、离散的条件判定剥离出来，交给更轻快的决策模型。当这个独立的「判断层」真正建立起来，AI 不一定需要和用户聊天，如果能像普通代码一样进入系统，自动化便可以进入真实的业务流程。