10 月 1 日，Cloudflare 在 Workers AI 上线两款自研「决策模型」Clef 与 Clef-flash，权重以 Apache 2.0 开源到 Hugging Face，并同时预览了一套强化学习微调平台。它们不生成文本，只对你给定的选项打分并返回概率——Agent 的路由与判定，正在从「让它说」变成「让它选」。
把判断交给聊天模型，是过去两年最常见的做法：这条工单归哪个团队、这次重试值不值得、这一步要不要停下来问人，全部写成提示词，等模型「说」一句，再用 JSON schema 或正则解析回来。代价是每一步都要先生成 token、再解析文本、还要处理格式跑偏。
Cloudflare 10 月 1 日上线了另一种做法：两个决策模型（decision model）把「回答问题」改成「对选项打分」，一次前向计算就能给出每个选项的概率，不做逐 token 生成。本文要回答的是：这种输出形式到底改变了哪一步工作流，以及它做不到什么。
发生了什么：两个模型，加一条 RL 微调链路
按 Cloudflare 官方博客，Clef 以冻结的 Qwen3.8-27B 为主干，用 rank-256 的 LoRA 适配器与路由头联合优化；Clef-flash 换成冻结的 Qwen3.5-9B 主干，主打低延迟。两者都是 64k 上下文，并带视觉编码器，接口与 Typesafe 的 Jev 决策模型格式完全兼容——官方称现有 Jev 客户端几乎不用改代码。
权重以 Apache 2.0 开源，托管在 Hugging Face 的 Cloudflare/clef 与 Cloudflare/clef-flash。工作方式上，模型只做一次 prefill，然后并行给所有合法选项打分，输出带概率的结构化结果，不做自回归解码。Cloudflare 给的例子是客服工单分流：输入一段工单文本，加上「归哪个团队（Billing / Technical / Sales）」和「是否紧急（Yes / No）」两组问题，模型返回的是 100% / 0% 这样的概率分布，而不是一句自然语言。
同一天发布的还有一套强化学习微调平台。它把 Cloudflare 已有积木拼在一起：AI Gateway 负责捕获生产流量、生成数据集；Workers AI 跑 rollout 并把调优后的模型重新部署；Containers 作为 RL 沙箱执行打分与回放；新增的 Trainer 组件负责计算损失并更新权重，同时支持自带模型。目前这套能力先以「前向部署工程师陪跑」的方式提供，自助平台后续才开放。
完整工作场景：从「解析文本」到「读概率」
假设你在做一个客服 Agent。旧流程是：把工单塞给通用大模型，提示词里写「请只输出 JSON」，拿到结果后用 schema 校验，失败了就重试或走兜底分支。这条链路上，模型每多输出一个 token 就多一次出错机会，字段名、层级、语气都可能跑偏；更麻烦的是，即使格式对了，你也不知道模型有多确信。
换成决策模型后，链路变成四步：确定要问的问题与候选答案 → 一次请求提交 state 与 questions → 取回每个选项的概率 → 用阈值决定是否转人工。Cloudflare 官方给出的一个内部例子是，判定一个领域用 Clef 花 2.2 秒，而用他们自己的通用大模型要 4.7 秒。因为不需要生成文本、也不需要解析，这一步的延迟和失败面同时变小。官方还建议把阈值按模型分别标定，并且可以在同一个请求里批量提交多组问题——它们彼此独立。
性能数据方面，Cloudflare 自报的 Jev Decision Index 为 Clef 61.2、Clef-flash 57.1，闭源的 Jev 是 57.9；延迟中位数 Clef 209.3ms、Clef-flash 38.8ms、Jev 524.1ms，p95 分别是 238.6 / 122.4 / 536.0ms。分类任务上，BANKING77 macro-F1 为 94.20（Jev 79.74），CLINC150+OOS 为 97.43（Jev 89.27），BFCL case exact 为 98.47 与 98.76（Jev 95.75）。这些数字全部来自产品方自己发布的博客。
为什么这改变了工作流
变化的核心不在模型大小，而在输出接口的形状。让模型输出文本，你必须同时解决三件事：生成、解析、置信度。决策模型把三件事压成一件——输出域就是你定义的选项集合，结果天然带概率。对 Agent 来说，这意味着路由、分类、审核，以及「这一步该不该继续」这类判断，可以做成一次可测试的打分调用：选项写死，概率可回归，阈值可调。
这带来两个工程上的直接后果。第一，判定逻辑变得可写测试：同一批输入喂进去，概率分布应当稳定，回归测试能像测一个函数那样测它。第二，灰度与回滚变简单：阈值是一个配置项，调高调低不需要改提示词、不需要重新对齐模型行为。相比之下，提示词工程的最大问题正是「改一个字，整条行为链都可能漂移」。
限制与人接管点
官方博客也写明了它做不到的地方。在 Typesafe 自己的评测套件里，Clef 四个工作流赢了三个，唯一输掉的是「Agent trace observability」，得分 68.5 / 69.8，低于 Jev 的 71.6。换句话说，需要追踪整条轨迹、解释「为什么这么走」的场景，决策模型不是答案——它只回答你问的那个问题，不解释推理过程。
工程上至少要留三个接管点。其一，低置信度结果必须能路由给人或更强的模型，概率是给这个分支用的。其二，选项集合的变更要当作 schema 变更来管理：模型只在给定选项里选，你的分类漏了一类，它就永远选不出那一类。其三，这套 RL 微调目前还没有自助入口，需要先与 Cloudflare 谈合作；而权重虽然开源，视觉能力虽已带上，同门的 Jev 目前仍是纯文本。此外博客未公布定价，成本要按 Workers AI 的实际计费去核算。
如何试用
现在就能用。模型可以在 Workers AI 上通过 API 调用，官方博客给了 curl 示例并链到开发者文档；权重在 Hugging Face 下载，官方还提供了一个在线的 benchmark 演示站点。想在自有数据上做领域微调的团队，可以联系 Cloudflare 申请 RL 微调的首批合作名额。
生态上还有一个值得留意的信号：同一周 llama.cpp 的 server 新增了 /v1/systemone 端点，沿用 TypeSafe System One 的格式，现有客户端据称只需要换 base URL，实现见 PR #29818。决策模型的调用约定正在被多个运行时接受，这可能比单次模型发布更值得关注。
信息来源
- Cloudflare 博客：Introducing Clef: our open-source decision models, and new RL fine-tuning platform（2026-10-01）https://blog.cloudflare.com/clef-decision-models/
- Cloudflare Changelog：Clef decision models（2026-10-01）https://developers.cloudflare.com/changelog/
- Hugging Face：Cloudflare/clef、Cloudflare/clef-flash 权重页
- Hugging Face 社区文章：New in llama.cpp: Decision Models（llama.cpp PR #29818）
HiFox：将 Agent 变成真正的队友
另外，我们也在思考，AI 如何从个人提效走进团队协作。
HiFox 是一个让人和 AI Agent 在同一个工作现场协作的平台：你可以像给同事分派任务一样指派 Agent，在任务看板中跟踪进度、查看结果，让 Agent 成为团队里的队友。
👉 立即体验 HiFox：https://hifox.com
AI Coding 交流群
如果你也在用 AI 写代码，或者正在研究 Cursor、Claude Code 这些工具，
欢迎加入以下交流群。群里平时会聊一些 AI 编程的实际用法、开发工作流，还有各种新工具和新玩法。
