摘要：2026 年 9 月 28 日，Cloudflare 发布 cf，一个目标是「镜像整个 Cloudflare API」的命令行工具，覆盖超过 3000 个操作——官方对比称 Wrangler 累积下来的操作路径约为 280 个。它默认输出 JSON、支持用自然语言检索命令，并把 cloudflare.config.ts 定为 Cloudflare 的全局配置格式，先从 Workers 落地。cf 目前处于 open beta 且已开源，beta 结束后 Wrangler 会发布最后一个大版本把用户与 Agent 引向 cf，之后继续维护 18 个月。
Cloudflare 这次给出的自我定位不是「又一个 CLI」，而是一个数字对比：cf 覆盖超过 3000 个 API 操作，Wrangler 累积下来大约 280 个操作路径。差了十倍以上的覆盖范围，指向的是同一个问题——过去用 Wrangler 做不了的事，不是因为 Cloudflare 没有这个 API，而是因为命令行没有把它包进来。
第二个关键词写在标题里：agentic。官方给出的依据是，最近 Wrangler 的使用中 Agent 占比达到 48%，而且 Agent 每天运行的不同命令几乎是人类的两倍，用到六条以上命令的概率接近四倍。当一个工具的主要使用者变成 Agent，为人类手敲设计的交互方式就需要重新考虑——比如 --json 只在部分命令上支持，另一些命令返回的是 unicode 表格。
下面把 cf 想解决的几件事、它的配置格式，以及两条需要提前知道的边界分开讲。
AI Coding 交流群
如果你也在用 AI 写代码，或者正在研究 Cursor、Claude Code 这些工具，欢迎加入以下交流群。群里平时会聊一些 AI 编程的实际用法、开发工作流，还有各种新工具和新玩法。
发生了什么：把整个 API 收进一个命令行，默认给 JSON
cf 的第一个设计决定是默认输出 JSON：给人看的时候美化排版，给 Agent 用的时候压缩成紧凑格式。对照的是 Wrangler 的历史包袱——它的 --json 标志只覆盖部分命令，其余命令会返回 unicode 表格。对要解析输出的自动化流程来说，这种不一致意味着每个命令都要单独处理。
第二个决定是让 Agent 自己找命令。cf cli search 允许用自然语言描述需求，背后是一个小型检索索引，基于 API 的描述与参数返回匹配的命令；Agent 第一次运行 --help 时会被主动告知这个能力。这解决的是 3000 多个操作带来的发现成本——操作多了以后，「怎么找到对的那条命令」本身就成了门槛。
第三个决定是交互形式：cf 把 API 的要求拆成一系列经过校验的输入步骤，官方举的例子是购买域名这类多步操作。这一步是对人友好的，同时也给了 Agent 一条可跟随的路径。
第四个决定影响最大——cloudflare.config.ts 被定为 Cloudflare 的全局配置格式，先从 Workers 开始。官方给出的理由是类型化配置能帮 Agent 在没有上下文时把配置改对，尤其是 env 这一项，它相对 Wrangler 里同名功能的语义变化很大。官方还提到，用 LSP 插件的 Agent（举的例子包括 Claude Code 与 Codex）能在上下文里解释这套 schema；而 TOML 没有可被访问的 schema，JSONC 的关联 schema 则很少被 Agent 用上。
一个具体场景：五千行配置是怎么被压掉的
官方在公告里给了一个可核验的数字：部分内部 Wrangler 配置被精简了 40%，起点是超过 5000 行。做法不是删功能，而是换结构——每个环境从共享的 base 构建，而不是把 env 块复制一份再改。
这类问题在真实团队里很常见。假设一个有五个环境的 Workers 项目：dev、staging、两个客户的独立环境、prod。每个环境都需要同一组绑定，但取值不同。Wrangler 的写法容易演变成五段几乎相同的配置，改一个绑定要同步改五处，漏一处就是线上问题。
新配置格式提供了两个辅助函数：bindings 覆盖环境变量、KV、D1、R2、队列、AI、Vectorize 与 Workers，triggers 覆盖 fetch、scheduled、queue 与 email。官方说明这套格式的最终意图是管理整个 Cloudflare，包括策略、zone 和 DNS，而不只是 Workers。这意味着今天按新格式整理的项目，是在为后面的统一管理铺路。
为什么这会改变工作流
第一，命令行工具的验收标准变了。判断一个 CLI 好不好用，过去看的是命令是否齐全、帮助文档是否清楚；当 Agent 成为主要调用方之后，多出来两条：输出是否稳定可解析，以及命令是否可被发现。cf 的 JSON 默认值和 search 索引，正是针对这两条设计的。
第二，配置格式的选择变成了 Agent 协作能力的一部分。公告里那段关于 schema 可访问性的说明很值得记住：TOML 没有可访问的 schema，JSONC 的关联 schema 很少被 Agent 使用，而 TypeScript 配置可以被 LSP 直接解释。这不是风格偏好，而是决定 Agent 能不能在没有人工说明的情况下改对配置。
第三，Forge 这条线把生成链路统一了。Forge 是 Cloudflare 新的统一 API 生成管线，正在开源；它直接从 API schema 生成 CLI 命令，而同一套 schema 也驱动 API 文档与 SDK 生成。公告写明，所有东西都有 OpenAPI schema，加上一点额外注解，schema 就能成为 Forge 生成 CLI 的来源。对 API 提供方来说，这提供了一条思路：如果 CLI 是从 schema 生成的，那么保持 schema 与实现同步就成了一件有直接回报的事。
限制、边界与人应该在哪儿接手
cf 目前处于 open beta，且已经开源，issue 走 Cloudflare 的 GitHub 仓库。beta 状态意味着接口还可能调整，把关键流水线迁过去之前需要评估这一点。
关于 Wrangler 的去向，公告给出的是一条有明确时间表的路径：beta 结束后，Wrangler 会发布最后一个大版本，把用户和 Agent 引向 cf；之后 Wrangler 继续获得维护支持 18 个月。这条信息对已经重度依赖 Wrangler 的团队很重要——迁移不是立刻要做的，但有截止窗口。
第三处边界在能力覆盖上：cf 会把 JavaScript Workers 中仍使用 esbuild 的项目，以及 Rust 和 Python Workers 的开发与部署转交给 Wrangler 处理。也就是说，cf 是统一入口，不是全部重写。静态站点仍然不需要配置文件就能起步。
人的接管点有两个：一是决定何时把生产流水线从 Wrangler 迁到 cf，考虑到 beta 状态，稳妥的做法是新项目先用 cf、存量项目排期；二是决定是否现在就按 cloudflare.config.ts 重组配置，因为这一步的收益是结构性的，成本集中在一次性的整理上。
如何试用
安装：npm i -g cf。
迁移已有项目：cf migrate 可以把基于 Vite 的 Workers 转换到新的配置格式。
新项目：cf init 与 cf init/deploy、cf deploy 分别处理初始化、初始化并部署，以及部署；静态项目不需要配置文件。
想让 Agent 自己找命令：直接用它熟悉的自然语言调用 cf cli search，或在首次运行 --help 时留意它给出的提示。
信息来源
- Cloudflare Blog：Introducing cf: the agentic CLI for the entire Cloudflare API（2026-09-28）— https://blog.cloudflare.com/cloudflare-cf-cli-launch/
- Cloudflare Blog：Forge — a pluggable, open-source generation pipeline（2026-09-28）— https://blog.cloudflare.com/forge-open-source-generation-pipeline/
- Cloudflare Docs：Workers 配置文件与 cf 迁移说明
开发必备：API 全流程管理神器 Apifox
介绍完上文的内容，我想额外介绍一个对开发者同样重要的效率工具 —— Apifox。作为一个集 API 文档、调试、设计、测试、Mock、自动化测试于一体的工具，Apifox 是目前提升研发效率的首选。
如果你正在开发项目，不妨试试其极其友好的界面设计，它完全兼容 Postman 和 Swagger 数据格式，导入数据非常方便，，即使是新手也能很快上手，点击这里即可注册使用。
值得一提的是，除了个人和常规团队使用，针对有高安全合规要求、或需要在内网环境协作的企业，Apifox 还提供了深度定制的私有化部署方案。
获取专属报价与部署方案
详细的私有化部署系统架构与安全白皮书
针对您公司规模的专属报价单
免费的 1v1 专属产品演示 (Demo) 机会
