决策模型正在悄然取代智能体循环中的大语言模型
Cloudflare 在十月的头几天发布了两款不写任何内容的模型。Clef 和 Clef-flash 读取一段输入以及一组带类型的问题，并为每个允许的答案返回一个概率。没有散文式输出，没有思维链，也不是一个 token 一个 token 地生成。只给出一个结构化的选择。
这听起来像是一次降级，直到你看到数字。在 BANKING77 这一标准意图分类基准上，Clef 的宏平均 F1 得分为 94.20，而开创决策模型这一品类的 Jev 仅为 79.74。更小的 9B 版本 Clef-flash 也能达到 90.93。延迟差距更大。Clef-flash 返回答案的中位数耗时为 38.8 毫秒；Jev 则需要 524.1 毫秒。Cloudflare 表示，在十项决策基准中的七项上，Clef 都胜过 Jev。
两款模型都以 Apache 2.0 协议发布在 Hugging Face 上，并且都与 Jev API 兼容，因此已经围绕 Jev 搭建系统的团队无需重写集成即可切换。相关 Hacker News 帖子在一天内就获得了 602 分和 200 多条评论。
为什么更小的模型能在更窄的任务上取胜
决策模型与大多数开发者习惯使用的聊天机器人形态不同。大语言模型生成开放式的文本。决策模型则读取一个状态和一份允许答案的列表，然后为每个答案打分。这一品类由 Typesafe AI 的 Jev 开创，它证明了智能体路由或分类任务并不需要 400B 的通用模型。它们需要的是有边界、低成本、快速的输出。
Cloudflare 的 Clef 基于 Qwen3.8-27B 构建，采用仅预填充（prefill-only）架构，并行地为各个模式选项打分，而不是逐个生成 token。延迟的差距就来自这里。通用模型必须一个 token 接一个 token 地输出答案；决策模型只需读取问题并做出决定。
还有一个值得注意的上下文差异。Clef 在 64k token 的窗口内接受多模态输入，涵盖文本、JSON、图像和视频。Jev 仅支持文本，窗口为 32k。对于一个需要根据截图或 PDF 进行路由的智能体来说，这可不是小优势。
社区的第一个质疑说到了点子上
Hacker News 讨论中最有价值的反对意见并没有质疑基准测试成绩，而是质疑标签本身。「是开放权重，不是开源，」一位评论者写道。权重带有宽松许可证，但训练数据和流水线并未公开，因此该模型无法从头复现。
对于任何要决定在哪里运行它的人来说，这一区别很重要。Clef 基于一个专有的 Qwen 起点训练而成。权重可以免费下载和托管，这确实能省下一笔成本，但它们的可审计性比不上开源软件。有严格供应链审查政策的团队，在假定 Apache 2.0 标签已经解决问题之前，应先阅读许可证和模型卡。
同一周，亚马逊把一个决策模型放进了你的笔记本电脑
Cloudflare 并非孤例。AWS 的 Strands Labs 发布了 Strands Decider 2B，这是一个开放决策模型，附有权重和训练脚本，设计用于本地运行，能在几十到几百毫秒内返回带置信度评分的选项。Cloudflare 还在 Workers AI 上为其决策模型新增了强化学习微调服务。
这一模式的核心是：一个小模型把一件事做好，并且运行在数据附近。如果你能用 40 毫秒的 2B 模型来判断是否放行一次工具调用、核实某个请求是否有依据，或者决定是否需要升级处理，那么让智能体的每一步都经过前沿模型的经济账就开始显得浪费了。
Jev 开创的范式，以及为什么用了一年才流行起来
Typesafe AI 的 Jev 在发布时提出了一个很容易被忽视的主张：智能体要求模型做的大部分事情并不是生成，而是分类。给这张工单定路由、挑选这个工具、判断这个操作是否需要审批。对于这些任务，一个会写段落的模型所做的工作远超任务所需。
Jev 证明了这种窄口径方案可以在自己的基准上击败通用模型，但它没能让这一品类显得紧迫。只有一家厂商卖一个决策模型，那只是个新鲜事。Cloudflare 发布一个与 Jev API 兼容的 Apache 2.0 版本则是另一回事，因为现在任何人都能托管它、审查许可证，并在无需重写的情况下替换进来。亚马逊在同一周带着自己的开放决策模型到来，则把一个新鲜事变成了一整个品类。
时间点也与智能体实际的构建方式相吻合。第一代智能体框架把每一步都路由给一个大模型，因为那最简单。当这些系统走向生产环境，路由成本就成了团队注意到的问题。把循环拆开，让需要语言能力的部分交给语言模型，不需要的部分交给决策器，是显而易见的解法，而这一解法要等到一个优秀的开放决策器发布才变得可行。
微调的视角
Cloudflare 还在 Workers AI 上为其决策模型新增了强化学习微调服务，这指向了该品类的下一步走向。通用决策器有用。而在你自己的路由历史、升级规则和范围界定上微调过的决策器更有用，因为它学到了对你业务真正重要的边界。
这也正是团队应当谨慎的地方。一个微调过的决策器会把你过去的决策编码进去，包括那些糟糕的决策。如果你的团队过去会批准本应升级处理的退款，模型就会学到这种模式，并以人类远不能及的速度应用它。校准是一把双刃剑。
这在智能体流水线中的位置
设想一个处理退款的客服智能体。在调用退款工具之前，必须先回答一些问题：这个请求是否在受理范围内、客户账户是否允许、是否需要人工介入。这些都是答案集合固定的决策问题。决策模型可以返回概率，智能体则依据阈值行动。
成本结构才是重点。把每一项这样的检查都经由 400B 模型路由，每次调用都要花钱，还会增加数百毫秒延迟。把这些交给本地 2B 或 9B 决策器，就能把前沿模型留给真正需要语言能力的部分：撰写回复、总结长对话、处理模糊个例。预算和延迟预算都会缩小。
但有个陷阱。决策模型返回的是概率，而概率可能以很自信的方式出错。如果你依据 0.92 的分数自动化审批退款，你只是把风险从模型的措辞转移到了你的阈值上。值得关注的指标变成了校准，而不是原始准确率。延迟和成本容易衡量；一个校准良好的 0.9 要难得多。
接下来值得关注什么
工具生态已经在追随这些模型。llama.cpp 加入了对决策模型的支持，Perplexity 和 Hugging Face 也都在同一方向上押注。如果这一品类站得住脚，那么有意思的问题就不再是哪个决策模型能赢得基准测试，而是你愿意把哪些决策交给一个概率。
对智能体开发者来说，务实的做法是审查整个循环，找出那些从来不需要流畅文本的步骤。分类、路由、工具选择和行动前检查通常都是候选对象。在这些步骤上，一个针对固定选项集、40 毫秒返回的答案可以取代缓慢而昂贵的生成。智能体的其余部分则可以继续使用它已经在用的模型。