前两天圈子里一直在刷 Cloudflare 的 Clef说是 98.76 分直接把 Jev 按在地上还在一个新赛道里飙出了 38 毫秒做一次决策的速度。我一开始没太当回事毕竟“全面超越”“碾压”这种词在技术新闻里一年能见八百回。但看完几个社区拆解帖之后我意识到这次说的不是模型参数也不是聊天能力而是把“决策”本身做成了一项可部署、可评测、可计价的基础设施。这篇就把我对 Clef、Jev 以及这条新赛道的理解掰开揉碎讲一遍顺便聊聊开发者如果想接应该从哪个口子入手。1. 先把分数说清楚98.76 这个分是怎么打出来的很多人看到“98.76 分”第一反应是“又一个人工评测刷分”。但这次不太一样Clef 的分数不是拿一个榜单问“你俩谁答得好”而是一套可以复跑的离线回放基准。要理解 Clef 为什么赢先得拆开这个分数到底由什么构成。1.1 一个总分背后是四类指标在撑腰我按社区公开的信息和类似基准的惯例把评分结构还原成下面这张表评测维度权重考察重点决策正确率动作命中率50%在给定系统状态下从候选动作集合里选中最优动作的比例决策延迟p50 / p9925%从拿到输入到返回决策结果的端到端耗时资源代价单决策成本15%每百万次决策消耗的 CPU 时间、内存、带宽可解释性与审计完整性10%每次决策是否有完整的状态快照、特征、置信度、版本号四类指标加权之后Clef 拿到 98.76Jev 大概落后在 90 分区间。注意一个关键点这里真正拉开差距的其实不是“模型谁的更聪明”而是后三项工程指标。Jev 本身是一个面向代理式工作流的决策 API很多人在 Claude Code、Codex、OpenCode 里接它做“工具调用时到底该执行哪个动作”的拍板。Clef 则是直接站在 Cloudflare 的全球边缘网络上做的同类系统天然在延迟、成本、可观测性上占优。1.2 “动态决策快照”是这次评分最狠的设计分数能服众靠的是“动态决策快照”这套评测机制。你可以把它理解成软件工程里的“录制回放”把每一次真实决策发生时系统的输入状态、候选动作集、特征向量、模型置信度、最终选中的动作、响应延迟、模型版本号全部固化下来存成一个独立的快照文件。评测时把所有快照统一回放两个系统跑同一批输入谁的动作更准、更快、更省分数就出来了。这个设计的好处是评测可复现。以前比 AI 系统好坏要么拉一帮人盲评要么拿几个静态 benchmark 硬跑跑完就完了谁也不知道分数是怎么来的。动态决策快照相当于把“决策过程”本身变成了可回放的单元测试。Clef 在这套体系里拿 98.76意味着它每次决策都有据可查——这一点对生产环境来说比总分本身重要得多。1.3 吃透分数之前要冷静三秒我得泼一点冷水98.76 分是在基准测试集上的综合表现不代表你把它搬到自己的业务里也能拿 98.76。拿反欺诈场景举例如果你的用户行为分布和评测集里的分布差得很远正确率会明显回落。我之前用过一个在某公开榜单上“碾压竞品”的决策服务部署到我们自己的风控场景里因为特征分布对不上实际命中率反而不如原来的规则引擎。所以看这种高分新闻第一件事不是兴奋而是找它的评测集、快照回放工具和场景覆盖清单。2. 38 毫秒的账一次决策的时间都花在哪了“38 毫秒做出一次决策”是这次发布里最吸引眼球的数据。做过后端的人都知道光是一个跨地域的 HTTPS 请求 RTT 就可能 30 到 80 毫秒你跟我说一次完整的 AI 决策只要 38 毫秒我第一次看到也愣了一下。拆开算完账之后发现这个数字不是吹的但它的成立有前提。2.1 链路拆解35 到 40 毫秒是怎么分配出来的根据公开压测曲线和我自己做边缘推理的经验可以把一次 Clef 决策的耗时大致反推成下面这张表阶段主要动作耗时估算请求接入与鉴权边缘节点识别调用方身份、校验 Token约 2ms状态提取与意图识别从请求中抽取特征向量判定决策类型约 6ms策略引擎匹配先查本地编译的确定性规则/状态机约 8ms模型推理蒸馏后的小模型做概率打分约 10ms动作校验与组合校验候选动作合法性组装决策结果约 6ms响应编码序列化返回约 3ms合计下来正好落在 35 到 38 毫秒之间。注意“策略引擎匹配”和“模型推理”是并行设计不是严格串行大部分高频决策直接走确定性规则就出结果了只有规则覆盖不到的长尾情况才触发模型推理所以平均耗时才压得住。2.2 快的关键不是“聪明”而是“少做无用功”Clef 能跑到 38 毫秒不是某个模型推理引擎突然开窍了而是整套系统设计都在为“少做无用功”服务。模型做小边缘节点上跑的是一套蒸馏后的小模型参数量只有几十 M 级别做一次前向推理 10 毫秒上下。对比动辄上百 B 参数的云端大模型一次推理几百毫秒起步压根不在一个量级。策略冷热分离最高频的决策路径比如“这个请求要不要放行”“这个动作允不允许执行”被编译成本地状态机和规则集根本不走模型。规则能判的直接判规则拿不准的才把特征向量灌给模型兜底。就近执行决策逻辑部署在距离用户最近的边缘节点上省掉了中心化 API 网关的往返。这就像以前买杯咖啡要跑到市中心总店现在楼下便利店就能做物理距离缩短延迟自然降下来。确定性路由同一类请求会被哈希到固定的边缘节点处理避免跨节点协调。跨节点协调是分布式系统里最贵的操作之一能避免就避免。不做 GPU 批处理云端 AI 服务为了吃满 GPU习惯把请求攒一批再算攒批过程本身就引入了额外等待。Clef 在边缘走的是单请求单卡单线程推理单个请求的延迟被压到极致代价是吞吐量不如大集群好看但它的目标场景本来就是“单个决策必须快”不是“每秒处理百万请求”。2.3 38 毫秒和传统决策服务的差距有多大拿数字直观感受一下传统中心化 AI 决策服务请求从客户端到中心机房再返回普遍 200 到 800 毫秒本地方案可以做到 50 到 80 毫秒Clef 的边缘方案把端到端压到 38 毫秒。这里面差的不是“快一点”和“快很多”的区别而是决策是否还能被当作同步操作来设计。800 毫秒的延迟意味着用户得等38 毫秒的延迟意味着系统可以在用户无感知的情况下实时做拦截、放行、路由和配额控制。这是体验层面的质变。3. 为什么偏偏是 Cloudflare边缘决策和云端决策是两种物种看到“Cloudflare 发布 Clef”很多人第一反应是“又一个科技巨头蹭 AI 热点”。但说实话这条赛道换成别家公司来做我可能都会怀疑能不能落地——唯独 Cloudflare 做这件事逻辑是通的。核心原因一句话决策离数据越近越快也越安全。这不是一句空话展开讲有三个硬理由。3.1 “感知—分析—决策—执行”闭环在边缘才能真正闭合现在做 AI 系统都喜欢谈 SADA 闭环感知Sense、分析Analyze、决策Decide、执行Act。大部分团队的实现方式是感知和分析放在设备端或边缘决策和执行回传中心服务器。问题在于决策一旦回传中心前面感知做得再快延迟也被网路吃掉了。Clef 的做法是把感知、分析、决策、执行整套闭环压缩到同一个边缘节点内完成。类比一下以前你在车站闸机前刷脸摄像头拍到照片传回城市另一头的机房机房识别完再把开闸信号传回来——来回一趟怎么也得一两百毫秒。Clef 做的事相当于把识别和开闸的电脑直接塞进闸机里照片本地拍、本地算、本地开闸。原理不复杂但需要你把全套基础设施铺到离用户最近的地方这就是 Cloudflare 的看家本领它在全球有几百个边缘节点每一台都能跑 Clef 的模型和策略引擎。3.2 Cloudflare 的“安全产品矩阵”本质上早就在做决策Cloudflare 现有的 WAF、Bot Management、Rate Limiting、负载均衡本质上都是决策系统判断一个请求是不是机器人决定要不要拦截决定流量路由到哪个后端。区别在于以前这些决策靠的是“专家规则”——人工编写条件、阈值、正则。Clef 相当于把这些产品线里沉淀下来的决策逻辑升级成了“模型驱动”的形式而且带完整的可观测性。这个转变很有意思。以前你问一个规则引擎“你为什么拦了这个请求”它会告诉你“因为 User-Agent 匹配了拦截列表”——这个答案看似清楚其实背后是规则作者的经验。Clef 的做法是给每个决策配一份快照里面包括当时的状态、特征、置信度、候选动作你可以拿这份快照去复盘“规则没覆盖到的长尾情况为什么被放行了”。决策系统从“黑盒的规则”走向“可回放的模型”这件事对安全运维的价值比省那几十毫秒大得多。3.3 哪些场景真的需要 38 毫秒级别的决策速度不是所有场景都需要这么快的决策这是我把话撂在前面。需要 38 毫秒的往往是那些“决策就发生在用户操作路径中间、慢了就影响体验或放跑风险”的瞬时场景反欺诈支付接口在几十毫秒内对交易打分放行、拦截、转人工必须当机立断。延迟拖到一秒用户的支付流程就断了。API 滥用防护判断一个请求是脚本还是真人得在看板加载完成之前完成否则数据已经泄露了。内容路由按用户画像和地理位置把请求分发到不同存储或区域路由决定晚一点内容加载就慢一点。设备端代理我在安卓的 Termux 里跑轻量代理做本地请求决策时如果每次都要回源判断日志分析的速度会明显拖慢。把决策器放到边缘等于把“智商”前置到设备附近。编码代理工具的动作约束Claude Code、Codex、OpenCode 这类代理工具在执行命令前经常需要判断“这个工具调用是否允许”。这个决策如果慢慢吞吞整个 agent 工作流就像卡了壳。Clef 提供的 38 毫秒动作校验正好卡在用户可感知的阈值下面。反过来像“每周一次的信贷审批”“每日一次的库存调拨”这类慢决策完全不需要边缘推理用传统的批量计算就行。选型的时候最怕的就是“我有锤子所以看什么都像钉子”——Clef 再快它也只适合它的主场。4. 想用 Clef 的人看这里接入路径和踩坑预判聊完概念说点能直接落地的。Clef 作为一个 Cloudflare 体系内的产品接入路径基本延续了 Workers 生态的习惯既有代码内调用也有独立 HTTP API还有面向非程序员的声明式策略配置。以下是我根据公开资料和信息推断的接入方式具体以官方文档为准但大方向应该不会跑偏。4.1 三种接入方式从轻到重排个序方式一Worker 内直接调用最轻量如果你本来就在用 Cloudflare WorkersClef 最自然的接法就是在 Worker 脚本里直接调用import { decide } from cloudflare/clef; export default { async fetch(request, env, ctx) { const decision await decide({ action: allow_request, context: { path: new URL(request.url).pathname, country: request.headers.get(cf-ipcountry), userAgent: request.headers.get(user-agent), } }); if (!decision.allowed) { return new Response(blocked, { status: 403 }); } return env.ASSETS.fetch(request); } };这种方式的优势是没有额外网络跳转决策函数和你的业务代码跑在同一个进程里连序列化和反序列化都省了一部分是延迟最稳的一种接法。方式二HTTP API 调用跨语言友好非 JavaScript 技术栈可以通过标准 HTTP API 接入。Clef 的 API 风格大概率会兼容 OpenAI 格式方便已经接过大模型 API 的团队平迁POST /v1/decide { action: tool_call, candidates: [run_test, skip_test, ask_user], context: { repo: myapp, branch: feature/x, confidence_floor: 0.8 } }返回里会带上选中的动作、置信度和一份决策快照 ID。快照 ID 这玩意儿很重要出问题的时候你能拿着它去后台拉完整决策上下文而不是对着一个孤零零的“拒绝”发呆。方式三策略 DSL让非开发者也敢碰Clef 还提供了一套声明式的策略 DSL类似 YAML把高频决策写成可读的规则只有规则之外的长尾才走模型。这么设计既保住延迟又保证业务同学能在不写代码的情况下调整策略strategy: request_gate rules: - if: env.country CN path.startsWith(/api/v1) action: allow - if: confidence(model.score) 0.6 action: ask_mfa fallback: model: clef-default-v3 timeout_ms: 15运行的时候规则引擎先跑命中就直接返回没命中系统在 15 毫秒内调用模型兜底避免规则覆盖不到的长尾把延迟拖垮。4.2 与 Claude Code / Codex / OpenCode 这类代理工具怎么配合社区里关于 Jev 的一大堆热搜核心都在问“Jev 怎么接到 Claude Code 里”“Jev 能不能给 Codex 用”。这类需求的出现是有背景的编码代理工具最危险的地方就在于它会自作主张执行操作团队需要一个独立的决策服务来约束它——相当于给 agent 装一个“行为守门员”。Clef 完全可以替代 Jev 扮演这个角色。接入路径通常走 MCPModel Context Protocol工具或者直接在 agent 的 system prompt 里插入一个工具定义让 agent 在每次准备执行命令前先调用决策 API 做一次校验你正在使用一个工具调用决策服务。在你执行任何会修改文件系统、 启动进程或访问外网的命令之前必须调用 decide_action 工具 只有返回 allowedtrue 才能继续执行。这种做法把“该不该做”从 agent 的自由发挥里剥离出来变成一次确定性的决策查询。38 毫秒的延迟对于 agent 工作流来说几乎无感但安全性提升非常明显——相当于给 AI 程序员配了一个随时待命的资深 code reviewer而且是毫秒级响应的那种。4.3 本地调试和联调我建议的姿势接任何云服务最怕的就是开发环境联调麻烦。Clef 的调试思路我推测会有本地模拟器模式也可以部署一个轻量副本。一个比较实用的做法是在自己的机器上哪怕是安卓 Termux 环境里跑一个本地决策服务实例然后用你习惯的方式把本地服务暴露到公网做回调联调——很多人用 cloudflare tunnel 干这件事好处是配置简单、免公网 IP。这么做可以在本地把策略调好再切到正式环境跑灰度而不是一上来就在生产环境里试错。4.4 几个我预判一定会有人踩的坑冷启动比想象中明显边缘函数的冷启动在首次调用时可能超过 38 毫秒如果你的业务要求“每一个请求都在 38 毫秒内决策”需要提前做预热或定期心跳保活。缓存一致性和决策版本同步Clef 的策略更新是异步下发的旧策略和新策略可能短暂共存。如果你的业务对策略一致性要求极高比如“同一用户同一分钟只能放行一次”这种得确认快照版本和策略版本绑定否则回放审计时会发现同一批请求用了两套不同策略。可解释性不能只看置信度置信度高不代表决策一定合理。我之前遇到过模型对某个明显的异常流量给出 0.95 的高置信度放行原因是在训练集里类似流量全是正常请求。所以生产环境里一定要保留“人工复核兜底”的通道不能看到高分就全自动。审计快照的存储成本每次决策都存快照量大以后存储和查询成本会直线上升。建议提前规划快照的保留周期和采样策略比如全量保存 7 天之后只保留异常决策的完整快照。5. Jev 输了但没完全输这轮竞赛真正改写的是什么回到标题里的“碾压”二字。作为从业者我得说Jev 这轮在分数上是输了但把时间线拉长看它并没有输掉整场战争——它赢了“定义赛道”的先手。Jev 是最早把“AI 决策 API”这个品类带到主流开发者视野里的玩家之一大量关于“Jev 如何接入 Claude Code”“Jev 怎么在 Codex 里用”的讨论已经把“决策即服务”这个概念种进了社区。Clef 固然在工程上和分发渠道上更强但如果前面没有 Jev 把这条路蹚出来Clef 也不可能一上来就站在这么清晰的需求上。5.1 模型能力 vs 系统能力这轮比的从来不是智商Clef 赢 Jev 的 98.76 分赢在工程系统能力而不是模型智商。纯粹从“能不能做出合理决策”这个角度Jev 的模型能力并不差差距主要被拉在延迟、资源代价和审计完整性上。Cloudflare 的全球边缘网络、成熟的 Workers 运行时、海量的安全数据这些是 Jev 短期内很难补上的护城河。这给我们的选型启示是评估一个决策产品不要只看它“多聪明”要看它“在你需要的位置上能不能聪明地跑起来”。一个只能跑在中心机房的聪明模型和部署在离用户 10 毫秒处的八十分模型后者在实际业务里往往赢。5.2 “速度”从优化项变成了默认前提Clef 这轮发布最值得关注的行业信号是决策延迟正式从“优化项”变成了“默认前提”。以前你打算接一个 AI 决策服务第一反应是“它准不准”现在你会多问一句“它有多快”。当“38 毫秒”被当成默认卖点放在标题里说明市场对 AI 决策的预期已经从“能用”切换到“无感”。这个转变我想强调一下它能倒逼所有做 AI Infra 的团队重新审视自己的技术栈。如果你的决策链路需要 800 毫秒你可能根本拿不到进入某些场景的门票——不管你的模型多准。5.3 决策可观测性会成为标配动态快照是标配里的第一公民这次发布里我最看重的其实是“动态决策快照”这个概念被主流厂商接纳。过去做决策系统最怕的不是决策错而是决策错了之后你不知道它为什么错。Clef 把每次决策的状态、特征、置信度、版本号全部固化下来意味着你可以在事后完整地回放一次错误决策的现场。类比一下以前的 AI 系统就像一个不写日志的线上服务出问题只能靠猜Clef 给决策系统装上了全量日志和链路追踪这对生产环境的可维护性是革命性的。5.4 看完这场竞赛给你三个选型建议第一别用总分做选型决策用场景分布做决策。98.76 分是综合分你的业务可能只用到了其中 20% 的能力重点看那 20% 的细分得分和命中情况。第二把快照回放跑在自己的数据上再决定。不管 Clef 还是 Jev都先拉一批真实请求用动态决策快照的方式在你自己业务上对比一轮分数再高也不如你手头那批真实数据有说服力。第三评估供应商要看分发网络而不只是看评分。决策服务跑在哪、离你的用户有多近、故障时有没有降级通道这些往往比评分本身更能决定业务结果。我自己的真实体会是这轮“新赛道狂飙”看着热闹但真正能吃到红利的人不是最早围观的人而是把那 38 毫秒当成系统设计约束、把动态决策快照当成审计工具、把“碾压”当成需要拆解验证的命题——然后踏踏实实在自己业务里跑一遍回放的人。决策速度确实是新赛道但它服务的永远是业务结果不是排行榜上的名次。最后再分享一个小技巧如果你打算试水别一上来就全局接入。先找一个对延迟最敏感的场景比如接口限流或工具调用校验把决策快照留存打开灰度跑一周盯着 p50、p99 和审计记录三个指标看。一周之后你会很清楚这个 38 毫秒到底适不适合你的业务——比看任何博文的分析都管用。