Cloudflare: Agent 现在可以自己注册账号、购买域名、部署上线了
长久以来，AI 编程助手能写代码，但不能真正"上线"。它生成了完整的项目，然后在部署环节停下来，等你手动去注册账号、复制粘贴 API Token、输入信用卡信息。这个最后几步，始终需要人来完成。 Cloudflare 在 2026 年 4 月 30 日发布的这篇博客，宣告这个局面正在改变。 要把一个应用部署到生产环境，Agent 需要三样东西： 这三件事，过去都必须由人来处理。即便 Agent 已经把代码写好了，用户还是要跳出对话，去平台控制台完成注册，生成 Token，再粘贴回来。 这个流程看起来不算什么大问题，但它意味着 Agent 的"自主性"存在一个硬边界——到了基础设施层，它就必须停下来等人。 Cloudflare 与 Stripe 合作，推出了一套新协议，以及基于这套协议的产品 Stripe Projects。 整个流程如下： 安装 Stripe CLI 并登录 Stripe 账号，执行： 然后告诉 Agent 要做什么，比如"构建一个新网站并部署到新域名"。 接下来，Agent 会自动完成： 如果当前邮箱已有 Cloudflare 账号，则走标准 OAuth 授权流程，Agent 获得对已有账号的操作权限。 整个过程中，除了在 Stripe 账号未绑定支付方式时会提示用户添加，其余步骤无需任何人工介入。 这套机制背后，是 Cloudflare 和 Stripe 共同设计的协议，分为三个层次。 Agent 在构建方案之前，首先需要知道哪些服务可以被调用。 通过执行： Agent 可以拿到一份可用服务的目录，包含 Cloudflare 的域名注册、R2 存储、Workers 沙箱等产品，以及其他服务商提供的资源。 对于人类来说，这份目录可能过于冗长，但对 Agent 来说，这正是它需要的上下文——它会根据用户的需求，自行从中选择合适的服务，用户不需要提前知道有哪些选项，也不需要做任何选择。 当 Agent 决定使用某个服务并发起调用时，Cloudflare 需要确认用户身份。 这里的关键设计是：Stripe 作为身份提供方，对用户身份进行背书。Cloudflare 收到请求后，如果该邮箱没有对应账号，就自动为用户创建一个，并把 API Token 安全地返回给 Stripe Projects CLI，由 CLI 存储并提供给 Agent 使用。 用户不需要访问 Cloudflare 的注册页面，不需要设置密码，不需要做任何额外操作。从 Agent 的视角看，它直接拿到了可以使用的凭证。 这是这套设计里最值得关注的环节之一。 Agent 在代购域名或开启付费服务时，Stripe 会在请求中附上一个支付 Token，Cloudflare 凭此完成计费。Agent 自始至终看不到真实的信用卡信息。 与此同时，协议默认设置了每个服务商每月 100 美元的消费上限，防止 Agent 失控乱买。如果需要调整上限，用户可以在 Cloudflare 后台手动设置预算警报。 这套协议的开放性是这次发布中另一个重要信号。 Cloudflare 和 Stripe 把自己的角色分别定义为 Provider（服务提供方）和 Orchestrator（编排方）。理论上，任何拥有已登录用户的平台，都可以扮演 Orchestrator 的角色，以同样的方式接入 Cloudflare 提供的服务。 举个具体场景：如果你在做一款编程 Agent 产品，你希望用户构建完之后能直接部署，而不是把他们推进一堆授权流程。现在你可以让自己的平台作为 Orchestrator，用一次 API 调用，为用户在 Cloudflare 上开通账号，拿回 Token，让 Agent 直接完成部署。 另一个方向是反过来，让 Cloudflare 用户能轻松调用其他服务商的产品。Cloudflare 和 PlanetScale 正在合作，让 Cloudflare 用户可以直接在 Cloudflare 侧创建 PlanetScale 的 Postgres 数据库——资金从用户现有的支付方式扣除，整个过程不需要跳转到 PlanetScale 平台。 Cloudflare 在博客中明确表示，这套协议的目标是把过去各个平台各自为战、定制化对接的方式，标准化成一套可复用的规范。类比 OAuth 对"账号授权"这件事的标准化作用，这套新协议试图把"账号创建 + 支付 + 凭证颁发"打包成一个统一的流程标准。 表面上看，这是 Cloudflare 和 Stripe 的一次联合发布，涉及账号、域名、支付的自动化。但如果往后退一步看，它代表的是一个更深层的转变。 过去，Agent 被定义为"帮助用户完成任务的工具"，它的能力边界在于生成内容、写代码、做分析。真正需要与外部系统交互、需要身份和支付的部分，都还是由人来承接。 这套协议把这个边界往外推了一步：Agent 现在可以作为一个独立的操作实体，代表用户完成原本需要人才能完成的基础设施操作。 这不只是"更方便"的问题。它意味着从构建到部署的整个周期，可以在一次对话中完成，而无需用户在多个平台之间来回切换。对于独立开发者和小型团队来说，这个变化缩短的不只是操作步骤，而是真正的决策摩擦——很多想法因为"上线太麻烦"而被搁置，这个门槛正在被系统性地降低。 当然，这也带来了新的问题需要回答：Agent 的操作行为由谁审计？如果 Agent 出错，责任如何界定？支付预算的默认上限是否足够合理？这些问题在协议还处于开放 Beta 阶段时，还没有完整的答案。 Cloudflare 这次和 Stripe 做的事情，本质上是在为 Agent 补全"最后一公里"的基础设施：账号、支付、凭证，这三件事原来是 Agent 能力的边界，现在被系统性地纳入了协议范围。 对开发者来说，这意味着可以用更少的前置设置，让 Agent 做更多原来只有人能做的事。对整个行业来说，这套协议如果能推广开来，可能会成为 Agent 调用第三方服务时的通用接口规范。 目前 Stripe Projects 已进入公开 Beta，无需已有 Cloudflare 账号即可开始体验。之前卡在哪里
现在变成了什么样
stripe projects init协议的三个核心环节
Discovery：Agent 如何知道能用什么服务
stripe projects catalogAuthorization：账号自动创建，不经过注册页面
Payment：给 Agent 一个预算，而非信用卡号
不只是 Stripe，任何平台都可以接入
这背后更大的变化
小结