Cloudflare推出cf CLI：Agent化的全API命令行工具

过去一年，Agent 对 Wrangler 的使用量急剧攀升。

2026 年 3 月，Agent 贡献了 Wrangler 25% 的使用量，而前一年还只是个位数占比。上周，Agent 使用率已达 48%。

Agent 是更高产的用户群体，每天使用的独立命令数量接近人类的两倍，且使用六个及以上命令的概率是人类的三倍多。

Agent 喜欢 CLI。但 Wrangler 只提供了约 280 个操作命令，而 Cloudflare 实际上提供了数千个。

今年早些时候，我们预告了解决这个问题的方案，如今我们正式推出一款全新 CLI——cf，让 Agent 能够使用 Cloudflare 的全部产品。

cf 是一款为下一代软件开发而生的 CLI：

• Agent 可以通过定制化搜索和引导功能找到所需命令，完成任何想做的事。
• JSON 是默认接口，为人类做了格式化输出，为 Agent 做了精简压缩，最大化节省上下文。
• cloudflare.config.ts 是整个 Cloudflare 的新配置格式，从 Workers 开始，将 TypeScript 的安全性和准确性带给你的 Agent 的语言服务器协议（LSP）。
• Vite 成为默认选项，带来了业界顶尖的本地开发服务器，以及面向开发者和框架作者的插件套件。

今天就在全球范围内安装开放测试版，随时随地运行它：

cf 让你的 Agent 能够访问整个 Cloudflare API

如果你的 Agent 能完成 Cloudflare 能做的一切事情，会怎样？这个问题在今年早些时候激发了我们的兴趣：Agent 越来越强大，但它们通过 Cloudflare CLI 能做的事仍然受限。

Wrangler 是手工打造的，每个产品团队贡献代码并各自负责自己命令的开发体验。在团队之间强制执行统一模式几乎是不可能的，即使在我们约 280 条命令路径中也是如此。各团队在不同时期提出了自己的实践方案，导致 d1 info、hyperdrive get、workflows describe 等命令的术语不一致。有些团队构建了完全定制的体验，代码动辄数千行，结果使用频率极低；还有团队针对同一问题提出了不同的解决方案。

我们希望在标准化现有内容的同时实现大规模扩展，一举两得。Forge——Cloudflare 的新型统一 API 生成流水线——使我们能够做到这一点，其核心思想是从驱动 API 文档和 SDK 生成的 API schema 直接生成 CLI 命令。我们提供的每一样东西都有 OpenAPI schema，只需再添加少量注解信息，就可以将其作为 Forge 生成 CLI 的来源。

这使我们能够将 cf 从 Wrangler 长期以来积累的约 280 个功能，扩展到覆盖超过 3000 个操作的整个 Cloudflare API 表面。

现在，只需给你的 Agent 提供 cf，让它帮你创建 Worker、部署它、监控和观察它、用 Cloudflare Access 保护它、购买域名、并用 Cloudflare WAF 为其前置防护，所有这些都通过一个工具完成。

为从未使用过 cf 的 Agent 而构建

cf 的构建面向软件工程的演进轨迹，Agent 式开发正在深刻改变软件的构建和部署方式。今年我们一直专注于提供支持这一转变的工具，最终成果就是 cf。cf 从零开始围绕 Agent 构建，包含了一系列创新的 Agent 命令发现工具，我们认为这些工具在不久的将来会成为更多 CLI 的标准配置。

Wrangler 的优势在于，多年积累的文档、博客和第三方指南已经被吸收到 LLM 的训练过程中。它的劣势也在于此：现在改变 Wrangler 的工作方式会与已学习到的行为相冲突，而且考虑到我们想要实现的改进规模，重大改变不可避免。

引入一款 Agent 从未见过的新 CLI 听起来像是一次巨大的颠覆性变革——但实际上这是我们能做的最干净利落的事。由于我们做出的设计决策、可以注入的上下文，以及可以附加的 AGENTS.md 文件，以这种方式切换实际上比让 Agent 将一款熟悉工具的两个版本之间的主要差异进行上下文理解更加清晰。我们首发时内置了几个这类面向 Agent 的功能，后续还会有更多。

Agent 需要过滤 JSON，而不是看表格

当 Agent 使用 Wrangler 时，它们会在每个运行的命令后附加 --json，然后通常用 jq 过滤输出以提取部分字段。但 Wrangler 中只有部分命令支持 --json；许多命令返回的是 unicode 表格，设计给在终端查看输出的人类。Agent 能搞定这些，但比起 jq 过滤，需要花费更多时间和 token。

在 cf 中我们采取了相反的立场：Agent 只需要 JSON，如果 Agent 是这款工具的未来主要用户，那它就应该成为默认值。对于绝大多数很少被人类访问的命令，这显然是正确的选择。

作为这款 CLI 的人类用户，实际上你与使用它之间隔了一层。Agent 能够轻松过滤结果，然后以你要求的任何格式返回过滤后的列表，这比提供你可能永远不会直接阅读的表格要好。

但如果你要做的事情可能需要真实的人工输入，比如搜索要购买的域名呢？

对于你的 Agent 可能需要通过一长串命名参数以冗长序列才能访问的命令，你只需填写一个表单即可。Cf 将 API 的需求解构为一系列经过验证的输入，即使是有复杂需求的域名购买也变得简单明了。

或者，如果你坚持，就让你的 Agent 来做这件事。

你的 Agent 可以自己找到正确的命令

面对一条 CLI 中 3000 条可能的路径，你的 Agent 如何在不膨胀上下文的情况下快速找到它所需的操作？为此我们还添加了 cf cli search。

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

让你的 Agent 进行类型检查的配置

我们的新配置格式基于 TypeScript，对人类和 Agent 都易于解析，并允许你以编程方式编写配置。

类型化配置对 Agent 非常有帮助。我们发现，即使没有先验的编程配置格式上下文，Agent 也能轻松按需识别和编辑配置，即使像 env 这样在 Wrangler 中发生了巨大变化的元素也不例外。所有使用 LSP 插件的 Agent，如 Claude Code 和 Codex，都能从在上下文中解读更多关于配置文件格式的信息中受益，因此能做出更准确的建议。

对比 TOML——它没有可访问的 schema，或者 JSONC——它有一个 Agent 很少使用的关联 schema。

Cloudflare 内部的一些 Wrangler 配置文件已从超过 5000 行（含每位开发者大量自定义环境）压缩了 40%，变成了能够更高效构建每位开发者配置的工厂文件。

这是通过编程方式从同一个通用基础定义每个环境来实现的，而不是像 Wrangler 中那样典型地复制 env 块。一个具有多个环境的简单 Worker 只需切换 Vite 原生的 mode 参数，就能在两组配置之间切换。

实现这一点的简单配置现在看起来是这样的：

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 为你的 Agent 提供了一个简单的入口来发现开发者平台的全部能力。一切——从环境变量到存储、数据库和队列——都可以在编辑器中自动补全和解释。

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` }),
                },
        },
  }));

同样，我们包含了 triggers 的辅助函数，这是定义 Worker 路由、队列、定时任务和邮件触发器的新方式。与其将这些分散在配置文件中，现在只需在单个代码块中就能简单找到所有可能触发 Worker 运行的 actions。

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 的方式。你需要的每一个产品——连同它的 API 通过 cf 对你的 Agent 可用——都将能够通过类型安全的配置来表达。很快你就能够配置完整的策略、设置 zones、配置 DNS 等等，全部通过这个配置文件完成。

业界顶尖的开发体验

当 Wrangler 最初开始构建 JavaScript Workers 时，Vite 还不存在。取而代之的是，我们在 Wrangler 中使用 esbuild 来打包你的 Workers。Wrangler 在 :8787 上提供的开发服务器是 Wrangler 团队构建的，修改任何这部分都意味着要深入 Cloudflare 特定的本地工具（如 Miniflare）的内部。

Vite 对此是一个巨大的改进，它附带了一个庞大的插件生态系统，以及业界顶尖的开发服务器和 HMR（热模块替换），构建则使用基于 Rust 的库 Rolldown 进行 tree-shaking。你能用 Vite 做的任何事，都可以用 Cloudflare Vite Plugin 来做。

Cloudflare Vite Plugin 是我们建议构建 Workers 的推荐方式，无论你在构建什么：无论是前端主导的项目还是后端 API。结合我们的 Vitest 插件，它提供了一个与 Workers 运行时匹配的内聚开发和测试环境，让你直接访问 bindings 和平台 API。

cf 默认基于 Vite 构建。你的大部分 Workers 只需通过 Agent 就能简单迁移。其他的可能需要更多时间，这就是为什么对于仍需使用 esbuild 和 Rust 的 JavaScript Workers 以及 Python Workers，cf 将继续委托给 Wrangler 进行开发和部署。

从 Wrangler 迁移

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

已经用 Vite 构建的 Workers 将为你转换为 cloudflare.config.ts。如果你的 Worker 依赖 Wrangler 的 esbuild，那么 cf 将继续委托给 Wrangler 进行构建。

开放测试版结束后，我们将发布 Wrangler 的最终主要版本，引导你和你的 Agent 使用 cf。测试版结束后，我们将继续提供 18 个月的维护支持，给你时间进行迁移。

你也可以通过运行 cf init/deploy 来启动新项目并自动为 Cloudflare 进行配置，这将为你安装 Cloudflare Vite Plugin 并创建一个配置文件。

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

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