Cloudflare 在其智能体周（Agents Week）活动中发布了 Cloudflare Wallets，为 AI 智能体提供稳定币余额和 cloudflare.pay 标识，用于在为调用 API、获取数据和内容服务进行付费时出示。目前仅有认领标识的功能可用。充值和支付功能预计将在未来几个月内推出。
已上线的功能已经招致不少抱怨。在 Hacker News 上，评论者 merek 发现他的公司名称以及多个变体名称都已被他人抢占注册：
没有域名验证，这个用户的意图除了欺诈/冒充仿冒还能是什么？
他补充说，已经有人冒用他的品牌搭建网站冒充自己，并误导客户。评论者 nikolay 将该功能的上线方式与 Meta 处理预留用户名的方式进行了对比——Meta 会提前公示规则、给所有用户公平的注册机会，并由此对这款产品得出了自己的结论：
Cloudflare 的做法本质上是在劝退我使用他们的服务，因为我拿不到属于自己的用户名。
支付功能基于 x402 实现，复用了 HTTP 402 “Payment Required（需要付款）”状态码，用于机器原生小额支付。最初由 Coinbase 发起，现交由 Linux 基金会托管，拥有约 40 个成员，包括 Cloudflare、Stripe、Visa、Mastercard、Google 和 Amazon Web Services。MCP 也走了同样的路线：从单一厂商项目，移交至智能体 AI 基金会（Agentic AI Foundation）管理，背后逻辑完全一致。如果一项协议要求所有竞争对手都必须实现，那么对协议发起方而言，将其交由基金会治理远比自己独自掌控更有价值。
基金会托管解决了协议规范的归属问题，但没有解决市场竞争的问题。Cloudflare 进入这个赛道的时间较晚，该领域早已存在 AWS、谷歌云、Circle 以及各大银行卡网络搭建的相关基础设施。它的优势在于分发能力。Wallets 是 Cloudflare 在 7 月 1 日推出的变现网关的买方配套产品，变现网关允许网站与 API 服务基于同一套协议体系向 AI 智能体按请求次数收取费用。同时持有两端意味着商家可以向智能体收费，智能体也可以向商家付款，覆盖 337 个城市、约五分之一网站的庞大网络。
不少评论者认为，这份公告的核心意义并不在于支付本身。网友 eddythompson80 提出：到目前为止，AI 智能体身份一直被禁锢在各个独立系统内部。例如 AWS IAM 分配的身份凭证无法在其他不相关的网站上使用；而 OIDC 联合身份机制对普通站点来说又过于复杂，难以落地。真正的阻碍从来不是技术实现手段，而是各方对身份提供方达成共识：
难点就在于要敲定唯一的身份提供商，可现实中这类身份提供商足足有 40 家之多。
他的结论是 Cloudflare 发现了这个机会：
这一需求客观存在，看起来 Cloudflare 认为如果他们成为那个“互联网智能体身份提供商”，那么他们将对互联网和 AI 的使用掌握巨大的影响力和控制权。
评论者 wxw 从平台角度表达了相同的观点，指出 Durable Objects 和 Workers 是优秀的智能体基础组件，因此已经在使用它们的团队不妨也采用钱包、沙箱和 AI 网关。但也有不少网友对此持保留态度。评论者 Ycros 表示，Cloudflare 总在各类业务中间横插一脚。对此 nater5000 回复称：一家企业在自身所处市场针对明确的用户需求开发产品本就无需额外过多解释。
值得仔细研读的是它的管控模型。每个账户持有者拥有一个主账户钱包，还可以为每个 AI 智能体创建独立的虚拟钱包；虚拟钱包资金来源于主账户，并受账户所有者设置的三项规则约束：额度上限、允许交易的商户白名单、单笔交易最大金额。官方设计意图是让智能体能够自主测试、购买服务，无需人工对每一笔支付进行审批，同时通过硬性上限限制可能造成的损失。
Cloudflare 仪表盘中的账户钱包和智能体的虚拟钱包（来源：Cloudflare 博客）
这些原语描述的是预算额度而非策略。可用额度是累计消耗的总金额；商户白名单只是校验是否在允许的集合内；单笔交易上限是针对单次请求的约束。以上三者都只是将当前这笔支付和固定阈值做比对，无法表达多笔支付之间的关系。
平台团队通常想要的规则恰恰需要表达交易之间的关系。智能体只能向经过官方目录核验过的供应商付款。它不能在一小时内向两家不同供应商购买同一项服务。首次向新商户发起采购前，必须获取审批。这些规则都需要对交易时序序列做逻辑判断，而不只是校验当前这一笔请求。
并发执行带来了一个相关问题。智能体会并行发起操作，因此会出现这样的情况：多笔支付同时校验额度，此时每一笔都还没有扣减预算余额；单看每一笔都没有触达上限，但全部加起来总额却超出了预算。Cloudflare 尚未公开在并发消费场景下额度限额的具体实现逻辑。在放开智能体免逐笔审批交易之前，这一点是必须明确的。
这种情况并非 Cloudflare 独有。该领域的各类服务商，推出的都只是限额管控能力而非完整的策略语言，并且把这些限制条件的组合逻辑全部丢给上层应用。
对于正在评估智能体支付方案的团队来说，需要关注的问题十分明确：支出策略应当放在钱包层还是放在上层应用？当多个智能体任务并行消耗同一个预算时会发生什么？服务商提供的是单纯的限额机制还是一套策略语言——这一点将决定团队需要自行开发多少业务逻辑。
x402 是一个可用的通道，由谁来治理这个协议的问题已经得到解决，但智能体在多笔支付中可以花费多少的问题尚未得到解决。
查看英文原文：https://www.infoq.com/news/2026/08/agent-payment-rails-x402/