8 月 4 日，Cloudflare 在 Agent Week 上推出 Cloudflare Wallets：给 AI Agent 一个可编程钱包和一个稳定身份，让它能无需人工逐笔审批地支付 API 调用、数据购买与 MCP 工具费用。底层是 x402 协议——HTTP 状态码 402「Payment Required」在规范里空置 35 年后被 Coinbase 复活成支付标准，Cloudflare、Stripe、Visa、Mastercard、Google、AWS 都是 x402 Foundation 成员。
💳 本教程适合：跑过 Agent 工作流、正在为「付费 API / 付费数据 / 付费工具」而手动付款或借服务账号的人。我们讲清钱包结构、三层护栏与信任风险，让你安全地放开 Agent 的「手」。
先搞懂：Agent 为什么要「自己的钱包」
过去 Agent 调用付费服务，要么用你的信用卡手动付，要么借用服务账号凭证——前者打断自动化，后者在审计里不可见。Wallets 想解决的是「小额高频 + 无需人肉审批 + 可审计」三角：
| 问题 | 传统做法 | Wallets 方案 |
|---|---|---|
| 逐笔付款 | 人工确认，打断流程 | Agent 自动付，人只设边界 |
| 身份不可见 | 借服务账号，审计黑洞 | 可读 handle，每笔可归属 |
| 小额支付成本高 | 卡手续费 2%-4% | USDC 链上结算，单笔约 0.0001 美元 |
| 失控风险 | 要么全开要么全关 | 三层护栏 + 超限人工 override |
先记住一句话：Agent 支付基础设施已经就位，但「信任层」还没有——USDC 转账不可逆，给 Agent 发钱包之前，先学会设预算。
Step 1：双层钱包结构——钱归人管，Agent 只拿「零花钱」
1 Account Wallet 与 Virtual Wallet 的分工
Cloudflare Wallets 是双层设计：
Account Wallet（账户钱包）
· 归属：人类 / 组织
· 职责：充钱、提现、完全控制
· Agent 永远接触不到它
Virtual Wallet（虚拟钱包）
· 归属：每个 Agent 一个
· 寻址：API Key
· 边界：由账户持有人设定
· 权限：被三层护栏包裹
关键设计：
· Agent 想超限 → 必须请求
账户钱包上的人类授权
· Agent 不能给自己提额
（不能批准自己的升级）
这就是「控制」与「建议」的
分水岭——很多厂商会只做
一个软提示，Cloudflare
做成了硬约束💡 动手前先画一张图：你的 Agent 体系里有哪些「会花钱的 Agent」？每个 Agent 单独开 Virtual Wallet，别共享——出事时才能精准止血。
Step 2：三层护栏怎么设——额度、白名单、单笔上限
2 给每个 Agent 定死消费边界
每个 Virtual Wallet 有三个可配置上限：
护栏一：消费额度（Spending Cap）
· 总额或周期额度
（如「每天最多 50 USDC」）
· 决定 Agent 的总预算盘子
护栏二：商户白名单
（Approved Merchant Allowlist）
· 只允许向指定收款方付款
· 白名单外的商家直接拒绝
· 防「prompt injection 骗付」
护栏三：单笔上限
（Maximum Transaction Size）
· 任何一笔支付的天花板
· 防止异常放大损失
配置建议（从紧到松）：
· 先按「最小可行额度」设
· 白名单只加确实要用的服务
· 单笔上限取「正常单笔 × 2」
留出合理余量
· 跑一周后根据实际账单
再微调护栏不是摆设：x402 生态里已有 48 万+ Agent 在跑、平均单笔约 30 美分，其中 25%-30% 的交易可能是「刷榜单」而非真实需求——护栏是唯一能挡住这类浪费的机制。
Step 3：超限怎么办——人工 override 与可读身份 handle
3 失控时，人永远在最后一关
超限流程：
1. Agent 触达任一护栏上限
2. 支付被拒绝
3. Agent 向账户钱包的
授权人类发起 override 请求
4. 人类批准 → 放行
人类拒绝 → 维持拒绝
注意：Agent 不能自我升级。
这是「权限最小化」的
落地形态——参考
《Agent 安全》
《预算护栏》
的做法。
可读身份（handle）：
· Agent 可认领人类可读的
地址，如
research.yourcompany.
cloudflare.pay
· 商家端可归属每笔购买
· 解决「借用服务账号 → 审计
黑洞」的老问题
实践建议：
· 每个 Agent 一个独立 handle
· handle 命名体现用途与归属
（team / 用途 / 环境）
· 把 handle 写进你的
Agent 资产清单💡 handle 的长期价值是「声誉」：稳定的 handle 会积累行为记录，商家会开始区分「欢迎的 Agent」与「可疑的 Agent」——把它当域名一样维护。
Step 4：钱怎么流动——USDC、Base 链与「不可逆」的代价
4 读懂支付轨道，才算真正会用它
x402 支付链路：
请求方（Agent）
│ 请求付费资源
▼
服务方（商家）
│ 返回 HTTP 402
│ + 机器可读支付条款
▼
Agent
│ 用 USDC 支付（Base 链）
│ 附上收据头重试请求
▼
商家 → 交付资源
结算参数：
· 货币：USDC 稳定币
· 链：Base（Coinbase L2）
· 手续费：单笔约 0.0001 美元
· 到账：2-4 秒
· 商家可代付 gas，
Agent 无需持有加密货币
对比卡网络：
· 卡：2%-4% 手续费 + 可退款
+ 争议处理，适合大额消费
（旅行、餐饮等）
· x402：近乎零手续费，
秒级结算，但转账不可逆
Mastercard 在走另一条路：
· Agent Pay for Machines
· Verifiable Vouchers（可验证
凭证）：先定规则后付款，
凭证可捆绑批量结算不可逆 = 最后防线：USDC 转出去就没有「撤销」按钮。把「护栏 + 白名单 + 单笔上限」三件套配齐之前，不要放真钱进去。
Step 5：配 Kitesurf 让 Agent「边逛边买」——场景清单
5 钱包 + 浏览器 = Agent 自主采购
Cloudflare 8 月 6 日发布 Kitesurf
（Agent 专用浏览器），与 Wallets
组合后 Agent 可以：
· 浏览开放网络
· 找到要买的东西
· 直接付款
（无结账页、无预存卡、无
人工点批准）
适合先落地的场景：
1. 付费 API 额度自动续
· 监控用量，额度不足时
自动购买补充包
2. 数据源订阅
· 定时抓取付费数据源
· 预算内自动续费
3. MCP 工具按次计费
· 单次调用按 x402 结算
4. 内容/报告购买
· 深度调研需要付费报告时
自动购买（白名单内）
不适合的场景：
· 高金额消费（旅行/采购）
· 需要退款/争议的服务
· 决策影响重大的购买
——这类走人工 + 卡支付
参考
《Kitesurf 云端浏览器》
了解 Agent 浏览器的边界💡 落地顺序建议：先挑一个「小额、高频、白名单内」的场景试点（如 API 额度自动续），跑通后再扩场景；每次扩场景都重审护栏。
Step 6：信任风险自查——VISA 指出的四大坑
6 支付基础设施有了，信任层还没有
VISA 与行业共识的四大风险：
1. 误购
· Agent 误解指令买错服务
· 即使支付成功，结果也是
错的
2. 恶意攻击
· prompt injection 诱导
超支 / 向攻击者付款
· 白名单是第一道闸
3. 权责模糊
· 买错了谁买单？
· 争议找谁？退款流程？
· 企业内部要提前指定
「Agent 退款责任人」
4. 合规与审计
· 每笔付款可追溯吗？
· handle 是否能对账到
具体业务？
自查清单（上线前打勾）：
□ 每个 Agent 有独立钱包与护栏
□ 白名单只含必要服务商
□ 单笔上限符合业务正常值
□ 指定了退款/争议责任人
□ 支付日志可审计可对账
□ 应急预案：钱包冻结流程
与
《分层路由降本》
《Agent 经济学》
配合，把「花钱」纳入
成本治理体系给 Agent 发钱包前，先答四问：谁授权？钱是谁的？买错了谁负责？商家怎么验证 Agent 身份？——答不全，就先别开放自主支付。
常见问题速查
| 你遇到的现象 | 大概率原因 & 解决 |
|---|---|
| Agent 付款被拒 | 触达护栏上限：检查额度/白名单/单笔上限，确需放行时走人工 override |
| 担心 Agent 被骗付 | 白名单收窄 + 单笔上限收紧：只留必要服务商，小额高频起步 |
| 付款了但没拿到资源 | 确认商家交付链路：x402 有 escrow 机制（款项锁定至交付），优先选支持 escrow 的商家 |
| 不想用加密支付 | 可等卡网络方案（Mastercard Verifiable Vouchers / Visa Agent 支付实验），或混合：小额走 x402、大额走卡 |
| 审计要求高 | 用可读 handle + 支付日志归档：把每笔消费映射回具体 Agent 与业务任务 |