关键词：Cloudflare Wallet / x402 / HTTP 402 / Agentic Payments / AI Agent / MCP / 多模型路由

最近，

Cloudflare Wallet 的 handle 认领突然火了。

但如果只是把它理解成“抢一个好看的钱包 ID”，

就会错过这件事对 AI 工程真正重要的部分。

先说结论：
Cloudflare Wallet 真正值得开发者关注的，不是“AI 终于有钱包了”，而是 AI Agent 的基础设施开始补上此前最缺的一层：可编程支付能力。

模型负责推理，Agent 负责规划，工具负责执行，而支付层开始负责让 Agent 在明确预算和权限边界内，真正完成交易闭环。

配图：Cloudflare Wallet 视觉素材

一、先把热点讲准确：现在开放的是 handle，完整钱包能力仍在逐步开放

2026 年 8 月 4 日，

Cloudflare 正式公布 Cloudflare Wallets。

当前用户可以先认领 Cloudflare Wallet handle，

而真正的资金存取、服务购买和 Virtual Wallet 等能力，

官方表述仍是后续逐步开放。

这点非常重要。
目前“抢到一个 handle” ≠ “已经可以让 AI 自动刷钱包”。
开发者写文章、做视频时，最好不要把“未来能力”写成“当前已经全面可用”。

Cloudflare 的设计里，

钱包会分成两层：

Account Wallet
面向账户所有者，也就是人。
负责充值、提现，以及向 Agent 分配可使用额度。

Virtual Wallet
面向 AI Agent。
Agent 可以在被授权的范围里购买 API、MCP Tool、数据、内容等资源。

更关键的是，

Virtual Wallet 并不是“把钱交给模型随便花”。

Cloudflare 给出的控制项包括：

• Allowance：总额度 / 周期额度；
• Allow list：允许消费的商家或服务；
• Maximum transaction size：单笔最大金额。

这意味着支付开始被抽象成一个可以执行策略的系统能力。

二、真正的技术核心不是 Wallet，而是 HTTP 402 上面的机器支付协议

以前 AI 调用一个付费服务，

经常会卡在“人类专属流程”上：

搜索服务
  ↓
打开官网
  ↓
注册账号
  ↓
绑定支付方式
  ↓
生成 API Key
  ↓
复制 API Key
  ↓
AI 才能继续调用

这套流程本质上是为人设计的。

对 Agent 来说，

它非常不“机器原生”。

x402 的思路是：

把“付款要求”直接放回 HTTP 请求 / 响应链路。

ERROR CODE → PAYMENT CHALLENGE

HTTP/1.1 402 Payment Required

在 Cloudflare 当前的 x402 文档中，

一个典型流程可以抽象为：

Step 1：客户端请求资源。

Step 2：服务端返回 402，并附带价格、币种、网络、商家地址等支付要求。

Step 3：客户端生成并签名支付载荷。

Step 4：客户端携带支付签名重新请求。

Step 5：服务端验证并结算后返回资源和收据。

GET /premium-data HTTP/1.1
Host: api.example.com

HTTP/1.1 402 Payment Required
PAYMENT-REQUIRED: <base64 payment challenge>

GET /premium-data HTTP/1.1
Host: api.example.com
PAYMENT-SIGNATURE: <signed payment payload>

HTTP/1.1 200 OK
PAYMENT-RESPONSE: <settlement receipt>

注意，

x402 并不是“1999 年发明的支付协议”。

老的是 HTTP 402 这个状态码。

x402 是围绕 402 构建的现代机器支付标准。

三、2026 年再看 Agentic Payments，x402 已经不是唯一选项

这是现在很多热点内容容易漏掉的一点。

Cloudflare 最新的 Agents SDK 文档里，

Agentic Payments 已经同时列出两套协议：

• x402：围绕 HTTP 402，当前重点是稳定币和链上结算；
• MPP（Machine Payments Protocol）：同样基于 402，可支持银行卡等传统支付方式和稳定币。

更有意思的是，

Cloudflare 文档明确写到 MPP 对 x402 具备兼容性。

这说明一个趋势：
“Agent 如何付款”未来大概率不会只绑定某一种结算网络。
真正稳定的抽象应该是：Payment Challenge → Policy Check → Credential → Verification → Receipt。

四、AI Agent 的完整技术栈，正在从“三层”变成“五层”

过去我们做 AI 产品，

经常只讨论模型层。

但真正能执行复杂任务的 Agent，至少需要五层。

User Goal
  ↓
① Agent / Planner：任务拆解、决策
  ↓
② Model Router：选择文本 / 图像 / 视频 / 推理模型
  ↓
③ Tool Layer：API / MCP / Browser / Search / Code
  ↓
④ Payment Layer：Wallet / x402 / MPP / Budget Policy
  ↓
⑤ Observability：日志、成本、权限、审计、回滚

这里最容易被低估的是第四层和第五层。

因为一旦 Agent 可以花钱，

“错误调用”就不再只是多消耗几个 token，而可能变成真实财务损失。

五、支付能力一旦进入 Agent，工程重点会从“能不能调用”转向“能不能安全地调用”

一个生产级 Agent，

不应该直接拿着一个无限权限的钱包私钥到处请求。

更合理的架构是把“决策权”和“付款权”拆开。

Agent
  │
  ├─ 选择服务
  │
  ├─ 评估价格 / 质量 / SLA
  │
  ▼
Payment Policy Engine
  │
  ├─ 是否在白名单？
  ├─ 单笔是否超限？
  ├─ 今日预算是否超限？
  ├─ 是否属于高风险操作？
  └─ 是否需要 Human-in-the-loop？
  │
  ▼
Wallet / Payment Signer
  │
  ▼
x402 / MPP Endpoint

从工程角度看，

至少要考虑下面这些问题：

• 支付请求是否具备幂等性；
• 签名是否可能被重放；
• 超时重试会不会造成重复扣费；
• 工具返回错误后是否自动退款或补偿；
• Agent 是否能绕过预算策略；
• 支付凭证是否和模型上下文隔离；
• 每笔消费能否关联到具体任务、模型和用户。

一个很重要的安全原则：
不要让大模型“拥有”密钥。
应该让大模型提出支付意图，再由受控的 Policy Engine 和 Signer 完成付款。

六、为什么这件事会反过来放大“多模型聚合”的价值？

因为 Agent 一旦能够自主购买服务，

它面对的就不再是“固定调用一个模型”。

而是“在一个动态能力市场里挑选最合适的模型、工具和服务”。

举个简单例子。

同一个内容生产任务，

可能需要：

• 推理模型：拆脚本、做规划；
• 文本模型：写旁白和对白；
• 图像模型：做角色设定和关键帧；
• 视频模型：生成镜头；
• 语音模型：配音；
• 外部 API：搜索、数据、素材或其他能力。

这时最麻烦的往往不是“有没有模型”，

而是不同模型的接口、鉴权、参数、价格和能力差异。

这也是多模型平台存在的工程价值：
把大量模型和能力先做统一接入、统一选择和统一工作流编排，降低 Agent 在不同供应商之间切换时的“适配税”。

我们自己的平台目前聚合了 500+ AI 模型，

同时提供智能体、无限画布、AI 漫剧、AI PPT 等能力。

它解决的是“模型和创作能力的聚合与编排”。

Cloudflare Wallet / x402 解决的则是另一层——机器支付和结算。

这里需要明确：
本文并不声称该平台已经接入 Cloudflare Wallet、x402 或 MPP。
更准确的理解是：多模型聚合属于“能力层”，Agentic Payments 属于“支付层”。
未来两层如果打通，Agent 才可能真正做到“自动选能力 → 自动判断成本 → 自动购买 → 自动完成任务”。

平台地址： https://api.tiantoken.com/

配图：Cloudflare Wallet handle 视觉示意

七、开发者现在应该提前补的，不是“抢 ID”，而是这 6 个工程能力

01｜统一模型路由
不要把 Agent 和某一个模型厂商写死。把模型能力抽象成可替换 provider。

02｜工具调用层
把 API、MCP、Browser、Search、Code Execution 统一放到 Tool Registry。

03｜预算策略
给不同用户、任务、Agent、服务定义消费上限和白名单。

04｜支付签名隔离
Agent 只能提出支付意图，不能直接接触长期密钥。

05｜可观测性
每一次模型调用、工具调用和付款，都必须能追溯到任务 ID。

06｜Human-in-the-loop
超过金额、命中特定商家、执行高风险动作时，自动切人工审批。

八、别再只把 402 当错误码：未来它可能是一个“业务分支”

对传统 HTTP 客户端来说，

4xx 通常意味着请求失败。

但对支持 Agentic Payments 的客户端来说，402 可能意味着：继续执行支付流程。

401 Unauthorized
→ 缺少身份凭证，先认证

403 Forbidden
→ 已认证，但权限策略拒绝

402 Payment Required
→ 资源可访问，但需要先完成支付挑战

429 Too Many Requests
→ 触发限流，退避重试或切换 Provider

5xx
→ 服务端故障，熔断 / 降级 / 切换服务

这其实是一个很有意思的变化：

HTTP 状态码开始直接参与 Agent 的任务规划。

九、一个更接近生产环境的 Agent 付款伪代码

async function callResource(url, taskContext) {
  let res = await fetch(url);

  if (res.status !== 402) {
    return res;
  }

  const challenge = parsePaymentChallenge(res);

  // 1. 先做策略检查，而不是直接付款
  const decision = await policyEngine.evaluate({
    userId: taskContext.userId,
    agentId: taskContext.agentId,
    merchant: challenge.merchant,
    amount: challenge.amount,
    resource: url
  });

  if (!decision.allowed) {
    throw new Error("PAYMENT_POLICY_DENIED");
  }

  // 2. 超过阈值时进入人工审批
  if (decision.requireHumanApproval) {
    await requestApproval(decision);
  }

  // 3. Signer 与模型上下文隔离
  const credential = await paymentSigner.sign(challenge);

  // 4. 携带支付凭证重试
  res = await fetch(url, {
    headers: {
      "PAYMENT-SIGNATURE": credential
    }
  });

  // 5. 记录任务、成本、收据
  await auditLog.write({
    taskId: taskContext.taskId,
    merchant: challenge.merchant,
    amount: challenge.amount,
    receipt: res.headers.get("PAYMENT-RESPONSE")
  });

  return res;
}

这段代码最重要的不是语法。

而是架构边界：LLM 不碰钱包密钥，Policy Engine 决定能不能花，Signer 只负责签名，Audit Log 负责追责。

十、最后：AI 真正“毕业”的标准，可能不是智商，而是闭环

今天的大模型已经能写代码、生成图片、做视频、分析文件。

但很多时候，

它仍然停在“建议你下一步怎么做”。

Agentic Payments 让这条链路又向前走了一步。

真正成熟的 AI Agent，
不只是会思考。
它还要会调用、会选择、会付费，
并且所有动作都发生在可审计、可撤销、可限制的权限边界里。

所以 Cloudflare Wallet 这波热点，

最值得开发者关注的并不是某个好看的 handle。

而是互联网正在第一次认真为“非人类消费者”重新设计支付、身份和资源购买协议。

当模型层、工具层、编排层、支付层和审计层真正接起来，

AI 才会从“聊天产品”进一步变成“可执行的数字代理”。

---

参考资料

1. Cloudflare Blog：Announcing Cloudflare Wallets: the programmable wallet for the agentic Internet

2. Cloudflare Agents Docs：x402

3. Cloudflare Agents Docs：Agentic Payments

注：Cloudflare Wallet 及相关 Agentic Payments 能力仍处于快速迭代阶段，具体开放范围、协议字段和 SDK 行为请以官方最新文档为准。