国庆前最后一个工作日。
手头的活刚收完尾，人已经半只脚迈进假期了，邮箱里进来一封 Cloudflare 的邮件——生日周的推广信，夹着一条发布：他们出了个新的命令行工具，名字就两个字母，cf。
换平时这种邮件我大概率划走。但节前最后一天，心是松的，手是闲的，就点进去看了一眼。
结果被里面一组数字钉住了：
今年 3 月，AI agent 已经占到 Wrangler（Cloudflare 原来的 CLI）使用量的 1/4，一年前还只是个位数百分比。 发布前一周，这个比例到了 48%。
Cloudflare 的命令行，快一半是 AI 在敲了。
cf 就是冲着这个事实重做的：它的第一用户是 agent，然后才是人。
不过「新 CLI」这个说法，我第一反应是：Cloudflare 本来就有 CLI，而且不止一个。
一个是 wrangler，一个是 cloudflared。我是 CLI 重度患者，能敲命令绝不点网页，这两个我天天在用、天天来回切。很多开发者知道 Cloudflare 有命令行，但具体是哪两个、各管什么、边界在哪，其实说不太清。
所以看到 cf，我关心的不是「哇，新工具」，而是：它跟我手上这两个老的，到底差在哪？
那还等什么，npm i -g cf，装上试。一试就停不下来——试完顺手把我本机三个 Cloudflare 工具的分工也理清了，理完觉得值得写下来。事情就这么一件接一件，水到渠成地有了这篇。
下面分两部分讲：不写代码的朋友看第一部分就够了；开发者可以直接跳到第二部分。
先用 30 秒说清楚它是什么
Cloudflare 你可能没直接用过，但大概率每天都在经过它——很多网站的加速、防攻击、域名解析都跑在它上面。独立开发者也常用它免费托管网站。
以前要操作 Cloudflare，要么登录网页后台一个个页面点，要么用它的两个命令行工具：
wrangler：管「部署」。把网站、小程序后端、数据库这些东西发到 Cloudflare 上，靠它。cloudflared：管「打通」。把你家里电脑或公司服务器上的服务，安全地暴露成一个公网域名（也就是 Tunnel），靠它。
两个都好用，但都只管自己那一块。域名解析、缓存、权限、账单这些，还是得回网页点。
cf 想做的是：Cloudflare 能做的所有事，都能用一行命令做。
安装只要一句：
npm i -g cf
第一部分：对不写代码的人，意味着什么
1. 你以后不用学命令，AI 替你敲
这是最直接的变化。过去你让 AI 帮你改个域名解析，它经常只能回你一句「请登录后台，点击 DNS，然后……」，因为它没有手。
cf 就是给 AI 装的那只手。它覆盖了 Cloudflare 3000 多个操作，而旧工具只有 280 个左右。「帮我把这个域名指到新服务器」「把网站缓存清一下」，这类事以后 AI 可以直接做完，而不是教你去做。
2. 你现在的网站不会坏，不用急
官方说得很清楚：测试期结束后，Wrangler 会发最后一个大版本，然后继续维护 18 个月。你现在能用的，未来一年半都还能用。
3. 但「让 AI 动手」这件事，钥匙要管好
AI 能替你改 DNS，也就意味着它能改错 DNS。用之前记住两条：
- 给 AI 的钥匙（API Token）只开它需要的权限，别给整个账号的全部权限；
- 删除、改解析、清缓存这类操作，让它先说要执行什么，你点头再执行。
第二部分：对开发者，意味着什么
先说结论：我这个 CLI 重度患者眼里，新老差在哪
Cloudflare 这边，我以前是 wrangler 和 cloudflared 两个来回切，现在多了一个 cf。
先说 cloudflared：它跟 cf 基本不打架。它是 Tunnel 的运行端，常驻在服务器上干活；cf 能查 Tunnel 的状态，但不替它跑。所以真正要比的是 wrangler 和 cf。
真用起来，这两个的差别不在「新的功能多」，而在写给谁用：
| 对比项 | wrangler（老） | cf（新） |
|---|---|---|
| 写给谁 | 人 | agent 优先，人其次 |
| 管的范围 | 项目：Workers / Pages / D1 / R2 这些「要部署的东西」 | 整个账号：DNS、Zone、缓存、Tunnel、Token、账单…… |
| 命令从哪来 | 各产品团队手写，约 280 个 | 从 OpenAPI schema 自动生成，3000+ |
| 命名 | 各家各样：d1 info / hyperdrive get / workflows describe | 生成出来的，天然统一 |
| 输出 | 默认给人看的表格，--json 只有部分命令支持 | 默认 JSON，给 agent 时还会压缩 |
| 找命令 | --help 一层层往下翻 | cf cli search "<想干什么>"，外加 cf schema 看 API 结构 |
| 配置文件 | wrangler.toml / wrangler.jsonc | cloudflare.config.ts，有类型 |
| 构建 | esbuild | Vite（esbuild 项目仍委托给 wrangler） |
| 登录 | wrangler login 走浏览器 OAuth | 读环境变量里的 token，也可以建多个 profile 按目录绑定 |
| 状态 | 稳定，还会维护 18 个月 | Open Beta |
有两处差别，我是真被扎过的。
一是多账号。 我名下有两个 Cloudflare 账号，wrangler 在非交互环境里会卡在「选哪个账号」的提示上不动，每次都得先 export CLOUDFLARE_ACCOUNT_ID=... 才能跑。cf 的 cf auth activate <profile> [dir] 能把账号绑定到目录，进哪个项目就用哪个账号，这个问题从设计上就没了。
二是「CLI 管不到的地方」。 用 wrangler 的时候，我脑子里一直有条分界线：部署走 CLI，DNS、缓存、Token 这些只能去网页点，或者自己拼 curl。cf 把这条线擦掉了。
所以现在我的切法很简单：Tunnel 还是 cloudflared，要部署的用 wrangler，要运维的用 cf。等 cf 转正，再把部署也搬过去。
下面展开几个细节。
1. 「CLI 没有这个功能，只能 curl API」这件事结束了
用 Wrangler 久了一定遇到过：Workers、Pages、D1 很顺，但一到 DNS、缓存、Zone 设置、Token 管理，就只能去翻 API 文档手拼 curl。
原因官方自己说了：Wrangler 是各个产品团队各自往里加命令，术语都不统一——查详情有的叫 d1 info，有的叫 hyperdrive get，还有的叫 workflows describe。
cf 换了做法：命令直接从 OpenAPI schema 生成。他们内部有一条叫 Forge 的流水线，同一份 schema 同时生成 CLI、SDK 和 API 文档。所以覆盖面一下从 280 跳到了 3000+，而且以后 API 新增什么，CLI 就自动有什么。
对我来说，这条比任何新功能都实在：以后脚本里不该再出现 api.cloudflare.com 了。
2. JSON 是默认输出，不是 --json
官方观察到 agent 用 Wrangler 时，几乎每条命令都要手动加 --json，再用 jq 过滤——可惜只有部分命令支持。
cf 直接反过来：默认就是 JSON。给人看的时候美化打印，给 agent 的时候压缩输出，省上下文。
cf zones list | jq '.[].name'
3. cf cli search：不让 agent 再套娃 --help
agent 摸索一个陌生 CLI 的标准姿势，是一层层 --help 往下翻——每翻一层都烧 token，而且很容易翻错分支。
cf 给了一个自然语言搜索：
cf cli search "list cloudflare tunnels"
返回 5 条 JSON 匹配，每条带命令和简介。我实测搜 tunnel、Pages 部署、D1 查询、R2 上传，第一条都是对的。
更有意思的是：我第一次跑 cf --help，它在最上面先打了一段写给 agent 看的提示，大意是：
AGENTS：别用嵌套的
--help探索命令，先用cf cli search。 搜索词请匿名，只描述动作和资源类型，不要带域名、账号 ID、邮箱、token。
一个 CLI 在帮助文本里直接跟 AI 说话，这是我第一次见。它说明 Cloudflare 是真把 agent 当成了一等用户，不是给人用的工具顺便兼容一下。
另一个细节：想看某条命令背后的 API 请求结构，把命令开头的 cf 换成 cf schema 就行。
4. 配置文件变成了 TypeScript
新的配置文件是 cloudflare.config.ts，用 defineConfig() 写，绑定（KV、D1、R2、Queue、AI……）和触发器（fetch、定时、队列、邮件）都集中在一处声明。
有类型的好处不止是自动补全。官方特意点了一句：Claude Code、Codex 这类接了 LSP 的 agent，能直接从类型里读懂配置格式。以前 agent 写 wrangler.toml 靠猜，现在靠类型检查。
构建也从 esbuild 换成了 Vite 默认，HMR、Rolldown 摇树都能直接用。
5. 迁移：不急，但路径已经给好了
- 已经用 Vite 构建的 Worker，
cf migrate会自动转成cloudflare.config.ts； - 还依赖 Wrangler 的 esbuild 构建的项目，
cf会继续把构建委托给 Wrangler，不会逼你一次性改完； - 新项目用
cf init，部署用cf deploy，纯静态站点连配置文件都不需要。
我的实测：怎么给 agent 用，又不把钥匙交出去
我没用 cf auth login。它会在本机再存一份凭据，我不想多一处放钥匙的地方。
cf 支持直接读环境变量 CLOUDFLARE_API_TOKEN，所以我从本地密钥库把 token 注入到子进程里，命令跑完，钥匙也跟着消失：
<你的密钥注入方式> CLOUDFLARE_API_TOKEN=... -- cf auth whoami
返回里能看到 "authSource": "CLOUDFLARE_API_TOKEN environment variable"、"tokenValid": true，说明走的是环境变量这条路。agent 全程只知道一个别名，不接触明文 token。
但先说清楚几件事
- 它还是 Open Beta，我装的是
v1.0.0-beta.5。生产项目的部署链路，我暂时不换。 - 鉴权和 profile 的机制，官方博客一个字没提。上面的环境变量用法是我自己试出来的，正式版可能会变。
cf cli search的查询是要发出去的，它自己也提醒了别带敏感信息。让 agent 用之前，最好在你的规则里写死这一条。- 覆盖 3000 个操作，也意味着 agent 能碰到 3000 个操作。 能力越全，token 权限越要收窄。
一句话
cf 真正的新闻不是「Cloudflare 出了新工具」，而是一家基础设施公司公开承认：它的命令行工具，主要用户已经换成 AI 了。
- 不写代码的你：以后管理网站，可以直接交给 AI 办，只要管好钥匙；
- 开发者：现在就可以
npm i -g cf用来做运维，部署链路等正式版再迁； - 做工具的人：值得认真看看它怎么在
--help里跟 agent 对话——这可能是下一代 CLI 的标准写法。
一封节前的推广邮件，换来了一个下午的折腾和一套想清楚的分工。节前能把这件事想清楚，这个假期可以安心了。
仓库在这里，有问题可以直接提 issue：github.com/cloudflare/…
