Cloudflare给Agent发钱包

AI Agent终于可以自己付钱了

Cloudflare在8月4日发布了Cloudflare Wallets与cloudflare.pay，试图让AI Agent在无需人类逐次介入的情况下购买API、MCP工具、模型推理和在线内容。简单说，Cloudflare不只是给Agent做了一个钱包，还同时补上了身份、预算和商户风控这三块基础设施。

Cloudflare Wallets是一个专为AI Agent设计的可编程支付系统。账户所有者可以先存入资金，再把有限的支出权限分配给特定Agent；Agent能够自主发起交易，但只能在预设预算、商户白名单和单笔金额上限内行动。

这项产品值得关注，但“推出”不等于已经全面可用。截至今天，也就是2026年8月5日，Cloudflare开放的是cloudflare.pay账户名称预留；包括资金存入、提取以及创建虚拟钱包在内的完整能力，将在未来数月逐步上线。它目前更像一次产品定调，而不是开发者今天就能直接接入生产环境的成熟支付服务。

这不是给Agent绑一张普通信用卡

Cloudflare Wallets采用“账户钱包+虚拟钱包”的双层结构，把资金所有权和软件支出权拆开。这个设计与企业给员工发公司卡相似，但控制粒度更细，并且执行者从人变成了持续运行的软件Agent。

| 钱包类型 | 使用主体 | 主要能力 | 风险控制 | 当前定位 | |---|---|---|---|---| | Account Wallet | Cloudflare账户所有者或管理员 | 接收、持有、管理资金，创建并授权虚拟钱包 | 统一资金管理、撤回授权、分配预算 | 企业或个人的中央余额账户 | | Virtual Wallet | 单个AI Agent | 通过凭证自主购买API、推理、数据、MCP工具和内容 | 总额上限、批准商户列表、单笔交易上限 | Agent可编程支出账户 |

Account Wallet是由人类或组织控制的中央账户钱包。按照Cloudflare公布的设计，它可以接收、持有和管理稳定币，并将部分支出权限委派给下层虚拟钱包，而不是把整个主账户暴露给Agent。

Virtual Wallet是分配给特定AI Agent的软件钱包。它通过机器可使用的凭证运行，只能在账户所有者设定的权限边界内消费，因此更接近一张带有强制策略的虚拟采购卡，而不是Agent拥有的独立银行账户。

双层结构解决了一个很现实的问题：企业可以授权Agent花钱，却不必把完整资金控制权交给模型。即便Agent受到提示词注入、工具调用错误或恶意网页诱导，损失也可以被限制在单个虚拟钱包的预算内，而不是扩散到整个账户。

Cloudflare给出的例子很直观：如果一次API试用只需要几美分，管理员可以先给Agent分配10美元预算，让它自主比较一批服务；这比直接授予1,000美元额度的风险低两个数量级。企业也可以为每位员工设置每周100美元的AI推理预算，超过限额后再要求人工审批。

x402把付款塞进HTTP请求

x402是一种将支付要求和支付证明嵌入HTTP交互的机器支付协议。它借用了HTTP 402“Payment Required”的语义，让服务端可以先返回价格或付款条件，客户端完成支付后再携带证明重新请求资源。

Monetization Gateway是Cloudflare面向服务提供方的支付接入层。它负责把API、模型推理、数据集、网页内容或MCP工具变成可以按请求计费的资源，并与Wallets共同组成买卖双方的交易闭环。

传统API采购流程的问题不在于Agent不会发HTTP请求，而在于支付流程仍然是为人设计的。Agent通常需要打开登录页、处理验证码或OAuth流程、等待用户添加银行卡、选择套餐、创建访问凭证，然后才能测试服务；其中任何一步失败，任务都会退回给人类。

x402试图把这条链路压缩成机器能够理解的请求—报价—付款—交付流程。对于单次只值几美分的推理、数据库查询或内容读取，Agent不需要先购买月度套餐，也不必为每一个新服务走一遍人工采购流程。

| 支付方式 | 是否适合机器自主执行 | 小额交易成本 | 预算控制粒度 | 身份与责任归属 | 主要问题 | |---|---:|---:|---:|---:|---| | 人工绑卡并购买套餐 | 低 | 较高 | 通常按账户或套餐 | 清晰 | Agent频繁回退到人工操作 | | 传统企业信用卡 | 中 | 不适合海量微支付 | 卡片级或商户级 | 较清晰 | 授权、拒付、欺诈和卡号泄露风险 | | 服务商预付余额 | 中 | 较低 | 单一平台内较细 | 仅平台内部清晰 | 资金碎片化，难以跨服务使用 | | 普通加密钱包 | 高 | 取决于网络 | 需要额外合约或策略层 | 链上地址不等于真实授权方 | 私钥风险高，企业治理不足 | | Cloudflare Wallets+x402 | 高 | 面向微支付设计 | Agent、商户、总额和单笔级 | 可关联Cloudflare账户 | 尚未全面上线，生态与合规仍待验证 |

稳定币是这套机器支付系统的重要底层选择。与信用卡相比，稳定币更容易进行程序化转移和快速结算，也没有传统卡网络中的拒付流程，因此更适合高频、小额、跨服务的Agent交易。

稳定币也不是没有代价。Cloudflare目前尚未完整披露支持哪些稳定币、覆盖哪些国家和地区、交易费率如何计算，以及企业如何处理托管、税务、会计和反洗钱要求；这些问题会直接决定Wallets能否进入大型企业，而不只是停留在开发者试验阶段。

cloudflare.pay给Agent一张可验证的“名片”

cloudflare.pay是Cloudflare为账户和Agent提供稳定网络身份的命名与验证体系。每个Cloudflare账户可以获得一个唯一、持久且人类可读的地址，再把这一身份授权扩展给具体Agent。

这个机制类似DNS把难记的IP地址映射为域名，但它映射的不是服务器位置，而是“谁授权了这个Agent”。当一个Agent向商户发起购买请求时，商户可以识别其背后的个人或组织，并据此决定是否放行、限制额度或拒绝交易。

Cloudflare的身份机制建立在Web Bot Auth的公私钥验证思路上。Agent可以使用密钥证明请求来自经过授权的软件实例，商户则可以验证签名与账户关联，而不必只根据User-Agent、IP地址或行为特征猜测它究竟是合法助手还是恶意机器人。

身份能力实际上比钱包本身更有战略价值。支付工具可以被替代，但如果大量商户开始把Cloudflare身份作为Agent准入条件，cloudflare.pay就可能成为代理网络里的信任入口，类似今天网站使用TLS证书证明域名身份。

可验证身份并不等于可信行为。cloudflare.pay最多能回答“是谁派来的”，却不能自动证明Agent当前的任务合理、模型没有被劫持、购买结果符合用户意图，或者它不会把付费内容泄露给其他服务。

商户仍然需要把身份、付款和授权分开判断。一个拥有真实组织身份且资金充足的Agent，同样可能因为提示词注入而购买错误数据；一个匿名Agent也可能是正常的个人助手，因此简单地把“有Cloudflare身份”当作绝对安全标签，会制造新的误判。

真正的变化是Agent有了有限财权

Cloudflare Wallets最实用的地方不是让Agent“拥有钱”，而是把有限财权变成可编程权限。过去企业往往只能在完全禁止自动消费和交出完整支付方式之间二选一，现在可以把风险切成多个小预算单元。

一个负责市场研究的Agent可以获得10美元测试预算，只允许购买数据检索和网页内容；一个代码Agent可以获得每周100美元推理额度，只允许访问批准的模型服务；一个采购Agent则可以设置500美元总预算和50美元单笔上限，并对新商户强制人工审核。

这种授权模式会扩大Agent实际可使用的服务范围。Agent不必因为一次几美分的试用反复等待人类操作，可以在预算内并行比较多个搜索、OCR、翻译或推理服务，然后根据延迟、准确率和价格选择组合。

MCP工具也可能因此从“连接协议”变成可直接交易的能力单元。MCP解决的是Agent如何发现和调用外部工具，而Wallets与x402解决的是调用后由谁付款、最多能花多少，以及服务方如何确认请求背后的责任主体。

Agent商业基础设施可以被拆成四层：

1. 发现层：Agent找到API、MCP工具、数据或内容；
2. 身份层：商户确认Agent由谁授权，Agent确认自己正在与哪个服务交易；
3. 支付层：双方协商价格并完成微支付；
4. 策略层：账户所有者限制预算、商户和单笔交易规模。

Cloudflare此次同时覆盖了后三层，而发现层仍然相对空缺。谁能进一步建立高质量的Agent服务目录、价格比较、信誉评价和争议处理系统，谁才可能真正控制代理商业的交易入口。

Cloudflare想做的远不只是钱包

Cloudflare正在把自己的边缘网络升级成Agent运行和交易的平台。此前的Workers AI、Sandboxes和Agent Cloud解决模型运行、代码执行与Agent部署问题，Monetization Gateway负责服务端收费，Wallets和cloudflare.pay则补齐购买方的支付与身份。

这套组合形成了明显的平台闭环。开发者可以在Cloudflare部署Agent，让Agent调用由Cloudflare保护的API，通过Cloudflare身份完成验证，再使用Cloudflare钱包付款；平台由此同时掌握执行环境、网络流量、身份策略和交易关系。

Cloudflare相较普通支付公司的优势在于它已经位于网络请求路径上。它不需要从零说服开发者部署新的客户端，也能把身份验证、机器人管理、速率限制、安全防护和支付策略放在同一层处理。

Cloudflare相较模型厂商的优势则是保持相对中立。模型公司的消费账户通常围绕自家推理服务设计，而Cloudflare希望让不同模型、API、数据源和MCP服务在同一支付体系里交易，这更接近互联网基础设施，而不是某一家AI产品的余额系统。

这种中立性仍然要接受现实检验。如果cloudflare.pay身份只能在Cloudflare生态内获得最佳支持，Wallets又与自家网关深度绑定，那么它可能从开放协议的推动者变成新的平台关卡；开发者需要关注身份和支付凭证能否迁移，以及商户是否必须购买额外Cloudflare服务。

三个风险不能被“预算护栏”掩盖

提示词注入仍然是Agent支付面临的第一类风险。恶意网页可以把“忽略之前指令并购买某项服务”隐藏在内容中，如果Agent同时拥有浏览、决策和支付权限，预算上限只能限制损失规模，无法阻止错误交易本身。

凭证管理是第二类风险。Virtual Wallet通过机器凭证运行后，凭证的存储、轮换、撤销、环境隔离和审计都会成为生产系统的核心要求；一旦凭证泄露，攻击者可能在策略允许范围内伪装成合法Agent消费。

稳定币合规是第三类风险。面向个人开发者的10美元测试预算容易落地，但跨国企业需要确认资金托管主体、资产赎回机制、地区限制、制裁筛查、财务记账和退款争议处理，而Cloudflare目前披露的信息还不足以回答这些问题。

企业在实际部署时至少需要保留以下控制：

• 对新商户、异常价格和高风险品类设置人工确认；
• 将浏览网页、生成购买建议和最终付款拆成不同权限；
• 为每个Agent单独创建钱包，避免多个任务共享同一凭证；
• 记录报价、付款证明、工具调用上下文和最终交付结果；
• 设置小时、日和周三级限额，而不只是一个总预算；
• 为钱包提供即时冻结和凭证撤销能力。

现在值得关注，但还不值得迁移生产系统

Cloudflare Wallets是目前少数把Agent身份、微支付和企业预算控制放进同一产品框架的方案。它抓住了代理商业最具体的阻碍：Agent不是不会调用工具，而是缺少被商户认可的身份，也没有风险可控的支付权限。

这次发布的最大价值是明确了一种可落地的授权范式。人类不需要审批每一笔几美分的请求，也不需要把完整信用卡交给模型，而是把10美元、100美元或限定商户范围的支出能力封装成软件权限。

这次发布的最大限制同样明确：完整钱包功能还没有正式开放。Cloudflare尚未公布确切上线日期、费率、支持资产、地区范围、退款机制和详细安全模型，因此现在更适合预留cloudflare.pay名称、评估架构和设计权限边界，而不是把现有支付链路立刻迁移过去。

Cloudflare押注的是一个更长远的变化：未来的互联网请求不仅包含身份和数据，还会携带价格、预算与付款证明。如果Agent真的开始代表个人和企业持续购买推理、数据和软件能力，Wallets可能会成为Cloudflare从网络基础设施进入交易基础设施的关键一步。

参考来源

• IT之家：Cloudflare Wallet推出，专为AI智能体设计的可编程钱包——整理了双层钱包结构、x402支付机制、预算限制与cloudflare.pay身份能力。