Cf：面向 Cloudflare API 的 Agentic CLI

过去一年中，Agent 对 Wrangler 的使用量激增。

2026 年 3 月，Agent 已占 Wrangler 使用量的四分之一，而在此前一年中这一比例仍处于个位数。上周，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 项功能，扩展为覆盖 Cloudflare API 全部能力面的 3,000 多项操作。

现在，只需给你的 Agent 配置 cf，就可以让它设置 Worker、部署 Worker、监控和观测 Worker、使用 Cloudflare Access 保护 Worker、购买域名，并在其前方部署 Cloudflare WAF——所有操作均通过一个工具完成。

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

cf 是为软件工程的发展方向而构建的：Agentic 开发正在彻底改变软件的构建和部署方式。今年，我们一直专注于提供支持这一转变的工具，而 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 是这一工具未来的主要用户，那么 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 < { 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 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——都将能够通过类型安全的配置来表达。不久后，你将能够通过这个配置文件配置完整策略、设置 zone、配置 DNS 等。

一流的开发体验

当 Wrangler 最初开始构建 JavaScript Workers 时，Vite 尚不存在。因此，我们在 Wrangler 中使用 esbuild 打包 Workers。Wrangler 在 :8787 提供的开发服务器由 Wrangler 团队自行构建，修改其中任何部分都意味着必须深入 Cloudflare 专用本地工具（如 Miniflare）的内部实现。

Vite 在这方面有巨大改进：它拥有庞大的可用插件生态系统，提供具备 HMR（热模块替换）的一流开发服务器，并使用基于 Rust 的 Rolldown 库进行 tree-shaking 构建。你能用 Vite 完成的任何事情，都可以使用 Cloudflare Vite Plugin 完成。

无论你构建的是前端项目还是后端 API，Cloudflare Vite Plugin 都是我们推荐的 Workers 构建方式。它与我们的 Vitest 插件共同提供统一的开发和测试环境，能够匹配 Workers 运行时，并让你直接访问 bindings 和平台 API。

cf 默认基于 Vite 构建。大多数 Workers 都可以借助 Agent 简单迁移。另一些可能需要更长时间，因此对于仍需使用 esbuild 的 JavaScript Workers，以及 Rust 和 Python Workers，cf 将继续委托 Wrangler 进行开发和部署。

从 Wrangler 迁移

从 Wrangler 迁移 Worker，只需运行相应命令即可。

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

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

你还可以通过运行 cf init/deploy 创建新项目并自动将其配置为使用 Cloudflare；该命令会为你安装 Cloudflare Vite Plugin 并创建配置文件。

静态站点在开始时仍不需要配置文件，在项目中运行 cf deploy 即可完成部署。

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

cf 是开源项目，问题可提交至我们的 GitHub 仓库。

Over the last year, agent use of Wrangler has skyrocketed.

In March 2026, agents were responsible for a quarter of Wrangler use, up from single-digit percentages the year prior. Last week, agent usage reached 48%.

Agents are more prolific users, using almost twice as many distinct commands per day, and are almost four times as likely to use six or more commands.

Agents love CLIs. But Wrangler only provides commands for around 280 operations, and Cloudflare offers thousands.

Earlier in the year we teased how we were planning to solve this and today, we’re enabling agents to use every Cloudflare product by introducing a new CLI: cf.

cf is a CLI that is built for the next generation of software development:

• Agents can find the command they need to do anything they want to do with bespoke search and steering.
• JSON is the default interface, pretty printed for humans and condensed for agents for maximum context savings.
• cloudflare.config.ts is the new configuration format for the whole of Cloudflare, starting with Workers, and bringing the safety and accuracy of TypeScript to you and your agent’s language server protocol (LSP)
• Vite becomes default, bringing with it the best local development server, and a plugin suite for developers and framework authors.

Install the open beta today globally and run it from anywhere:

Copy promptCopy promptPrompt copied!

cf gives your agent access to the entire Cloudflare API

What if your agent could do everything Cloudflare can do? That’s the question that sparked our interest earlier this year: agents were getting ever more powerful, but what they were able to do with Cloudflare’s CLI was still limited.

Wrangler was hand-built with each product team contributing and taking their own approach to their command developer experience. Enforcing patterns across teams was virtually impossible, even across our ~280 command paths. We had inconsistent terminology across d1 info, hyperdrive get, workflows describeÂ as each team came up with their own practices at different times. Some teams built entirely custom experiences across thousands of lines of code that turned out to be used extremely rarely, and teams came up with different approaches to solve the same problems.

We wanted to both standardize what we had and make a massive expansion, all at once. Forge — Cloudflare’s new unified API generation pipeline — enabled us to do this, building on the idea of generating our CLI commands directly from the API schema that powers our API documentation and SDK generation. Everything we provide has an OpenAPI schema, and if we annotate this with just a little more information, we can use it as the source for Forge to make a CLI.

This enables us to expand cfÂ from the ~280 functions that Wrangler had built up over time, to cover the entirety of the Cloudflare API surface of over 3,000 operations.

Now it’s simple to give your agent cf and ask it to go set up a worker, deploy it, monitor and observe it, protect it with Cloudflare Access, buy a domain, and front it with Cloudflare WAF, all from a single tool.

Building for an agent that has never used cf

cf is built for the trajectory of software engineering, where agentic development is drastically changing how software is built and deployed. This year we’ve been focused on providing tools to support this shift, culminating in cf. cf has been built from the ground up with agents in mind, and includes novel tools for agentic command discovery that we think will become standard in more CLIs in the near future.

Wrangler came with the advantage that years of documentation, blogs, and third-party guides have been absorbed into the training process of LLMs. It also came with the same disadvantage: changing how Wrangler works now goes against learned behavior, and significant change would be inevitable given the scale of improvement we want to make.

Introducing a new CLI that agents have never seen sounds like a big disruptive change — but actually it’s the cleanest thing we can do. Because of the design decisions we have made, the context injections we can make, and the AGENTS.md files we can append, making a switch in this way is actually less confusing than having an agent contextualize the major differences between two versions of a tool it is familiar with. We’re launching with a couple of these agent-focused features built in, with more to come.

Agents need to filter JSON, not look at tables

When agents use Wrangler, they append --jsonÂ to every command they run, and then often filter the output with jqÂ to extract a subset of fields. But only some commands in Wrangler supported --jsonÂ ;Â many commands returned unicode tables, designed for humans looking at output in their terminal. Agents can figure these out, but it costs them more time and tokens than a jqÂ filter.

In cf we’re taking the opposite stance: agents just need JSON, and if agents are the future primary user of this tool, it should be the default. For the vast majority of commands that will rarely be accessed by humans, this is obviously the right call.

You as the human customer of this CLI are, in reality, one step removed from using it. Agents being able to easily filter their results and then return that filtered list in whatever format you request is preferable to supplying tables you will never likely read directly.

But what if you’re looking to do something that might require real personal input, like searching for a domain to buy?

For commands that your agent can access through chaining named parameters in a long and unwieldy sequence, you can simply fill in a form. Cf deconstructs the requirements of the API into a series of validated inputs, so buying a domain, even one with complex requirements, is simple to follow.

Or, if you insist, just ask your agent to do it.

Your agent can find the right command itself

With 3,000 possible routes through a CLI, how can your agent find the right operation it needs quickly without bloating your context? For this reason we have also added cf cli search.

This command allows your agent to ask in natural language what it needs to do, and a small search index will provide a list of appropriate commands, based on their API description and parameters. We automatically tell your agent about this command when it runs --helpÂ for the first time.

Configuration that type-checks your agent

Our new configuration format is based on TypeScript, which is easy for humans and agents to parse, and allows you to write your configuration programmatically.

Typed configuration is enormously helpful for agents. We’ve found that even with no prior context of the programmatic configuration format, agents are able to easily identify and edit the configuration on demand, even across elements like env which have dramatically changed from the same named feature in Wrangler. All agents that use LSP plugins, such as Claude Code and Codex, benefit from being able to interpret more about the configuration file format in context, and make much more accurate suggestions as a result.

Compare this to TOML, which had no accessible schema, or JSONC, which had a linked schema that agents rarely used.

Some Wrangler configuration files inside Cloudflare have been condensed by 40% from over 5,000 lines, with many custom environments per developer, to factory files that build each developer’s configuration more efficiently.

This is achieved through programmatically defining each environment from the same universal base, instead of copying envÂ blocks as was typical in Wrangler. A simple Worker with multiple environments simply switches on the Vite-native modeÂ argument to swap between one set of configuration and another.

A simple configuration that does this now looks like:

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

You can migrate your Cloudflare Worker to this new format through cf migrate.

We’re also providing a few helper functions to make building your Worker a breeze.

bindings gives you a simple place for your agent to discover all the developer platform has to offer. Everything — from environment variables to storage, database, and queues — can be auto-completed and explained by your editor.

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

Similarly, we have included a helper for triggers, which is the new way to define routes, queues, schedules, and email triggers for your Worker. Rather than having these scattered through your configuration file, it’s now simple to find, in a single block, the actions that could trigger your Worker to run.

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 is just the start here. Our intention with cloudflare.config.ts is that this is how you manage Cloudflare as a whole. Every product you need — along with its API being available to your agent through cf — will be able to be expressed through typesafe configuration. Soon you will be able to configure entire policies, set up zones, configure DNS and more, all through this configuration file.

A best in class development experience

When Wrangler first started building JavaScript Workers, Vite didn’t exist. Instead, we used esbuild in Wrangler to bundle your Workers. The dev server that Wrangler made available on :8787 was something that the Wrangler team built, and modifying any of this meant reaching into the internals of Cloudflare-specific local tooling like Miniflare.

Vite is a huge improvement on this, and comes with a large ecosystem of plugins you can use, as well as providing a best in class dev server with HMR (hot module replacement), and builds that use the Rust-based library Rolldown for tree-shaking. Anything you can do with Vite, you can do with the Cloudflare Vite Plugin.

The Cloudflare Vite Plugin is the recommended way we suggest you build Workers, whatever you are building: whether that’s a frontend-focused project or a backend API. Together with our Vitest plugin it provides a cohesive development and testing environment that matches the Workers runtime and gives you direct access to bindings and platform APIs.

cf is built on Vite as default. Most of your Workers will migrate simply with agents. Others may take more time, which is why cf will continue to delegate to Wrangler for dev and deployment for JavaScript Workers that need to continue to use esbuild and Rust and Python Workers.

Migrating from Wrangler

Migrating a Worker from Wrangler is as simple as running

Workers that already build with Vite will be converted to cloudflare.config.ts for you. If your Worker relies on Wrangler for esbuild, then cf will continue to delegate builds to Wrangler.

When the open beta ends we will release a final major version of Wrangler that directs you and your agent to use cf. We’ll continue to provide maintenance support for Wrangler for 18 months after the beta ends, to give you time to migrate.

You can also take new projects and automatically configure them for Cloudflare by running cf init/deploy, which will install the Cloudflare Vite Plugin for you and create a configuration file.

Static sites still don’t require a configuration file to start, and deploying them is as simple as running cf deploy in your project.

To start a new Hello World project with cf, use cf init.

cf is open source and issues can be reported to our GitHub repository.