资讯 Cloudflare 发布 cf CLI：命令从 Wrangler 的 280 条扩到 3000+，默认输出 JSON 给 AI Agent

2026-10-05 20:02:43

Cloudflare 发布 cf CLI：命令从 Wrangler 的 280 条扩到 3000+，默认输出 JSON 给 AI Agent

作者：Matt "TK" Taylor、Samuel Macleod，2026 年 9 月 28 日。

GitHub：
npm：
官方博客：
文档：

过去一年，Agent 对 Wrangler 的使用量涨得很快。2026 年 3 月，Agent 占 Wrangler 使用量的四分之一，前一年还是个数百分比。上周这个比例到了 48%。Agent 是更重度的用户：每天用到的不同命令数几乎是人类的两倍，用到 6 条以上命令的概率接近四倍。

Agent 喜欢 CLI。但 Wrangler 只覆盖约 280 个操作，而 Cloudflare 有几千个。今年早些时候 Cloudflare 预告过要解决这件事，今天正式发布新的 CLI：cf。

cf 面向下一代软件开发方式：

Agent 可以通过专门的搜索和引导，找到它想做的任何事的命令。
JSON 是默认接口，对人类 pretty print，对 Agent 压缩输出，尽可能省 context。
cloudflare.config.ts 是整个 Cloudflare 的新配置格式，从 Workers 开始，把 TypeScript 的安全性和准确性带给开发者以及 Agent 的 LSP。
Vite 成为默认，带来本地开发服务器和一套给开发者、框架作者的插件。

安装开放式 beta 版本，全局可用：npm i -g cf

Wrangler 只用于已经使用它的项目——存在 wrangler.jsonc、wrangler.json 或 wrangler.toml 文件——或者用户明确要求时。这些项目继续用 Wrangler，除非要迁移，迁移时使用 cf migrate。cf 的命令和 Wrangler 不同，查 cf --help 或 cf cli search ，不要猜。如果 cf 命令在一个不使用 Wrangler 的项目里失败了，不要直接回退到 Wrangler（包括 npx wrangler），除非先提出报告问题。

cf 让 Agent 访问整个 Cloudflare API

Wrangler 是手工构建的，每个产品团队各自贡献，各自决定自己命令的开发体验。跨团队强制统一模式几乎不可能，即使只有约 280 条命令路径也是如此。术语就不一致：d1 info、hyperdrive get、workflows describe，因为不同团队在不同时间形成了各自的做法。有些团队写了上千行高度定制的东西，实际极少被用到；也有团队用不同方式解决同一个问题。

Cloudflare 想一次性做到两件事：把已有的标准化，同时大幅扩展。Forge——Cloudflare 新的统一 API 生成流水线——让这件事可行。它的思路是直接从支撑 API 文档和 SDK 生成的 API schema 生成 CLI 命令。Cloudflare 提供的产品都有 OpenAPI schema，只要在 schema 上多标注一点信息，就能作为 Forge 的输入生成 CLI。

这条路径让 cf 从 Wrangler 多年积累的约 280 个功能，扩展到覆盖整个 Cloudflare API 表面的 3000+ 操作。

现在可以给 Agent 装上 cf，让它建一个 Worker、部署、监控观测、用 Cloudflare Access 保护、买域名、再用 Cloudflare WAF 放在前面，全部在一个工具里完成。

面向一个从没用过 cf 的 Agent 来设计

cf 从一开始就按 Agent 的用法设计，包含了一些新的 Agent 命令发现工具。

Wrangler 的优势是多年的文档、博客、第三方指南已经被 LLM 训练吸收。劣势同样是这一点：改变 Wrangler 的工作方式，就是在和已经学到的行为对着干。引入一个 Agent 从没见过的新 CLI 听起来像很大的破坏性变化，但实际上这是最干净的做法。

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

Agent 用 Wrangler 时会给每条命令加上 --json，然后用 jq 过滤出需要的字段。但 Wrangler 里只有部分命令支持 --json，很多命令返回的是为人类终端阅读设计的 unicode 表格。Agent 能看懂，但比一次 jq 过滤要花更多时间和 token。

cf 站到对立面：Agent 只需要 JSON，如果 Agent 是未来的主要用户，那它就应该是默认输出。对绝大多数很少被人类访问的命令，这显然是正确的选择。至于那些需要串联一长串难用命名参数的命令，你只要填一个表单。cf 把 API 的要求拆解成一系列经过校验的输入，所以买域名这种需求再复杂，跟着走也简单。

Agent 自己找到正确的命令

一个 CLI 里有 3000 条可能路径，Agent 怎么快速找到需要的操作而不撑爆 context？为此 Cloudflare 加了 cf cli search。这个命令让 Agent 用自然语言描述它要做什么，一个小型搜索索引会根据 API 描述和参数返回合适的命令列表。Agent 第一次运行 --help 时会自动被告知这个命令的存在。

能给 Agent 做类型检查的配置

新的配置格式基于 TypeScript，人类和 Agent 都容易解析，也允许用编程方式写配置。带类型的配置对 Agent 帮助很大。Cloudflare 发现，即使没有编程式配置格式的先验上下文，Agent 也能轻松按需识别和修改配置，哪怕遇到像 env 这种和 Wrangler 同名但已经大幅变化的元素也一样。所有使用 LSP 插件的 Agent，比如 Claude Code 和 Codex，都能在上下文里解读更多配置格式信息，给出更准确的建议。

对比之下，TOML 没有可访问的 schema，JSONC 有链接的 schema 但 Agent 很少用。Cloudflare 内部一些 Wrangler 配置文件从 5000 多行压缩了 40%——原来每个开发者都有一堆自定义环境——改成工厂文件，更高效地构建每个开发者的配置。做法是从同一个通用 base 编程式定义每个环境，而不是像 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 迁移到这个新格式。

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({ name: `example-${mode}-jobs` }),
AI: bindings.ai(),
SEARCH_INDEX: bindings.vectorize({ name: `example-${mode}-search` }),
API: bindings.worker({ worker: `example-${mode}-api` }),
},
},
}));

同样，triggers helper 是定义 Worker 的 routes、queues、schedules 和 email triggers 的新方式。

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 上提供的 dev server 是 Wrangler 团队自己做的，要改动其中任何部分都得深入 Miniflare 这类 Cloudflare 专用的本地工具内部。

Vite 是巨大的改进，有庞大的插件生态，提供带 HMR（热模块替换）的一流 dev server，构建时用基于 Rust 的 Rolldown 做 tree-shaking。你在 Vite 里能做的，用 Cloudflare Vite Plugin 都能做。无论构建什么，Cloudflare Vite Plugin 都是推荐方式。配合 Vitest 插件，它提供与 Workers 运行时匹配的开发和测试环境，并能直接访问 bindings 和平台 API。

cf 默认构建在 Vite 之上。大多数 Worker 可以由 Agent 直接迁移，另一些可能需要更多时间。所以 cf 会继续把开发与部署委托给 Wrangler，用于那些需要继续使用 esbuild 的 JavaScript Worker，以及 Rust 和 Python Worker。

从 Wrangler 迁移

把 Worker 从 Wrangler 迁移过来只需要运行 cf migrate。已经用 Vite 构建的 Worker 会被转换成 cloudflare.config.ts。cf 是开源的，问题可以报到 GitHub 仓库。

开放式 beta 结束后，Cloudflare 会发布 Wrangler 的最终大版本，把你和你的 Agent 引导到 cf。beta 结束后 Wrangler 会继续维护 18 个月，留出迁移时间。你也可以运行 cf init/deploy 自动为新项目配置 Cloudflare，它会安装 Cloudflare Vite Plugin 并创建配置文件。

复制全文生成海报 Cloudflare CLI Wrangler AI Agent Vite