机器支付(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 机制。
相关 topic
- x402:了解围绕 HTTP 402 的开放支付标准。
MPP
难度:中级。 MPP(Machine Payments Protocol)关注机器与机器之间的支付协商和结算。
它的价值在于把 agent service 的付款过程协议化:发现服务、获取报价、授权支付、结算、返回收据。对 builder 来说,重点是理解机器支付需要的不只是链上转账,还包括报价、凭证和错误处理。
MPP 类协议适合思考“机器之间怎么谈生意”:服务发现、价格协商、支付凭证、交付回执、失败重试都应该有机器可读格式。如果没有协议,Agent 只能读网页或 API 文档临时拼流程,可靠性会很差。
在实现上,不要把 MPP 理解成必须上链的所有步骤。很多步骤可以链下完成,链上只承担最终结算、抵押、收据锚定或争议证据。
相关 topic
- MPP:了解 Machine Payments Protocol 的基本方向。
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 如何支持支付权限。