Cloudflare Wallets 是 Cloudflare 为 AI Agent 设计的可编程钱包与委托支付系统：人类控制主账户资金，再给不同 Agent 分配受限的 Virtual Wallet，让它们按规则购买 API、MCP 工具或数字内容。需要先说明的是，截至 2026 年 8 月 5 日，用户已经可以领取 cloudflare.pay 钱包标识，但充值、稳定币存储、Virtual Wallet 和自动支付等核心能力仍以“即将支持”或规划状态为主，并非完整产品已经普遍开放。
先看当前状态
Cloudflare 的公告混合了“今天可以做的事”和“未来将提供的能力”。如果只看产品愿景，很容易误以为钱包已经能够充值并让 Agent 自动消费。按官方原文的时态拆分，当前状态更接近下面这张表。
| 能力 | 截至核验时的状态 | 应如何理解 |
|---|---|---|
| 领取 Wallet handle | 已经开放 | Cloudflare 账户可以在 cloudflare.pay 领取唯一、可读的标识 |
| 存储稳定币与收付款 | 即将支持 | 公告没有给出全面开放日期、全部资产和网络清单 |
| 创建 Virtual Wallet | 即将支持 | 规划用于给 Agent 分配资金和 API 访问凭据 |
| 额度、白名单、单笔上限 | 规划能力 | 用于限制 Agent 能花多少、向谁付款以及单次风险 |
| 法币出入金 | 分地区推进 | 支持地域、资格和具体方式仍需等待正式说明 |
所以，现阶段最稳妥的动作是先领取自己需要的 handle，并把 Wallets 当作 Cloudflare 正在建设的 Agent 支付基础设施来观察，而不是把它当成已经成熟的钱包服务迁移资金。
两类钱包分工
Cloudflare 把资金所有权和 Agent 的执行权限拆成两层。Account Wallet 面向 Cloudflare 账户的所有者和用户，由人类充值、提取资金，并决定向哪些 Virtual Wallet 分配预算；Virtual Wallet 面向软件 Agent，通过 API key 操作，只能在账户所有者设定的范围内消费。
这种设计的重点不是让模型直接掌握主钱包，而是把“可以做什么”和“最多损失多少”写成预先授权。一个研究 Agent 可以获得小额试用 API 的预算，内容审核 Agent 可以只访问许可商户，生产环境 Agent 还可以设置更低的单笔上限。超出限制时，官方规划由 Agent 请求具备权限的人类进行一次性批准或调整额度。
委托不等于放权
Virtual Wallet 的价值来自可控自治。Cloudflare 提到的三类 guardrail 分别对应不同风险：allowance 限制一段时间内可用的总额，allow list 限定可交易对象，maximum transaction size 限制单笔金额。三者组合后，人类不必逐笔点击确认，又能把错误调用、提示注入或异常循环造成的损失控制在预设范围内。
但钱包上限不是完整的安全方案。开发者仍要限制工具权限、验证商户与响应、记录支付回执，并为高风险操作保留人工确认。尤其当 Agent 能自行发现新服务时，“允许尝试很多 API”也意味着它会接触更多不熟悉的端点，资金限制只能控制金额，不能自动证明服务可信或返回内容安全。
x402 怎么付款
Wallets 公告主要围绕 x402 展开。x402 利用 HTTP 402 Payment Required，把价格、付款和访问凭证放进普通请求与响应，不要求 Agent 先走登录页、绑定银行卡再复制 API key。典型链路是：
- Agent 请求一个收费的 API、MCP 工具或内容资源。
- 服务端返回 HTTP 402，并说明金额、接受的资产、网络和收款地址。
- 客户端钱包按 Virtual Wallet 的策略检查预算与权限，满足条件后生成付款凭证。
- Agent 带着付款凭证重试原请求；服务端或 facilitator 验证并结算。
- 验证成功后，服务端返回资源和支付回执。
Cloudflare Agents SDK 已经支持 x402 服务端与客户端集成，也支持另一套基于 HTTP 402 的 Machine Payments Protocol（MPP）。但 Wallets 这次公告明确描述的是稳定币与 x402 兼容端点，不能据此推断 Cloudflare Wallets 已经支持 Agents SDK 中的全部支付方式。
买卖两侧拼图
Wallets 解决买方问题：Agent 如何持有受限预算并完成无界面支付。Cloudflare 早前公布的 Monetization Gateway 则解决卖方问题：网站、数据集、API 或 MCP 工具如何在 Cloudflare 边缘按照规则返回 402、验证付款并放行请求。两者合在一起，才构成 Cloudflare 所说的双边 Agent 市场。
- 买方：Account Wallet 提供资金，Virtual Wallet 提供受限执行权限。
- 协议：x402 把报价、付款凭证和回执装进 HTTP 往返。
- 卖方：Monetization Gateway 计划在边缘执行计价、验证和访问控制。
- 身份：
cloudflare.payhandle 让 Agent 可以选择声明一个稳定、可读的来源标识。
这也解释了 Wallet handle 为什么不只是收款地址。Cloudflare 希望把它作为密钥对的可读别名，类似 DNS 用域名映射难记的 IP。商户可以据此区分已声明来源的 Agent 与匿名调用者，但声明身份是可选的，商户是否给予优先级或优惠仍由商户决定。
它解决了什么
传统 API onboarding 针对人类设计：注册账号、验证邮箱、添加付款方式、创建 API key，再把凭据交给 Agent。这个流程既阻碍自动探索，也迫使人类提前为大量可能不会继续使用的服务建账户。Wallets 与 x402 的目标，是让 Agent 用几美分测试多个接口，比较质量后再选择长期服务。
这对研究、数据采购、模型推理、临时 MCP 工具调用和按篇内容访问尤其有吸引力。它不是为了让 Agent 随意购买高价商品，而是优先解决大量低金额、高频率、按请求计价的机器交易。Cloudflare 的构想是：给研究 Agent 10 美元预算，可能比把 1000 美元主钱包交给它更自由，因为风险边界足够明确，人类无需盯住每一次调用。
落地仍有门槛
这套方案值得关注，但现在还不能只看演示界面判断成熟度。正式用于生产前，至少需要确认以下问题：
- 开放范围：哪些国家或地区可以开户、充值、提取和兑换法币。
- 资产与网络：支持哪些稳定币、链和结算方式，费用与到账时间如何计算。
- 托管与恢复：密钥由谁保管，API key 泄露、账户恢复和权限撤销如何处理。
- 策略粒度：额度按日、周还是任务计算，白名单能否绑定域名、钱包或具体接口。
- 商户覆盖：只有足够多的 x402 端点接入后，Agent 自动比较服务才有实际价值。
- 会计与合规：企业如何获取可审计记录，并处理稳定币、税务和跨境支付要求。
Cloudflare 近期还推出了面向 Agent 临时部署 Workers 的 Temporary Accounts。前者减少部署环节的人类登录依赖，Wallets 则试图减少注册和付款依赖，可以结合阅读 Cloudflare Temporary Accounts 是什么，理解 Cloudflare 如何逐步补齐 Agent 的身份、运行和交易基础设施。
谁值得关注
API、数据、内容或 MCP 工具的提供者，应关注 Monetization Gateway 与 x402 能否带来真正的按次收入；构建自主 Agent 的开发者，应关注 Virtual Wallet 的策略 API、回执和人机审批流程；企业安全与财务团队，则要重点评估地域、托管、审计和稳定币合规。普通用户目前没有必要把它当成日常消费钱包，但如果希望保留理想的公开标识，可以先领取 handle。
信息边界：本文核验于 2026-08-05。Cloudflare Wallets 公告发布于 2026-08-04，当前可确认的是 handle 领取入口；正文提到的充值、稳定币存储、Virtual Wallet、支出策略和法币出入金均按官方的未来时态表述。开放日期、支持地域、资产、费用和完整 API 仍可能变化。
官方资料：
Cloudflare Wallets 公告：https://blog.cloudflare.com/wallets/
Cloudflare Agentic Payments 文档：https://developers.cloudflare.com/agents/tools/payments/
Monetization Gateway 公告：https://blog.cloudflare.com/monetization-gateway/
x402 文档：https://docs.x402.org/introduction
© 版权声明
本站部分内容源于网络收集，文章等版权归原作者所有，若需删稿请联系管理员邮箱：satomini@warpnav.com
相关文章
暂无评论...
