机器支付（Machine Payment）

约 2568 字大约 9 分钟

2026-05-12

Machine Payment 讨论的是 Agent、API、服务和钱包之间如何自动完成报价、授权、付款、收据和预算控制。重点不是“AI 会花钱”，而是让机器之间的支付可限制、可验证、可追踪。

为什么要学这个

如果 Agent 只能免费调用工具，它的能力会停在 demo 阶段。真实服务需要付费：模型推理、数据 API、浏览器环境、链上交易、存储、人工审核、另一个 Agent 的任务执行。

机器支付让 Agent 可以在用户授权的预算内购买服务，也让服务方可以在收到可验证付款后交付结果。这里的挑战不是转账本身，而是：谁授权，价格是多少，什么时候扣款，失败怎么退，收据如何验证，预算如何不被滥用。

机器支付的核心，是把“付款意图”和“实际结算”拆开，并让每一步都有凭证。

第一性原理

Agent 不应该拥有无限支付能力，只应该拿到具体任务、预算和收款方范围内的支付权限。

支付是执行能力的一部分。一旦 Agent 可以付款，它就可以消耗用户资金、触发链上状态变化、购买外部服务或被恶意上下文诱导。

预算先于执行：没有预算边界，就没有安全自动支付。
报价必须可比较：Agent 要知道价格、币种、有效期、服务范围和退款条件。
收据必须可验证：付款后要能证明付给谁、为什么付、交付了什么。

知识节点

Stablecoin Payment

难度：初级。 稳定币适合机器支付，因为它价格相对稳定、结算快、可编程、容易被合约和服务验证。

Agent 支付 API 调用费或服务费时，通常不希望价格随原生资产剧烈波动。稳定币可以作为计价单位，但仍要处理 chain id、token address、decimals、allowance、gas 和跨链可用性。

真实产品里还要区分“计价币种”和“结算币种”。服务方可以用 USD 报价，用户用 USDC 支付，也可能通过 Paymaster 或中间路由把其他 token 转成稳定币。Agent 不能只看到“0.1”，必须知道这是 0.1 USDC、0.1 USDT 还是 0.1 原生 gas token。

判断一个稳定币支付方案时，至少看四件事：付款 token 是否在目标链上有足够流动性，收款方是否接受该 token，支付失败是否会消耗 gas，用户是否需要提前 approve。对 Agent 来说，approve 本身就是高风险动作，不能和普通付款混在一起。

Budget

难度：初级。 Budget 是用户授权给 Agent 的最大支出范围。

预算可以按时间、任务、服务方、币种和额度定义，例如“今天最多花 5 USDC 调用数据 API”“单次浏览器任务不超过 0.2 USDC”。预算不应该只存在聊天里，而要进入 wallet policy、session key 或后端账本。

预算最好拆成多层：全局预算、任务预算、单次调用上限、服务方上限和紧急停止条件。这样 Agent 即使被诱导反复调用工具，也只能消耗很小范围内的额度。

一个常见错误是只设置总预算，不设置频率和服务方范围。结果是 Agent 可以把全部预算花在一个异常报价上，或者被恶意网页诱导重复购买同一服务。预算系统应该能回答：这笔付款是否属于当前任务，是否在用户授权的服务范围内，是否超过频率或金额限制。

Quote

难度：中级。 Quote 是服务方给 Agent 的可执行报价。

一个合格 quote 至少包含：服务内容、价格、币种、收款地址、有效期、交付条件、退款条件和 quote id。Agent 接受 quote 前，要检查它是否在预算内，服务方是否可信，报价是否过期。

Quote 的有效期很重要。价格、汇率、服务容量和链上 gas 都会变化。过期 quote 不能被 Agent 继续使用，否则可能出现“用户以为买的是 0.1 USDC 服务，实际执行时价格已经变成 1 USDC”的问题。

Quote 还应该能被签名或验证来源。服务方返回的 quote 如果没有签名、没有 quote id、没有收款地址绑定，后续 dispute 时很难证明 Agent 当时接受的到底是什么条件。

Payment Intent

难度：中级。 Payment Intent 表达“用户或 Agent 想为某个具体服务付款”，但不等同于已经结算。

Payment Intent 应该绑定任务、金额、收款方、有效期和可接受结果。这样即使后续由 Agent 自动执行，也能回到用户的原始授权，而不是让 Agent 临时决定花钱。

可以把 Payment Intent 理解成“用户授权这类付款”，而不是“某一笔交易已经发生”。它通常在真正结算前创建，用来给后续 payment、escrow 和 receipt 提供上下文。

在 Agent 支付里，Payment Intent 至少应包含：用户目标、服务方、最大金额、币种、链、过期时间、quote 引用、是否允许自动重试、是否需要人工确认。缺少这些字段，Agent 的付款行为就很难审计。

x402

难度：中级。 x402 尝试把 HTTP 402 Payment Required 变成互联网原生支付流程，让服务可以用标准响应要求付款。

在 x402 风格的流程里，客户端请求资源，服务返回付款要求，客户端完成支付后再带着付款证明重新请求。它适合 API、数据、内容和 agent service 的小额按次付费。

x402 的价值是把“付费才能访问资源”放回 HTTP 语义里。对 Agent 来说，这意味着工具可以像处理 401 登录一样处理 402 付款：先读取付款要求，再检查预算，再完成付款，再重放请求。

需要注意的是，x402 只解决付款协议的一部分。它不自动解决服务质量、退款、交付争议和长期订阅。高价值服务仍然需要 escrow、receipt 和 dispute 机制。

MPP

难度：中级。 MPP（Machine Payments Protocol）关注机器与机器之间的支付协商和结算。

它的价值在于把 agent service 的付款过程协议化：发现服务、获取报价、授权支付、结算、返回收据。对 builder 来说，重点是理解机器支付需要的不只是链上转账，还包括报价、凭证和错误处理。

MPP 类协议适合思考“机器之间怎么谈生意”：服务发现、价格协商、支付凭证、交付回执、失败重试都应该有机器可读格式。如果没有协议，Agent 只能读网页或 API 文档临时拼流程，可靠性会很差。

在实现上，不要把 MPP 理解成必须上链的所有步骤。很多步骤可以链下完成，链上只承担最终结算、抵押、收据锚定或争议证据。

Subscription

难度：中级。 Subscription 是持续服务的支付模型，例如每月 API 包、持续监控或长期 Agent 任务。

订阅比单次付款更需要撤销能力。用户要能看到当前授权、下次扣款时间、剩余额度、服务范围，并能随时停止。

Agent 订阅尤其要小心“静默续费”。如果一个 Agent 为了持续监控风险而订阅数据源，系统必须让用户知道：订阅什么时候续费，最高月预算是多少，服务方是否可以涨价，失败时是否继续扣款。

订阅更适合和智能账户 policy 结合：每月上限、服务方白名单、扣款时间窗口、异常扣款告警。不要让 Agent 通过无限 allowance 实现订阅。

Micropayment

难度：高级。 Micropayment 适合高频、小额、自动化服务，但对手续费、批量结算和欺诈控制要求更高。

如果每次调用都上链结算，成本可能超过服务本身。实际系统可能需要 L2、payment channel、批量结算、预付余额或链下账本加链上最终结算。

Micropayment 的设计要先算经济账：单次服务价值、链上手续费、失败率、欺诈成本、对账成本。很多场景并不适合每次都发链上交易，而是适合预存额度、累计消费、定期结算。

对 AI 工具尤其如此。一次搜索、一次轻量推理、一次网页抓取可能只有几厘或几美分价值，适合批量结算；一次高价值报告、审计或交易执行，则更适合 escrow 和单独 receipt。

在 AI x Web3 中的位置

Machine Payment 是 Agentic Commerce 的基础。Agent 要购买数据、委托另一个 Agent、调用付费 API 或为用户完成任务，都需要支付能力。

但支付能力必须和 Agent Wallet、Policy、Settlement、Receipt 连接起来。一个可用链路应该是：用户授权预算，Agent 获取 quote，系统检查 policy，付款进入 escrow 或直接结算，服务交付，收据留下证据。

最小实践

设计一个 Agent 购买 API 的支付流程：

用户授权：今天最多 3 USDC。
API 返回 quote：一次调用 0.1 USDC，5 分钟内有效。
Agent 检查预算和服务方身份。
钱包或支付工具完成付款。
API 返回结果和 receipt。
系统记录 quote、payment intent、交易哈希、结果和剩余预算。

扩展阅读

x402：了解基于 HTTP 402 的互联网原生支付标准。
MPP：了解机器到机器支付协议的设计方向。
AP2 Documentation：了解 Agent Payments Protocol 如何表达授权、支付和证明。
Coinbase x402 Docs：查看 x402 在开发者工具里的实现入口。
ERC-4337 Documentation：理解智能账户、Paymaster 和 session key 如何支持支付权限。