Cloudflare 和 Stripe 在 5 月 18 日出货了一个 agent 商务协议,让 AI agent 自主创建云账号、注册域名、开通订阅、部署到生产。三个组件:返回 JSON 服务描述符的 REST discovery API,Stripe 作为身份提供方(已有匹配的 Cloudflare 账户就走 OAuth,没有就自动 provision 一个),以及用 Stripe tokenization 做支付,让 agent 永远看不到原始卡数据。默认每月每 provider 上限 100 美元,Stripe 端强制。Stripe Projects 是面向开发者的产品(docs.stripe.com/projects),在 open beta。由 Cloudflare 的 Sid Chatterjee 和 Brendan Irvine-Broque 宣布。
让这件事变得重要的架构选择是信任边界放在哪里,而不是 API 表面。Cloudflare 和 Stripe 明确把线划在「法律和金融后果」上:四个动作需要人做 —— Stripe 认证、接受 ToS、设置 billing、merge 决定。其它全部 —— 账户 provisioning、credential 接线、部署流水线、域名注册 —— 都由 agent 来做。这是对 agent 经济体信任模型的具体提案,不是一个单纯的集成。其它的「云 + 支付」大厂要么采纳这个四动作 pattern,要么反提案。截至今天,没有其它任何主流云厂商提供与之相当的 agent 驱动的账户 provisioning。
把这件事放在 2026 年 5 月这一周的 agent 基础设施栈里看。Anthropic Routines、OpenAI Symphony、BerriAI 的 LiteLLM Agent Platform 都回答的是「agent 在哪里跑」。Cloudflare+Stripe 回答的是另一个问题:「agent 能替用户买什么、provision 什么」。这是不同的一层 —— 是 agent 经济的底层基础设施,不是 agent 执行的底层基础设施。一旦 agent 能自主交易并部署,那 agent 编排器(Routines vs Symphony vs LiteLLM)之间的选择就变成「哪个编排器最善用这一层」。看 AWS Bedrock、Azure AI、GCP 下个季度有没有出货自己的 agent 商务原语,还是把 Cloudflare-Stripe 协议当成事实标准接下来。
周一上手:如果你在做需要 provision 基础设施的 agent workflow(部署到一个新云、为生成的应用注册域名、在第三方 API 上开个 billing 订阅),Cloudflare-Stripe 协议在 open beta,值得在低风险用例上试一试 —— 100 美元/月的上限会限制爆炸半径。InfoQ 一个评论者提出了一个真问题:agent 在一个 flaky API 上陷入重试循环,会触发反复的 micro-charge,单看每笔都没问题,但累计起来对上限来得很快。在 agent 的购买流里加上 retry-with-backoff 和 idempotency key,再去把 load-bearing 的东西交给它。更深一层的问题是:在 agent 栈的哪个点上要重新核对一次人的持续 consent?Cloudflare+Stripe 给出的是四个锚点。你的应用可能需要更多。