一个购买数据库查询、模型调用和一批计算资源的 AI 智能体并不自动需要加密货币。卡片、账户余额或现有的 API 计划可能更简单。
当智能体必须即时发现服务、按需支付、跨供应商或跨国界运行，并且在不与每个卖家开设独立账户的情况下结算极小金额时，加密货币就变得有趣了。即便如此，支付轨道也无法回答最核心的问题：智能体被允许购买什么？
从支付任务开始
对于每天使用的单一受信任供应商，传统的设置很难被超越。API 密钥识别客户，订阅定义周期性收费，而基于使用的计费可以将请求汇总到发票中。Stripe 为现有的 Billing Meters 集成提供了使用记录文档，并推荐 Metronome 用于新集成。这展示了一种计费选项，而不是建议开始新的 Billing Meters 部署。在 Stripe 中记录使用情况
当智能体从它预先不知道需要哪些服务而组装任务时，摩擦就出现了。每个新服务可能要求注册、API 密钥、预付余额、合同或结账步骤。Mastercard 本身将这些描述为当今数字服务的常见支付关系。它们适用于小型、已知的供应商列表；当智能体在任务中途更换供应商时，它们会增加工作量。Mastercard，2026 年 10 月 20 日
x402 改变了什么
x402 利用 HTTP 的 402 Payment Required 响应来让服务实际上表达：“此请求的费用为该金额，支付条款如下。” 客户端可以提交支付负载，由服务提供商或协调方进行检查。根据支付流程的不同，结算或托管资金可以在执行前完成，也可以在执行后结算。该规范支持不同的方案和网络；它不选择智能体的预算，也不决定哪些提供商值得信任。x402 协议与流程 · x402 v2 规范
这可以适配按需付费的服务：单次数据查询、图像生成任务或推理请求。当卖家接受支持的支付方式时，它还可以减少对预先账户关系的依赖。“无需 API 密钥”并不意味着“无需身份验证或信任评估”。钱包、支付协调方、服务提供商和智能体运行时依然重要。
支付方案的选择会影响机制。精确支付授权特定金额；upto 方案可以授权上限并结算实际使用量；批量结算可以在链上赎回前将小额费用分组。按请求支付易于理解，但为每个微小的请求支付一笔链上交易可能会造成浪费。批量流程减少了结算操作，但引入了托管、代金券和权利请求处理的复杂性。x402 方案概述
加密货币可以提供帮助的地方——以及不能提供帮助的地方
当以下条件之一或多个成立时，考虑使用加密货币或稳定币结算是值得的：
- 卖家需要全球性的、互联网原生的结算，且在实际操作中无法将每个买家都纳入作为卡片客户；
- 费用足够低或随用量变化，以至于账户设置和发票管理成本超过了服务价格；
- 提供商暴露了一个标准的支付挑战，智能体可以通过程序化方式回答；
- 业务需要在周末进行结算，或者在不共享银行关系的系统之间进行结算。
那些是架构条件，并非加密货币更便宜的证据。真正的对比必须包括网络费用、协调方成本、转换或提现成本、失败的请求、支持和会计工作。一笔支付在 API 响应中可能是“一美分”，但其获取、授权或对账的成本可能仍然更高。
当任务涉及少数已知供应商、定期账单、退款、消费者纠纷，或企业已经拥有卡片和发票工作流时，加密货币是一个较弱的默认选择。稳定币的美元挂钩并不意味着支付可撤销，且公共区块链不会授予智能体安全支出的权限。
企业必须围绕支付方式设置控制措施：允许的供应商、单次调用的最高限额、每日或任务预算、资产/网络白名单、智能体可发送的数据，以及停止条件。如果服务返回了智能体未预料到的支付挑战，智能体应当能够拒绝，而不是将每一个 HTTP 402 都视为支付批准。
Mastercard 十月试点展示的内容
2026 年 10 月 20 日，Mastercard 发布了基于 x402 构建的 Agent Pay for Machines 演示。示例智能体在单一批准预算下，向两家供应商支付了九笔用于社交媒体研究和生成图像的费用。Mastercard 表示，智能体提交已签名的凭证，供应商对其进行验证，且费用可以合并并在稍后赎回；其描述称，交互发生在链下并以机器速度进行，通过指定的合作伙伴以法定货币或稳定币进行结算。Mastercard 独立的早期访问页面明确表示，该服务仍处于试点阶段，尚未投入商业使用。Mastercard 试点账户 · 早期访问和状态
这是支付网络及其合作伙伴能够展示基于 x402 的具有支出权限和延迟结算的机器支付流程的证据。它并非客户采用率、成本节省、生产可靠性，或每项 x402 集成都需要 Mastercard 或加密货币的证据。Mastercard 自身的示例围绕开放支付协议使用了一个更广泛的业务框架。
简短的决策规则
这些选择在不同层级上运行。API 密钥用于验证客户端；订阅或发票定义计费；卡片或稳定币承载支付；x402传达支付要求。它们可以共存：经过验证的 API可以使用 x402，而基于使用的计费最终可以由卡片或稳定币支付。
| 场景 | 起始方式 | 原因 |
|---|---|---|
| 一到两个已知服务，循环使用 | API 密钥、订阅或发票 | 更简便的计费、支持和对账 |
| 许多服务是动态选择的，按请求计费 | 如 x402 之类的 HTTP 支付标准 | 支付指令可以随请求流传输 |
| 极小的重复费用 | 按量计费或批次结算设计 | 避免为每一次微小的使用支付结算开销 |
| 高风险操作或大额支出 | 人工审批和严格的委托限制 | 支付轨道不是授权策略 |
| 需要退款或信用卡式的追索权 | 除非卖家定义了其他补救措施，否则采用现有的账户/卡片工作流 | 链上结算不提供自动退款 |
在采用加密货币之前，先对整个工作流进行定价。如果卡片和 API 账户已经能够干净地解决问题，就没有必要增加钱包。如果智能体需要开放式的服务发现和按量计费的跨供应商支付，请在有限的预算内测试支付挑战——并让支出策略比智能体的提示词更可靠。
研究核查日期为 2026 年 10 月 26 日。Mastercard 的详情描述了其宣布的试点和早期访问，而非通用的商业推广。这是一个架构解释，而非财务或法律建议。