Clef 和 Clef-flash 的发布,瞄准的不是长篇内容生成,而是应用中更高频、更靠近控制面的任务:分类请求、选择工具、判断是否升级人工处理,以及决定智能体下一步动作。两款模型以开源形式提供,并托管在 Workers AI 上;配套的强化学习平台则允许开发者使用自己的数据微调决策模型。
这类模型值得关注,是因为很多 AI 系统真正的瓶颈并不在“能否生成答案”,而在“能否快速、稳定地做出正确选择”。
决策模型适合放在哪一层
一个典型智能体可能需要在每次请求中完成以下判断:
- 这是退款、物流查询,还是账户安全问题?
- 应调用搜索、数据库、工单系统,还是直接回复?
- 当前结果是否足够可信,需要不需要交给更大的模型?
- 某个操作是否涉及权限、资金或隐私,必须人工确认?
这些任务通常拥有有限的动作空间,输出也可以约束为标签、分数或结构化 JSON。与自由文本生成相比,它们更重视延迟、稳定性和可评估性。
Clef 与 Clef-flash 为这种决策层提供了新的模型选择。不过,仅从发布摘要无法得出两者精确的速度、成本和质量差异。实际选型时,应该使用自己的流量样本做基准测试,而不是根据模型名称推断适用场景。
一种稳妥的架构是:
用户请求
│
▼
Clef 决策层 ── route=direct ──> 直接处理
│
├── route=tool ────────────> 调用受控工具
│
├── route=large_model ─────> 转交更强模型
│
└── route=human ───────────> 人工审核
决策模型负责缩小选择空间,业务代码继续负责权限检查、参数校验和最终执行。不要让模型输出直接绕过服务端安全策略。
在 Worker 中实现一个分类路由器
下面是一个可以改造的最小 Cloudflare Worker 示例。它假设目标模型接受文本输入,并返回可读取的文本或 response 字段;具体模型 ID、输入参数和返回结构需要按照 Clef 在 Workers AI 中的实际接口调整。
先创建 wrangler.toml:
name = "clef-decision-router"
main = "src/index.ts"
compatibility_date = "2025-01-01"
[ai]
binding = "AI"
[vars]
# 部署前替换成 Workers AI 中实际可用的 Clef 或 Clef-flash 模型 ID
DECISION_MODEL = "REPLACE_WITH_CLEF_MODEL_ID"
然后创建 src/index.ts:
interface Env {
AI: any;
DECISION_MODEL: string;
}
type Decision = {
route: "direct" | "tool" | "large_model" | "human";
confidence: number;
reason: string;
};
const ALLOWED_ROUTES = new Set([
"direct",
"tool",
"large_model",
"human",
]);
function parseDecision(result: any): Decision {
const raw =
typeof result === "string"
? result
: result?.response ?? result?.output ?? "";
const parsed = JSON.parse(raw);
if (!ALLOWED_ROUTES.has(parsed.route)) {
throw new Error("Model returned an unsupported route");
}
const confidence = Number(parsed.confidence);
if (!Number.isFinite(confidence) || confidence < 0 || confidence > 1) {
throw new Error("Invalid confidence score");
}
return {
route: parsed.route,
confidence,
reason: String(parsed.reason ?? ""),
};
}
export default {
async fetch(request: Request, env: Env): Promise<Response> {
if (request.method !== "POST") {
return new Response("Use POST", { status: 405 });
}
const body = (await request.json()) as { message?: string };
const message = body.message?.trim();
if (!message) {
return Response.json({ error: "message is required" }, { status: 400 });
}
const prompt = `You are a request router.
Choose exactly one route:
- direct: simple question that can be answered without tools
- tool: requires an approved internal tool
- large_model: requires deeper reasoning
- human: security, payment, privacy, or irreversible action
Return JSON only:
{"route":"direct|tool|large_model|human","confidence":0.0,"reason":"short reason"}
Request:
${message}`;
try {
const result = await env.AI.run(env.DECISION_MODEL, { prompt });
let decision = parseDecision(result);
// 低置信度时采取保守策略,而不是盲目信任模型。
if (decision.confidence < 0.65) {
decision = {
route: "human",
confidence: decision.confidence,
reason: `Low-confidence fallback: ${decision.reason}`,
};
}
return Response.json(decision);
} catch (error) {
return Response.json(
{
route: "human",
confidence: 0,
reason: "Decision model failed; using safe fallback",
},
{ status: 200 }
);
}
},
};
安装 Wrangler 并本地运行:
npm install --save-dev wrangler
npx wrangler dev
发起测试请求:
curl -s http://localhost:8787 \
-H 'content-type: application/json' \
-d '{"message":"请删除我的账户以及全部历史订单"}'
这个例子刻意加入了三层保护:输出枚举校验、置信度阈值和异常降级。生产环境还应增加身份认证、速率限制、日志脱敏,以及针对高风险工具的二次授权。
用自己的数据做强化学习,重点是奖励定义
新的强化学习平台允许开发者使用自有数据微调决策模型。真正困难的部分通常不是“上传多少条数据”,而是如何把业务目标变成不会误导模型的奖励信号。
可以先把历史记录整理成如下 JSONL。以下只是建议的数据准备格式,不代表平台的官方上传协议:
{"input":"查询昨天的快递状态","action":"tool","reward":1.0,"metadata":{"tool":"shipment_lookup"}}
{"input":"帮我转账 5000 元到新账户","action":"human","reward":1.0,"metadata":{"risk":"financial"}}
{"input":"解释一下什么是幂等性","action":"direct","reward":1.0,"metadata":{"topic":"engineering"}}
{"input":"分析这份包含多个附件的合同","action":"large_model","reward":0.8,"metadata":{"complexity":"high"}}
训练数据至少需要区分三个概念:
- 输入:模型做决策时真实可见的信息。
- 动作:有限且稳定的候选决策集合。
- 奖励:该动作是否带来了可接受的业务结果。
不要简单地把“用户没有投诉”视为正奖励,也不要把“任务很快结束”当成唯一目标。否则模型可能学会拒绝复杂请求、过度转人工,或者选择成本最低但质量最差的路径。这就是典型的奖励投机。
在提交训练前,可以用下面的 Python 脚本检查 JSONL:
import json
import sys
ALLOWED_ACTIONS = {"direct", "tool", "large_model", "human"}
def validate(path: str) -> None:
total = 0
action_counts = {action: 0 for action in ALLOWED_ACTIONS}
with open(path, "r", encoding="utf-8") as file:
for line_number, line in enumerate(file, start=1):
if not line.strip():
continue
row = json.loads(line)
total += 1
if not isinstance(row.get("input"), str) or not row["input"].strip():
raise ValueError(f"line {line_number}: invalid input")
action = row.get("action")
if action not in ALLOWED_ACTIONS:
raise ValueError(f"line {line_number}: invalid action {action!r}")
reward = row.get("reward")
if not isinstance(reward, (int, float)) or not -1 <= reward <= 1:
raise ValueError(f"line {line_number}: reward must be between -1 and 1")
action_counts[action] += 1
if total == 0:
raise ValueError("dataset is empty")
print(f"valid rows: {total}")
for action, count in sorted(action_counts.items()):
print(f"{action}: {count} ({count / total:.1%})")
if __name__ == "__main__":
if len(sys.argv) != 2:
raise SystemExit("usage: python validate_dataset.py decisions.jsonl")
validate(sys.argv[1])
运行方式:
python validate_dataset.py decisions.jsonl
类别分布检查很重要。如果历史系统几乎把所有请求都交给人工,模型很容易复制这一偏差,而不是学到更好的路由策略。
上线前不要只看准确率
决策模型的离线评估应该贴近动作后果。普通准确率可能掩盖严重问题:把一个简单问题错分给大模型只是增加成本,把资金操作错分为自动执行则可能造成安全事故。
建议至少追踪以下指标:
- 每个动作类别的精确率与召回率;
- 高风险请求被自动执行的比例;
- 人工升级率及其变化;
- P50、P95 和 P99 推理延迟;
- 每千次决策的模型与工具成本;
- 新模型与旧规则发生分歧时的真实结果;
- 不同语言、地区和客户群体之间的错误率差异。
部署初期可以采用影子模式:新模型只记录建议,不实际控制流量。确认指标稳定后,再从低风险类别开始逐步放量。强化学习微调也应保留独立测试集,避免训练数据与评估数据混用。
是否应该采用 Clef
如果系统需要大量低延迟分类、工具选择或智能体路由,Clef 和 Clef-flash 值得进入基准测试名单。开源模型有利于理解和复现实验,Workers AI 托管则减少了自行部署推理服务的工作;新的强化学习平台进一步提供了利用私有业务反馈调整模型的路径。
采用前可以逐项确认:
- 是否已经定义稳定、互斥的动作集合;
- 是否存在可信的历史反馈,而不只是点击或停留时长;
- 是否为低置信度和服务故障准备了安全降级;
- 是否能阻止模型直接执行高风险操作;
- 是否有独立评估集和可回滚的版本策略;
- 是否对 Clef、Clef-flash、现有规则和其他模型做过同流量对比。
决策模型最适合做“受约束的选择器”,而不是系统中的最终授权者。把模型放在清晰的策略边界内,再用真实结果持续校准奖励,才能同时获得速度、成本和可靠性上的收益。