Cloudflare 发布 cf：为 AI 代理重写命令行，Wrangler 开始退场

如果你让一个 AI 代理去部署 Cloudflare Worker，它大概率会先“回忆”Wrangler 的命令：wrangler deploy、wrangler dev、wrangler kv key put……这些命令在训练数据里出现了太多次，模型记得很牢，但 Cloudflare 自己却越来越难改。10 月 19 日，Cloudflare 推出全新的开源命令行工具 cf 公测版，并明确表示 Wrangler 将逐步停用。

一分钟速览

• cf 是以 AI 代理为中心重新设计的 CLI，使用 TypeScript 编写；
• 提供结构化 JSON 输出与命令发现能力，方便代理解析和调用；
• 以 OpenAPI schema 为源，覆盖 3000 多个 API 操作，而 Wrangler 内置约 280 个；
• 采用 cloudflare.config.ts 配置格式，默认集成 Vite；
• 以 Apache 2.0 或 MIT 许可开源，Wrangler 进入退场流程。

为什么要另起炉灶

Cloudflare 的解释很直接：Wrangler 是各个产品团队手工拼起来的，每个团队按自己的习惯设计命令。大约 280 条命令路径里，d1 info、hyperdrive get、workflows describe 各有一套命名逻辑，想在不破坏兼容性的前提下统一，几乎不可能。

更麻烦的是“模型记忆”。Wrangler 的用法已经写进大量文档、博客和代码仓库，LLM 学到的是一套固定的行为模式。如果直接在 Wrangler 上做以代理为中心的重构，模型会不断把旧习惯带回来，形成冲突。新工具从零开始，反而可以摆脱历史包袱。

cf 的设计重点有三处。其一是结构化输出：命令返回可解析的 JSON，人类能读，代理也能直接消费。其二是命令发现：代理可以先查询“有哪些命令、参数是什么”，再决定调用哪一条，而不必把整本手册塞进上下文。其三是统一配置：cloudflare.config.ts 用 TypeScript 描述项目，类型提示和校验都更自然。

CLI 正在变成代理的“操作系统接口”

过去，CLI 是给人用的：命令要短、帮助要清楚、输出要好看。现在，CLI 的第一用户可能是代理。代理不关心颜色和排版，它关心的是输出是否稳定、错误码是否明确、能否一次拿到足够的信息。谁能把接口做成“机器可读”，谁就更容易被代理选中。

这也是 MCP、OpenAPI、CLI 三种路线同时在竞争的原因。MCP 适合把工具直接暴露给模型，OpenAPI 适合描述 HTTP 能力，CLI 则更贴近开发者的真实工作流：本地有文件、有 Git、有构建工具，代理只要会敲命令，就能完成大部分操作。cf 把三者串了起来：OpenAPI 做底座，CLI 做入口，JSON 做交换格式。

对开发者来说，短期内的迁移成本不可避免。Wrangler 的配置、插件、CI 脚本都要改；对习惯 wrangler.toml 的团队，cloudflare.config.ts 也需要重新适应。但长期看，统一的命令语义和更强的可发现性，能减少“每个产品一套玩法”的摩擦。

写在最后

Cloudflare 不是第一家为代理重做工具链的公司，但它把问题说得很透：当代理成为主要调用者，工具的兼容性包袱会变成创新阻力。cf 能否成功，取决于两件事：3000 多个 API 操作是否真的都能稳定调用，以及社区是否愿意为它重写插件。Wrangler 的退场不会一夜完成，但方向已经很清楚。