Agent 开始自己刷卡：自主支付的三道关
先说一个冷知识。
1997 年，万维网的设计者们在写 HTTP 规范时，预留了一个状态码：402 Payment Required（要求付费）。他们的设想很超前——将来网页可以为每一次访问、每一份数据收一笔极小的钱，几分之一美分，自动结算，不需要任何人点"确认"。然后这个状态码就闲置了。整整 28 年，没人真正用它，因为卡组织处理不了 sub-cent（亚分）级别的交易，而人类也不可能为看一篇文章去走一遍收银台。
2025 年 5 月，Coinbase 把它激活了。基于 402 的 x402 协议上线，到 2026 年 6 月，Coinbase CEO 说这条协议上已经跑过 1.6 亿笔自主交易。而就在几天前——2026 年 7 月 2 日——Cross River 银行和 Stripe 正式宣布，为 AI Agent 提供银行级的一次性虚拟卡：Agent 可以自己付钱，但从头到尾碰不到你真实的卡号。
这些信号拼在一起，指向同一件事：Agent 正在跨过一个临界点——从"能读、能写、能调 API"，走到"能自己花钱"。而一旦软件能自主花钱，一个被搁置了很多年的问题就必须现在回答：你怎么放心让一段程序替你刷卡？
这篇文章把这件事拆成三道关——授权、结算、追责。前两道，工程上已经跑通了；第三道，是整个行业现在最悬而未决的地方。
一、为什么是现在：为人类造的支付轨道，喂不了机器
先理解一件事：现有的支付基础设施，每一个环节都默认"有个人在回路里"。
信用卡要人填账单地址；订阅账单按月走，对应的是人的决策节奏；再精巧的支付 API，链条里某处也总假设有个人在发起或批准这笔转账。这套东西服务人类几十年，没问题。但 Agent 一上来，就把这些假设的荒谬之处以机器的速度暴露出来了：
- 一个按毫秒消耗 API token 的 Agent，不可能等到月底出账单；
- 一个多 Agent 工作流——一个 AI 雇另一个 AI 干子任务——中间没有一只手能去掏信用卡；
- 经济账也算不过来：一个卖 AI 产品的公司，token 一被消耗就产生算力成本，可收入要按月滞后回来。理想模型是按 token、实时结算，但卡组织的轨道做不到——sub-cent 规模下光手续费就超过交易本身，而每秒上百万笔的结算速度，会直接压垮任何为人类购买节奏设计的账单系统。
Stripe 在 2026 年 4 月的 Sessions 大会上，一口气发了 288 个新产品，背后就一个论断：为人类造的支付基础设施无法服务机器，Agent 需要自己的轨道。
但真正有意思的，是那个 402 状态码为什么"技术没变、却突然能用了"。答案不在技术侧，在买家侧。经济学里有个概念叫心理交易成本（mental transaction cost）：人在决定要不要花钱时，哪怕金额再小，也有一层认知摩擦——一篇一美分的付费文章，带来的犹豫不比一份 10 美元的订阅少，因为"做决定"本身就是成本。Agent 没有心理交易成本。 对它来说，一次付费就是一次函数调用：判断资源是否需要、执行支付、继续。这才是同一个 402 熬了 28 年、如今突然通了的根本原因——不是轨道变好了，是换了一种根本不会犹豫的买家。
二、第一道关·授权：怎么让 Agent 花钱，又不把卡给它
Agent 要花钱，第一个问题不是"怎么付"，而是"怎么授权"——你怎么把花钱的权力交给它，又不至于把家底全押上去？
这里有两条正在成形的技术路线，本质是同一件事：把用户的意图和边界，压进一张可验证、有约束、会过期的凭证里。
第一条：Mandate（授权令）。 这是 Google 主导的 AP2（Agent Payments Protocol）的核心概念——一份数字签名的声明，明确定义 Agent 被允许做什么。它有两种形态，分别对应两种场景：
- 意图授权（Intent Mandate）：用户不在场时，把"意图"预先授权给 Agent。比如"帮我盯着这双球鞋，降到 800 块以下就买，上限一双"。Agent 之后在这个边界内自己行动。
- 购物车授权（Cart Mandate）：实时场景下，Agent 把最终购物车摆到用户面前，用户用密码学签名批准这一单。签的是"就这一车、就这个价"。
关键在于 Mandate 的几个属性：防篡改、可验证、可撤销、不可抵赖。它是一份"可携带的、密码学签名的意图证明"——谁授权了什么、边界在哪，事后任何一方都能验证，也谁都赖不掉。这一点在第三道关会变得极其重要。
第二条：一次性令牌 / 单次虚拟卡。 这是 Stripe 这一侧的做法。它的 Shared Payment Token（SPT，共享支付令牌）是一个限定范围、限定时间、绑定上下文的授权：令牌里写死了能付给哪个商户、最多多少钱、在什么时间窗内有效；Agent 全程拿不到底层的真实凭证；一旦 session 结束或额度用尽，令牌立即失效。它的 Link 钱包（覆盖 2.5 亿用户）则更进一步——Agent 每次要付款，就临时签发一张一次性虚拟卡，只对这一笔交易有效，真实卡号、账单地址、CVV 从不暴露给 Agent 或商户；用户能预设额度和"需人工批准"的规则，事后在账户里看到完整消费记录。
7 月 2 日 Cross River 的意义就在这里：它给这套虚拟卡补上了银行级的合规底座——卡组织规则、反洗钱（AML）、了解你的客户（KYC）、欺诈责任框架。这正是"工程原型"和"可部署的金融基础设施"之间的分界线。
熟悉这个系列的读者会发现，这一关和之前讲 Agent 直连数据库的身份传播是同一个母题：不要把万能凭证交给一个概率式、随时可能越界的执行体，而是给它一张"替谁做、能做什么、做到哪为止"都写清楚、且可验证的收敛凭证。 数据库那边叫 OBO token exchange，支付这边叫 Mandate 和 SPT——形态不同，逻辑一模一样。
三、第二道关·结算：让钱在机器速度下流动
授权解决了"能不能花、花的边界"，下一关是纯工程问题：钱怎么在机器的速度和粒度下真正流动起来？
x402：把支付塞进 HTTP 握手。 x402 复活的就是开头那个 402 状态码，做法极简，四步一个来回：
- Agent 请求一个付费资源；
- 服务器返回
402，附上机器可读的支付指令：价格、接受的稳定币、区块链网络、收款钱包地址； - Agent 签一笔 USDC 支付授权，带着支付凭证重新请求；
- facilitator（结算方）验证链上到账，服务器返回资源。
在 Coinbase 的 L2 网络 Base 上，整个来回约 2–4 秒，成本约 0.0001 美元。没有账号、没有 API key、没有账单面板、没有人在回路里。x402 在 2026 年 4 月被贡献给了 Linux Foundation 旗下的 x402 Foundation。
MPP：给结算加一层"会话"。 x402 每次请求独立结算一次，适合孤立、低频的调用。但真实的 Agent 活动往往是连续、高吞吐的——一个编程 Agent 在一个 session 里跨几百次函数调用消耗算力，或一个流式 AI 产品按机器速度连续消耗 token 好几个小时。每次都上链结算，成本和延迟都受不了。
Stripe 和 Tempo 合作的 MPP（Machine Payments Protocol，机器支付协议）在 402 之上加了一个会话层：Agent 先对一个已注资的钱包预授权一个额度——就像在酒吧开一个 tab——然后随着资源消耗持续流式付款；交易在链下累积，按间隔批量上链结算。这样每笔延迟压到 100 毫秒以内，也免掉了每笔的 gas 费。
MPP 和 x402 最关键的设计差异是不绑定支付方式：x402 是区块链原生、只结 USDC；而 MPP 通过前面说的 Shared Payment Token，既能走稳定币，也能走信用卡、借记卡乃至先买后付。底层的 Tempo 是 Stripe 和 Paradigm 合建的支付专用 L1——它刻意只优化支付结算需要的东西（快速最终性、低费用、高吞吐），而不是以太坊那种通用可编程性。原因很直接：以太坊 12–15 秒的出块、还常要多个区块才最终确认，和 Agent 速度的商业结构上就不兼容。
顺便说一句：在这套架构里，稳定币不是给消费者的产品，而是一个后端优化——结算更快、转移更便宜、比卡组织更可编程。用户和开发者甚至不需要知道底层发生了区块链的事。
四、第三道关·追责：错了谁担——最难，也最没建好的一关
前两关，工程上都跑通了。第三关，是整个行业现在最悬而未决的地方：当一个 Agent 花错了钱，谁负责？
这不是杞人忧天。IMF 在 2026 年 4 月的一份分析里，明确把 agentic 支付列为对消费者保护、市场稳定、监管的实质性风险。核心问题是结构性的：几乎所有管支付的消费者保护法律——电子资金划转法（EFTA）、拒付（chargeback）权利、欺诈责任框架——都建立在一个假设上：一笔交易由人发起、由人批准。而当一个 Agent 在被授权的范围内行动、却越了界，或者被一个伪装的欺诈商户骗了，现有法律没有清晰答案：该由用户、Agent 开发者、支付处理方，还是商户来担责？
更棘手的是欺诈形态。Visa 的分析点出一个现有检测手段搞不定的场景：一个被攻击者控制的、已通过验证的 Agent session，能骗过认证、执行恶意交易——因为它的行为看起来跟一个合法的自动化 session 毫无区别。 Agent 那种让它好用的特质（速度快、没有人类的随机性），恰恰也让它难以和"精心构造的机器人"区分开。
技术侧不是没有答案，而是答案只到一半。前面第一关讲的 Mandate，它的"不可抵赖 + 可验证审计链"就是为这一关准备的：每一笔 Agent 支付，理论上都能顺着签名链回溯到那个授权它的人、那一条具体的意图。Stripe 的 Radar 风控系统也更新了，用来区分合法的 Agent 交易和欺诈行为。但这些能力都还在各自的孤岛里——真正缺的，是一个跨生态的共享标准：Agent 身份怎么跨平台验证、消费范围怎么传达给商户、Agent 超出授权（out of mandate）时纠纷怎么裁决。x402 Foundation 正在推动把它做成 W3C 标准，但这个过程通常要好几年。
这一关，正是我在上一篇组织边界的文章里提到的"责任的边际成本"在支付场景的具体化：Agent 的真实成本从来不只是算力，还有出错和违规的赔付。这笔责任压不到零，而在它被制度接住之前，规模化的自主支付就始终悬着一只靴子。
五、协议腰之争：谁定义标准，谁拿中心位
看到这里可能会晕：x402、MPP、ACP、AP2……到底什么关系？
它们其实不是竞品，而是同一个栈里的不同层。这正是我之前讲的"薄协议腰"——Agent 经济的价值和控制权，会向定义这些标准的那一层聚集。
- 执行层：x402。 最底层，把一次支付嵌进 HTTP，链无关、极简，专为微支付和按次付费的 API 而生。
- 会话层：MPP。 在执行层上加会话/额度/流式结算，解决高频连续消耗的账单问题，且不绑定支付方式。
- 商户层：ACP（Agentic Commerce Protocol）。 Stripe 和 OpenAI 共建、Apache 2.0 开源，解决"商户怎么变得对 Agent 友好"：商户仍是 merchant of record，走现有 PSP，Agent 通过它安全地发起结账。已经在 ChatGPT 的 Instant Checkout 里生产运行。
- 授权层：AP2。 Google 主导、60 多家合作方，定义跨生态的信任与授权模型——也就是前面讲的 Mandate。它可以给底层的 x402 结算背书，让一笔 USDC 支付带上和刷卡一样的审计链。
一个企业完全可能同时用好几层：用 ACP 支持 Agent 购物，用 AP2 做内部治理与审计，用 x402 试机器对机器的数据付费。真正的风险不是选错，而是忽视它们，直到它们已经嵌进你依赖的平台里。
而这一层的争夺已经白热化：Visa 推出了 Trusted Agent Protocol，Mastercard 的 Agent Pay 在试点，x402 Foundation 的创始成员里坐着 Google、Visa、AWS、Mastercard、Circle、Microsoft、Shopify、American Express——这个阵容本身就说明，没有哪一家能独占这条腰。但也要记住上一篇的教训：协议腰若最终被少数平台把持，"薄腰"随时会变"厚腰"，去中心化的叙事开场，最后价值还是可能重新向中心聚集。
六、工程落地：现在该做什么
如果你是开发者或企业架构师，这件事不是"等标准定了再说"，而是有几件可以现在做的：
- 商户侧：把自己变得"Agent 可读"。 出现了一类两年前还不存在的商户——没有店面、没有结账页、没有人类顾客，整个商业界面就是一个供 Agent 查询和交易的 API。对它们，优化的重点从"结账页转化率"变成了Agent Experience：目录是不是机器可读、定价能不能编程查询、结账支不支持 SPT/ACP。Agent 没有品牌忠诚、只有完美的价格敏感——谁先让自己被 Agent 读懂，谁就在"机器来购物"的经济里有结构性优势。
- 企业侧：先立规矩，再放 Agent。 在 sandbox 里评估 ACP/AP2 集成；在 Agent 上线之前就设好花钱的边界——额度、白名单商户、需人工批准的阈值；让财务和采购团队尽早参与，明确"Agent 发起交易时谁担责"。
- 别跳过可观测与风控。 Agent 交易的速度和无变化性让它难以和恶意机器人区分，欺诈检测必须能识别"合法 Agent 交易 vs 被劫持的 Agent session"。这也呼应一个更普适的落地原则：验证不了的东西，不要放它自主执行。
七、ICE 观察
技术层面：这一波的关键词是"令牌化的授权" + "协议分层"。把花钱的权力，收敛成一张可验证、有边界、会过期的令牌（Mandate / SPT / 单次卡），是所有方案的共同底座——它和数据库场景的 OBO、组织场景的薄协议腰，是同一套思想在不同层的复用。谁定义了授权层和执行层的标准，谁就拿走了这条腰的中心位。
落地层面：三道关的成熟度是倒序的——结算（第二关）最成熟，授权（第一关）在快速标准化，追责（第三关）最不成熟且卡在法律侧。所以企业当下能控的，恰恰是自己那一段：把授权边界和额度策略当成上线前的硬门槛，而不是等出了事再补。裸奔放一个有宽泛授权的 Agent 去花钱，是现在最贵的错误。
本土视角：国内其实早有"授权代扣"的雏形——免密支付、代扣协议、限额授权，逻辑上和 Mandate 是近亲。但真正缺的是两样东西：一是跨 Agent、跨平台的授权与结算标准（现在各家钱包各管各的），二是Agent 越权时的追责与纠纷裁决机制。这恰好可以和正在落地的智能体互联互通国标、Agent 身份证接起来——身份可验证是授权可追溯的前提。谁把"授权令牌 + 可追责审计链"这套东西先做成国内标准，谁就握住了本土 Agent 支付的那条腰。
结尾
回到开头那个沉睡了 28 年的状态码。它一直都在那里，等的不是更好的技术，而是一种不会犹豫的买家。现在这种买家来了，支付的三道关也随之摆上台面：授权和结算，工程已经给出了漂亮的答案；而追责——错了谁担——还悬在半空。
Agent 能自己刷卡，是一件确定会发生的事。真正的悬念只剩一个：在软件替我们花钱花错的那一刻到来之前，身份、授权和责任的框架，能不能先建好；以及我们自己，知不知道该在什么时候按下那个"需要我批准"的按钮。