Cloudflare 给 agent 发了张能刷的卡

这周 Cloudflare 让 agent 直接来注册域名、刷信用卡、部署服务了。

听起来像把控制权交了出去 - 给 agent 信用卡和 API token，那不就等于让它失控吗？

但拆开看其实不是。Cloudflare 把控制点从 agent 的执行边缘挪到了协议层。这是个完全不一样的 agent 安全哲学，也是 Cloudflare 在赌 agent 是一类新的客户类型。值得仔细看一下。

agent 现在能干什么

Cloudflare 跟 Stripe 合作发了个新协议，叫 stripe projects。原话是：``Starting today, agents can now be Cloudflare customers. They can create a Cloudflare account, start a paid subscription, register a domain, and get back an API token to deploy code right away.''

具体动作就是三条命令：

stripe projects init
stripe projects catalog
stripe projects add cloudflare/registrar:domain

第一行初始化项目，第二行查可用的 provider 和服务，第三行让 agent 通过 Cloudflare 的 registrar 服务注册一个域名。

flow 大致是：用户先登 Stripe → 跑 stripe projects add ... → Stripe 作为 identity provider 验身份 → Cloudflare 自动开账号（如果还没有），或者走标准 OAuth（已有账号）→ Cloudflare 把 API token 发回 CLI，存在系统 keychain 里 → agent 拿这个 token 直接调 Cloudflare API 部署。

这是一个 stripe projects 协议层的封装，不仅是 Cloudflare 自己。理论上任何 provider 都能注册成 stripe projects 的 catalog 项，agent 通过同一个 CLI 就能跨 provider 自由组合。Cloudflare 是首发合作方，但意思是要做一个标准。

缰绳藏在协议里不在执行层

最容易引发的反应是："给 agent 信用卡？这不疯了吗？"

但 Cloudflare 没真给信用卡。它把三道关挪进了协议层。

第一道是 OAuth 同意。用户必须明确接受 Cloudflare TOS、批准 OAuth scope，agent 不能绕过。这跟传统 OAuth 一样，但意义不同 - 在传统场景下 OAuth 是 "用户授权一个 app"，这里是 "用户授权一个 agent 代表用户行使账号能力"。授权的颗粒度（域名注册、账单订阅、API token 范围）由 OAuth scope 决定，而不是给 agent 全权。

第二道是预算 cap。Stripe 给每个 provider 默认 $100/月上限，agent 花超就停。用户可以调高，但默认是收紧的。这把 "agent 失控会怎样" 这个最大恐惧从 "无限烧钱" 收口到 "最多 100 块"。

第三道是凭证隔离。原话："Raw payment details like credit card numbers aren't ever shared with the agent." agent 拿到的是 opaque payment token，不是真正的卡号。token 失效或被滥用，可以即时回收，不影响用户的卡。

三道关合起来，agent 拿到的不是 "信用卡"，是 "用户授权的、范围限定、有月度上限、用完就丢的代付能力"。控制点从执行边缘挪到了协议边缘 - agent 能调哪些经过 OAuth scope 的 API、最多花多少钱、用什么凭证，全在协议层就规定死了。

这套思路最大的好处是 agent 失控的最坏情况是 "可计算的"。$100 烧光了就停，token 用滥了就回收，OAuth scope 之外的操作根本调不通。把 "万一 agent 出事" 从一个开放风险变成一个有边界的、能买保险的事故。

把 agent 升级为 first-class 客户类别

Cloudflare 这步表面上是产品发布，本质是 product positioning 的判断 - 它在赌 agent 是一类新的客户类型，需要专门的 onboarding、计费、TOS 路径。

传统 SaaS 客户的画像：人类，从 marketing → trial → 转化 → 付费 → 增购，每一步都要做用户研究、转化率优化。这套 funnel 不适用于 agent。Agent 不需要 marketing，它就是一段代码、看到合适的 API 就调。Agent 也不会做 trial - 它要么需要这个服务、要么不需要。

所以 Cloudflare 给 agent 设计的是一条全新通道：

• 入口是 stripe projects catalog（替代 marketing landing page）
• 注册是自动 provisioning 加 OAuth（替代 sign-up form）
• 计费是预算 cap 加 token-based payment（替代信用卡加月度账单）
• 监控是协议层 telemetry（替代 dashboard 加客服）

这套设计的目标用户特征非常具体：高频、小额、自动化、可监控、可即时叫停。每一笔交易可能就 $0.10、$1，但一个 agent 一天可能跑几百次。月度 GMV 加起来不小，但每一笔都是 micro。

SaaS 行业过去 10 年没认真做过这种用户。Stripe 加 Cloudflare 现在做的事，是把 micro-payment、scoped auth、自动 provisioning 这三块原本分散的能力封装成一个标准协议。如果这件事跑通，agent 经济这条线会从 "agent 调 API" 升级成 "agent 是 buyer"。这是质的不同。

短期看，这是 Cloudflare 抢先一步给 agent 经济造了一个入口。长期看，任何卖 infra 的公司迟早要做类似的事 - 不然就被 agent 直接跳过去。这是个先发优势的赌注。

几条该重新评估的判断

Provider 必须给 agent 留入口。 如果你做 SaaS 或 API 产品，"是否有 agent-friendly 的注册和计费协议" 在未来 12 个月会变成评估标准。手动 dashboard 加复制粘贴 token 这条路对 agent 不友好，等于自我边缘化。stripe projects 这种协议一旦扩散，没接的 provider 会被 agent 直接跳过。

OAuth scope 是 agent 时代被低估的设计。 多数 OAuth 用法停留在 "授权一个 app"，但 agent 时代要细化到 "授权这个 agent 在这个 scope 内的具体操作"。Scope 设计直接决定 agent 安全的上限。现在重新审视一下你产品的 OAuth scope - 它是为 app 写的还是为 agent 写的？

预算 cap 是新的安全边界。 传统安全边界是 "能做什么"，agent 时代多了一条 "能花多少"。$100/月这个默认值不是数字游戏 - 它把 "agent 失控的最坏情况" 变成了一个可承受的、可保险的、可量化的事故。任何让 agent 动钱的产品，预算 cap 都该是默认机制不是高级选项。

Agent-as-customer 是新的商业类别。 这一类用户的特征是高频小额、自动化、可监控、可即时叫停。SaaS 定价模式过去十年都是为人类设计的 - 月度订阅、年度合约、tiered pricing。给 agent 用户重新设计的话，可能是按调用计价、按预算 cap 划档、按 scope 分级。等到大家都在做这件事的时候，先发的 Cloudflare 已经把标准定了。