cf 正式发布：面向整个 Cloudflare API 的智能体驱动的 CLI

在过去一年里，AI 智能体对 Wrangler 的使用量急剧攀升。

2026 年 3 月，AI 智能体贡献了 Wrangler 使用量的四分之一，而前一年的占比还是个位数百分比。上周，智能体的使用率已达到 48%。

AI 智能体是更高产的用户，每天使用的不同命令数量几乎翻倍，使用六个或更多命令的可能性几乎是四倍。

AI 智能体喜爱 CLI。但 Wrangler 仅提供约 280 种操作的命令，而 Cloudflare 提供的操作多达数千种。

今年早些时候，我们曾预告过我们的解决方案。今天，我们正式推出全新 CLI：cf，让 AI 智能体能够使用每一个 Cloudflare 产品。

cf 是专为下一代软件开发打造的 CLI：

• AI 智能体可以通过专属搜索和引导找到所需的命令，完成任何想做的事情。
• JSON 是默认接口，对人类友好地美化输出，对 AI 智能体则进行压缩，以实现最大限度的上下文节省。
• cloudflare.config.ts 是 Cloudflare 全平台的全新配置格式，从 Workers 开始，将 TypeScript 的安全性和准确性带给您以及您的智能体的语言服务器协议（LSP）。
• Vite 成为默认工具，带来业界最佳的本地开发服务器，以及面向开发者和框架作者的插件套件。

立即全球安装公开测试版，随时随地运行：

npm i -g cf

cf 让您的智能体访问整个 Cloudflare API

如果您的 AI 智能体能做到 Cloudflare 能做的一切，会怎样？这正是我们今年初产生兴趣的问题：智能体变得越来越强大，但它们通过 Cloudflare CLI 所能完成的事情仍然有限。

Wrangler 是手工构建的，每个产品团队都以自己的方式为命令开发者体验做出贡献。即便只有约 280 条命令路径，在团队之间推行统一模式几乎不可能。d1 info、hyperdrive get、workflows describe 之间的术语不一致，因为每个团队在不同时期制定了各自的实践方式。部分团队花费数千行代码构建了完全自定义的体验，但这些体验极少被使用，而且各团队对同一问题采用了不同的解决方案。

我们希望在标准化现有内容的同时，一次性完成大规模扩展。Forge——Cloudflare 全新的统一 API 生成流水线——让我们得以实现这一目标。其核心理念是直接从支持 API 文档和 SDK 生成的 API 模式中生成 CLI 命令。我们提供的所有内容都有 OpenAPI 模式，只需添加一点额外信息进行注解，即可将其作为 Forge 生成 CLI 的来源。

这使我们能够将 cf 从 Wrangler 多年积累的约 280 个功能，扩展到涵盖 Cloudflare API 全部超过 3,000 个操作。

现在，只需将 cf 交给您的 AI 智能体，让它设置 worker、部署、监控、使用 Cloudflare Access 进行保护、购买域名，并通过 Cloudflare WAF 进行防护——全部通过单一工具完成。

为从未使用过 cf 的智能体而构建

cf 是为软件工程的发展轨迹而构建的，智能体驱动的开发正在从根本上改变软件的构建和部署方式。今年，我们专注于提供支持这一转变的工具，cf 是这一努力的集大成之作。cf 从零开始以智能体为核心进行构建，包含用于智能体驱动命令发现的创新工具，我们认为这些工具将在不久的将来成为更多 CLI 的标准。

Wrangler 有一个优势：多年的文档、博客和第三方指南已被纳入 LLM 的训练过程。但这也带来了同样的劣势：改变 Wrangler 的工作方式现在与已学习的行为相悖，而鉴于我们希望实现的改进规模，重大变更是不可避免的。

引入一个 AI 智能体从未见过的新 CLI 听起来像是一次巨大的颠覆性变化——但实际上这是我们能做的最干净的事情。由于我们所做的设计决策、我们可以进行的上下文注入以及我们可以追加的 AGENTS.md 文件，以这种方式进行切换实际上比让智能体理解它所熟悉的工具的两个版本之间的主要差异更少令人困惑。我们在发布时内置了几项此类面向智能体的功能，更多功能即将推出。

智能体需要过滤 JSON，而不是查看表格

当 AI 智能体使用 Wrangler 时，它们会在每个命令后附加 --json，然后经常用 jq 过滤输出以提取字段子集。但 Wrangler 中只有部分命令支持 --json；许多命令返回的是专为人类在终端查看而设计的 Unicode 表格。智能体能够解读这些表格，但代价是比 jq 过滤器更多的时间和 token。

在 cf 中，我们采取了相反的立场：智能体只需要 JSON，如果智能体是这个工具未来的主要用户，那么 JSON 就应该是默认值。对于极少由人类访问的绝大多数命令来说，这显然是正确的选择。

作为这个 CLI 的人类用户，您实际上与直接使用它隔了一层。让 AI 智能体能够轻松过滤其结果，然后以您要求的任何格式返回该过滤后的列表，比提供您可能永远不会直接阅读的表格更为可取。

但如果您想做一些可能需要真实个人输入的事情，比如搜索要购买的域名，该怎么办？

对于您的 AI 智能体可以通过在长而繁琐的序列中链接命名参数来访问的命令，您只需填写表单即可。cf 将 API 的要求分解为一系列经过验证的输入，因此购买域名——即使是有复杂要求的域名——也简单易懂。

或者，如果您坚持，直接让您的智能体来做。

您的智能体可以自行找到正确的命令

在一个有 3,000 条可能路径的 CLI 中，您的 AI 智能体如何才能快速找到所需操作而不会让您的上下文爆炸？为此，我们还添加了 cf cli search。

这个命令允许您的 AI 智能体用自然语言询问需要做什么，一个小型搜索索引将根据 API 描述和参数提供合适命令的列表。当智能体第一次运行 --help 时，我们会自动告知它这个命令。

对智能体进行类型检查的配置

我们的新配置格式基于 TypeScript，人类和 AI 智能体都易于解析，并允许您以编程方式编写配置。

类型化配置对 AI 智能体极为有用。我们发现，即使没有对编程配置格式的任何先验背景，智能体也能够轻松识别并按需编辑配置，即便是像 env 这样相比 Wrangler 中同名特性已发生重大变化的元素也不例外。所有使用 LSP 插件的智能体，例如 Claude Code 和 Codex，都能从在上下文中解读更多配置文件格式信息中获益，并因此给出更精准的建议。

相比之下，TOML 没有可访问的模式，JSONC 虽然有关联模式，但 AI 智能体很少使用。

Cloudflare 内部的一些 Wrangler 配置文件已从超过 5,000 行（每位开发者有许多自定义环境）压缩了 40%，成为能更高效地构建每位开发者配置的工厂文件。

这是通过从同一通用基础以编程方式定义每个环境来实现的，而不是像 Wrangler 中常见的那样复制 env 块。具有多个环境的简单 Worker 只需切换 Vite 原生模式参数即可在不同配置集之间切换。

现在，实现此功能的一个简单配置如下所示：

import { bindings, defineConfig } from "cf/config";
import * as entrypoint from "./index.js" with { type: "cf-worker" };

export default defineConfig(({ mode }) => ({
  worker: {
    name: "example-worker", 
      entrypoint,
      compatibilityDate: "2026-09-27",
      env: {
        Environment: bindings.text(`This is ${mode} environment`),
      },
    },
}));

您可以通过 cf migrate 将您的 Cloudflare Worker 迁移到此新格式。

我们还提供了一些辅助函数，使构建您的 Worker 变得轻而易举。

通过 bindings，您的智能体可以便捷地发现开发人员平台提供的各项能力。包括环境变量、存储、数据库和队列在内的一切都可以由您的编辑器自动完成并进行解释。

import { bindings, defineConfig } from "cf/config";

export default defineConfig(({ mode }) => ({
  worker: {
    // ...
    env: {
      API_URL: bindings.text(
        mode === "production"
          ? "https://example.com"
          : "https://staging.example.com",
      ),
      API_TOKEN: bindings.secret(),
      CACHE: bindings.kv({
        id: mode === "production"
          ? "production-namespace-id"
          : "staging-namespace-id",
      }),
      DATABASE: bindings.d1({ name: `example-${mode}-database` }),
      UPLOADS: bindings.r2({ name: `example-${mode}-uploads` }),
      JOBS: bindings.queue < { userId: string } > ({
        name: `example-${mode}-jobs`,
      }),
      AI: bindings.ai(),
      SEARCH_INDEX: bindings.vectorize({
        name: `example-${mode}-search`,
      }),
      API: bindings.worker({ worker: `example-${mode}-api` }),
    },
  },
}));

同样，我们包含了一个触发器提供了一个辅助函数，这是一种为 Worker 定义路由、队列、计划和邮件触发器的新方式。所有可能触发 Worker 运行的操作现在集中在单一配置块中，而不是以往那样零散地分布在配置文件各处。

import { defineConfig, triggers } from "cf/config";

export default defineConfig({
  worker: {
    // ...
    triggers: [
      triggers.fetch({ pattern: "example.com/*" }),
      triggers.scheduled({ schedule: "0 * * * *" }),
      triggers.queue({ name: "jobs", maxBatchSize: 10 }),
      triggers.email({ addresses: ["support@example.com"] }),
    ],
  },
});

defineConfig.worker 只是一个开始。我们创建 cloudflare.config.ts 的初衷，是让它成为您统一管理整个 Cloudflare 的方式。您所需的每一款产品——连同通过 cf 向其开放的 API——都将能够以类型安全的配置方式来表达。很快您将能够通过此配置文件配置整个策略、设置区域、配置 DNS 等。

同类最佳的开发体验

当 Wrangler 开始构建 JavaScript Workers 时，Vite 还不存在。我们在 Wrangler 中使用 esbuild 来打包您的 Workers。Wrangler 在 :8787 上提供的开发服务器是 Wrangler 团队自己构建的，对其进行任何修改都意味着要深入 Miniflare 等 Cloudflare 专属本地工具的内部。

Vite 在这方面是一个巨大的进步，它拥有丰富的插件生态系统，提供具备 HMR（热模块替换）的同类最佳开发服务器，并使用基于 Rust 的库 Rolldown 进行 tree-shaking 构建。您用 Vite 能做的一切，都可以用 Cloudflare Vite Plugin 来实现。

Cloudflare Vite Plugin 是我们建议您构建 Workers 的推荐方式，无论您在构建什么：无论是以前端为主的项目还是后端 API。结合我们的 Vitest 插件，它提供了一个与 Cloudflare Workers runtime 相匹配的一体化开发和测试环境，让您直接访问绑定和平台 API。

cf 默认基于 Vite 构建。您的大多数 Workers 将在 AI 智能体的协助下轻松迁移。其他的可能需要更多时间，这就是为什么 cf 将继续把需要继续使用 esbuild 的 JavaScript Workers 以及 Rust 和 Python Workers 的开发和部署委托给 Wrangler。

从 Wrangler 迁移

将 Worker 从 Wrangler 迁移就像运行 cf migrate 一样简单。

cf migrate

已经使用 Vite 构建的 Workers 将自动转换为 cloudflare.config.ts。如果您的 Worker 依赖 Wrangler 的 esbuild，cf 将继续把构建委托给 Wrangler。

当公开测试版结束时，我们将发布 Wrangler 的最终主要版本，引导您和您的 AI 智能体使用 cf。在测试版结束后，我们将继续为 Wrangler 提供 18 个月的维护支持，以便您有时间进行迁移。

您也可以运行 cf init/deploy 来自动为 Cloudflare 配置新项目，它将为您安装 Cloudflare Vite Plugin 并创建配置文件。

静态网站仍然不需要配置文件即可启动，部署它们就像在您的项目中运行 cf deploy 一样简单。

要使用 cf 启动一个新的 Hello World 项目，请使用 cf init。

cf 是开源项目，如有问题请反馈至我们的 GitHub 仓库。