Cloudflare让AI接管云服务：Agentic CLI开始直接操作云平台

Cloudflare近期推出了面向开发者和AI Agent的统一命令行工具 cf，让智能体可以通过命令行直接调用Cloudflare平台上的云服务能力。这个工具在2026年4月的 Agents Week 期间公布，截至2026年9月28日，已经成为Cloudflare“Agent Cloud”战略中最值得关注的开发者入口之一。

Agentic CLI 是一种为AI Agent设计的命令行工具，它把云平台能力整理成可发现、可执行、可验证的命令，让Agent能够通过终端完成真实的基础设施操作。

Cloudflare给出的规模数字很直接：cf试图统一覆盖平台上接近 3000个API操作。这意味着Agent不再只是生成一段Worker代码、写一份Terraform配置，或者告诉开发者“请到控制台创建一个R2存储桶”，而是可以进一步执行创建、查询、修改、部署和排障动作。

这不是一次普通的CLI改版。它更接近于给云平台增加了一层“Agent原生控制面”。

Cloudflare发布的到底是什么

cf 是Cloudflare推出的统一命令行界面，用于以一致的方式访问Cloudflare不同产品和接近3000个API操作。

过去，Cloudflare的开发体验并不完全统一。开发者可能会在不同产品之间切换：用Wrangler部署Workers，用控制台管理DNS和域名，用另一套命令或脚本处理Pages、R2、KV、D1、Queues以及安全策略。对于熟悉平台的人，这些工具并非不能用；但对AI Agent来说，命令风格、参数结构、返回结果和文档组织方式的不一致，会显著增加任务规划和执行难度。

cf的目标，就是把这些能力收拢到一个更一致的入口中。开发者或Agent可以围绕同一套命令结构，完成从资源查询到变更执行的完整流程，而不是先判断“这个产品应该用哪个工具”。

从产品定位看，它同时服务两类用户：

• 开发者：在终端中用统一命令管理Cloudflare资源，减少在控制台和多套CLI之间来回切换。
• AI Agent：通过shell环境发现可用命令、读取结构化输出，并把命令执行结果作为下一步推理的上下文。

这两类用户其实正在快速融合。现在的编码Agent已经可以读取代码、运行测试、执行Git命令和启动本地服务。下一步自然是把能力边界从“代码仓库”推进到“云基础设施”。

它和传统CLI的差别，不只是多了AI两个字

传统CLI主要服务于已经知道命令和参数的人。Agentic CLI则需要解决另一个问题：Agent如何理解一个庞大、动态、容易造成破坏的云平台。

传统CLI的核心是让人高效执行已知操作，Agentic CLI的核心是让智能体能够发现、组合并验证未知操作。

一个人可以凭经验记住如何创建Worker、绑定KV命名空间，或者为DNS记录添加变更。Agent却需要通过命令帮助、参数描述、返回结果和错误信息建立自己的操作模型。如果每个产品都使用不同的命名规则，Agent就必须消耗更多上下文来猜测工具行为，错误率也会随之上升。

因此，面向Agent的CLI通常需要具备几个特征：

1. 命令结构一致：不同产品的资源管理动作尽量采用相近的组织方式。
2. 结果易于机器解析：输出不能只适合人类阅读，还要能够被Agent稳定识别和继续处理。
3. 能力可发现：Agent不必预先记住所有命令，而是可以通过帮助信息、命令树和文档逐步找到正确操作。
4. 执行过程可验证：创建或修改资源后，Agent能够再次查询状态，而不是把命令执行结束误认为任务完成。
5. 权限边界清晰：云资源操作必须受到账号、项目和具体资源权限的约束，不能因为自然语言表达就绕过安全控制。

Cloudflare没有把cf包装成一个只能通过自然语言使用的黑盒。相反，它仍然是命令行工具，只是命令设计和输出方式更适合被编码Agent、自动化脚本以及人类共同使用。这一点很重要：当Agent执行失败时，开发者可以在同一个终端里复现、修改和接管任务。

从“生成代码”到“执行云端动作”

过去一年，AI Agent在软件开发中的典型工作流是：读取需求，修改代码，运行测试，提交补丁。云平台通常停留在流程的最后一公里，开发者仍需要手动完成部署、域名配置、环境变量设置、日志检查和资源清理。

cf试图把这一公里也交给Agent。

例如，一个开发者可以给编码Agent下达类似这样的任务：

检查当前Worker的生产环境状态；如果发现最近部署失败，读取相关日志，定位问题；修复代码后重新部署，并确认路由和域名访问正常。

这类任务至少涉及代码仓库、构建流程、Workers部署、日志或状态查询，以及最终的线上验证。以前，Agent可能只能完成前两步；现在，它可以通过云端CLI继续向后推进。

再比如，一个内容应用需要上线新版本。Agent可以规划出这样的步骤：

读取项目配置
→ 检查Cloudflare资源状态
→ 创建或更新部署
→ 验证绑定的数据库和对象存储
→ 检查域名与路由
→ 返回部署结果和异常项

这里的关键不在于某一条命令，而在于云平台操作开始成为Agent工作流中的可组合动作。部署、DNS、存储、域名、日志和安全配置不再是相互割裂的后台功能，而可以被Agent放进同一个任务计划中。

近3000个API操作，价值在“统一”而不是数量

Cloudflare平台拥有大量产品和接口，接近3000个API操作听起来很庞大，但单纯增加覆盖范围并不能自动带来好的Agent体验。

对于Agent来说，API数量的价值取决于这些能力能否被统一描述、正确调用并安全组合。

如果Agent只能完成单个资源的查询，cf更像是API文档的另一种外壳；如果它可以把多个产品能力串成可验证的任务链，才真正接近基础设施Agent。

可以把两者的差异理解为：

| 使用方式 | 人类开发者 | AI Agent | 主要问题 | |---|---|---|---| | Cloudflare控制台 | 直观、适合偶发操作 | 难以稳定自动化 | 页面状态和交互流程不利于机器执行 | | 单个产品CLI | 熟悉后效率高 | 需要学习多套工具 | 命令风格和输出不一致 | | 直接调用API | 灵活、覆盖完整 | 需要理解大量接口细节 | 参数、认证、错误处理成本高 | | Agentic CLI cf | 统一终端入口 | 便于发现、组合和验证 | 仍需严格控制权限与变更风险 |

这也是Cloudflare没有只推出一个MCP服务器的原因之一。MCP适合把工具暴露给支持该协议的Agent应用，但CLI拥有更成熟的执行环境：它可以被脚本调用，可以进入CI/CD，可以在容器中运行，也可以被Claude Code、Cursor等编码Agent通过终端使用。

换句话说，MCP更像是“把工具接入Agent运行时”，Agentic CLI则更像是“重新设计工具本身，使它适合Agent使用”。两者并不冲突。

Cloudflare正在把整个云平台改造成Agent工作台

cf并不是Agents Week期间唯一和Agent相关的发布。Cloudflare同时推出或更新了多项面向智能体的基础设施能力，包括用于本地数据调试的Local Explorer、面向浏览器自动化的Browser Run、支持持久化多步骤任务的Workflows，以及让Agent执行代码的沙箱环境。

Cloudflare的整体路线，是把Agent从本地编码助手扩展成能够运行、调试、部署并持续执行任务的云端工作负载。

其中，Local Explorer解决的是开发阶段的数据观察问题。Agent在处理本地数据库、文件或运行状态时，需要知道实际发生了什么，而不是仅凭代码推断。Browser Run则把实时视图、人工干预、CDP访问和会话录制等能力带给浏览器Agent；官方资料显示，Browser Run对AI Agent的并发限制提高了4倍。

Workflows解决的是另一类问题：Agent任务经常不是一次调用，而是跨越多个步骤，可能运行数分钟、数小时甚至更久。一个可靠的工作流需要在失败后重试、在外部事件到达后继续，并保留此前的执行状态。

这些产品和cf放在一起看，方向就很清楚了：

• cf负责让Agent触达Cloudflare控制面；
• Sandboxes负责让Agent拥有隔离的执行环境；
• Browser Run负责让Agent操作网页和浏览器；
• Workflows负责让任务跨时间持续运行；
• Workers AI和Agent Cloud负责提供模型推理及部署基础设施。

Cloudflare想卖的并不是一个孤立的AI插件，而是一套围绕Agent构建和运行的云平台。

域名注册也被纳入Agent工作流

Cloudflare在同一阶段还宣布，Registrar API进入测试阶段。Registrar API 是允许开发者和Agent在编辑器、终端或自动化工作流中搜索、检查并注册域名的接口。

这看似只是域名管理能力，实际却很能说明Agentic CLI的方向。

过去，Agent可以生成网站代码，但上线一个完整项目仍需要人手动选择域名、修改DNS、绑定部署、配置证书和检查访问状态。域名注册能力进入自动化流程后，Agent理论上可以从“创建项目”一路推进到“准备上线”。

当然，域名注册属于高风险、不可逆或涉及费用的操作，不应该被默认自动批准。更合理的方式是让Agent完成搜索和可用性检查，在真正注册前要求人工确认；部署生产版本、修改DNS、删除资源等操作也应采用类似的审批机制。

Agent能否执行动作，和Agent是否应该直接执行动作，是两个不同的问题。Cloudflare把操作入口交给Agent之后，权限分层、审批、审计和回滚就不再是附加功能，而是产品能否进入生产环境的前提。

最大的现实价值：减少上下文切换

开发者不会因为又多了一个CLI就自动提高效率。cf真正可能带来的收益，是减少开发者在代码、终端、控制台、文档和监控系统之间的切换。

一个典型的线上故障排查流程可能是：

1. 在代码仓库查看最近提交；
2. 在CI系统查看构建结果；
3. 在Cloudflare控制台确认部署状态；
4. 查询Worker日志；
5. 检查路由、DNS和绑定资源；
6. 修改代码并重新部署；
7. 回到浏览器验证结果。

对人类来说，这个流程主要消耗注意力；对Agent来说，问题则是缺少统一的工具接口。cf让这些步骤至少在执行入口上更接近，Agent可以把状态查询结果串起来，减少“看完一个页面再把信息复制到另一个页面”的手工过程。

这也是为什么它对深度用户比对普通用户更有意义。普通用户可能只需要控制台按钮；而开发者、平台工程师和维护多个项目的团队，更在意命令是否可组合、输出是否稳定、错误是否可定位，以及同一套工作流能否在本地、CI和Agent中复用。

但它不会自动解决云上自动化的安全问题

Agentic CLI最容易被忽略的风险，是它把“理解错误”直接连接到了“执行错误”。

传统聊天机器人说错一句话，损失通常是信息层面的；拥有云平台权限的Agent如果理解错一条指令，可能删除资源、覆盖配置、修改流量路由，甚至造成线上服务中断。

因此，企业真正部署cf时，至少需要考虑以下控制措施：

• 最小权限：为不同Agent分配不同权限，不要使用拥有全局管理能力的身份。
• 只读优先：排障Agent先只允许查询日志、状态和配置，变更操作单独授权。
• 高风险操作审批：删除、注册域名、修改DNS、切换生产路由等操作必须人工确认。
• 变更前后验证：Agent执行修改前读取当前状态，执行后再次查询并报告差异。
• 完整审计：记录任务目标、模型输出、实际命令、返回结果和最终操作者。
• 限制执行范围：将Agent绑定到特定账号、项目、环境或资源集合。
• 准备回滚路径：任何自动部署都要能够恢复到上一个已知正常版本。

Agentic CLI的出现，反而会推动云平台重新设计权限系统。过去的权限模型主要围绕“哪个人可以访问哪个API”展开；未来还需要回答“哪个Agent、在什么上下文、经过什么审批、可以对哪个资源执行什么动作”。

和Terraform、MCP、传统脚本是什么关系

cf不会立即取代Terraform、Wrangler或现有CI/CD系统。更现实的判断是，它们会形成分工。

| 工具类型 | 更适合的场景 | 优势 | 局限 | |---|---|---|---| | Terraform等声明式工具 | 稳定的基础设施编排 | 状态管理、变更计划、可审计 | 临时排障和动态任务不够灵活 | | 传统CLI | 人类执行明确命令 | 透明、可脚本化 | 对Agent的发现和解释能力有限 | | MCP工具服务器 | 把能力接入Agent应用 | Agent调用体验直接 | 依赖运行时和工具描述质量 | | cf Agentic CLI | 终端、脚本和Agent共用 | 统一入口、便于组合 | 仍需解决权限和破坏性操作问题 | | 控制台 | 偶发配置和可视化操作 | 上手直观 | 难以复用和自动化 |

Terraform适合描述“最终应该是什么状态”，cf更适合处理“现在发生了什么，以及下一步该做什么”。MCP适合把能力暴露给Agent框架，cf则能作为底层执行工具被不同Agent复用。

对团队而言，比较稳妥的架构不是让Agent绕过现有基础设施流程，而是让它先负责查询、生成计划和执行低风险变更；涉及生产环境的基础设施变更，仍然通过审查、计划和发布流程完成。

我们的判断：这是云平台Agent化的关键一步

Cloudflare cf的产品价值不在于“让AI会敲命令”，而在于它把云服务从一组等待人类点击的后台功能，变成了Agent可以理解和组合的行动空间。

它目前最适合三类场景：

1. 编码Agent辅助部署：从修改代码、运行测试到部署Worker，减少人工接力。
2. 平台工程和运维排障：自动收集状态、日志和配置，给出诊断结果并执行低风险修复。
3. 面向客户的云资源自动化：让企业内部Agent根据业务事件创建临时环境、配置路由或清理闲置资源。

但它距离“完全自动运维”仍然很远。近3000个操作只是能力覆盖面，真正决定体验的是命令语义、结构化输出、错误恢复和权限设计。Cloudflare如果能把这些细节做好，cf可能成为Agent访问云平台的事实入口；如果只是把现有API机械地包装成命令，它最终仍会停留在“更方便的CLI”层面。

截至2026年9月，Cloudflare已经把Agent从代码编辑器进一步推向部署、浏览器、工作流和基础设施控制面。cf是其中最关键的一块拼图：它让AI Agent第一次更像一个可以被授权的云平台操作员，而不只是一个会写代码的聊天窗口。

对开发者来说，现在值得关注的不是要不要马上把生产权限交给Agent，而是提前把云资源、部署流程和审计机制整理成Agent能够安全理解的形式。因为下一轮开发工具竞争，争夺的将不只是哪个模型写代码更快，而是谁能让Agent更可靠地把代码变成真实运行的服务。

参考来源

• Cloudflare GitHub 官方组织：Cloudflare相关开源项目、开发者工具和示例代码的集中入口，可用于跟踪CLI及Agent生态的后续实现。
• Cloudflare Blog，《The Agentic CLI for the Cloudflare API》：本文关于cf统一命令行、Agent访问Cloudflare API及近3000个操作覆盖范围的主要参考资料。
• Cloudflare Blog，《Building the agentic cloud: everything we launched during Agents Week 2026》：本文关于Local Explorer、Browser Run、Workflows、Registrar API及Agent Cloud整体路线的参考资料。