devgo.cn先问一个场景：你的 AI Agent 在收到用户请求后，需要决定是转给客服、自动回答、还是升级到人工。常见做法是让大模型生成一段 JSON 指令，再解析结果，但生成过程慢、还容易吐出不规范内容。Cloudflare 在 Birthday Week 上开源了 Clef——一套不做文本生成、只做分类决策的模型，把“从预定义选项里选一个”这件事变成了单次前向传播（一次性推理，模型只算一遍就能输出所有问题的答案），直接输出每个选项的概率。
Clef 有两个尺寸：9B 和 27B 参数。27B 版是多模态模型，能同时处理文本、JSON、图片甚至视频。你给它一个状态（比如当前的对话上下文、支持工单内容）和一个“带类型的问题列表”，它一次性返回每个问题的每个允许选项的概率。全程不生成自由文本，也不需要输出解析（output parsing，即把模型输出的字符串拆成结构化数据的过程），因此延迟和出错率都大幅下降。Cloudflare 的 API 兼容 Typesafe 的 Jev System One 模型，后者是目前比较流行的决策模型，但 Clef 额外加了视觉编码器（vision encoder，能把图像转为特征向量的模块），所以能分类图片和视频内容，而 Jev 目前只做文本分类。Clef 还拥有 64k 的上下文窗口（context window，模型一次能“看到”的输入长度），比 Jev 的 32k 大一倍，允许塞进更多状态信息来做判断。
为什么这类“决策模型”值得关注？因为现实中的很多任务本质上是分类，而不是开放生成。比如路由一个支持工单（该转给支付组还是技术组）、判断一条消息是不是垃圾、决定是否升级优先级。传统方式让大模型输出 JSON 或自然语言，再解析，这又慢又脆。决策模型把答案空间锁死在预定义选项里，结果天然可验证，还能给出置信度。Cloudflare 把这套模型放到边缘 GPU 上，所以网络延迟很低，可以直接放在 Agent 的“热路径”（每次请求都要走的必经流程）里，配合 Workers AI 上的 LLM 做行动生成——先用 Clef 快速判断方向，再让更强的模型写回复或执行动作。
实测数字：Clef 27B 的中位延迟是 209.3 ms，而 9B 的 Clef-Flash 是 38.8 ms，后者专门为对延迟敏感的任务设计。这个数字相当惊人，因为 38 毫秒基本可以当“瞬时决策”用了。Cloudflare 已经把权重和 API 都放出来了。
社区有讨论，也有质疑。Hacker News 上有人觉得这不是新范式，只是别人早就该捡的“低垂果实”；也有人提醒公开 benchmark 容易被“过拟合”（overfitting，为了刷分而专门优化测试集），真正要关心的是模型在“假阳性比漏判代价更大”的场景下表现如何，有没有“知道自己不知道”的能力（比如在数据分布变化时会不会盲目自信）。Reddit 用户 bugra_sa 更直白：在乎的该是模型什么时候该让位给人类，而不是一个孤立精度。这些讨论都很有意思，说明决策模型虽然概念简单，但要真正落地，评测方法还得和真实业务一起设计。
Cloudflare 后续计划针对客服分流、机器人识别等场景做微调（fine-tuning，用你自己的数据继续训练模型），并提供微调服务，初期由官方工程师协助，后续会开放自助平台。开发者现在就能从 Hugging Face 下载权重，或者在 Workers AI 上直接调用，拿自己的数据试试。
我的感受是：Clef 把“决策”从“生成”里剥离出来，很符合工程上的单一职责原则。对做 Agent 的团队来说，与其让一个 70B 模型每次生成一堆 token 再解析，不如先用一个小而快的决策模型把范围收窄，再让生成模型发力。这个思路可以用在所有“从有限选项里选一个”的地方：工单分流、内容审核、路由、任务规划的第一步。要注意的坑是：决策模型的准确率依赖于你给的选项设计得够不够好，以及状态输入里有没有足够信息。另外，公开 benchmark 仅供参考，真用之前一定要在你自己数据的分布上做压力测试，特别是当出错代价不对称时，得看模型的置信度是否会随着数据扰动而下降。
内容与图片版权归原作者所有 · 原文: https://www.infoq.com/news/2026/10/clef-decision-models/?utm_campaign=infoq_content&utm_source=infoq&utm_medium=feed&utm_term=global