介绍cf：适用于整个Cloudflare API的智能体CLI

过去一年，agent 对 Wrangler 的使用量急剧上升。2026 年 3 月，agent 贡献了 Wrangler 使用量的四分之一，而前一年这个数字还只是个位数百分比。上周，agent 的使用占比达到了 48%。Agent 是更高产的用户，每天使用的不同命令数量几乎是人类的两倍，使用六条及以上命令的可能性则接近四倍。Agent 喜欢 CLI。但 Wrangler 只为大约 280 种操作提供了命令，而 Cloudflare 有数千种。

今年早些时候，我们预告了打算如何解决这个问题，而今天，我们通过推出一个新的 CLI，让 agent 能够使用 Cloudflare 的每一款产品：cf。cf 是为下一代软件开发而打造的 CLI：

Agent 可以通过专门的搜索与引导，找到完成任何任务所需的命令。
JSON 是默认接口，对人类格式化输出，对 agent 压缩输出，以最大限度节省上下文。
cloudflare.config.ts 是整个 Cloudflare 的新配置格式，从 Workers 开始，把 TypeScript 的安全性和准确性带给你和你的 agent 的语言服务器协议（LSP）。
Vite 成为默认选项，随之而来的是最好的本地开发服务器，以及一套面向开发者和框架作者的插件。

立即在全球范围内安装这个公开测试版，随处运行：

npm i -g cf

cf 让你的 agent 访问整个 Cloudflare API

如果你的 agent 能做到 Cloudflare 能做的一切，会怎样？这正是今年早些时候引起我们兴趣的问题：agent 变得越来越强大，但它们借助 Cloudflare 的 CLI 能做的事情仍然有限。

Wrangler 是手工打造的，每个产品团队各自贡献，并在命令的开发者体验上各走各的路。跨团队推行统一模式几乎不可能，即便是在我们约 280 条命令路径上也是如此。d1 info、hyperdrive get、workflows describe 之间的术语并不一致，因为每个团队在不同时间各自形成了自己的做法。有些团队用数千行代码构建了完全定制的体验，结果发现极少被使用；而不同团队又用不同的方式去解决同样的问题。

我们想一次做成两件事：把现有的东西标准化，同时做一次大规模扩展。Forge——Cloudflare 全新的统一 API 生成流水线——让我们做到了这一点。它的思路是直接从 API schema 生成 CLI 命令，而这份 schema 同时也是 API 文档和 SDK 生成的基础。我们提供的每一项能力都有 OpenAPI schema，只要在上面多加一点标注，就能把它作为 Forge 的输入来生成 CLI。

这样一来，cf 就能从 Wrangler 多年来积累的约 280 个函数，扩展到覆盖 Cloudflare 整个 API 面，超过 3,000 个操作。

现在，你只需给 agent 装上 cf，让它去创建一个 worker、部署、监控和观测、用 Cloudflare Access 保护它、买一个域名、再用 Cloudflare WAF 挡在前面——全都在一个工具里完成。

为一个从没用过 cf 的 agent 而构建

cf 是顺着软件工程的演进方向做的，而 agentic 开发正在彻底改变软件的构建和部署方式。今年我们一直专注于为这一转变提供工具，cf 是这一工作的集大成者。cf 从底层设计开始就把 agent 放在核心位置，还内置了一些用于 agentic 命令发现的新机制，我们认为用不了多久，这些机制会成为更多 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 将来是这个工具的主要用户，那 JSON 就该是默认输出。对于绝大多数人类很少碰的命令，这显然是正确的选择。

作为这个 CLI 的人类用户，你实际上已经隔了一层。让 agent 能轻松过滤结果，再按你要的格式把过滤后的列表返回给你，比给你一张你多半不会直接去看的表格要好。

但如果你想做的事需要真正的人工输入呢？比如搜索一个想买的域名。

对于那些 agent 可以通过串联命名参数、拼出一长串难用的命令来访问的操作，你直接填个表单就行。cf 把 API 的要求拆解成一系列带校验的输入项，所以买域名——哪怕需求很复杂——也能一步步照着填。

或者，如果你坚持，就让 agent 去做。

Agent 自己就能找到正确的命令

一个 CLI 有 3,000 条可能的路径，agent 怎么才能快速找到它需要的那个操作，又不把上下文撑爆？为此我们还加了 cf cli search。

这条命令让 agent 用自然语言说明自己想做什么，一个小型搜索索引会根据命令的 API 描述和参数，返回一份合适的命令列表。agent 第一次运行 --help 时，我们会自动告诉它有这么一条命令。

能给 agent 做类型检查的配置

我们新的配置格式基于 TypeScript，人和 agent 都容易解析，而且你可以用编程的方式写配置。

类型化配置对 agent 的帮助极大。我们发现，即便没有任何关于这套编程式配置格式的先前上下文，agent 也能轻松按需识别并修改配置，哪怕面对的是 env 这类与 Wrangler 中同名特性相比已发生巨大变化的元素。所有使用 LSP 插件的 agent，比如 Claude Code 和 Codex，都能在上下文中解读出更多关于配置文件格式的信息，从而给出准确得多的建议。

相比之下，TOML 没有可访问的 schema，JSONC 虽然有链接的 schema，但 agent 很少用。

Cloudflare 内部的一些 Wrangler 配置文件已经从超过 5,000 行压缩了 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 ({
 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 运行的动作。

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 暴露给 agent 的 API——都将能通过类型安全的配置来表达。不久之后，你就能通过这个配置文件配置整套策略、创建 zone、配置 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 都能做。

无论你在构建什么——前端项目还是后端 API——我们都建议用 Cloudflare Vite Plugin 来构建 Workers。配合我们的 Vitest 插件，它提供了一套连贯的开发和测试环境，与 Workers 运行时保持一致，并让你直接访问 bindings 和平台 API。

cf 默认基于 Vite 构建。大多数 Workers 用 agents 就能顺利迁移，另一些则需要更多时间。因此，对于仍需继续使用 esbuild 的 JavaScript Workers，以及 Rust 和 Python Workers，cf 会继续把 dev 和部署委托给 Wrangler。

从 Wrangler 迁移

把一个 Worker 从 Wrangler 迁移过来，只需运行

cf migrate

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

开放 beta 结束后，我们会发布 Wrangler 的最后一个大版本，引导你和你的 agent 改用 cf。beta 结束后的 18 个月内，我们会继续为 Wrangler 提供维护支持，给你留出迁移时间。

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

静态站点依然无需配置文件即可上手，部署也只需在项目中运行 cf deploy。

若想用 cf 新建一个 Hello World 项目，运行 cf init 即可。

cf 是开源的，如有问题，欢迎到我们的 GitHub 仓库反馈。