智能体钱包上线，为何管不住多笔支付？3个关键问题待解

Cloudflare 在智能体周（Agents Week）上发布了 Wallets 产品，为 AI 智能体提供稳定币余额和 cloudflare.pay 标识，用于在调用 API、获取数据和内容服务时付费。目前只有认领标识的功能可用，充值和支付功能预计未来几个月内推出。

已上线的功能已经招来不少抱怨。在 Hacker News 上，评论者 merek 发现他的公司名称以及多个变体名称都已被他人抢先注册。他质疑道：没有域名验证，这个用户的意图除了欺诈或冒充还能是什么？他还补充说，已经有人冒用他的品牌搭建网站冒充自己，误导客户。

另一位评论者 nikolay 将这一功能的上线方式与 Meta 处理预留用户名的方式对比——Meta 会提前公示规则、给所有用户公平的注册机会——并得出结论：该公司的做法本质上是在劝退他使用服务，因为他拿不到属于自己的用户名。

支付通道背后的治理逻辑

支付功能基于 x402 实现，复用了 HTTP 402“Payment Required（需要付款）”状态码，用于机器原生小额支付。这个协议最初由 Coinbase 发起，现交由 Linux 基金会托管，拥有约 40 个成员，包括 Stripe、Visa、Mastercard、Google 和 Amazon Web Services。MCP 也走了同样的路线：从单一厂商项目移交至智能体 AI 基金会（Agentic AI Foundation）管理，背后逻辑完全一致——如果一项协议要求所有竞争对手都必须实现，那么对协议发起方而言，将其交由基金会治理远比自己独自掌控更有价值。

基金会托管解决了协议规范的归属问题，但没有解决市场竞争的问题。该公司进入这个赛道的时间较晚，该领域早已存在 AWS、谷歌云、Circle 以及各大银行卡网络搭建的相关基础设施。它的优势在于分发能力。Wallets 是该公司在 7 月 1 日推出的变现网关的买方配套产品，变现网关允许网站与 API 服务基于同一套协议体系向 AI 智能体按请求次数收取费用。同时持有两端意味着商家可以向智能体收费，智能体也可以向商家付款，覆盖 337 个城市、约五分之一网站的庞大网络。

身份提供商之争才是关键

不少评论者认为，这份公告的核心意义并不在于支付本身。网友 eddythompson80 提出：到目前为止，AI 智能体身份一直被禁锢在各个独立系统内部。例如 AWS IAM 分配的身份凭证无法在其他不相关的网站上使用；而 OIDC 联合身份机制对普通站点来说又过于复杂，难以落地。真正的阻碍从来不是技术实现手段，而是各方对身份提供方达成共识——难点就在于要敲定唯一的身份提供商，可现实中这类身份提供商足足有 40 家之多。

他的结论是该公司发现了这个机会：这一需求客观存在，看起来该公司认为如果他们成为那个“互联网智能体身份提供商”，那么他们将对互联网和 AI 的使用掌握巨大的影响力和控制权。

评论者 wxw 从平台角度表达了相同的观点，指出 Durable Objects 和 Workers 是优秀的智能体基础组件，因此已经在使用它们的团队不妨也采用钱包、沙箱和 AI 网关。但也有不少网友对此持保留态度。评论者 Ycros 表示，该公司总在各类业务中间横插一脚。对此 nater5000 回复称：一家企业在自身所处市场针对明确的用户需求开发产品本就无需额外过多解释。

管控模型的真实局限

值得仔细研读的是它的管控模型。每个账户持有者拥有一个主账户钱包，还可以为每个 AI 智能体创建独立的虚拟钱包；虚拟钱包资金来源于主账户，并受账户所有者设置的三项规则约束：额度上限、允许交易的商户白名单、单笔交易最大金额。官方设计意图是让智能体能够自主测试、购买服务，无需人工对每一笔支付进行审批，同时通过硬性上限限制可能造成的损失。

但这些原语描述的是预算额度而非策略。可用额度是累计消耗的总金额；商户白名单只是校验是否在允许的集合内；单笔交易上限是针对单次请求的约束。以上三者都只是将当前这笔支付和固定阈值做比对，无法表达多笔支付之间的关系。

平台团队通常想要的规则恰恰需要表达交易之间的关系。智能体只能向经过官方目录核验过的供应商付款。它不能在一小时内向两家不同供应商购买同一项服务。首次向新商户发起采购前，必须获取审批。这些规则都需要对交易时序序列做逻辑判断，而不只是校验当前这一笔请求。

并发执行带来了一个相关问题。智能体会并行发起操作，因此会出现这样的情况：多笔支付同时校验额度，此时每一笔都还没有扣减预算余额；单看每一笔都没有触