作者: Yuki（刘雨晴）Stablehunter/Money in Motion
Cloudflare 发布了一张很漂亮的橙色“卡”。
卡面上写着 “ IDENTITY / ACCOUNT & AGENT”，中间是一个 “cloudflare.pay” 地址。很多人第一眼看到它，都会把它理解成一张给 AI Agent 用的银行卡：以后 Agent 也可以自己花钱了。
准确地说，Cloudflare 现在开放的只是 Wallet Handle 抢注。充值、转账、Virtual Wallet 和授权付款等主要功能，还要等后续上线。
当 AI 从回答问题，走向真正替人执行任务，它迟早会遇到一个很现实的问题：它需要自己购买服务。
一个 research agent 为了完成一份报告，可能需要查询商业数据库、调用搜索 API、购买付费内容，再用另一个模型整理信息。一个 coding agent 可能需要临时购买云资源、测试环境或代码审查工具。每笔钱可能只有几美分，但它不可能每调用一个新服务，都停下来等人注册账号、购买套餐和申请 API key。
所以，Cloudflare Wallet 真正要解决的，不是“怎么让 AI 刷卡”。而是当 Agent 需要花钱完成任务时，谁给它预算，允许它买什么，最多能花多少，以及买错了谁负责。
从这个角度看，Cloudflare 做的也不只是一个稳定币钱包，它正在尝试建立的，是一套给 AI Agent 使用的机器采购制度。
Agent 拿到钱包，第一件事不是逛街
为了完成刚才那份行业报告，research agent 还可能临时运行一次代码，或者调用一个专门生成图表的 MCP tool。
这些服务单次可能只值几美分或几美元。问题是，今天的互联网收费方式仍然是为人设计的：注册账号、验证邮箱、绑定信用卡、选择套餐、申请 API key，然后才开始调用。
人可以忍受这套流程，Agent 很难。它不能为了试用一个 0.03 美元的接口，每次都停下来找人注册一个 SaaS 账号。
所以 Agent 最先需要钱包的场景，很可能不是订酒店、买衣服或点咖啡，而是购买 API、数据、模型、算力和工具。
这是一种新的采购行为。购买者是软件，商品也是软件能力；交易金额很小，却可能高频发生。Agent 在开始任务前，甚至不知道最后会组合哪些服务。
银行卡可以帮助 Agent 进入已经存在的 checkout，但它没有解决开放网络里的“按需采购”：Agent 怎么知道价格，怎么判断自己有没有权限买，付款后又怎么立即获得服务？
Cloudflare Wallet 瞄准的是这个缺口。
给 Agent 10 美元，怎样保证它不乱花？
给 Agent 钱并不难。难的是，怎样让它拥有一定自主权，又不把主账户和无限额度一起交给它。
Cloudflare 设计了两层钱包。
Account Wallet 属于人或组织，负责持有和管理资金。Virtual Wallet 则分配给具体的 Agent，通过 API key 使用。所有者可以为每个 Virtual Wallet 设置 allowance、允许付款的对象和单笔交易上限；遇到异常支出或超过额度，再回到人类审批。
比如，公司可以给 research agent 10 美元，只允许它购买数据和模型调用，单笔不能超过 0.5 美元。开发 Agent 可以有另一笔预算，只能购买测试环境和云资源。营销 Agent 则拥有不同的工具白名单。
这和直接把一张通用信用卡交给 Agent，是两种不同的授权方式。
信用卡主要证明“这个凭证可以付款”。Virtual Wallet 还要表达：是谁在花、代表谁花、最多花多少、可以向谁花，以及什么时候必须回来问人。
从这个角度看，Cloudflare Wallet 不只是一个稳定币钱包。它更像企业卡、费用管理、IAM 和采购审批的结合，只是管理对象从员工和部门，扩展到了软件 Agent。
它正在尝试建立的，是一套机器采购制度。
而额度和白名单也不只是限制。恰恰因为最坏损失被提前限定，人才能允许 Agent 在边界内自主试错。如果每一笔几美分的调用都要人确认，Agent 就没有真正的执行能力。
x402 解决的，是购买动作如何嵌进任务
钱包里有钱，还需要一种机器能够理解的付款方式。
Cloudflare Wallet 计划首先通过稳定币和 x402 支付。x402 把付款要求放进普通 HTTP 请求：Agent 请求一个资源，服务方返回 402 Payment Required，告诉它价格、接受的资产和付款方式；Agent 判断是否符合预算和权限，完成支付，再次请求并获得资源。
过去的流程是：先注册、买套餐、拿 API key，再使用服务。
x402 想变成：请求服务、看到价格、付款、立即获得结果。
这也是稳定币在这里的实际作用。它不是为了让 Agent 炒币，而是为几美分甚至更小的数字服务提供机器可调用、快速结算的支付方式。对于已经有商户、订单和争议处理体系的消费场景，卡网络仍然有优势；但对于低金额、高频率、即时交付的 API 和数据调用，账户加稳定币的组合更自然。
因此，Agentic Payment 的第一批真实需求，可能不是消费者把购物交给 AI，而是企业把一部分数字服务采购交给 AI。
Cloudflare 想拿到的，不只是钱包入口
单独看 Wallet，它只是一个买方工具。把它和 Cloudflare 7 月公布的 Monetization Gateway 放在一起，公司的意图会更清楚。
Monetization Gateway 面向卖方。网站、API、数据集和 MCP tool 的提供者，可以设置哪些请求需要付费、价格是多少，并让 Cloudflare 在请求到达源站前完成付款验证和访问控制。
Wallet 面向买方，Account Wallet 提供资金，Virtual Wallet 给 Agent 预算和权限。Agent 收到 402 后，在规则允许时完成付款。
一边帮助互联网资源按次收费，一边帮助 Agent 按次购买；再叠加 Cloudflare 已有的 Agents SDK、Workers、Web Bot Auth、Bot Management 和全球网络。Cloudflare 想连接的是一条完整交易链：
- 谁在请求；
- 它代表哪个人或组织；
- 是否有权访问；
- 这个资源多少钱；
- Agent 是否有预算付款；
- 付款之后能否立即放行；
- 整个过程如何留下记录。
过去 Cloudflare 站在互联网流量中间，判断一个请求应该被加速、放行还是拦截。现在它希望进一步判断：这个请求要不要付钱、应该付多少，以及付款以后能不能获得服务。
这才是 Cloudflare Wallet 更大的商业意义。它不是孤立的钱包产品，而是 Cloudflare 把互联网请求变成交易的一块拼图。
“cloudflare.pay”也属于这套结构。未来，一个组织可以拥有类似 “example.cloudflare.pay” 的账户，它的 research agent 可以使用 “research.example.cloudflare.pay”。这个可读名称会和 Agent 的密钥身份关联，让商户不只看到一个临时钱包地址，还能知道这个 Agent 声称代表谁。
这并不等于完整的 KYA，也不能自动证明 Agent 值得信任。但支付只能证明钱到了，商业关系还需要身份、授权和责任。
钱可以过去，不代表这笔购买是对的
这次发布也需要踩一下刹车。
目前，Cloudflare Wallet 真正开放的是 Wallet Handle 抢注。Account Wallet、Virtual Wallet、稳定币存储、出入金和各类 guardrails 仍是计划中的功能。Monetization Gateway 也还在 waitlist 阶段。
Cloudflare 尚未在公告里完整说明正式上线时间、费用、支持地区、托管安排、KYC/KYB、密钥恢复、退款争议和风控责任。Virtual Wallet 通过 API key 操作，也意味着凭证安全、prompt injection 和 Agent 运行环境被攻击的问题仍然存在。
更重要的是，x402 可以证明一笔付款发生了，却不能证明 Agent 买对了东西。
如果数据质量很差，API 返回了错误结果，Agent 因为模型判断失误购买了不必要的服务，或者攻击者诱导它连续调用付费接口，责任应该由谁承担？稳定币交易缺少卡支付熟悉的 chargeback 机制，低摩擦也意味着出错后更难撤回。
一套 Agent 支付基础设施是否成立，最终还要看三件事：是否有足够多的优质服务愿意按请求出售；是否有 Agent 持续产生真实付费需求；以及当误付、欺诈和服务未交付发生时，平台能否给出清楚的责任和处理机制。
所以，现在还不能说 Cloudflare 已经给 Agent 发了一张可以到处使用的卡。它正在尝试建立一个账户系统：人提供资金和规则，Agent 在边界内自主采购，商户根据身份与付款决定是否交付服务。
过去大家讨论 Agentic Payment，注意力主要放在钱能不能实时过去。Cloudflare Wallet 提醒我们，下一道更难的问题已经出现：谁允许 Agent 花钱，如何限制它，又怎样为它的购买负责。
未来真正决定 Agent 能不能进入商业世界的，不是那张漂亮的橙色卡面，而是卡背后的预算、权限和责任。
