Tempo 上线后,我用一段脚本跑通了「机器支付」
2026-03-1910:37
ForesightNews 速递
2026-03-19 10:37
ForesightNews 速递
2026-03-19 10:37
收藏文章
订阅专栏
没有信用卡和 OpenAI 账号,笔者在终端敲下 MPP 的回车,AI Agent 在不到一秒内自己掏出稳定币,买到了 ChatGPT 的回复。


撰文:Sanqing,Foresight News


3 月 18 日,Stripe 和 Paradigm 支持的稳定币支付公链 Tempo 宣布主网正式上线。与此同时,Tempo 与 Stripe 共同推出了机器支付协议(MPP),旨在为 AI Agent 提供原生的编程式支付标准。该协议支持微交易与定期支付,允许 Agent 通过稳定币或法币直接结算服务费。目前,Stripe 上的 Browserbase、Postalform 甚至纽约线下餐厅 Prospect Butcher 等 50 余个服务已率先接入 MPP。


图源:Tempo 推文


Tempo:一条专为稳定币支付设计的 L1


与市面上大多数追求通用计算或交易撮合的公链不同,Tempo 的定位非常明确:一条专为稳定币支付场景设计的 Layer 1。


在 Tempo 上,链上手续费直接用合规稳定币(如 USDC)支付,开发者和用户不需要持有任何额外的波动性 Gas Token。区块在约 0.6 秒内达成最终确认,没有重组风险。


协议层面设有专用支付通道,即使网络活动高峰期,手续费依然维持低位稳定。此外,Tempo 内置了针对稳定币和合规代币化存款优化的原生 DEX,并支持基于生物识别(指纹 / 面容)的 Passkey 无感钱包签名,最大限度降低终端用户的使用门槛。


简单来说,Tempo 是一个面向企业级应用、高频微交易、AI Agent 支付等场景的「去中心化清算引擎」。


MPP:不止让机器之间实现稳定币结账


在 Tempo 的基础设施之上,MPP(Machine Payments Protocol,机器支付协议) 定义了一套让机器与机器之间无需 API Key、无需信用卡、无需人工介入,就能直接用稳定币完成按次付费、定期付费等的开放标准。


它的工作原理并不复杂。


当 AI 客户端向一个收费 API 发起请求时,服务端会返回 HTTP 402 Payment Required 响应,附带一份标准化的账单(Challenge),写明价格、币种与收款地址等信息。


客户端的 MPP SDK(如 mppx)自动拦截这个 402,在本地用私钥签署一张链上凭证(Voucher),附在请求头中重新提交。服务端验证凭证有效后,即返回正常数据。


整个过程对上层应用代码而言几乎是透明的。你写的还是 fetch(url),只是底层多了一段自动付钱的逻辑。


与 x402 协议的关系:x402 是一套基于 HTTP 传输层的信令规范,它解决的是客户端和服务端如何规范化地交换账单和凭证的问题。


而 MPP 在 x402 的通信标准之上,进一步引入了状态通道(Escrow Session)。客户端预存一笔押金到链上智能合约,之后的多次请求都在链下用签名白条(Voucher)完成增量结算,不再逐次上链。这大幅降低了高频调用的 Gas 成本。


值得强调的是,MPP 的野心不止于「付钱」这一个动作。在传统互联网中,API Key 同时承担了身份认证和计费凭证两个角色,而 MPP 用链上钱包地址替代了前者,用密码学签名的 Voucher 替代了后者,重新定义了机器之间建立信任的方式。


此外,MPP 还提供了标准化的服务目录接口,Agent 可以通过编程方式自动发现哪些服务支持用稳定币按次购买,这构成了一个机器可读的商业索引。


再加上状态通道本身维护的是一段持续的计费关系而非一次性交易,MPP 更准确的定位应该是一套机器间的经济交互协议。服务发现、身份验证、持续计费、增量结算,都被装进了同一个框架里。


实测记录:从部署到踩坑的完整流程


以下是笔者与 AI 编程工具 Antigravity 协作完成的一次完整部署测试,记录了真实的操作步骤和遇到的问题。


笔者的环境是 Windows 11,运行时为 Node.js v24 配合 TypeScript(ts-node/esm),核心依赖包括 mppx(MPP 客户端 SDK)、viem(以太坊交互库)和 dotenv。


部署分四步完成。首先,用 viem 的 privateKeyToAccount 方法在本地生成一个链上钱包地址,私钥加密后保存于本地,作为 AI Agent 的专属账户。


然后,笔者通过 Tempo 的 Passkey 钱包(基于面容 / 指纹验证),向该地址转入 USDC 作为启动资金,AI 的「第一桶金」需要人类注入。


接下来,在代码中用几行配置初始化 MPP 客户端,设定单次支付通道的最大押金上限。SDK 会自动接管全局的 fetch 函数,遇到 402 时自动执行付款流程。


最后一步是测试,笔者实际调用了 ChatGPT。向 https://openai.mpp.tempo.xyz/v1/chat/completions 发起标准的 OpenAI 格式请求。第一次请求时,SDK 会在链上开通一条「状态通道」,质押 maxDeposit 额度的资金;之后的所有请求都在链下通过递增的 Voucher 累计结算,不再产生额外的链上交易费。


整个流程看似顺畅,但实际踩坑不少。


官方命令行工具的平台兼容性。Tempo 的 CLI 工具目前仅支持 macOS 和 Linux,Windows 用户直接安装失败。Antigravity 给笔者的解决办法是绕过 CLI,改用 Node.js SDK 在代码层面完成所有操作。


授权的精度陷阱。 在设置单次通道的最大押金时,笔者填入了 5000000,以为是授权 5 USDC。但 SDK 会自动补足精度,在这个数字基础上再补 6 个零。也就是说,笔者实际上向智能合约申请质押了 500 万美元。正确的做法是直接填入人类可读的金额,比如 0.1 就代表 0.1 USDC。


模块格式的配置冲突。 MPP 的客户端 SDK 采用了较新的 JavaScript 模块标准,如果项目配置文件中的几个关键字段没有对齐,程序会直接报错无法启动。这类问题对有经验的开发者来说不难解决,但对新手可能是一道隐形的门槛。


支付通道的「健忘症」。 这是笔者花了最多时间排查的问题,也是理解 MPP 设计哲学的关键。每次笔者重新运行测试脚本时,系统都会在链上开通一条全新的支付通道,重复扣除一笔押金,即使上一次的通道里还有大量余额没花完。


原因在于,MPP 客户端是完全无状态的。程序一关闭,它就「忘记」了自己之前开过哪条通道、已经花了多少钱。要实现跨次启动的通道复用,必须在程序关闭前把「channelId」和「cumulativeAmount」两个关键信息保存下来,下次启动时重新喂给客户端。


搞清楚这个机制后,笔者连续完成了 10 次以上的 ChatGPT 调用,全程只在第一次时触发了一笔链上操作(Gas 费约 0.03 美元),后续 9 次调用在链上完全静默、零额外开销。


如果你对上面提到的技术细节感到陌生,完全不用担心。事实上,这次部署的大部分代码都是笔者用自然语言引导 Antigravity 一步步完成的。


笔者只需要给他 Tempo 的文档和 Github 链接,再用自然语言描述意图,它就会生成对应的代码、解释每一步的含义,并在出错时帮笔者定位原因。类似的工具还有 Claude Code、Cursor 等。


MPP 的下一站:跨链扩张与代理经济


从技术上看,MPP 协议本身并不与 Tempo 链深度耦合。它的核心逻辑(HTTP 402 信令交换、链下 Voucher 签名递增、链上 Escrow 合约托管)理论上可以移植到任何支持 EVM 智能合约的网络。


这就引出了一个自然的问题:如果 MPP 不局限于 Tempo 呢?


如果未来 MPP 的 Escrow 合约部署到 Base、Arbitrum 甚至 Solana 上,AI Agent 将获得在多条链上同时拥有支付账户的能力,并根据 Gas 成本和结算速度动态选择最优链路完成付款。


这意味着「机器支付」可能不再绑定于某一条特定公链,而是演化为一个跨链的、协议级的基础设施层。


但支付通路只是第一层。


前文提到,MPP 同时承担了服务发现、身份验证和持续计费的功能。一旦这套协议在多条链上落地,一个 Agent 的链上钱包地址将成为跨网络通用的「商业身份」。


它在 Tempo 上积累的交易信誉、在 Base 上开通的服务通道、在 Arbitrum 上的消费记录,都指向同一个密码学身份。这为 Agent 构建去中心化的「信用画像」提供了原生的数据基础,也让服务商有可能根据 Agent 的历史行为提供差异化定价或授信额度。


这种扩张一旦发生,对 AI Agent 支付的影响将是结构性的。当前,一个 Agent 的消费能力受限于单链余额和单一稳定币的流动性。


如果 MPP 实现多链部署,Agent 可以在 Tempo 上以极低 Gas 完成高频微交易(比如测试中逐次调用 LLM,单次消耗约 0.00006 美元),同时在 Base 或以太坊主网上完成大额的数据采购或合约交互,甚至利用跨链桥在不同网络间自动调拨资金。


风控模型也会随之进化,智能合约层面的 maxDeposit 限额可以按链、按服务商、按时间窗口精细设定,形成一套比传统信用卡风控更灵活、更不可篡改的多维预算体系。


说到这里,不妨把想象再推远一步。


当机器具备独立的、跨链的支付能力后,「Agent-as-a-Service」将不再只是一个概念。


一个部署在云端的研报 Agent,可以自主采购算力、抓取数据、调用翻译模型、生成多语言内容,最终将成品交付给付费用户。整个链路中没有人类逐笔审批,利润自动沉淀在 Agent 的链上地址中。


更进一步,Agent 之间也可以互相雇佣。一个擅长数据清洗的 Agent 向另一个擅长金融建模的 Agent 按次付费购买分析结果,形成真正的“机器对机器”的劳动力市场。


当这些 Agent 的收入积累到一定规模,它们甚至可以通过 Bridge 的 MPP 服务等合规出入金通道将稳定币结汇为法币,自动打回运营者的银行账户。


当然,现阶段仍有短板。通道状态(channelId 和 cumulativeAmount)的持久化在生产环境中是必选项,否则每次进程重启都会造成不必要的重复质押。但这些问题更多是工程层面的打磨,而非协议层面的硬伤。


当 MPP 从 Tempo 一条链扩展到整个 EVM 生态甚至更广泛的区块链网络时,「代理经济」的规模天花板将被彻底打开。



附录:MPP 生态服务一览


内容来源:mpp.dev/services

【免责声明】市场有风险,投资需谨慎。本文不构成投资建议,用户应考虑本文中的任何意见、观点或结论是否符合其特定状况。据此投资,责任自负。

专栏文章
查看更多
数据请求中

推荐专栏

数据请求中

一起「遇见」未来

DOWNLOAD FORESIGHT NEWS APP

Download QR Code