AI Agent 正从“调用工具”走向“独立完成交易”。Cloudflare Wallets 面向这一变化，为 Agent 提供原生支付能力与可验证身份，并通过 x402 协议支持按需购买 API 和内容。真正值得关注的不是 Agent 多了一个钱包，而是支付、身份和安全策略可以进入同一套可编程执行流程。
x402 把付费变成机器可处理的协议步骤
传统付费 API 往往要求开发者先注册账户、绑定支付方式、购买套餐，再把长期 API Key 写入配置。这套流程适合人操作，却会打断 Agent 的自主执行。
x402 利用 HTTP 402 Payment Required 的语义，把“当前资源需要付款”放进请求响应流程。一个典型交互可以抽象为：
- Agent 请求 API 或内容。
- 服务端返回
402，同时给出价格、资产、收款目标和有效期等支付条件。 - Agent 的钱包检查预算、商户身份和策略限制。
- 条件满足后，钱包生成支付证明或完成支付授权。
- Agent 携带证明重新请求资源。
这使 API 可以从“预先订阅”转向“按次购买”。例如，一个研究 Agent 不必长期订阅十个数据源，而可以只为当前任务所需的三次查询付款。
支付协议并不等于无限授权。生产系统仍需明确单笔限额、周期预算、允许购买的资源类型、可信服务列表，以及遇到价格变化时是否必须请求人工确认。
钱包同时承担身份与策略执行
Agent 付款之前，交易双方需要回答两个问题：谁在发起请求，以及它被允许做什么。Cloudflare Wallets 所强调的可验证身份，可以让服务端判断请求是否来自特定 Agent、组织或授权环境，而不必只依赖一个容易泄露的静态密钥。
在实际架构中，可以把权限分成三层：
- 身份层：证明 Agent、工作负载或所属组织的身份。
- 支付层：保存支付能力，生成交易授权或支付证明。
- 策略层：决定某次购买能否执行，例如限制金额、域名、时间和资源类型。
策略必须在钱包或受信执行环境中强制实施，不能只写进提示词。提示词会受到注入攻击，也无法提供可靠的并发预算控制。即使模型决定“应该购买”，最终付款仍应由确定性的程序检查。
可以这样实践：模拟一次受限的 x402 购买
下面的示例不是 Cloudflare Wallets 的正式 SDK，也没有假设具体的支付证明格式。它使用 Python 标准库模拟 请求资源 -> 收到 402 -> 检查预算 -> 付款后重试 的控制流程，可直接运行，并适合作为接入真实钱包 API 时的骨架。
将代码保存为 agent_payment_demo.py，然后运行 python agent_payment_demo.py：
from dataclasses import dataclass
from decimal import Decimal
@dataclass(frozen=True)
class PaymentRequirement:
resource: str
merchant: str
amount: Decimal
currency: str
class PolicyWallet:
def __init__(self, budget: str, allowed_merchants: set[str]):
self.remaining = Decimal(budget)
self.allowed_merchants = allowed_merchants
def authorize(self, requirement: PaymentRequirement) -> str:
if requirement.merchant not in self.allowed_merchants:
raise PermissionError("merchant is not allowed")
if requirement.currency != "USD":
raise PermissionError("unsupported currency")
if requirement.amount > Decimal("0.10"):
raise PermissionError("transaction exceeds per-purchase limit")
if requirement.amount > self.remaining:
raise PermissionError("insufficient agent budget")
self.remaining -= requirement.amount
# 接入真实钱包时，在这里请求签名、授权或支付证明。
return f"demo-proof:{requirement.merchant}:{requirement.amount}"
def paid_api(payment_proof: str | None = None) -> tuple[int, object]:
requirement = PaymentRequirement(
resource="market-summary",
merchant="data.example",
amount=Decimal("0.04"),
currency="USD",
)
if payment_proof is None:
return 402, requirement
if payment_proof != "demo-proof:data.example:0.04":
return 403, {"error": "invalid payment proof"}
return 200, {"summary": "Demand increased 8% this week."}
def main() -> None:
wallet = PolicyWallet(
budget="0.20",
allowed_merchants={"data.example"},
)
status, payload = paid_api()
if status == 402 and isinstance(payload, PaymentRequirement):
proof = wallet.authorize(payload)
status, payload = paid_api(payment_proof=proof)
if status != 200:
raise RuntimeError(f"request failed: {status} {payload}")
print(payload)
print(f"remaining budget: ${wallet.remaining}")
if __name__ == "__main__":
main()
预期输出如下：
{'summary': 'Demand increased 8% this week.'}
remaining budget: $0.16
接入真实服务时，需要将示例中的 PaymentRequirement 替换为 x402 响应解析逻辑，并把 authorize() 中生成演示字符串的部分替换为钱包提供的签名或支付接口。价格、收款方、网络、资产和过期时间都应经过结构化校验，不能直接信任模型生成的参数。
上线前要补齐的控制面
Agent 支付系统的风险不只来自私钥泄露。提示词注入可能诱导 Agent 购买无关资源；恶意服务可能反复返回付款要求；并发任务也可能分别通过检查，却在汇总后突破总预算。
上线时至少应落实以下措施：
- 为单笔、单任务、单日和单商户分别设置限额。
- 使用商户允许列表，并验证服务身份与支付条件的完整性。
- 为支付要求设置有效期，拒绝重复使用或重复扣款。
- 将付款决策、策略版本、资源标识和响应结果写入审计日志。
- 对高金额、首次访问的商户和价格突变设置人工确认。
- 使用原子预算扣减，避免多个 Agent 并发超支。
- 将钱包凭据与模型上下文隔离，禁止模型直接读取密钥。
Cloudflare Wallets 与 x402 展示的是一种更适合 Agent 的商业接口：资源可以在请求时定价，身份可以验证，付款可以自动执行，但授权边界仍由开发者定义。早期采用时，适合从低价值、可重试、按次计费的 API 开始，把钱包视为受策略约束的基础设施组件，而不是交给模型自由支配的账户。