Stripe 在年度 Sessions 2026 上把 Link 往 AI 场景推了一步。

新版 Link 允许用户连接银行卡、信用卡、加密钱包和“先买后付”服务，也能管理账单、订阅和结账信息。变化在于，AI Agent 可以在用户授权后，通过 Link 代为发起支付。

这件事最容易被写成“AI 会自己购物”。但我更在意的是另一点：Stripe 没有把钱包直接交给 Agent，而是在钱包和 Agent 中间加了一层权限、审批和风控。

也就是说，AI 可以帮你发起付款，但还不能随便花你的钱。

Link 变成 Agent 可用的钱包入口

Link 不是 Stripe 新造的品牌。它原本就是 Stripe 体系里的快捷结账和数字钱包产品。

这次升级的重点，是 Link 开始服务 AI Agent 的任务流。比如购物、订票、预订、补货这类场景，Agent 不再只能停在“找到商品”这一步，而是可以进入付款环节。

但边界很关键。

Agent 不能直接拿到用户的信用卡号、银行账户或原始支付凭证。用户接入的是 Link，Agent 调用的是经过授权的支付能力。

对比项过去的 Link面向 Agent 的 Link影响
核心用途快捷结账、保存支付信息让 Agent 发起支出请求钱包变成权限入口
支付方式卡、银行账户等银行卡、信用卡、加密钱包、BNPL覆盖更像综合钱包
凭证处理用户向商户付款Agent 不接触原始凭证降低凭证泄露风险
用户动作选择支付方式并付款审核 Agent 的支出请求自动化仍受人控制

对普通用户来说，这比“AI 帮我买东西”更现实。

你真正要判断的是：要不要允许一个 Agent 替你发起支出请求；每次请求来了，你看不看得懂交易背景；如果未来出现免审批低额支付，你愿不愿意打开这个开关。

这不是体验细节，是信任门槛。

风控流程比自动下单更重要

Stripe 的设计不是让 Agent 拿着钱包自由消费。

用户需要先通过 OAuth 授权 Agent 访问 Link。Agent 发起付款时，会创建一笔支出请求，并带上交易背景。用户在网页或移动端审核后，支付才继续往下走。

审批通过后，Stripe 才会使用相应支付凭证完成交易。底层有两条路径：一次性虚拟卡，或 Shared Payment Token（SPT）。后者由用户的银行卡或银行账户提供支持。

这套能力来自 Stripe Issuing for agents。它支持虚拟卡、实时授权、消费控制和交易可见性。

支付行业真正关心的不是 Agent 会不会点“购买”。问题更硬：谁授权了这笔钱，最多能花多少，交易出了问题能不能查清楚。

目前的限制也要写清楚。

现在，支出请求仍需要用户审核。Stripe 称未来会加入消费限额，以及用户可选择的部分免审批场景。agentic tokens、稳定币等支付形式也只是计划支持，不能当成已经上线。

这里的分寸很重要。Link 现在更像“受控代付”，还不是“完全自主消费”。

开发者少造钱包，但商业闭环还要过三关

对做 AI 个人助理、购物 Agent、企业采购 Agent 的团队来说，Link 的直接价值很明确：少造一套钱包和支付凭证系统。

早期团队如果要让 Agent 帮用户订酒店、买票、采购办公用品，难点不只是调用商户接口。更麻烦的是付款权限、凭证隔离、风控记录和合规责任。

如果团队本来准备自建钱包，现在更合理的动作可能是延后自建，先评估 Stripe 的接入方式。支付和风控团队则要把 Agent 交易单独拉出来看：授权证据、限额策略、退款争议，不能完全沿用“人手动下单”的规则。

但这条路还没闭环。

至少有三件事现在看不清：

变量现在能看到什么还卡在哪里
用户信任每笔支出仍需审核免审批低额支付能否被接受
商户接受度Agent 可代发起支付商户如何处理误购、退货和争议
风控责任Stripe 提供授权、控制和可见性责任边界仍要靠场景验证

这也是 Stripe 和 PayPal、Apple Pay、Google Pay 的差别所在。

后几者更偏消费者钱包和设备侧支付体验。Stripe 这次押注的是开发者和 Agent 工作流，把付款能力嵌进自动化任务里。

我不太买账的是，把这件事直接说成“AI Agent 商业化突破”。现在还早。

更稳的判断是：Stripe 先把支付权限这块地圈出来。至于 Agent 能不能真的替用户高频花钱，要看免审批场景能否被用户接受、被商户承认、被风控系统兜住。

钱袋子这件事，从来不是能不能自动化这么简单。它要先让人敢授权。