Cloudflare Wallets NEW

Cloudflare Wallets是什么？

Cloudflare Wallets 是 Cloudflare 在 2026 年 8 月 4 日官宣的「智能体互联网可编程钱包」。它要解决的问题很具体：今天一个 AI Agent 想试用新 API，得先过一遍为人类设计的登录注册页，找人来绑支付方式，再生成 API key，最后才轮到调用。Agent 缺的其实是两样东西——一个稳定的身份标识，和一种原生的付款方式。缺了这两样，Agent 往往干脆放弃，把注册、付款和取 key 全甩回给人，也就谈不上自己去比较几十个 API。

Cloudflare 的解法是把钱包拆成两层。Account Wallet 是给人用的账户钱包，可以充值稳定币、向下授信、按需取回；Virtual Wallet 是给 Agent 的虚拟钱包，通过 API key 运作，能花多少由账户钱包封顶。再配合 x402 协议把支付直接附加在 HTTP 请求上，Agent 就能按次为 API、MCP 工具和内容付费，不用先注册账号。

有一点必须讲清楚：按官方博客的措辞，「从今天起」能做的是在 cloudflare.pay 申领一个 Wallet handle，而「设置并使用钱包为 API 和内容付费」用的是 soon。现在你能拿到的是身份，钱还付不了。

核心功能

• Account Wallet：人类持有，存入稳定币、把消费权委派给虚拟钱包、随时取回资金。
• Virtual Wallet：Agent 专用，凭 API key 在权限内花钱，上限由账户钱包设定。
• 支出护栏：官方点名的三件套是额度（allowance）、允许列表（allow list）、单笔最大交易额。
• x402 微支付：支付直接挂在 HTTP 请求上，可为推理、数据、内容按次结算；卖方侧对接 Monetization Gateway，构成双边市场。
• 可读身份 handle：cloudflare.pay 下形如 research.example.cloudflare.pay 的标识，让商家知道这个 Agent 代表哪个组织，是否声明完全由你决定。
• 异常复核与提额：出现异常快速消费时交由人工确认，确认是有意为之可提额或一次性注资，否则策略照常拦截。

值不值得用？

先把定位摆正：它现在不是一个「能跑起来」的产品，而是一层正在铺的基建。值得肯定的有两点。第一，人机分权这套设计是对的——把「人管钱包、Agent 管花钱」分开，再用额度、允许列表和单笔上限收口，比给 Agent 塞一张信用卡靠谱得多。官方那句话说得很在理：如果一个 Agent 只对 10 美元负责，你对它的容忍度自然比 1000 美元高；而试一次 API 只要几分钱时，10 美元足够它把一堆方案都摸一遍。约束反而换来了自由度。第二，钱包必须和卖方侧连起来才有意义，Cloudflare 手上有 Monetization Gateway，这是它比单点创业公司更有底气的地方。

不看好的部分也直说：费率没公布，出入金只在支持的地区开放，稳定币自充仅面向符合条件用户，支付能力的上线时间没有承诺。如果你要的是「这个月就能把 Agent 付费搬进生产系统」，它给不了答案。

使用建议

• 先去 cloudflare.pay 把 handle 占下来。身份类资源先到先得，成本几乎为零。
• 已经在用 Cloudflare Agents SDK 的团队，可以先照 x402 开发者文档把「付费端点」这条链路在测试环境跑通，等钱包开放再接真金。
• 提前设计护栏粒度。官方举的例子是「每位员工每周 100 美元推理预算」，这种额度模型最好在接入前就想好，别等上线再补。
• 别只盯买方。Monetization Gateway 是同一套基建的卖方侧，只看钱包会漏掉一半价值。

适合谁用？

推荐：正在做 Agent 商务、需要让 Agent 自主试用并支付 API 的开发者与平台团队，尤其是已经在 Cloudflare 生态里的团队。 可考虑：关注 x402 与 Agent 身份标准演进的技术决策者，先申领 handle、观察后续放量。 不推荐：现在就需要可用支付能力的业务，以及所在地区尚未开放出入金的用户——等它从 soon 变成 today 再动手。