作者:Stablehunter
上周在香港参加 Web3 Festival,一个很明显的感受是:现在几乎每一个论坛、每一场 panel,都绕不开 AI。
不管原本聊的是支付、稳定币、RWA、钱包、交易所,还是合规和基础设施,最后几乎都会回到同一个问题:当 AI 不再只是生成内容,而是开始替人执行任务、调用服务、做决策、甚至处理资金流时,现有的金融和支付系统还够不够用?
在我参加的一个panel里,也有人直接抛出了一个问题:Web3 是不是在蹭 AI?我觉得并不是。当然,蹭热点的项目一定会有。但如果只把 AI × Web3 理解成叙事拼贴,可能也会错过一个更底层的变化:AI 负责理解、决策和行动,Web3 提供资产、账户、结算和可验证执行环境。两者不是简单叠概念,而是在重新分工。
香港财政司司长陈茂波在 Web3 Festival 2026 的演讲里也提到,AI agents 未来会以机器速度分析信息并采取行动,同时在后台充分利用 blockchain infrastructure,从而提高交易效率,并重塑金融、贸易、财富管理、供应链和物流等场景。当 AI 开始行动,问题就不只是“智能”本身,而是这些行动如何被授权、如何被结算、如何被记录、如何被追责。
其中,Agentic Payment 是一个越来越难被忽略的话题。但我一开始也有一个很朴素的疑问:为什么大家一聊 Agentic Payment,或者 Agentic Commerce,就好像默认它一定会和 Crypto、Stablecoin、Blockchain 绑在一起?
AI Agent 不能用银行卡吗?不能用信用卡吗?不能用 Apple Pay、Visa、Mastercard、Stripe、PayPal 吗?
如果 Agent 只是帮我买一张机票、订一家酒店、续费一个 SaaS,理论上它完全可以调用现有支付体系。用户授权一次,Agent 在额度和规则内执行付款,背后走银行卡、虚拟卡、企业账户或者第三方支付钱包,听起来并没有什么不合理。
所以问题不是“银行卡能不能用”。当然能用。真正的问题是:银行卡和信用卡到底适合解决 Agentic Payment 的哪一部分,又解决不了哪一部分?AI Agent 到底会不会用银行卡?以及为什么 Agentic Payment 发展到一定阶段,几乎一定绕不开稳定币和区块链。
一、银行卡解决的是 checkout,不是 Agent Economy
如果 Agentic Payment 只是让 AI Agent 帮人完成最后一步付款,比如买一张机票、订一家酒店、续费一个 SaaS,背后走银行卡、信用卡、虚拟卡、Apple Pay、Stripe、PayPal,都没有什么本质障碍。银行卡当然可以用,信用卡当然也可以用。
用户提前授权,Agent 在额度和规则内执行付款。这件事并不难理解,本质上有点像更聪明的自动扣款、企业虚拟卡、差旅卡或者自动化采购系统。
所以,Visa、Mastercard、Stripe 这些传统支付玩家不会消失。它们甚至会成为早期 Agentic Commerce 的重要入口。
Stripe 和 Tempo 推出的 Machine Payments Protocol 就很能说明这一点。它不是单押稳定币,而是让商户可以直接接受来自 agents 的付款,既支持 stablecoins,也支持 cards、BNPL 等 fiat payment methods。也就是说,在 agent payment 的早期阶段,传统支付和稳定币更可能是共存关系,而不是谁立刻替代谁。 但这只解决了 Agentic Commerce 里的一个部分:checkout。
Checkout 的前提是,商品、商户、订单、支付按钮、退款和争议处理流程都已经存在。Agent 只是站在用户旁边,帮用户更自动化地完成一次购买。
真正的问题发生在另一类场景里:Agent 不再只是进入一个已经搭好的购物车,而是在开放网络里连续调用资源、组合服务、完成任务。比如,一个 AI research agent 为了完成一份行业报告,可能要调用多个数据库、购买几份付费资料、访问不同模型 API、调用一次爬虫服务、支付图表生成工具,甚至向另一个 Agent 购买一段分析结果。这里面可能没有一个传统意义上的“商店”。也未必有一个完整的 checkout 页面。它面对的可能是 API、数据接口、模型服务、算力节点、内容资源、自动化工具,甚至是另一个 Agent。
我自己最近也遇到过一个很具体的例子。我想做一个流量分析助手,让它可以在需要的时候自动去调用类似 Semrush 这样的数据源,帮我分析一个网站的流量、关键词、竞品和市场趋势。但真正开始整理方案时,我发现问题不是“AI 能不能分析”,而是“它怎么拿到数据”。很多商业数据源并不是按照“单次调用、单次付费、即时返回”的方式设计的。以 Semrush 为例,它的 API 体系更接近账号、套餐和 API units 模式。每次 API request 会消耗一定数量的 API units,用户需要有对应的 API access 或购买 API unit package;Trends API 虽然可以单独购买 access,也仍然是基于 API units 请求数据。
但对于 Agent 来说,这个模式就不够自然。如果一个 Agent 只是偶尔需要调用一次流量数据,它真正需要的可能不是注册一个 SaaS 账号,也不是购买一整包 API units,而是像访问网页一样发起一次请求:这个数据多少钱?我是否被授权购买?如果在预算范围内,就付款,然后马上拿到结果。
这就是 Agentic Payment 和传统 API 商业模式之间的断层。今天大量 API 的收费方式,仍然是为“人类公司采购软件”设计的,而不是为“机器按需购买资源”设计的。
所以,Agentic Payment 的问题不是最后一步能不能扣款,而是整个任务链条里,机器如何持续获得授权、发起付款、验证交付、完成结算。
这里才是银行卡体系的边界。
不是因为银行卡落后,而是因为它原本服务的是人类消费场景:一个人进入商户环境,选择商品,确认订单,完成支付,后面再由银行、卡组织、收单机构和支付服务商完成授权、清算、风控和争议处理。
但 Agent Economy 面对的是另一组问题:这个 Agent 凭什么有权花这笔钱?服务方如何确认这不是恶意 bot,而是用户真实意图的延伸?Agent 能不能在没有人工确认每一步的情况下,完成小额、高频、跨平台付款?服务方收到付款后,能不能立刻释放对应资源?如果 Agent 买错了、越权了、被攻击了,责任应该落在谁身上?
这也是为什么 Google 做 AP2 时,没有把重点放在“用哪种支付方式”上,而是放在一套更通用的 agent payment 信任框架上。Google 官方介绍里,AP2 被定义为一个 payment-agnostic framework,让用户、商户和支付服务商可以在不同支付方式之间更有信心地完成 agent-led payments。AP2 specification 也明确提出,Agent 需要一种安全、简单的方式获得 scoped permissions,代表用户执行动作;协议的安全性依赖用户和商户对相关信息进行 cryptographic signing。
所以,Agentic Payment 的第一层问题,并不是:钱从哪里扣?而是:Agent 凭什么有权花这笔钱?
这个问题,银行卡体系可以解决一部分。比如虚拟卡、tokenized credentials、额度管理、企业费用控制、风控规则,都能让 Agent 在现有商户体系里完成交易。
Visa 也在沿着这个方向推进。它的 Intelligent Commerce 和 Trusted Agent Protocol,本质上就是让 AI Agent 能在现有商户网络里被识别、被信任、被允许代表消费者或企业完成交易。Visa Developer 对 Trusted Agent Protocol 的描述也很直接:AI agents 会帮助用户浏览商户网站、发现产品、比较价格和做选择,而商业旅程早在 checkout 之前就已经开始;过去这些自动化访问经常会被商户、CDN 或 bot mitigation 服务当成 bot 拦掉。
这说明传统支付网络也看到了同一个问题:Agentic Commerce 不是只发生在付款按钮那一刻,而是从搜索、比较、选择、授权,到最终支付的整条链路。但卡网络更擅长解决的是:Agent 如何进入现有 commerce flow,并完成一笔被授权的交易。它不天然解决的是:Agent 如何在开放网络里,为 API、数据、模型、算力、内容、工具和另一个 Agent 持续发起小额支付。
所以,银行卡不是不行。更准确地说:银行卡解决的是 Agentic Commerce 的 checkout 问题,但 Agent Economy 需要的是一套更底层的支付协议。
这就把问题推到了下一层:如果交易对象不是一个传统商户,而是一个 API、一个模型、一个数据接口,甚至另一个 Agent,机器之间应该如何发起和完成一笔支付?这也是 x402、L402、T402 这些协议开始被讨论的原因。
二、Agent 真正需要的,是机器可读的支付协议
如果交易对象是一个传统商户,Agent 当然可以进入现有 checkout flow,用信用卡、借记卡、虚拟卡或者钱包完成支付。但如果交易对象不是一个商户,而是一个 API、一个模型、一个数据接口、一个内容资源,甚至另一个 Agent,问题就变了。
这时候,机器之间需要的不是一个“付款按钮”,而是一套机器可以理解的支付流程:Agent 请求一个资源。服务方告诉它:这个资源需要付款,价格是多少,收款地址是什么,支持什么支付方式。Agent 判断这笔付款是否在用户授权范围内。如果符合规则,就完成支付。服务方验证付款后,立即释放资源。
这个流程听起来很简单,但它其实是在补互联网过去一直缺失的一层能力:原生支付层。过去,互联网天然支持信息流动。网页可以被请求,邮件可以被发送,API 可以被调用,文件可以被下载。但“付款”通常不是互联网协议本身的一部分,而是被外挂到另一个系统里:注册账户、绑定银行卡、接入支付网关、购买套餐、管理 API key、月底对账。
这对于人类来说可以忍受。人可以注册、登录、绑卡、审批、采购、报销。但对于 Agent 来说,这个流程太重了。
Agent 不应该每调用一个 API 都注册一个账号,不应该每访问一次数据都买一整个套餐,也不应该为了几美分、几毛钱的小额调用,走一套完整的人类支付和采购流程。这就是 x402 这类协议出现的原因。
x402 重新激活了 HTTP 402 Payment Required 这个长期存在但很少被真正使用的状态码。它让服务方可以在 HTTP 层直接告诉客户端:你要访问这个资源,需要先付款。客户端可以是人,也可以是机器。付款完成后,服务方验证支付,再返回对应的 API、内容或者数字服务。Coinbase 对 x402 的定义很直接:它是一个通过 HTTP 实现即时、自动稳定币支付的开放协议,让 human and machine clients 可以在不需要账户、session 或复杂认证的情况下,程序化支付并获得访问权限。
这里真正重要的不是“用不用 Coinbase”,也不是“是不是一定用 USDC”。真正重要的是,x402 把付款嵌回了互联网的请求-响应流程里。过去是:
先注册账号。
再买套餐。
再拿 API key。
再调用服务。
月底再对账。
x402 想变成:
请求资源。
收到 402 Payment Required。
完成付款。
获得资源。
这对 Agentic Payment 很关键。因为 Agent 的交易不是少数几次大额购买,而可能是大量小额、实时、按需的服务调用。
一个写作 Agent 可能为一篇文章购买一次数据查询。
一个投研 Agent 可能为一个问题调用一次链上分析服务。
一个旅行 Agent 可能同时向多个价格 API 询价。
一个开发 Agent 可能按次购买模型推理、代码审查或者测试环境。
一个流量分析 Agent 可能只想为某一个网站买一次 Semrush 类数据,而不是先买一整套 SaaS 套餐。
如果每一个服务都要求账号、订阅、API key、套餐和人工审批,Agent 的执行能力会被卡在支付和采购流程上。所以,x402 的意义不是让支付变得“更 crypto”,而是让支付变得更像互联网协议:可请求、可返回、可验证、可自动执行。
L402 是另一条类似的路线。
它同样围绕 HTTP 402 展开,但结合的是 Bitcoin Lightning Network、macaroons 这类访问凭证和小额支付。Lightning Labs 对 L402 的定义是:它用于促进 API endpoint、计算资源等服务的认证和交易,并且让服务可以向 API endpoint 收费,让 AI agents 更容易参与其中。
L402 说明,这个问题并不是 x402 才突然发明出来的。更早就有人在尝试把三件事揉在一起:HTTP 访问控制、小额支付、数字服务权限。只是过去缺少一个足够强的需求方。
人类用户不会为访问一个 API endpoint 付几分钱。但 Agent 会。人类不会在一天里自动调用几百个数据源。但 Agent 会。人类不会为了完成一个任务,在不同服务之间实时组合调用、询价、付款、验证交付。但 Agent 会。
所以,AI Agent 的出现,让 HTTP-native payment 这条路线突然变得有意义了。
围绕 USDT / Tether 生态,也开始出现类似方向。Tether WDK 的 x402 文档明确写到,x402 对 AI agents 很重要,因为 agents 需要程序化地为资源付款;x402 让付款成为 web stack 的一等公民,使 agent 可以在一次 request-response cycle 里发现价格、签署付款并获得资源。 同时,t402 项目也把自己描述为 internet native payments 的开放标准,目标是支持 crypto、fiat、stablecoins、tokens 等多种价值形式,并且和 Tether WDK 兼容。这里需要谨慎一点:我不建议把它直接写成“已经成为 Tether 官方标准”,更稳的表达是,围绕 USDT / Tether 生态,正在出现类似 x402 的协议探索。
这背后其实是一个很值得关注的趋势:Agentic Payment 不是单一公司的产品竞争,而是在形成一套新的协议栈。
AP2 更像是在回答:Agent 凭什么被授权付款?
x402、L402、T402 这类协议更像是在回答:当 Agent 请求一个数字资源时,服务方如何发起付款要求,Agent 又如何完成付款并拿到资源?
稳定币和区块链则更像是在回答:这笔钱最终用什么资产结算,在哪里验证,如何做到低成本、实时、可编程和跨平台?
所以,Agentic Payment 和 Crypto 被放在一起讨论,不是因为 Web3 想硬蹭 AI。更准确地说,是因为 Agentic Payment 把互联网过去没有解决好的“支付原生性”问题重新翻了出来。
信息可以原生地在互联网上流动。但价值长期不能。Agent 的出现,正在倒逼互联网补上这一层。
这也是为什么 x402、L402、T402 这些协议值得关注。它们并不是简单地说“让 AI 用加密货币付款”,而是在尝试定义一种新的交互方式:
机器请求资源,机器理解价格,机器验证授权,机器完成支付,机器获得服务。如果说银行卡解决的是 checkout,那么这些协议解决的是:
机器之间如何发起一笔支付。而一旦进入这个问题,稳定币和区块链就不再只是支付工具,而会变成 Agentic Payment 的底层结算语言和执行环境。
三、为什么是稳定币:Agent 需要稳定的计价单位,而不是波动资产
如果 Agent 真的需要一种机器可读、可以自动执行的支付协议,那为什么大家讨论最多的是 stablecoin?为什么不是 BTC?为什么不是 ETH?为什么不是普通银行卡?
这里的关键,不在于“crypto asset”本身,而在于 Agent 到底需要一种什么样的支付资产。如果一个 Agent 只是长期持有资产,那它可能会关心涨跌、收益、风险敞口。但如果一个 Agent 是为了完成任务而付款,它最需要的不是投机资产,而是一个稳定的计价单位。
一个 research agent 调用一次数据 API,可能是 0.1 美元。一个 coding agent 调用一次模型推理,可能是 0.03 美元。一个 marketing agent 购买一次流量数据,可能是 1 美元。一个 procurement agent 自动比价、下单、支付,可能需要在预算范围内控制每一笔支出。
在这些场景里,Agent 不是在做交易,也不是在炒币。它是在完成任务。所以,它需要知道:这个资源到底多少钱?这次调用会不会超过预算?这笔付款是不是在用户授权范围内?服务交付之后,成本能不能被准确记录?
如果支付资产本身每天剧烈波动,Agent 的预算管理就会变得很奇怪。今天一个 API 调用值 0.1 美元,明天因为币价波动变成 0.12 美元或者 0.08 美元,这对于交易市场可能没什么,但对于机器按需购买资源来说,会增加很多不必要的复杂度。
这就是为什么 Agentic Payment 里更自然出现的是稳定币,而不是高波动的 crypto asset。
稳定币的第一层价值,是提供一个更接近现实商业世界的计价单位。今天大量 API、SaaS、数据服务、模型服务、云服务,本来就是以美元计价的。Agent 如果要按需购买这些服务,用美元稳定币作为支付资产,就可以直接把预算、价格、授权和账单放在同一个单位里。
这件事听起来很普通,但对 Agent 很重要。因为 Agent 不只是“付钱”,它还要做判断。它要判断这次调用值不值得。它要判断预算够不够。它要判断是否需要回到用户确认。它要记录任务成本。它还要在出错时解释:为什么花了这笔钱。
所以,Agentic Payment 需要的是一种低波动、机器可读、可以被程序直接调用的支付资产。稳定币刚好比 BTC、ETH 这类波动资产更接近这个需求。
第二层价值,是稳定币更适合小额、高频、即时结算。前面讲 x402 时,其实已经能看到这个趋势。Coinbase 对 x402 的定义就是通过 HTTP 实现即时、自动的 stablecoin payments,让 API、数字内容和服务可以向 human 和 machine clients 收款,而且不需要账户、session 或复杂认证。 这句话背后有一个很关键的变化:支付不再一定要发生在完整的 checkout 页面里,而可以发生在一次 API 请求里。
Agent 请求一个资源。服务方返回 402 Payment Required。Agent 判断价格和授权。Agent 支付稳定币。服务方验证后释放资源。
这套流程天然适合小额、高频、按需调用的场景。比如一次数据查询、一次模型调用、一次内容解锁、一次链上分析、一次图表生成。Tether WDK 的 x402 文档也把这个点说得很直白:AI agents 需要以程序化方式为资源付款,而 x402 让 agent 可以在一次 request-response cycle 里发现价格、签署付款并获得资源。
这和银行卡不是一个使用语境。银行卡更适合人类消费里的 merchant checkout。稳定币更适合作为机器调用资源时的即时结算资产。当然,这不意味着银行卡会消失。Stripe 和 Tempo 的 Machine Payments Protocol 就明确支持两条路径:一条是 direct on-chain crypto payments,另一条是 cards、wallets 等 fiat payments。Stripe 官方也提到,商户可以通过 MPP 接受来自 agents 的付款,既可以用 stablecoins,也可以用 cards 和 BNPL 等 fiat payment methods。
所以更准确的判断不是“稳定币替代银行卡”,而是:银行卡适合已经存在的商户网络和 checkout 场景。稳定币更适合开放网络里的机器按需支付场景。
第三层价值,是稳定币天然更适合跨平台和跨境。Agent 不一定只在一个平台里工作。一个 Agent 可能调用美国的数据 API、欧洲的模型服务、亚洲的内容接口、链上的分析工具,再和另一个 Agent 发生交易。如果每一层都依赖不同国家的银行账户、收单机构、本地支付方式和结算周期,整个任务链会被支付系统切碎。但稳定币是互联网原生资产。它可以 7×24 小时流转,可以跨平台、跨钱包、跨应用调用,也可以被智能合约或支付协议直接处理。这对于人类用户来说可能只是“更快到账”。但对于 Agent 来说,意义更大。因为 Agent 的执行不是按照银行营业时间发生的。
它不应该因为周末、跨境、银行清算窗口、商户账户体系而中断任务。它需要的是一种随时可用、可自动调用、可被验证的结算资产。
这也是为什么 x402、Tether WDK 对 x402 的支持,以及围绕 USDT / Tether 生态出现的 t402 探索,都在往同一个方向走:把稳定币支付变成机器可以直接调用的 web stack 组件,而不是让 Agent 先进入一个人类设计的支付页面。
但这里也需要泼一盆冷水。稳定币不是没有问题。
不同稳定币的储备透明度、发行主体、监管状态、赎回能力、链上流动性都不一样。BIS 在 2025 年 Annual Economic Report 里也明确批评过稳定币,认为它们在 singleness、elasticity、integrity 这些货币体系关键标准上存在不足,不应该被简单视为现代货币体系的完整替代品。
更准确的说法是:稳定币不是完美货币,但它是目前最接近 Agentic Payment 需求的互联网原生结算资产之一。
它的价值不在于“去中心化叙事”,而在于它同时满足了几个条件:价格相对稳定。可以被程序调用。可以跨平台流转。可以 7×24 小时结算。可以和 HTTP-native payment、钱包、智能合约、链上审计结合。
这就是为什么 Agentic Payment 一讨论到开放网络里的资源调用,稳定币就会自然出现。因为 Agent 需要的不是一张“会刷卡的手”,而是一种可以被软件直接理解和使用的钱。
如果说信用卡是为人类消费设计的支付凭证,那么稳定币更像是为机器经济准备的结算语言。
当然,这个语言还不成熟。它需要更好的合规框架、更稳定的发行机制、更清晰的风控、更完善的钱包权限管理,也需要和 AP2、x402、MPP 这类协议结合,才能真正进入可大规模使用的 Agentic Payment 场景。
但方向已经很清楚:Agent 需要稳定的价格单位,需要即时的结算资产, 需要可以被程序调用的钱, 需要跨平台、跨国界、跨服务的支付能力。
这就是稳定币在 Agentic Payment 里不可忽视的原因。不是因为所有支付都要变成 crypto payment。而是因为当交易对象从“人类消费者”变成“软件主体”,稳定币第一次让“钱”变得更像互联网协议的一部分。
但稳定币只回答了一个问题:Agent 用什么钱付款。它还没有回答另一个问题:当 Agent 在开放网络里花钱之后,这笔钱是谁授权的、花在哪里、有没有越权、服务有没有交付。这个问题,就会把我们带到 blockchain。
四、为什么需要区块链:不是为了上链,而是为了让 Agent 的行为可验证
就算 Agent 需要稳定币付款,为什么一定要 blockchain?不能是一个中心化账本吗?不能是 Stripe、Visa、银行,或者某个平台自己记账吗?
当然可以。如果这个 Agent 只在一个封闭平台里活动,比如只在 Amazon 里购物,只在某个 SaaS 里调用服务,只在一个企业内部系统里做采购,那中心化账本完全够用。平台自己知道用户是谁,Agent 是谁,权限是什么,花了多少钱,服务有没有交付。
但 Agentic Payment 真正有意思的地方,恰恰不是 Agent 在一个封闭平台里帮你点付款按钮,而是它可能会跨平台、跨服务、跨钱包、跨国家,甚至跨不同 Agent 去完成一个任务。到了这个阶段,问题就不只是“钱能不能付出去”,而是这笔钱为什么付出去、是谁授权的、Agent 有没有越权、服务方有没有交付、如果出错了责任应该落在哪里。
这几个问题,才是区块链在 Agentic Payment 里真正有价值的地方。不是因为所有交易都必须上链,也不是因为链上一定比银行高级,而是因为当 Agent 开始替人执行任务、调用服务、处理资金流时,它的每一个经济动作都需要留下可以被验证的记录。
人类付款的时候,其实可以忍受很多不透明。买了一个服务没收到,可以找客服;公司采购出了问题,可以翻合同、找财务、查邮件、开会扯皮;银行卡扣错了,可以找银行走争议处理。这些机制很笨,但人类社会长期就是这么运行的。
Agent 不一样。Agent 的交易频率可能更高,金额可能更小,服务方可能更多,执行链条也更长。如果每一笔都要靠人工事后查账、截图、对邮件、找客服,那 Agentic Payment 就失去了意义。所以,Agent 需要的不是一个更酷的钱包,而是一条更清楚的责任链。
比如,用户给 Agent 一个任务:这周最多花 100 美元,帮我做一份市场分析,只能购买数据、模型调用和图表生成服务。然后 Agent 去请求一个数据 API,服务方返回这次查询 0.2 美元。Agent 判断这笔钱在预算内,于是完成付款,服务方收到钱后释放数据。这个过程里,真正重要的不是“用了哪条链”,而是事后我们能不能回答几个问题:用户当时给过什么授权,Agent 买的是什么,这笔钱有没有超过预算,服务方有没有真的返回数据,如果后面发现 Agent 被 prompt injection 诱导买了不该买的东西,能不能追溯。
这也是为什么我觉得,讨论 Agentic Payment 时重新看 Bitcoin 白皮书,其实不是为了怀旧。Satoshi Nakamoto 当年要解决的核心问题,并不是“发明一种可以交易的资产”,而是如何在没有可信第三方的情况下,让一笔电子现金的转移被网络验证、排序和记录。白皮书里写得很清楚:网络会把交易通过哈希写进一条持续增长的 proof-of-work 链,形成一份如果不重做工作量就无法更改的记录。
Agentic Payment 面对的问题不完全一样。它不只是 double-spending,而是 Agent 的授权、越权、交付和责任。但它们有一个共同点:一旦经济行为发生在开放网络里,可验证的交易记录就不再是附属品,而是基础设施本身。
这就是区块链的意义。它不是让支付变得玄学,而是让一部分原本藏在平台数据库里的状态,变成可以被外部验证的状态。至少在理想情况下,付款记录、授权凭证、服务访问、退款条件、预算消耗,都可以被更标准化地记录和验证。对人类用户来说,这可能只是“账更清楚”;但对 Agent 来说,这可能是它能不能被信任的基础。
因为 Agent 不是人。它不能靠“我记得我当时是这么想的”来解释行为。它需要一套外部可验证的证据链。
这也是为什么 AP2、x402、稳定币和 blockchain 经常会被放在同一张图里讨论,但它们其实不是一回事。AP2 本身不是去中心化协议,也不是区块链协议。Google 对 AP2 的定位,是一个 payment-agnostic 的开放框架,让用户、商户和支付服务商可以在不同支付方式之间,更有信心地完成 agent-led payments;AP2 specification 也把它定义为让 AI agents 能够安全、自主地代表用户完成支付的开放协议。
所以更准确地说,AP2 更像是 Agentic Payment 的授权与信任层,负责表达用户意图、授权范围和责任边界。x402、L402、T402 更像是支付请求层,解决 Agent 请求一个资源时,服务方如何向它发起付款要求。稳定币是结算资产,解决 Agent 用什么稳定单位付款。Blockchain 则是可验证状态层,解决交易记录、结算状态和后续执行能否被外部验证。
这几层不是一回事,但它们放在一起,才比较像一套真正的 Agentic Payment 基础设施。否则就会变成一个很尴尬的状态:Agent 很智能,可以帮你找服务、比价格、做决策,但一到付款,就又回到人类世界那套流程:注册账号、绑卡、买套餐、查账单、找客服、走报销。那它就不是 Agentic Payment,只是一个更会点按钮的浏览器助手。
当然,这里也不能过度乐观。让 Agent 接入链上支付,不是没有风险,甚至风险会更直接。传统支付里,很多交易还能争议、冻结、撤回。链上交易一旦发出去,很多时候就没那么好追回。如果 Agent 被攻击了,如果用户授权范围写得太宽,如果服务方收了钱不交付,如果一个恶意网站诱导 Agent 付款,如果一个 Agent 一晚上把预算全花完,这些都不是小问题。
所以,Agentic Payment 不是简单地让 Agent 拿一个钱包,然后说“去吧,自己花钱”。那太危险了。真正需要的是一整套控制机制:额度、白名单、黑名单、授权范围、风险等级、人工确认、暂停开关、审计记录。小额、低风险、机器原生的调用,可以自动化;大额、高风险、涉及真实世界履约的交易,还是应该回到人类确认。
所以我更愿意把 blockchain 在 Agentic Payment 里的角色理解成:它不是用来证明 Web3 比传统金融高级,而是用来给 Agent 的经济行为提供一层可验证的底座。Agentic Payment 需要 blockchain,不是因为所有支付都应该上链,而是因为当 AI Agent 开始在开放网络里花钱,我们需要一种方式证明,它花的钱是被授权的,它买的东西是可记录的,它的行为是可追溯的,它造成的问题是可以追责的。
这才是区块链在这个问题里的真实位置。不是信仰,不是叙事,也不是“AI + Web3”硬拼,而是当机器开始参与经济活动,原来的账户体系和平台数据库不一定够用了。我们需要一层更开放、更标准化、更容易被机器读取和验证的经济状态层,而区块链至少提供了一个方向。
五、不是替代银行卡,而是支付系统开始分层
所以讲到最后,我并不认为 Agentic Payment 会简单走向一个结论:稳定币替代银行卡,区块链替代传统支付网络。
这个判断太粗暴,也太容易被现实打脸。至少在很长一段时间里,银行卡、信用卡、Apple Pay、Visa、Mastercard、Stripe、PayPal 这些体系仍然会存在,而且会继续承担大量真实世界消费场景里的支付入口。人类在电商网站买东西、订酒店、买机票、线下消费、企业采购,这些场景不会因为 Agent 出现就突然消失。
甚至在 Agentic Commerce 的早期,Agent 很可能就是先接入这些已有支付体系。
因为现有商户网络已经很成熟,消费者已经有卡和钱包,商户已经接好了收单,银行和卡组织已经有成熟的风控、争议处理、退款、合规和身份体系。对于“AI 帮我完成一次购买”这种场景,直接沿用现有 rails 是最现实的路径。
所以问题不是“卡会不会消失”。
问题是,Agentic Payment 会不会只停留在这个层面。如果 Agent 只是帮人点击 checkout,那它确实可以继续用银行卡。但如果 Agent 开始进入更开放的任务网络,去调用 API、购买数据、支付模型服务、结算算力、解锁内容、和另一个 Agent 交易,那它需要的就不是一个更智能的支付按钮,而是一套新的支付协议栈。
这也是为什么我觉得,未来更可能出现的不是“银行卡 vs 稳定币”,而是支付系统开始分层。
在人类消费和成熟商户网络里,银行卡、信用卡、钱包、银行账户仍然会是主流。在 Agent 帮人完成购物、订票、订酒店、SaaS 续费这些场景里,传统支付 rails 也会继续发挥作用。Agent 只是进入已有的 commerce flow,帮用户更自动化地完成交易。
但在 API、数据、模型、算力、内容、链上服务、Agent-to-Agent 交易这些更机器原生的场景里,稳定币和区块链会更容易长出来。因为这里的支付对象不是传统商户,而是数字资源;交易金额可能很小,频率可能很高;服务方可能来自不同平台、不同国家、不同系统;整个过程最好可以被机器自动理解、自动支付、自动验证。
如果用一句话概括:银行卡解决的是人类消费时代的付款问题,稳定币和区块链更像是在解决机器经济时代的结算语言和可验证执行环境问题。
当然,这并不意味着稳定币和区块链已经准备好了。今天的链上体验仍然复杂,钱包管理仍然不够友好,稳定币监管仍然在变化,不同链之间的流动性也很分散。更关键的是,让 Agent 直接控制资金本身就很危险。如果没有权限管理、额度控制、风控机制、人工复核和审计系统,Agentic Payment 很容易从“自动化”变成“自动闯祸”。
所以,Agentic Payment 的真正落地,不会是让 Agent 拿着钱包到处乱花钱。
它更可能是一个逐步演进的过程:先进入现有支付系统,帮用户完成更自动化的 checkout;再获得更细粒度的授权能力,比如预算、白名单、使用范围、时间限制、风险等级;然后 API、数据、模型和内容服务开始支持机器可读的支付请求,让 Agent 可以按需购买资源;再往后,稳定币才会成为部分机器原生场景里的结算资产,尤其是小额、高频、跨平台、跨境的数字服务调用。
从这个角度看,Agentic Payment 不是某一个公司、某一条链、某一个稳定币、某一个协议就能单独完成的事情。它更像是整个支付系统在面对 AI Agent 这个新主体时,被迫重新拆分和重组。
过去,支付系统默认服务的主体是人和公司。未来,支付系统可能还要服务一种新的主体:被授权的软件代理。
它不是法律意义上的人,也不是传统意义上的企业账户,但它会发起请求、比较价格、调用服务、消耗资源、触发付款、留下记录。当这样的主体开始大量出现,支付系统就必须回答新的问题:它是谁,它代表谁,它被允许做什么,它能花多少钱,它买了什么,它有没有越权,出了问题谁负责。
这些问题,已经不是一个简单的支付按钮能解决的。
所以回到文章最开始的问题:AI Agent 会用银行卡吗?
会。
但它不会只用银行卡。
银行卡会继续解决 checkout,稳定币会开始解决机器原生的小额即时结算,区块链会提供一部分可验证状态和执行环境,AP2、x402、L402、T402 这类协议会尝试把授权、支付请求和资源访问连接起来。
这才是 Agentic Payment 最值得关注的地方。它不是让 AI 多一个付款功能。它是在逼我们重新思考:当机器开始参与经济活动,互联网到底需要一套什么样的支付系统。
