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

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

智能体是更高产的用户，每天使用的不同命令数量几乎是人类的两倍，使用六条或更多命令的可能性也几乎是人类的四倍。

智能体钟爱 CLI。但 Wrangler 只为大约 280 种操作提供了命令，而 Cloudflare 提供数千种。

今年早些时候，我们预告了我们计划如何解决这个问题而今天，我们通过推出新的 CLI：cf，让智能体能够使用 Cloudflare 的每一款产品。

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

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

今天即可在全球范围内安装公开测试版，并在任何地方运行它：

npmi-gcf

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

如果你的智能体能够做到 Cloudflare 能做的一切会怎样？这正是今年早些时候激起我们兴趣的问题：智能体正变得越来越强大，但它们用 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 个函数，扩展到覆盖 Cloudflare API 全部超过 3,000 个操作。

现在，给你的智能体配上它变得很简单cf然后让它去搭建一个 worker、部署它、监控和观测它、用 Cloudflare Access 保护它、购买一个域名，并用 Cloudflare WAF 为它做前置防护，全部通过一个工具完成。

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

cf 是为软件工程的发展轨迹而构建的，在这一轨迹中，智能体式开发正在彻底改变软件的构建和部署方式。今年我们一直专注于提供支持这一转变的工具，最终成果就是 cf。cf 从底层开始就以智能体为核心进行设计，并包含用于智能体命令发现的新颖工具，我们认为这些工具在不久的将来会成为更多 CLI 的标准配置。

Wrangler 的优势在于，多年的文档、博客和第三方指南都已被吸收进 LLM 的训练过程中。它也有同样的劣势：改变 Wrangler 的工作方式现在与已习得的行为相冲突，而鉴于我们想要实现的改进规模，重大变化将不可避免。

推出一个智能体从未见过的新 CLI 听起来像是一次巨大的颠覆性变化 —— 但实际上这是我们能做的最干净利落的事情。由于我们所做的设计决策、我们能进行的上下文注入，以及我们能追加的 AGENTS.md 文件，以这种方式进行切换实际上比让智能体去理解它熟悉的某个工具两个版本之间的重大差异更不容易造成困惑。我们发布时已内置了几个这类以智能体为核心的功能，未来还会有更多。

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

当智能体使用 Wrangler 时，它们会在运行的每条命令后附加--json，然后通常用以下方式过滤输出jq以提取字段子集。但 Wrangler 中只有部分命令支持--json；许多命令返回的是 unicode 表格，专为在终端中查看输出的人类设计。智能体可以弄明白这些，但相比jq过滤器，这会消耗它们更多的时间和 token。

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

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

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

对于那些你的智能体可以通过一长串笨拙的命名参数链式访问的命令，你只需填写一个表单。Cf 将 API 的需求解构为一系列经过验证的输入，因此购买域名，即使是需求复杂的域名，也很容易操作。

或者，如果你坚持的话，直接让你的智能体去做。

你的智能体可以自己找到正确的命令

一个 CLI 中有 3,000 条可能的路径，你的智能体如何在不膨胀上下文的情况下快速找到它需要的正确操作？为此我们还添加了cf cli search。

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

为你的智能体做类型检查的配置

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

类型化配置对智能体帮助极大。我们发现，即使没有程序化配置格式的先验上下文，智能体也能轻松按需识别并编辑配置，甚至跨越诸如env这类元素——它们与 Wrangler 中同名特性相比已发生巨大变化。所有使用 LSP 插件的智能体，例如 Claude Code 和 Codex，都能受益于在上下文中解读更多关于配置文件格式的信息，从而给出准确得多的建议。

相比之下，TOML 没有可访问的 schema，而 JSONC 虽有链接的 schema，但智能体很少使用。

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

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

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

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

export defaultdefineConfig(({ mode })=>({
worker:{
name:"example-worker",
entrypoint,
compatibilityDate:"2026-09-27",
env:{
Environment:bindings。text(`Thisis${mode} environment`),
},
},
}));

你可以通过以下方式将你的 Cloudflare Worker 迁移到这个新格式cf migrate。

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

bindings为你的智能体提供了一个简单的地方，去发现开发者平台所提供的一切。从环境变量到存储、数据库和队列——一切都能由你的编辑器自动补全并解释。

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

exportdefaultdefineConfig(({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 运行的操作。

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

export defaultdefineConfig({
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 对你的智能体可用——都将能够通过类型安全的配置来表达。很快你就能通过这个配置文件配置完整的策略、设置区域、配置 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 插件，它提供了一个连贯的开发和测试环境，与 Workers 运行时保持一致，并让你直接访问绑定和平台 API。

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

从 Wrangler 迁移

从 Wrangler 迁移一个 Worker 只需运行

cfmigrate

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

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

你也可以创建新项目并自动为 Cloudflare 配置它们，只需运行cf init/deploy，它会为你安装 Cloudflare Vite Plugin 并创建一个配置文件。

静态站点仍然不需要配置文件即可开始，部署它们只需在你的项目中运行cf deploy。

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

cf 是开源的，问题可以报告到我们的 GitHub 仓库。