Agent 循环里最烧钱也最慢的一类调用，其实不是「写文章」，而是「做判断」：这条工单加不急？该转给哪个团队？这个请求放行还是拦截？很多开发者的做法是把这些判断也丢给大模型，让它生成一段自由文本再解析——慢、贵，还可能解析失败。2026 年 10 月 1 日，Cloudflare 在官方博客发布了 Clef 与 Clef-flash，这是 Workers AI 团队训练的开源「决策模型」：它不生成文本，而是读一段输入状态（state）加一组类型化问题，直接返回每个允许答案的概率，让 Agent 拿到结构化决策就能立刻执行——路由工单、拦截请求、或升级转人工。
按官方 changelog 的口径，两个模型的定位很清晰：Clef 是 27B 的高精度版本，Clef-flash 是 9B 的低延迟版本，上下文窗口都是 64K token，权重以 Apache 2.0 协议开源在 Hugging Face。官方给出的 43 组延迟基准里，Clef 中位数 209.3 毫秒、Clef-flash 中位数 38.8 毫秒；Clef 还与 TypeSafe 的 Jev 决策模型按 System One API 兼容，已有 Jev 集成改一下端点和模型名就能切换。本教程带你把它跑进 Workers AI，接入一个真实的工单路由场景，再嵌入 Agent 循环做「置信度不够就升级」的热路径决策。
前置准备清单：一个 Cloudflare 账号（Workers 免费额度即可开始）、Node.js 16.17.0 或更高版本（Wrangler 的要求，官方建议用版本管理器安装）、一个能跑 npm 的终端。不需要单独申请模型 API Key——Workers AI 通过 Worker 内绑定调用，凭证由平台托管。
Clef 刚发布，返回体字段名、定价与配额以 Workers AI 官方模型页（developers.cloudflare.com/workers-ai/models/clef）当前版本为准；本教程代码中的字段引用均来自官方 changelog 原文示例，若与模型页不一致，以模型页为准。
Step 1：创建 Worker 项目并绑定 Workers AI
先用官方脚手架起一个最小 Worker 项目。--no-deploy --no-git 把部署和版本控制的主动权留给你：
npm create cloudflare@latest -- clef-router --category=hello-world --type=hello-world --lang=ts --no-deploy --no-git
cd clef-router生成的目录里，wrangler.jsonc 是配置中心，src/index.ts 是入口。打开 wrangler.jsonc，把 compatibility_date 改成当天日期，并加上 Workers AI 绑定：
{
// ...其余配置保持脚手架默认
"compatibility_date": "2026-10-03",
"ai": {
"binding": "AI"
}
}这个绑定让代码里通过 env.AI 调用 Workers AI 的所有模型，包括刚上线的 Clef。官方脚手架默认会带上观察日志配置，保留它，后面排查决策延迟会用到。
Step 2：本地跑通一条最小决策请求
把 src/index.ts 改成下面这样——代码结构照官方 changelog 的示例原文改写，场景换成客服工单分流：输入一段工单状态描述，问两个问题——急不急（noul 是非题）、该归哪个团队（choice 单选题）：
interface Env {
AI: Ai;
}
export default {
async fetch(request: Request, env: Env): Promise {
const response = await env.AI.run("@cf/cloudflare/clef", {
model: "clef",
state: "Checkout has been failing for every customer for the last hour.",
questions: {
urgent: {
type: "noul",
instructions: "Is this support request urgent?",
},
team: {
type: "choice",
instructions: "Which team should handle this request?",
criteria: {
billing: "Payments, invoices, and refunds",
technical: "Outages, errors, and configuration",
sales: "Plans and upgrades",
},
},
},
});
// response.answers.urgent.noul -> 判定为"是"的概率
// response.answers.team.choice -> 概率最高的团队选项
return Response.json(response);
},
}; 启动本地开发服务：npx wrangler dev，浏览器或 curl 访问本地地址，你会看到返回 JSON 里带着每个答案的概率。官方示例注释标明的两个取值路径是 answers.urgent.noul（yes 概率）与 answers.team.choice（最高概率选项）。官方每次请求最多允许 64 个问题，一次状态判断可以并行问完一整组。
# 本地默认监听 8787 端口，另开一个终端验证
curl http://localhost:8787/state 写得越具体，判断质量越稳。把「用户投诉」换成「过去一小时所有客户的结账都失败了」，模型拿到的上下文密度完全不同。criteria 里每个选项的描述要写出「判给它的理由」，而不是只写名字。
Step 3：把决策嵌进 Agent 循环：阈值、回退与升级
决策模型的价值在热路径上——每条请求都要判断时，它的速度优势才兑现。一个务实 pattern 是三层分级：概率够高就自动执行，不够就回退到大模型细看，再不够就转人工。把 Step 2 的调用包一个路由函数：
async function routeTicket(env: Env, state: string) {
const r = await env.AI.run("@cf/cloudflare/clef-flash", {
model: "clef-flash",
state: state,
questions: {
team: {
type: "choice",
instructions: "Which team should handle this request?",
criteria: {
billing: "Payments, invoices, and refunds",
technical: "Outages, errors, and configuration",
sales: "Plans and upgrades",
},
},
},
});
const pick = r.answers.team.choice; // 官方注释：概率最高的选项
// 完整返回体里还带每个选项的概率与置信度字段，
// 字段名以模型页返回体文档为准，不要凭猜测硬编码
return pick;
}热路径用 Clef-flash（官方基准中位数 38.8 毫秒），低频但重要的判断再用大号 Clef。回退分支里调 LLM 时，把 Clef 给出的概率分布一并塞进提示词，让大模型带着「前一个判断者的犹豫」做二次判断，命中率通常比裸问更高。
阈值不要拍脑袋。拿一百条历史工单跑一遍，统计每个档位的实际概率分布，再定「自动执行」的下限。官方博客的基准分数（如 BANKING77 宏平均 94.20）是通用分类任务的成绩，不等于你的业务分布。
Step 4：三种问题类型：noul、choice 与 score
官方 changelog 明确了三类问题的语义：noul 是是非题，返回「是」的概率；choice 从你定义的选项集里选一个，返回所选选项、每个选项的概率与置信值；score 按有序评分标准打分，返回概率加权的分数与每档概率。前两类的请求字段在官方示例里有完整代码，score 的语义清楚但官方 changelog 未附完整请求示例。
score 类型的具体请求字段名官方 changelog 没有给出完整代码示例，不要照抄网上二手教程的字段名——部署前以 Workers AI 模型页的请求体文档为准，先用一个最小请求在 wrangler dev 里验证返回结构，再接入业务代码。
工程上的分工建议：noul 适合做守门（拦截、放行、加急），choice 适合做分流（路由、归类、选工具），score 适合做排序与优先级（工单 urgency、线索质量分）。三类可以同请求混合使用，一次调用把一条状态的所有判断问完，摊薄网络往返。
Step 5：成本结构与批量巡检
决策模型没有自由文本输出，也就没有输出 token 账单——成本结构天然比生成式调用简单。官方渠道未在本教程撰写时给出明确单价，部署前查一下模型页的价格表；按官方基准的延迟数据，把原来每条请求都过一遍大模型的巡检任务换成 Clef-flash，延迟中位数从数百毫秒级进入几十毫秒级。
批量场景（定时巡检监控告警、夜里扫一天的客服会话）可以把同一组 state 的多个判断合并进一次请求的 64 个问题额度里。比如夜里巡检一批告警，一次请求同时问加急与否、归属团队、是否重复告警：
const r = await env.AI.run("@cf/cloudflare/clef-flash", {
model: "clef-flash",
state: alertText, // 一条告警的完整上下文
questions: {
urgent: { type: "noul", instructions: "需要立即人工介入吗" },
team: { type: "choice", instructions: "该派给哪个值班组",
criteria: { infra: "服务器与网络", app: "应用与接口", data: "数据与权限" } },
dup: { type: "noul", instructions: "过去 24 小时已有同类告警在处理中吗" },
},
});注意每次请求的 state 是共享上下文，别把不相关的判断硬塞进同一次调用——state 变长会稀释每个问题的判断质量。
把「上周所有转人工的工单」作为评估集：先只跑判断不出动作，对比 Clef 的选择与人工的真实分流，得到你业务上的混淆矩阵，再决定哪些档位可以放开自动执行。
Step 6：换模型、本地化与迁移 Jev 集成
两个模型都在 Hugging Face 以 Apache 2.0 开源了权重（Cloudflare/clef 与 Cloudflare/clef-flash），想本地跑或自托管推理是可以的；不过要注意官方开源的是权重，训练数据与流程未公开。本地部署的推理框架选择、显存需求属于另一套工程，本篇不展开——在自托管环境里先复现官方模型页的效果基准，再决定迁移。
已有 Jev 集成的团队按官方说法是即插即换：Clef 遵循 System One API，改端点与模型名即可切换。从零开始的读者可以直接在 Workers AI 上起步，绑定、计费、可观测都留在 Cloudflare 生态里。
Clef 的强化学习微调服务目前处于 design partner 阶段（官方博客口径），尚未开放自助平台；想让模型适配自有业务分布，现阶段可行路径是：用 AI Gateway 攒业务请求日志做评估集，微调开放后拿同一批数据去对齐。不要把「微调后精度提升」写进任何对外承诺。
预期效果自查：wrangler dev 里访问 Step 2 的路由，返回 JSON 应包含 answers 对象且每个问题都有概率输出；把 state 换成明显不紧急的咨询（「想了解升级方案」），urgent 的概率应显著下降、team 应倾向 sales——两条都满足，说明链路与判断质量都在线。
常见问题 FAQ
Clef 能替代对话生成吗？不能。它只做判断不生成内容，输出是概率而非文本。正确的用法是「Clef 做分诊、LLM 做执行」：判断交给它，生成、撰写、总结仍走大模型。
和写一段提示词让 LLM 分类相比，优势在哪？按官方基准，速度中位数进入几十到两百毫秒级，没有推理 token 等待，没有自由文本解析失败，也没有「分类顺带编一段理由」的幻觉成本。代价是你需要按选项组织判断，复杂开放性任务仍归 LLM。
我的业务判断很特殊，通用基准分说明不了什么怎么办？这恰恰是对的怀疑。官方分数是公开基准，你的动作应该是 Step 5 说的：用自己业务的评估集跑混淆矩阵，按业务分布定阈值；等 RL 微调平台开放后再考虑对齐自有分布。