Cloudflare 开源 Clef，Agent 有了决策层

Cloudflare 近日开源 Clef，一组专门用于 Agent 决策的模型。它们的任务不是像 GPT、Claude 那样写长文本，也不是单纯负责函数调用，而是根据当前上下文、可用工具和任务状态，判断 Agent 下一步应该采取什么动作。

决策模型是负责选择 Agent 下一步行动的专用模型，它连接了通用语言模型、工具和执行环境。

这听起来像是把“规划”从大模型里拆出来，但它背后的变化比换一个模型更重要：Agent 的核心组件正在从单一的大语言模型，变成由推理模型、决策模型、工具执行器、记忆系统和安全策略共同组成的系统。

Clef 解决的不是聊天，而是下一步

传统 Agent 通常把所有任务交给一个大模型。模型先理解用户意图，再决定是否调用工具；工具返回结果后，模型继续阅读上下文，判断下一步；如果任务复杂，还要不断重复这个循环。

这个架构的优点是简单，缺点也很明显。每个决策都要经过一个参数规模很大的模型，成本高、延迟高，而且模型容易在工具选择上出现摇摆。一个需要读取 100 个文件、执行多轮命令的编码 Agent，真正耗时的往往不是生成最终答案，而是中间大量的“要不要调用工具”“调用哪个工具”“工具返回后是否继续”的判断。

Agent 决策循环是指模型根据任务状态反复选择下一步动作，直到任务完成、失败或需要人工介入。

Clef 的切入点，就是把这个循环里的部分判断交给更小、更专门的模型。通用模型可以负责理解复杂需求、生成代码和处理开放式问题；Clef 则负责判断当前状态是否应该继续执行、选择哪个工具、是否转交给其他 Agent，或者直接结束任务。

这种分工类似操作系统里的调度器。调度器不负责完成应用本身的工作，却决定哪个进程先运行、使用多少资源以及何时暂停。对 Agent 来说，Clef 也不一定直接产出最终内容，但它可能决定整个系统如何运行。

为什么是现在：工具越来越多，单模型架构开始变贵

Agent 工具链正在迅速膨胀。一个面向开发者的 Agent 可能同时拥有文件读写、终端执行、代码搜索、网页访问、数据库查询、浏览器控制和部署工具。工具数量从几个增加到几十个后，工具选择本身就变成了一个分类问题。

工具选择是 Agent 在多个候选操作中，结合任务目标和当前状态确定最合适动作的过程。

过去，开发者通常有三种处理方式：

• 把全部工具描述塞进大模型上下文，让模型自行选择；
• 在模型外部写大量规则，例如遇到文件问题就调用搜索工具；
• 先用一个模型生成计划，再由另一个执行器按计划运行。

第一种方式最灵活，但上下文越来越长，工具描述会抢占模型的有效窗口；第二种方式可控，却很快演变成难以维护的规则系统；第三种方式更稳定，但计划一旦过时，Agent 仍然需要重新判断。

Clef 代表了第四种思路：训练一个专门理解“状态—动作”关系的模型，让它以更低成本完成高频决策。

这也是 Cloudflare 把 Clef 放进 Agent Cloud 语境中的原因。Cloudflare 过去的重点是把 Agent 部署到全球网络、Durable Objects 和 Workers 上；随着 Agent 变成持续运行的服务，模型每一步的调用成本和延迟都直接影响基础设施账单。一个每次只需要判断“继续、暂停、调用工具 A 还是工具 B”的环节，没有必要反复调用最昂贵的通用模型。

Clef 与通用大模型不是替代关系

把 Clef 叫作“新模型”容易，但把它理解成 GPT、Claude 的竞争者就错了。它更接近一种模型组件，定位类似路由器、规划器或控制器，而不是面向用户的聊天入口。

| 对比项 | 通用大语言模型 | Clef 决策模型 | |---|---|---| | 主要任务 | 理解需求、生成文本、编写代码、复杂推理 | 选择下一步动作、工具、流程或执行路径 | | 输出形式 | 自然语言、代码、结构化结果 | 动作选择、决策结果或控制信号 | | 适合场景 | 开放式问题和复杂任务 | 高频、重复、边界相对清晰的 Agent 决策 | | 调用特点 | 单次成本和延迟相对较高 | 适合在循环中高频调用 | | 主要风险 | 幻觉、长上下文成本、工具调用不稳定 | 决策空间覆盖不足、错误动作被放大 | | 与 Agent 的关系 | 负责“理解和创造” | 负责“调度和推进” |

这意味着最现实的部署方式不是“把所有请求换成 Clef”，而是让两类模型协作。例如，一个客服 Agent 可以让通用模型理解用户问题，让 Clef 判断是否需要查询订单、转人工或结束会话；一个代码 Agent 可以让大模型修改代码，让 Clef 决定是否运行测试、读取更多文件或创建子任务。

决策模型的价值，在于每一步都更便宜

Agent 的成本不能只看用户发出的那一次请求。真正需要计算的是整个任务生命周期：模型调用次数、上下文长度、工具执行次数、失败重试次数，以及等待外部系统返回结果的时间。

假设一个任务平均经历 20 次决策循环。如果每次都调用一个高成本模型，模型调用就可能成为主要开销；如果其中 15 次只是判断“继续执行上一步”或“选择一个已经明确的工具”，用专用决策模型处理，就有机会减少大模型调用次数。

这里的关键不是 Clef 是否比通用模型“更聪明”，而是它是否在一个狭窄任务上更稳定。一个只负责判断工具路由的模型，不需要写诗、做数学证明或生成完整前端页面。它只需要在定义好的动作集合里做出可靠选择。

专用模型的优势是把模型能力限制在明确任务上，从而换取更低延迟、更低成本和更容易评估的行为。

当然，Cloudflare 目前公开的 Clef 材料并没有给出足够完整的统一基准，无法据此断言它在所有 Agent 任务中都优于 GPT、Claude 或其他开源模型。尤其是以下数据仍需要在实际使用中验证：不同工具数量下的选择准确率、长任务中的错误累积率、模型推理延迟、显存需求，以及在工具描述发生变化后的迁移能力。

对开发者来说，这反而是一个重要提醒：决策模型的评估指标不应只看通用语言模型常见的知识问答分数，而要看它能否减少无效调用、降低重试次数，并在失败时把控制权交还给人或更强的模型。

Clef 与 Cloudflare Agent Cloud 的关系

Cloudflare 今年持续扩展 Agent Cloud，目标是把 Agent 从本地脚本变成可以长期运行、被事件唤醒并在全球网络上执行的生产服务。其 Agents SDK 基于 Durable Objects，为每个 Agent 提供持久身份、状态和 SQLite 存储；Project Think 则进一步加入持久化执行、子 Agent、沙箱代码执行和会话管理等能力。

持久化 Agent 是能够在进程结束后保留状态，并在 HTTP 请求、定时任务、邮件或其他事件到来时继续工作的 Agent。

在短对话里，决策模型的价值可能还不明显。但在一个持续数小时甚至数天的任务中，决策层会变得关键。长任务通常需要处理暂停、恢复、重试、并发、权限变化和外部依赖失败等状态。如果每一次状态切换都依赖一个通用模型，系统的行为很难预测；如果所有情况都靠硬编码规则，又很难覆盖真实世界的变化。

Clef 可能处在两者之间：它用模型处理规则难以穷举的状态判断，同时把动作限制在开发者定义的工具和权限范围内。这样一来，Agent 的行为不再完全由提示词决定，而是由模型、状态机、工具清单和安全策略共同决定。

这也解释了为什么 Clef 和 Gatekeeper 这类安全组件需要被区分。Gatekeeper 更接近安全与治理层，负责限制 Agent 能做什么；Clef 更接近决策层，负责在允许的范围内判断下一步做什么。前者划定边界，后者在边界内调度。

开源的意义：让决策层变成可替换组件

Cloudflare 开源 Clef，最值得关注的地方不只是“又多了几个模型权重”，而是它公开了一个更容易被基础设施厂商和开发者接受的接口思路：模型不必总是作为产品入口，也可以作为 Agent 系统里的中间组件。

过去，开发者往往围绕某个大模型的提示格式、函数调用协议和上下文限制搭建整个应用。一旦模型更换，工具描述、错误处理和工作流都可能需要重写。决策模型的引入，则提供了一种更模块化的结构：

• 通用模型负责复杂理解，决策模型负责动作选择；
• 大模型可以按任务难度动态切换，决策层保持相对稳定；
• 工具权限和动作集合由应用控制，模型只在有限空间内决策；
• 决策结果可以被记录和评估，便于定位 Agent 为什么走错路径。

对开源社区而言，真正重要的不是 Clef 是否马上成为默认模型，而是它能否形成可复用的数据格式、评估基准和训练范式。如果不同平台都能用相似方式训练“工具选择模型”“任务路由模型”和“恢复策略模型”，Agent 工具链就可能出现类似数据库驱动或消息队列那样的基础组件生态。

目前仍有三个问题没有答案。第一，Clef 的训练数据如何覆盖复杂、多轮、带失败分支的任务；第二，模型面对新工具和新工具描述时，是否需要重新训练；第三，当 Clef 的决策与通用模型的判断冲突时，谁拥有最终控制权。

这些问题决定了决策模型究竟是可靠的基础设施，还是另一层不可解释的黑盒。特别是在部署、支付、删除数据或修改生产配置等高风险动作中，不能因为模型更小、延迟更低，就默认它更安全。动作白名单、权限隔离、人工确认和审计日志仍然必不可少。

开发者现在应该怎么看

如果你的 Agent 只有一个工具、只运行几秒钟，Clef 暂时不会改变架构。直接使用现有模型的工具调用能力，通常更简单。

如果你的系统已经出现以下症状，决策模型就值得评估：

• 工具数量超过 10 个，模型经常选错工具；
• 一个任务需要经历 10 次以上工具调用；
• 大量模型调用只是判断是否继续，而不是生成新内容；
• Agent 需要暂停、恢复、重试或跨设备继续运行；
• 你需要记录每一步决策，并对错误路径进行统计；
• 生产环境对延迟、调用成本和权限边界有明确要求。

实践上，最稳妥的落点不是一开始就让 Clef 接管整个 Agent，而是先把它放在低风险、高频率的环节。例如工具路由、任务分类、重试判断和简单的子任务分发。复杂规划、代码生成和涉及不可逆操作的决策，仍然交给更强模型或人工审核。

判断 Clef 是否有用，看三个指标

第一是有效决策率：模型选择的动作是否真的推动任务向完成状态前进，而不是只看单步分类准确率。

第二是单位任务成本：一个完整任务从开始到结束消耗多少模型调用、多少计算时间，以及失败后是否需要额外重试。

第三是错误可恢复性：即使 Clef 选错了，系统能否检测错误、回滚状态并切换到更强模型。一个不是每次都正确、但错误容易被发现和修复的决策层，往往比一个偶尔产生严重错误的“高准确率”组件更适合生产环境。

Cloudflare 的动作说明很清楚：Agent 的下一阶段竞争，不只是谁拥有更大的模型，也是谁能把模型组织成更可靠、更便宜、更可观察的系统。Clef 不是通用模型的替代品，但它把一个长期被藏在大模型内部的问题单独拿了出来——Agent 到底应该在什么时候做什么。

这件事的意义在于，一旦“决策”成为独立组件，开发者就可以单独训练、部署、替换和评估它。未来的 Agent 工具链，可能不再只有一个负责所有事情的大模型，而是由多个能力边界清晰的模型共同完成任务。Clef 是否会成为这一层的标准答案，现在还不能下结论；但 Cloudflare 已经把决策模型从架构讨论推进到了可运行、可开源的产品组件阶段。

参考来源

• Cloudflare GitHub 官方组织：查看 Cloudflare 开源的 Agents、Workers 与相关开发工具项目。
• Cloudflare Agents SDK 仓库：了解 Cloudflare 持久化 Agent、会话和部署能力的开源实现。
• Hugging Face：用于检索 Clef 相关模型权重、模型卡和社区评测信息。