Cloudflare下场做AI钱包！

Cloudflare正在把AI智能体的“付款能力”接进自己的网络基础设施。

近日，Cloudflare宣布推出Cloudflare Wallets，并开放钱包标识预留。按照官方规划，未来用户可以通过Account Wallet管理资金，再为不同AI智能体创建Virtual Wallet，为其设置支出上限、核准商户清单和单笔交易上限。

充值、提现、稳定币管理及Virtual Wallet等完整功能目前尚未全面开放，将在未来数月逐步推出。

这不是一个面向普通消费者的数字钱包。Cloudflare真正补上的，是智能体交易链条中的买方账户和支出授权层。补上买方账户后，Cloudflare此前面向卖方收费、身份验证和支付验证的能力，开始可以接到同一条交易链上。

支付正在离开由人逐笔点击确认的环节，进入机器自主执行任务的流程。

AI有了钱包，钱仍然不能随便花

按照Cloudflare披露的规划，Wallets将采用两层结构。

第一层是Account Wallet，由个人或企业的Cloudflare账户控制。完整功能开放后，它将承担资金进入、退出和余额管理，是整个钱包体系的总账户。

第二层是Virtual Wallet。账户所有者未来可以针对具体AI智能体创建Virtual Wallet，并分配一定资金和交易权限。不同智能体可以拥有不同支出上限，也可以限定允许交易的商户和单笔交易金额。当支出超出既有限额时，还可以请求有相应权限的账户管理员进行人工处理。

两层结构把账户控制权和交易执行权拆开了。Account Wallet保留资金和规则的最终控制，Virtual Wallet则向智能体下放有限的交易执行权。企业决定一个智能体最多花多少钱、能向哪些商户付款、单笔交易最多达到多少，也可以调整或撤销相关权限。

如果AI每购买一个API、调用一项付费数据、订阅一个工具都要等待人工点击确认，那么智能体即使具备任务规划能力，也很难真正形成自动执行闭环。但如果把完整账户和无限支出能力直接交给AI，一次错误判断、异常调用甚至恶意提示，都可能转化为真实的资金损失。

人在上层决定目标、预算和规则，智能体则可以在规则范围内决定具体何时采购、向谁采购以及是否完成付款。

这里发生的变化，不只是给AI多开了一个子账户。原本需要由人逐笔作出的支付授权，被拆成预算、商户范围和单笔上限，提前写进机器可以持续执行的规则。钱包由此同时承载资金和账户所有者设定的交易权限。

从AI专属支付工具到智能体支付协议，行业面对的始终是同一个问题：怎样让AI获得真实交易能力，又不让账户控制权随之失去。

Wallets补上买方一侧，支付开始进入HTTP请求

仅有钱包，还无法完成Cloudflare设想中的智能体交易。

在Wallets之前，Cloudflare已经宣布Monetization Gateway，希望帮助API、数据、MCP工具和其他数字内容提供者直接向机器访问收费。目前该产品仍处于候补名单和早期访问阶段，并未面向所有客户全面开放。

按照规划，卖方将可以设定哪些资源需要付费、如何定价、接受什么支付方式，以及付款完成后是否放行访问。智能体请求收费资源后，服务端可以通过HTTP 402返回价格和支付条件，智能体完成付款并重新提交支付凭证，验证通过后再获得相应资源。

这里使用的核心协议之一是x402。

x402最初由Coinbase创建，目前已经进入Linux Foundation旗下x402 Foundation的开放治理体系，Cloudflare是参与建设的成员之一。x402负责在HTTP请求中表达价格、支付条件和支付证明，本身不承担钱包托管或账户授权。

服务端可以通过HTTP 402告诉访问方需要支付多少、使用什么资产以及向哪里付款。客户端完成交易后，再把支付凭证带回原来的请求。它也可以脱离Cloudflare Wallets运行，Cloudflare此前的Agents SDK已经支持智能体通过配置加密钱包账户和私钥完成x402支付。

Monetization Gateway解决的是“卖方怎样收费”，x402解决的是“买卖双方怎样在HTTP请求中表达和证明付款”，Wallets解决的则是“智能体使用什么账户付款、可以花多少、由谁授权”。

三者分别对应账户、网关和协议。

当这三层开始连接起来，AI智能体在交易中的角色也发生了变化。

传统自动扣款或者程序化支付中，机器往往只负责执行一个已经由人决定的交易。付款对象确定、金额确定、交易时间确定，程序只负责把指令执行下去。

智能体交易可能把机器的位置进一步向前推。

一个AI为了完成任务，可以先寻找需要的API或数据源，判断哪项服务更合适，读取价格，再决定是否接受卖方报价。如果价格、商户和金额都处于账户所有者设定的权限内，它还可以自行调用Virtual Wallet完成付款，并继续使用购买到的资源完成后续任务。

人仍然控制预算和规则，但具体交易决定开始部分交给智能体。

在Cloudflare设想的链路里，一笔数字资源交易甚至不再需要单独进入收银台。智能体请求资源，Cloudflare验证请求，卖方返回价格和支付要求，钱包按照授权规则付款，支付凭证验证成功，资源随即被放行。

支付从网页和App里的独立动作，变成一次机器请求中的组成部分。过去，支付通常发生在采购决定之后。到了智能体交易中，发现资源、判断价格、付款和继续执行任务，可能被压缩到同一条调用链上。

对于Cloudflare而言，这种变化也意味着新的基础设施位置。它没有必要像传统支付公司那样首先争夺消费者手机里的钱包入口，而可以利用自己的网络、边缘节点、机器人识别和访问控制能力，进入请求到达服务提供者之前的身份验证、规则执行、支付验证和资源放行环节。

支付竞争也因此从用户手里的付款动作，继续延伸到智能体背后的交易决策权。智能体开始承担具体采购决定之后，谁能够验证身份、执行授权、验证付款并决定资源是否放行，谁就更接近这条交易决策链的基础设施位置。

Cloudflare并不直接替智能体决定购买什么，它争取的是这套交易规则的执行位置。

身份和支付开始汇合，责任链条还没有消失

智能体真正自主交易之后，仅仅证明“这个钱包有钱”还不够。

系统还需要知道，这个请求究竟是谁发出的，这个AI代表谁，它是否有权使用某个钱包，以及本次采购是否仍然处于原来的任务和授权范围之内。

Cloudflare目前正在把不同能力连接起来。

Web Bot Auth主要解决请求身份验证，通过HTTP消息签名和公钥信息确认一个请求是否由相应机器人、智能体或运营者签发。Wallet handle则给钱包和智能体建立更容易识别的账户关联。Cloudflare参与支持的Agent Name Service，则进一步试图解决智能体在不同平台间的命名、发现和验证问题。

一个智能体发起API请求后，系统可以先验证请求来源，再识别其关联账户。Monetization Gateway匹配访问和收费规则，服务端返回x402支付要求。Virtual Wallet检查预算、金额和商户权限。智能体在授权范围内决定是否付款。支付完成后，Cloudflare再验证凭证并决定是否放行资源。

身份、账户、授权、付款和交付，由此可能被压缩进一条连续的网络请求链路。

但身份验证解决不了全部支付风险。

一个请求由正确的密钥签发，只能说明它确实来自相应智能体或系统，不能证明智能体作出的购买判断一定正确。一个AI可能因为错误推理选择了不需要的数据，也可能受到提示注入影响，调用错误工具，还可能在连续交易中快速消耗授权额度。

传统支付系统主要判断账户是否异常、指令是否伪造、交易频率和金额是否可疑。到了智能体场景，系统还要判断AI是否仍然执行原来的委托、采购行为是否偏离任务目标，以及它调用的外部工具是否可信。

同样，授权有效也不意味着责任问题已经结束。

如果智能体在授权范围内买错了服务，损失由账户所有者、智能体运营者还是模型提供者承担？如果钱包已经付款，但API无法使用或者数据没有正确交付，又由谁负责退款和争议处理？

智能体支付把原本可能由一个人连续完成的决定、授权、付款和验收，拆给了账户所有者、智能体、钱包、支付验证方和资源提供者。流程可以因为机器调用而变短，责任却可能因为参与主体增加而更加分散。

从目前公开材料看，Cloudflare披露得更充分的仍是交易前和交易中的能力。身份验证、账户关联、预算控制、支付要求、付款凭证和资源放行。真正进入完整支付闭环后，还会面对资金由谁托管、充值提现具体如何完成、支持哪些稳定币和区块链、KYC和反洗钱如何分工，以及退款、争议和追偿如何处理等问题。

结算资产也尚未完全明确。Cloudflare此前提出过NET Dollar稳定币计划，但本次Wallets及Monetization Gateway公开材料并没有说明NET Dollar已经进入这套产品体系。

Cloudflare真正争取的不是消费者手机里再多一个钱包，而是智能体访问互联网资源时的规则执行位置。先判断是谁发起请求，再判断它有没有权限交易，随后验证付款，最后决定资源是否交付。

智能体支付正在把账户控制、交易决策、风控和责任链条重新拆开。Cloudflare能否把Wallets及其网络位置真正变成支付基础设施，还要看钱包托管、合规、交易后责任以及卖方收费体系能否接上。

这里是支付之家。我们关注支付表象之下的规则差异与逻辑变化，提供支付科技领域增量信息。观点内容仅供参考。