https://blog.cloudflare.com/cloudflare-cf-cli-launch/ 解读一下

群友 7409，这篇不是说“Cloudflare 以前没有 CLI”，而是推出了新的 cf：从原来的 Wrangler，走向覆盖整个 Cloudflare API、优先供 Agent 使用的统一操作入口。不只是换个名字。 为什么要重做？ 文章给了一个背景：上周，Agent 已占 Wrangler 使用量的 48%。但 Wrangler 很多设计仍然面向人，比如终端表格、不同产品不一致的命令命名。 Cloudflare 的判断是：既然越来越多操作由 Agent 完成，就不该只让 Agent 勉强适应旧工具，而应该直接按它的使用方式设计。 最重要的变化，是覆盖范围和生成方式 Wrangler 大约覆盖 280 项操作，新 cf 覆盖超过 3000 项，延伸到整个 Cloudflare API。 以前，各产品团队手写命令，容易出现同类操作分别叫 info、get、describe 的情况。现在通过 Forge 管线，从同一套 OpenAPI 描述生成 CLI 命令，与 API 文档、SDK 共用源头。 所以价值不只是“命令更多”，而是减少人工维护带来的不一致，让 Agent 能用一个入口串起更多产品的操作。 3000 个操作，怎么不把 Agent 的上下文塞爆？ 它提供了 cf cli search，让 Agent 用自然语言寻找需要的命令。首次查看帮助时，也会被引导使用这个搜索入口。 这相当于不把整本操作手册提前塞给 Agent，而是让它先查目录，再了解当前任务需要的操作。 输出也默认采用 JSON，而不是面向人的终端表格。Agent 可以用 jq 等工具筛出需要的字段，再继续处理，减少无关输出进入上下文。 这里的关键是：不仅要让工具“可调用”，还要让 Agent 容易找到、容易读懂。 配置也变成了 Agent 更容易修改的代码 新的 cloudflare.config.ts 使用 TypeScript。 实际价值有两层：一是配合语言服务获得类型提示、补全和部分错误反馈；二是能通过代码复用配置，不必为每个环境复制一大段内容。 文章提到，Cloudflare 内部某些超过 5000 行的 Wrangler 配置，通过这种方式缩减了 40%。这是具体案例，不代表所有项目都有同样收益。 注意一个重要边界：整个 API 可通过 cf 操作，不等于所有产品都已经支持这套 TypeScript 配置。目前配置从 Workers 起步，DNS、完整策略等更多产品的声明式配置仍属于后续计划。 开发体验也一起调整了 cf 默认采用 Vite，复用它的开发服务器、热更新和插件生态，而不是继续把所有能力都放在 Cloudflare 自己的专用工具里。 但不是立即切断旧项目：仍依赖 esbuild 的 JavaScript Workers，以及 Rust、Python Workers，开发和部署仍会委托给 Wrangler。 目前是公开测试版。文章说的是测试结束后，Wrangler 再继续维护 18 个月，不是现在就停止支持。 我的理解 它真正想解决的是：Agent 已经能写业务代码，但把代码变成一个完整、可运行的线上服务，还需要跨很多云产品操作。 比如在已授权范围内，Agent 不只部署一个 Worker，还可以继续配置访问保护、WAF，并查看运行状态。cf 把这些步骤放进同一个可搜索、结构化的操作入口。 所以这篇最值得关注的，不是“又出了一个 CLI”，而是基础设施厂商开始把 Agent 当作工具的主要使用者，围绕它重新设计发现、调用、输出和配置的全过程。