mt logoMyToken
ETH Gas
Tiếng việt

Stripe 的下一张牌:为 AI 支付搭建底座

sưu tầmcollect
đăng lạishare

让 Agent 能买,也让商户敢卖。

昨天整理了一下 Stripe Tour 的视频素材和内容,重新回看现场演示的几个 Demo,我发现都还挺有意思。

第一个 Demo 里,Stripe 大中华区解决方案架构师 Annice Liu 对 Kimi 说:帮我上线一个亲子出游服务。这个服务会根据家长的偏好和本地最新资讯,每周生成一份个性化的亲子出行周报。

接下来,Agent 开始自己找需要的服务:注册域名,把域名部署到 Cloudflare,通过 OpenRouter 接入模型,再接入 Supabase 保存用户偏好。几分钟后,一个原本只存在于对话里的想法,真的变成了可以打开的网站。

Stripe 的下一张牌:为 AI 支付搭建底座

这个demo里其实我们也看到海外软件的生态,它不是让 Agent 进入一家公司的封闭平台,寻找里面已经准备好的全部功能,而是让它组合一组独立服务。

Cloudflare 提供域名和部署,OpenRouter 提供跨模型入口,Supabase 提供数据库,Stripe Projects 则把这些服务的开通、配置和付费串在一起。每家公司只做自己擅长的一层,Agent 根据任务把它们拼成一个完整产品。

Stripe 联合创始人及CEO Patrick Collison 此前也提到,Stripe Projects 受到 Claude Code 工作方式的启发:当 Agent 写出一个产品,它很快就会需要日志、托管、数据库和模型等外部服务。Stripe 想做的,是让 Agent 可以直接发现并开通这些服务。

Stripe Projects 从想法到公开发布,由两三名工程师用了大约两个月完成,其间接入了约 50 项服务。他估计,在过去,这至少需要更大的团队和半年时间。

国内更常见的路径,是从超级 App 内部开始。账户、支付、商户、内容和生活服务原本就在同一个生态里,Agent 更容易在平台内部完成从需求到交易的闭环。它的好处是链路短、用户不需要管理多个账户;代价是 Agent 能调用什么、数据如何流动,往往更依赖单一平台的边界。

海外这种组合也不是天然更容易。Agent 每接入一个新服务,就多出一组身份、授权、账单和风险问题。过去这些事情由开发者逐个处理;如果 Agent 要自己搭产品,就需要一层基础设施把不同服务变成可以被发现、开通、计量和付款的资源。

这么看也会给Stripe收购OpenRouter提供另一个视角,Demo中OpenRouter 看起来只是一个模型接口,让 Agent 不必分别接入不同模型公司。但对 Stripe 来说,它代表的是 AI 产品运行时最频繁的一种消费:每一次模型调用,都要在价格、速度、可靠性和效果之间做选择,也会产生一笔可以计量的 Token 成本。

如果模型路由、Token 计量、Billing 和支付被连在一起,Stripe 管理的就不再只是产品卖出去以后怎样收钱,也包括一个 AI 产品运行过程中,怎样选择和购买模型能力。

从这个角度看,Stripe想做的,更像是给开放生态提供一层共同的资金、计量和权限系统,让 Agent 即使跨越多家公司,也能获得接近超级 App 内部的连贯体验。

另个Demo是 Meta 的个人 Agent Muse。用户让它寻找一张从波士顿直飞都柏林的往返机票,Muse 找到一个总价 470 美元的选项,确认乘客信息,然后问用户要不要完成预订。

到了付款环节,它没有要求用户把银行卡号发给 AI。Stripe的 agent 钱包 Link 弹出一个授权页面。用户可以看到金额、使用哪张卡,并在 “Deny” 和“Allow”之间做选择。只有用户批准以后,Agent 才拿到完成这一次交易所需的支付凭证,最后把机票订下来。

这两段演示放在一起,很像 Stripe 对 AI 经济的一张缩略图。

一边,Agent 可以自己搭建产品、调用服务、产生收入;另一边,Agent 也可以替人寻找商品、形成订单并发起付款。Stripe 想做的,并不只是给聊天机器人加一个付款按钮,而是把 Agent 从“会说话的软件”接进真实的商业系统。

Stripe 的下一张牌:为 AI 支付搭建底座

我们可以把这一年 Stripe 公布的产品、协议和 Demo 串起来,会发现它在AI支付做了不同的尝试。

AI 帮人购物,最先遇到的问题不是怎么刷卡,而是怎么准确地知道商户在卖什么。

人可以打开网页,看图片、筛选尺码、理解运费,再点击结账。Agent 如果只能模仿人类在网页上找按钮,就很容易选错规格、读到过期价格,或者在页面更新以后直接失效。

2025 年,Stripe 与 OpenAI 一起推出 Agentic Commerce Protocol,也就是 ACP。它把商品目录、库存、价格和结账过程变成一套机器可以调用的流程。当时第一个公开用例,是 ChatGPT 里的 Instant Checkout。

这一步的重要性不在于“ChatGPT 里也能买东西”,而在于 Stripe 开始把 Checkout 从一个给人看的页面,变成 Agent 可以调用的商业接口。

Stripe 还推出 Agentic Commerce Suite,它想让商户接入一次,就能面对不同的 AI 入口,不需要分别为 ChatGPT、Gemini、Copilot 或下一家 Agent 重做一套商品和结账系统。

商户仍然是 merchant of record,继续控制库存、税费、配送、退款、拒付和客户关系。AI 平台负责提出需求和带来订单,Stripe 负责把前面的自然语言请求翻译回商户原有的交易系统。

这也是 Stripe 与纯 AI 平台最大的不同。OpenAI、Google、Meta 争夺的是用户入口;Stripe 想成为所有入口背后都可以使用的商业基础设施。它不需要押中最后是哪一个 Agent 赢,只需要越来越多 Agent 开始参与交易。

Muse 采用的是一条类似的接入路径:先通过浏览器操作网站,让还没有专门适配的商户也能被访问;再与重要合作伙伴打通 API,让过程更快、更稳定。Zuckerberg 的判断是,未来企业会像今天拥有网站、邮箱和社交账号一样,拥有自己的 Agent。

浏览器操作解决的是“现在能不能用”,直接接口解决的才是“以后能不能稳定地做生意”。这也是 Stripe 要把商品、Checkout 和支付能力改造成 Agent 接口的原因。

Agent 能形成订单以后,下一个问题是:它凭什么使用用户的钱?

传统网上支付经常把“拿到了正确卡号”当成重要的信任信号。但对 Agent 来说,持有支付凭证,不等于获得了眼前这笔交易的授权。

Stripe 为此做了 Shared Payment Token,简称 SPT。它不是把真实卡号交给 Agent,而是生成一份受限制的支付凭证。这份凭证可以限定商户、金额、币种和有效时间,也可以被撤销。Agent 可以拿它去付款,却不能把它变成一张到处都能刷的卡。

Stripe 在 Sessions 2026 做过一个很直观的演示:Token 的额度是 25 美元。商户收取 25 美元时,交易成功;把金额改成 50 美元以后,Stripe 直接拒绝。

这看起来只是一个限额功能,实际却是 Agentic Payment 最关键的设计之一。

如果预算只写在 Prompt 里,那只是要求 Agent 自觉遵守;如果额度写进支付凭证,即使模型判断错了、被恶意指令影响,支付系统也不会放行。

大模型负责理解模糊意图,支付系统负责执行确定规则。

今年,Stripe 又把 SPT 扩展到 Visa、Mastercard 的 Agentic Token,以及 Affirm、Klarna 这类先买后付方式。它想做的不是再造一个支付网络,而是把不同网络的 Agent 授权,统一翻译成商户可以接收的支付凭证。

SPT 解决了“商户怎么安全收钱”,但消费者还需要一个地方管理:哪些 Agent 可以向我请求付款,我批准了什么,它最后花了多少钱。

这就是 Link Agent Wallet 的位置。

Agent 可以先向 Link 发起一笔 “spend request”,写清楚商户、金额和购买目的。用户在网页或手机上审核,批准以后,Link 再向 Agent 返回一次性虚拟卡或 SPT。用户原始的银行卡资料不会暴露给 Agent。

上面的第二个Demo就是一个例子,Stripe 在 Sessions 还展示过一个更小的例子:Claude 给演示者的女儿写了一封包含冷笑话的信,再调用 PostalForm 把 PDF 邮寄出去。Link 手机上弹出 3.40 美元的请求,用户看到商户和用途,用 Face ID 批准,Agent 随后完成付款和邮寄。

这两个例子一个是机票,一个是邮费,金额不同,背后的逻辑却相同:

用户不是把钱包长期交给 AI,而是批准一个有上下文、有金额、有对象的具体任务。

每一笔 Link Agent Wallet 支出仍然需要用户逐笔确认,未来也许会增加预算和免逐笔审批的规则。从接入名单看,到了 9 月,Muse、Grok Bot 和 Instinct 已经在使用 Link Agent Wallet。通过 Link 完成的 Agentic purchases,也在一个月内增长了 38 倍。

增长很快,但绝对交易量我想都还是在早期,但这依然是一个值得大家“幻想”的方向。

从Demo上的 Muse,到我真的开始用 Muse

在 Stripe Tour 看到这段 Demo 时,我还没有用 Muse。我最近开始用muse帮我做短视频和规划美国的行程,整个过程还是很丝滑的。它不只是给我列几个建议,而是能够记住前面的要求,继续查找和整理后面的安排,Personal Agent 可能真的会成为一个新的消费入口。

Meta 对 Muse 的商业化设想也已经更明确,Zuckerberg 提到,Muse 的基础版本会尽量保持免费,Muse Wonder 通过订阅收费;更长期看,当 Muse 帮用户省钱、赚钱或者完成交易时,Meta 希望从它创造的价值中取得一小部分。

Zuckerberg 还举了一个很具体的例子,他以前几乎不用 Instacart,但为了让 Muse 根据对话购买做饭需要的食材,专门注册了账户,现在反而每周会使用一两次。他由此提出,Agent 带来的不只是更高的转化率,它也可能创造原本不会发生的交易。未来,账户关系甚至不再只属于人,Agent 也会逐渐拥有自己的账户。

当然,想从交易里赚钱,不等于这门生意很容易成立。

如果商家付佣金,Muse 就要回答一个很现实的问题:它推荐某个酒店或商品,究竟是因为最适合用户,还是因为对方给的佣金更高?如果向用户收费,它又要证明自己节省的时间和金钱,确实值得额外付费。再往后还有买错、价格变化、取消、退款和售后,任何一个环节处理不好,都会消耗用户对 Agent 的信任。

这里也要分清 Muse 和 Stripe 想赚的不是同一笔钱。Muse 更接近一个交易入口,希望从“帮用户把事情办成”中获得订阅或成交收入;Stripe 提供的是支付凭证、授权、发卡、风控和交易处理,赚的是基础设施的钱。

但对 Stripe 来说,这仍然是一次很不一样的机会。收单业务本来就在处理消费者付款,Link 也早已直接保存消费者的支付方式。只是过去,Stripe 与消费者的关系更多发生在某个商户的结账页面里:用户完成付款,Stripe 帮商户把钱收进来。

Agent Wallet 把这种关系向前推进了一步。Stripe 开始直接管理消费者与 Agent 之间的连接:我允许哪个 Agent 请求付款、这次可以买什么、金额是多少、需不需要再次确认、买错以后有没有保护。变化是它从处理一笔消费者付款,进一步参与消费者怎样把支付权委托给 Agent。

如果 Personal Agent 最后真的成为人们搜索、比较和购买服务的入口,Stripe 甚至不需要自己做出最受欢迎的 Agent。它只要成为不同 Agent 都愿意接入、消费者也愿意信任的钱包,就能从商户结账背后的支付处理者,进一步成为消费者授权 Agent 花钱时调用的基础设施。

这条路当然很难,处理商户发起的收款,和持续管理消费者对 Agent 的授权,不是同一种产品关系。后者还要面对品牌、体验、隐私,以及每天都可能变化的用户信任。但也正因为 Stripe 正在从“完成这笔付款”向“管理谁可以替我付款”前移,一旦 Link Agent Wallet 真能占住 Personal Agent 的支付入口,它带来的想象空间会比多一个支付产品大得多。

消费者让 Agent 买机票,背后仍然是一笔熟悉的电商交易。但 Agent 自己也会消费。

它可能临时需要一份天气数据、一次图片生成、一段模型推理、一次身份核验,或者调用另一个 Agent 提供的能力。这些交易往往只有几美分或几美元,而且非常高频。

传统 API 的购买流程对机器并不友好,先注册账户、申请 API Key、选择月度套餐、绑定卡片,这些步骤通常都需要人介入。一个只想查询一次数据的 Agent,不应该先去买一整年的订阅。

Stripe 与 Tempo 一起推出 Machine Payments Protocol,也就是 MPP。它利用 HTTP 402 “Payment Required”,让服务在同一次请求里告诉 Agent:这个资源需要付费、价格是多少、可以怎样支付,Agent 根据已有授权完成付款,再拿到结果。

一个 Agent 创建并部署了一项 API 服务,另一个 Agent 用 MPP 和 Link 支付 2 美元,购买一次代码审查。另一个演示里,Agent 以极小金额购买天气数据。付款方式可以是通过 SPT 承接的银行卡,也可以是稳定币。

这条线与“AI 帮我购物”其实是两门不同的生意。

前者是 Agent 代表人消费,重点是用户身份、授权、售后和责任;后者是软件为了完成任务购买资源,重点是程序化、微支付、可观测和自动对账。

Stripe 同时做两条线,是因为它判断未来 Agent 不只是新的购物入口,也会成为新的企业客户和软件买家。

Patrick Collison 列出的下一步问题很具体:Agent 怎样注册和使用 Stripe、MCP 是否足够、Stripe CLI 应该怎样适配,以及 Agent 之间怎样付款、使用什么货币。他给出的判断是,未来大约三年内,按交易笔数计算,大多数交易的双方都可能是 Agent。这不意味着 Agent 会占据大部分交易金额;更可能出现的,是数量庞大、金额很小的 Agent-to-Agent payments。

这会让支付从一次购买动作,变成 Agent 协作过程中的基础协议。一个 Agent 为了完成任务,可能不断调用模型、数据、软件和其他 Agent;每一次调用背后,都需要身份、授权、计费和结算。

真实交易不是付完钱就结束了的。

机票价格可能在最后一步增加行李费;银行卡可能触发 3D Secure;商品可能缺货;Agent 可能买错尺寸;用户可能要求退货;商户还要判断这到底是可信 Agent,还是伪装成 Agent 的自动攻击。

最近Link Agent Wallet 的更新,开始把这些问题摆到台面上。

如果最终价格因为税费、运费或附加服务上涨,Agent 可以申请提高已授权金额,而不是重新下单、再次冻结一笔钱。如果付款需要额外验证,Link 可以给 Agent 一个链接,让它把用户带回 3D Secure 或身份核验流程。如果原来的卡被拒绝,Agent 也可以请用户换卡并重新发起支出请求。

同时也开始让 Agent 在用户许可下读取消费记录,用于判断常去的商户、预算和商品偏好。这会让个人助理更懂用户,也会把新的问题带进来:一个购物 Agent 应该看到多少金融数据?它能否用过去的消费习惯影响未来的选择?用户是否真正理解自己开放了什么?

更值得注意的是购买保护,符合条件的 Link Agent 交易已经覆盖意外损坏、物品遗失、降价、免手续费退货等情况,Muse 是第一个接入这项保护的 Agent。

这说明 Agentic Payment 真正的竞争,已经不只是“谁能让 AI 付出第一笔钱”,而是“AI 买错以后谁负责”。

支付行业最难复制的从来不只是一个付款按钮,而是付款背后的授权、风控、退款、争议和责任分配。

回头看 Stripe 这一年的尝试,大致可以归成四个位置:

• Agent 如何发现并理解商品;

• 商户如何接收来自 Agent 的订单;

• 用户如何把一部分支付权安全地交给 Agent;

• 机器如何直接购买 API、数据和计算资源。

ACP 和 Agentic Commerce Suite 在解决前两个问题,SPT 和 Link Agent Wallet 在解决第三个问题,MPP 在解决第四个问题。Radar、Checkout、Issuing、Financial Connections,以及 Stripe 原有的退款和争议系统,则把这些新入口重新接回传统支付世界。

把这些放在一起,刚好能从两端补全这张图。Zuckerberg 判断,Agent 会逐渐拥有自己的账户,并创造新的消费;Patrick 则判断,大量交易的双方最终都可能是 Agent。前者描述新的需求从哪里来,后者提出支付系统将面对什么。它们目前都还是方向判断,而不是已经发生的市场事实,但也解释了为什么 Stripe 要同时布局商户接口、个人授权和机器支付。

Stripe 并不只是想让 AI 使用 Stripe,它想让任何 AI 平台进入交易时,都绕不开 Stripe 已经擅长的那一层:把一个模糊的购买意图,变成商户敢接受、用户能撤销、系统可追责的一笔交易。

━

但现在还不是“AI 可以自己花钱”的成熟阶段

现在Agent 不只能生成购物清单、创建订单或者把人带到收银台。它确实可以在用户批准以后拿到受限凭证,并继续执行后面的交易。

但这与“AI 已经可以自主支配用户的钱”仍然有很大距离。

今天大部分公开案例仍然依赖逐笔确认,免确认预算仍停留在下一步规划里,而不是默认能力。跨平台的退款、重复下单、身份冒用和责任认定,远没有被彻底解决。

所以,也许2026 年可以被称为 Agentic Payment 的协议与基础设施元年,现在在发生的变化是 Agent 已经进入交易决策,并开始接触支付凭证;而支付公司正在把人类世界里原本隐含的信任,重新写成机器可以执行的规则。

未来成熟的 Agentic Payment,大概不会是“给 AI 一张卡,让它自由发挥”。

它更可能是另一种东西:用户先定义目标和边界,Agent 负责搜索、比较和执行,钱包与支付网络负责在最后一刻检查金额、商户、时间和用途;一旦出现错误,还有明确的退款、争议和责任链。

在上海的大屏幕上,这看起来只是一次很顺的机票预订,

但 Stripe 真正想卖的,是这笔交易为什么可以被放心地放行。

本文内容仅为个人观察与思考,不构成任何投资或商业建议。请读者结合自身理解与信息来源理性参考。

Tuyên bố từ chối trách nhiệm: Bản quyền của bài viết này thuộc về tác giả gốc và không đại diện cho MyToken(www.mytokencap.com)Ý kiến ​​và vị trí; vui lòng liên hệ với chúng tôi nếu bạn có thắc mắc về nội dung
community_x_prefix
X(https://x.com/MyTokencap)
community_tg_prefixcommunity_tg_name
(https://t.me/mytokenGroup)
Đọc liên quan