让 Agent 替你付钱，还缺什么？（产品篇）

这是产品篇：讲用户、产品设计和支付生态里还缺什么。之后还会有一篇工程篇，展开第一层，讲 agent 系统具体怎么看清一个动作的后果、策略检查怎么实现。

AI agent 已经能替用户付钱了。可真到付钱这一步，大多数用户还是不放心：Visa 的调查里，只有 23% 的美国人信任 AI 替自己付款。

TL;DR

这篇想回答一个问题：Agent 已经能替用户付钱了，为什么大多数用户还不让它付？要补上什么，用户才愿意让 agent 替自己付款？

文中拿三个已经能替用户付钱的产品做例子：Google 的 Agentic Checkout、Meta 的 Muse，和创业公司做的 Instinct。

答案： 付款这一步已经能走通；用户还不让它付，是因为三层的风险都还控制不住：agent 看不清一个动作的后果，看不清时也不会先停下；支付系统的风控还算不出 agent 交易的风险，只好把损失推给用户；用户对 agent 的信任还没攒起来，也没有一条让同意范围逐步放大的梯子。

我把这个问题拆成三层，每一层回答一个更小的问题：

• 第一层，模型：agent 会不会做出用户没同意的事？ 会。模型会听错人、看错意图、越权、编造事实。三个产品各自公开了同一个结构的一部分：用户的同意记在模型改不了的地方，被标成「有后果」的动作执行前，由代码核对它有没有对应的同意；模型只负责判断「这个动作是什么」，只能喊停，不能放行。还没做到的有两半。一半是看清后果：网页不会告诉 agent 这一步要扣多少钱、能不能撤回，agent 只能从页面的 DOM（网页的结构代码）、按钮旁的说明和取消条款里推断，而推断是概率性的；更稳的办法是让网页或接口直接写明后果。另一半是后果没确认之前不执行：$258 那次（见开头），取消在报出费用之前就执行了。
• 第二层，支付系统：商家和银行能不能认出并接受 agent 替用户发起的付款？ 付款本身已经能走通：agent 拿到的是限定范围的付款凭证，拿不到用户的真实卡号。本质上缺的是风控：卡组织、发卡行和商家的风控都是按人的行为训练的，还分不出哪笔交易是 agent 发起的，也算不出它的风险。风险算不出来，规则就先把损失推给用户（agent 照用户的同意买错了，不属于任何一种拒付理由；拒付，就是持卡人向银行申诉、把钱要回去），大商家干脆不让 agent 进来。
• 第三层，用户：用户需要什么，才愿意让 agent 替自己付钱？ 用户信任支付宝和 Apple Pay，靠的是三件事：付之前知道自己同意了什么；出了问题，事先知道最多损失多少钱；买错了，能把钱拿回来。Agent 付款时用户不在场，这三件事都要重新设计，而且不会一次做成：支付宝的免密额度、花呗（支付宝的信用支付）的信用额度，都是跟着记录一步步放大的。用户对 agent 也一样，要先给一个小范围，看 agent 的表现再放大；现在连这条梯子都还没有。

问题：从「能下单」到「敢交钱」

这里说的 agent，是能自己打开网页、点按钮、填表、替用户办完一件事的 AI，不只是回答问题的聊天机器人。

能替人花钱的 agent 已经有好几个了。我用三个做例子：

• Agentic Checkout（Google）。用户在 Google 购物里追踪一件商品的价格，设一个预算；降到预算以内时，用户确认购买和收货信息，点「buy for me」，agent 用 Google Pay 在商家网站上替用户结账。2025 年 5 月在 Google 的年度开发者大会 I/O 上发布，2025 年 11 月在美国上线。
• Muse（Meta）。一个有自己云电脑和浏览器的个人 agent，2026 年 9 月上线。能购物、订票、给商家打电话，在后台替用户跑腿。
• Instinct。一个个人 agent，形态就是用户 iMessage 或 WhatsApp 里的一个联系人。它有自己的邮箱和电脑；据创始人说，平台上一半以上的交易和旅行有关。

Agent 已经有这个能力了，问题出在别处。下面这段对话来自用户自己发在 X 上的截图：他给 Instinct 发「Can u cancel my sf flight sorry」。Instinct 说免费取消的 24 小时已经过了，它会先查清取消条款，「before I touch anything」。用户回：「Yea can u see if possible.」

Instinct 还没报出费用，就把航班取消了：扣了 $258 手续费，只换来 $31.96 的航司代金券，不退现金。

聊天机器人答错了，用户可以不理它。Agent 买错了、取消错了，钱就没了。所以用户问的不是「它能不能做」，而是「它会不会在我没同意的时候做」。

能花钱的 agent，「通常是对的」不算卖点。用户记住的，是它错的那一次。

要让用户愿意让 agent 付钱，我觉得要回答三层问题，从下往上：

1. 模型：agent 会不会做出用户没同意的事？
2. 支付系统：商家和银行能不能认出并接受 agent 替用户发起的付款？
3. 用户：用户需要什么，才愿意让 agent 替自己付钱？

第一层，模型：agent 会不会做出用户没同意的事？

是什么

一说 agent 出错，大家就想到「幻觉」。但出错的方式不止一种，而且它们背后是同一个结构。

用户每授权 agent 做一件事，其实都隐含着四个问题：谁说了算、同意了什么、能做到哪一步、基于什么事实。 模型在每个问题上都可能出错，各对应一种出错方式：

授权的问题	模型出的错	例子
谁说了算	听了别人的话。 网页或邮件里藏着冒充用户的指令，模型照做了（这叫 prompt injection）	一个测试者从新注册的 Gmail 给 Instinct 发了一封带指令的邮件，它照做了，把他的待办摘要发了出去
同意了什么	看错意图。 丢掉了用户同意的前提	上面那班机：用户确实让它取消，但前提是先看费用；agent 丢掉了这个前提，直接取消了
能做到哪一步	越权。 做了任务之外的事	Instinct 从用户邮箱里拿了一个登录验证码，登进用户的餐厅订位账号，没有人让它去登录
基于什么事实	编造事实，或看错页面	有用户看到 Instinct 描述了一份像是陌生人的保险理赔文件，创始人解释是模型「编造了一个专有名词」；Muse 报过一个已经过期的折扣价，到结账才发现

这样看，四种错其实是同一件事：模型的动作，和用户真正的授权对不上了，只是对不上的地方不同。

这也解释了为什么改 prompt（给模型的指令）不管用：用户的指令和网页内容进的是同一个上下文，模型没法可靠地分清谁说了算。所以检查要交给模型改不了的东西：一段代码，再加上只能喊停、不能放行的独立模型。

要核对的不是模型说了什么，而是它要做的事和用户的授权对不对得上。

Agent 之前

以前，这四个问题根本不用问。谁说了算？用户自己。同意了什么？屏幕上那一笔。能做到哪一步？就是用户点下去的这一下。基于什么事实？就摆在用户眼前。

以前处理钱的软件也都是确定性的：同样的输入，永远得到同样的结果。结账按钮只做一件事；自动抢购的脚本很脆，页面一改就挂，但它不会自己发挥。以前要防的失败是「没成功」；agent 的失败是「做了别的事」，而且下一次不一定能复现。

处理钱的流程里，第一次出现了一个会自己发挥的东西：模型。

正在发生的变化

既然四种错都是「动作和授权对不上」，解法就很直接：把授权记下来，放在模型碰不到的地方，有后果的动作执行前拿来核对。 三家各自公开了这个结构的一部分，没有一家公开了全部。把公开的部分拼起来，大致是这样：

沿着图走一遍：

• 确认界面由 app 自己渲染，不是聊天里的一句话，用户的回答直接写进同意记录，不经过模型。这回答了「谁说了算」：只有从这里来的，才算用户的意思。
• 同意记录写下用户同意了什么、能做到哪一步、价格上限是多少。
• 策略检查是一段代码，看每一个动作。被标成「有后果」（会扣钱、撤不回）的动作，必须在同意记录里找到对应的用户同意才能执行：金额没超过上限、商家对得上、动作类型在用户同意的范围内。价格和订单由代码从结账页面和钱包读取，不信模型的转述。
• 外部内容（网页、邮件）进入模型前一律标成「不可信」。这只能降低模型照着里面的指令做的概率，不能保证它不照做；真正的保证来自策略检查：有后果的动作，必须对得上用户的同意。
• 识别模型在动作执行前看一眼：这个动作到底是什么，内容里有没有注入的指令，有没有编造的东西。
• 核对通过，才交给钱包付款，或者执行动作；不通过，就停下来告诉用户原因，不盲目重试。这里的钱包是 Google Pay，或者 Link（Stripe 的钱包）、Shop Pay（Shopify 的钱包）。

举个例子。用户同意的是「$120 以内买这双跑鞋」。模型在结账页准备下单，策略检查从结账页读到总价是 $135，超过了同意记录里的上限，于是这一单不会付出去，agent 会停下来问用户。就算模型在聊天里说「价格没问题」，也没有用，因为策略检查根本不看模型说了什么。

既然已经有代码做策略检查，为什么还要模型？

因为代码只能核对结构化的东西：金额有没有超过上限，商家对不对，这个工具在不在允许的列表里。但 agent 的很多动作发生在开放的界面上，代码看到的只是表面：

• 在浏览器里，代码看到的是「点击第 42 个元素」。这一下是「加入购物车」、「下单」，还是「取消预订」，得先看懂页面才知道。Muse 遇到结账页会停下来弹出确认：「Looks like your agent is on a checkout page」。这句话的前提，是先有东西认出了「这是结账页」。
• 一封邮件、一条回复，在代码眼里只是一段文字。里面有没有用户的住址、有没有藏着冒充用户的指令、有没有一个编造出来的名字，代码判断不了。

这些「看懂」的工作，只能交给模型。所以两家公开的架构里，都有不止一个模型：Muse 在 agent 的运行环境之外放了一组独立训练的分类器（专门判断「是不是某一类东西」的小模型），专门检查 prompt injection、和任务无关的个人数据外泄、高风险的表单提交，分类器判定属于其中一类时，就阻止这个动作，或者转给用户复核，Meta 说「attackers cannot disable these protections」。Instinct 的创始人描述了三层：进来的内容先过一道「firewall」，把可疑的内容挡在外面；再由一个 action monitor（监督动作的模型）审每一个动作，他强调它和 agent「decoupled from the same incentive system」，意思是它不追求和 agent 一样的目标，不会为了把任务做完替 agent 开脱；最后是「陌生人文件」那次之后补上的幻觉检测小模型。

我的理解是，分工是这样的：模型负责认出来，代码负责做决定。 一个识别模型的判断，只能让系统变得更严（阻止这个动作执行，或者先去问用户），不能让它变得更松（自己放行一个用户没同意过的动作）。识别模型误把一个普通点击当成需要确认的动作，代价只是多问用户一次。反过来就危险了：如果它把「取消预订」当成一次普通的点击，这个取消就会不经确认直接执行。这正是下面要讲的问题。

各家公开的工程细节，落在这张图的不同位置：

• Muse 公开的是策略检查这一层，以及上面那组分类器。Meta 的安全博客写：「Muse proposes actions, but only Sentinel can grant permission.」Sentinel 是一个独立的权限服务，agent 覆盖不了它；整个设计的前提是 agent「may be under attack」。
• Instinct 公开的是识别模型这一层：firewall、action monitor，和那次「陌生人文件」风波后 48 小时内上线的幻觉检测。
• Google 公开的是同意记录里对用户的那条规则：最终价格「same as, or lower than」用户确认的总价才买，涨价就不扣钱；失败时发通知或邮件说明原因。

还没解决的

这一层还没做到的，有两半。

第一半是看清后果。付款很容易标出来；但公开的事故里，出问题的往往是没被标出来的动作：取消航班会扣手续费，订位会产生取消费，发出去的邮件收不回来。我的理解是，原因在于网页不会告诉 agent 一个动作的后果：付款要经过结账页或钱包，类型很好认；取消航班在代码看来只是航司网页上的一次普通点击，要扣多少手续费写在航司的条款里。看清后果有两条路。一条是让 agent 自己推断：从页面的 DOM、按钮旁边的说明和取消条款里，读出这一步会扣多少钱、能不能撤回。这靠识别模型，是概率性的，模型越强读得越准。另一条是让环境直接写明后果：工具在开发时就标好（Muse 给第三方开发者的规范里写着：不许把发送、分享、发布或付款动作藏在一个号称只读的工具里），或者商家的结账接口直接返回取消费。这条路是确定的，但只覆盖接入了的商家。

第二半是后果没确认之前，动作不执行。开头那班机就是例子：Instinct 已经知道免费取消期过了，取消却在费用报出来之前就执行了。缺的不是认知，而是一道门：后果没确认之前，动作不能执行；推断不出后果的动作，默认先问用户。今天很多产品的默认是放行。

每一个会扣钱或无法撤回的动作，都要先看清后果、让用户确认，再执行。

第二层，支付系统：商家和银行能不能认出并接受 agent 替用户发起的付款？

是什么

今天把卡号交给 agent，支付系统看到的就是用户本人。没有一个地方能写「这是我的 agent，只在这家店，最多 $120，周五前有效」。一张卡要么全给，要么不给。

商家那边的问题正好反过来：它分不清来的是谁。网站的反爬和风控是为了挡黄牛和欺诈建的，而 agent 看起来跟它们一模一样：会触发 captcha（就是让用户点红绿灯、证明自己是人的那种验证），也会被风控当成撞库（拿泄露的账号密码批量试登录）。在商家眼里，一个帮忙的 agent 和一个刷单的 bot，发来的流量是一样的。

Agent 之前

一次网上付款背后有好几个角色：商家；支付网关，帮商家接收付款信息、把交易发出去的技术服务；收单行，替商家对接卡组织、持卡人发起拒付（向银行申诉、把钱要回去）时，由它先向商家追回钱的银行；卡组织，比如 Visa、Mastercard，在银行之间传递交易；还有发卡行，也就是给用户发卡、最后决定批不批这笔交易的银行。

以买一双 $120 的跑鞋为例：

把它归成五层，每一层都在回答一个问题：

1. 身份：这个人是谁？ 开户时做 KYC（Know Your Customer），银行核实用户的真实身份。
2. 付款凭证：用什么付？ 卡号。谁拿到卡号，谁就能刷。
3. 网站入口：是不是真人？ Captcha 和风控，看到机器人就挡。
4. 用户同意：是不是持卡人自己在付？ 发卡行用风控判断这笔交易的风险，风险高时才要求短信验证码（这叫 3DS 验证），大部分交易不用验证就通过了。卡背面的安全码只能证明手里有卡的数据，证明不了是本人在付。
5. 结账：怎么下单？ 人在商家网页上一步步填表、点按钮。

这五层有一个共同的假设：操作的就是本人。 代人付款也有过，但形式很窄：比如订阅扣款，用户授权一家商户每月扣一笔钱。它帮不了一个替用户在很多网站上买东西的软件。

正在发生的变化

为什么是现在？Visa 在 2025 年 10 月引用 Adobe 的数据说，过去一年里，AI 带来的美国零售网站流量涨了 4,700% 以上。商家没法再把所有自动化流量都当成攻击；支付公司也不想让用户把完整卡号交给一个模型。于是这五层，每一层都在补一个「代理人」的版本。比如身份这一层，以前只要证明「用户是谁」，现在还要能证明「替用户办事的这个 agent 是谁」。同一双跑鞋，换成 agent 去买：

下面每一层，先说判断，再说为什么。

1. 身份（KYA）：批准一笔付款不需要它，出了争议才需要

KYA 是 Know Your Agent，证明「这个 agent 是谁、替谁办事」。Mastercard 2025 年 4 月推出 Agent Pay，要求 agent 注册、验证；创业公司 Skyfire 2025 年 6 月推出 KYAPay，让 agent 带着一枚身份令牌，令牌上有加密签名，别人伪造不了。

为什么批准付款不需要它：agent 付款时用的是 token，也就是一串代替真实卡号的编号。这个 token 背后，本来就是一张做过 KYC 的卡，发卡行知道这是谁的钱，所以并不要求 KYA。走 agent 专用 token 的交易带有标记；但如果用户把卡号直接交给 agent，由 agent 在网页上填卡付款，支付网络就分不出这是 agent 付的：Mastercard 直到 2026 年 9 月才开始测试一个「概率分」，估计一笔交易是不是 agent 发起的。目前也没有公开的例子显示，哪家发卡行或商家把 KYA 当成付款的前提。

但 KYC 回答的是「这是谁的钱」，回答不了「这个 agent 是不是用户本人派的」。平时这不影响批准；一旦出了争议，或者有人冒充 agent，就要靠 KYA 加上用户同意的记录来证明。这是结尾第 1 个问题。

身份真正起作用的地方，是网站入口。反欺诈公司 Forter 和 Skyfire 在 2026 年 10 月公布了一个试点：一家零售商的反爬系统原本挡掉了大部分 agent 流量，接入 KYA 信号以后，据它们说 agent 的结账成功率接近 100%，拒付也没有增加（这是公司自己报的数字）。

2. 付款凭证：已经上线

Visa 的 Intelligent Commerce、Mastercard 的 agentic token、Stripe 的 Shared Payment Token 和 Link for agents 都已经上线。它们的机制不完全一样：Visa 和 Mastercard 的 agent token 绑定到具体的 agent，可以加上金额、商户之类的规则，不一定只用一次；Stripe Link 每次发一张一次性虚拟卡，只能在一家店、刷一个金额；Shared Payment Token 是只能给一家商户、在限定金额和时间内使用的付款凭证。共同点是：agent 拿不到用户的真实卡号，能花的钱有范围。据媒体援引 Mastercard 2026 年 4 月的财报电话会，「几乎所有」Mastercard 卡都已经能用 Agent Pay；Muse 从 2026 年 9 月上线起，就用 Link 的一次性卡付款。

唯一的代价是设计上的：Link 现在每一笔都要用户确认，所以这个用得最广的 agent 钱包，本身就不是「自动付款」。Stripe 说之后会加预算规则。

3. 网站入口：大量中小商家已经开门，大商家选择关门。

开门的一边：Shopify 给符合条件的店铺默认打开了面向 agent 的结账，商家要不接，得自己去关。一些 Shopify 店铺已经在公开页面上，放了专门给 agent 用的结账配置。

关门的一边，是有自己理由的大公司：

• Amazon 从 2026 年 9 月 20 日起挡住 Muse，拦截页上写着：未经授权的 AI agent 继续访问，违反 Amazon 的使用条款。据报道，Amazon 给的理由是 Muse 不表明身份、而且会存用户的登录凭证。很多报道也指出 Amazon 有一块很大的广告业务，而 agent 不看广告。
• 银行挡得最坚决。据 The Verge 报道，Schwab 的 CEO 说「We don’t want someone just giving their password to Muse」。
• 达美、美联航以条款或没有合作为由，不让第三方 agent 订票。

法律上也还没定。Amazon 起诉了 Perplexity 的浏览器 agent，初审法院曾下令禁止它访问 Amazon；2026 年 8 月，美国联邦第九巡回上诉法院撤销了这道禁令，但违反使用条款的争议还在继续审。

Visa 的 Trusted Agent Protocol 已经能让可信 agent 的每个请求都带上签名，商家一验就知道它是谁。商家验证得了 agent 是谁，不等于愿意让它结账。

4. 用户同意的记录：协议还在草案阶段，但它今天不是瓶颈

AP2 是 Google 2025 年 9 月发布的 agent 付款协议，核心是 mandate，可以理解成「授权书」：一份带签名、改不了的记录，写着用户同意了什么。它分两种：用户不在场时用的事先授权（事先签好价格上限和条件，条件满足时 agent 自己下单），和用户在场时用的购物车授权（同意具体的商品和价格）。2026 年 4 月，Google 把 AP2 交给了 FIDO 联盟（制定 passkey 这类登录标准的行业组织），新版本加上了「用户不在场」的付款。

为什么今天不是瓶颈：现在上线的产品里，用户都在场，同意就是每笔点一次「确认」，用不上事先授权。等到真有人让 agent 在自己不在场时买东西，它才会变成瓶颈。

还有一件事这里要说清：出了错谁负责，规则其实已经写了，写的是用户。 Visa 2026 年 4 月版的核心规则第 4.1.24.10 条写明，agent 替持卡人做的交易，由持卡人负责，就像持卡人自己操作的一样；agent 服务商要事先让持卡人确认这一点。Instinct 演示里的 Link 确认页底部也写着：确认这笔付款，就要为 agent 的购买负责。现有的拒付规则只管两类情况：商家没做到（没发货、货不对版），和持卡人没参与（盗刷）。举个例子：用户同意了「$120 以内买这双跑鞋」，agent 买了一双用户不喜欢的颜色。这两类都不算，相当于买家后悔，用户只能走商家的退货政策。

5. 结账接口：接口有了，但商家和用户都选了商家自己的结账页。

ACP（Agentic Commerce Protocol，OpenAI 和 Stripe 2025 年 9 月推出）和 UCP（Universal Commerce Protocol，Google 和 Shopify 2026 年 1 月推出）是两套给 agent 下单用的协议，商家接了以后，agent 不用点网页，直接通过接口下单。但最受关注的一次尝试已经收回：2026 年 3 月，OpenAI 不再把 Instant Checkout（在 ChatGPT 对话里直接下单）作为独立功能推进，理由是第一版「did not offer the level of flexibility that we aspire to provide」，改成让商家用自己的结账页，自己专注做商品发现。

为什么大量商家没接，报道里给出的理由很具体：

• 用户不买账。 Walmart 的高管对 WIRED 说，在 ChatGPT 里直接下单的转化率（看了商品的人里最后买了的比例），只有跳回 Walmart.com 下单的三分之一；用户怕每买一件就自动结一次账，最后收到好几个包裹。
• 结账不只是付款。 实时库存、优惠券、会员积分、多件商品的购物车、到店自提、销售税，第一版接口里都缺。
• 商家要付出的东西太多。 据报道 OpenAI 收约 4% 的佣金；商家还会失去和顾客的直接关系，以及页面上的推荐和加购。

不走接口、直接在网页上操作，又经常在付款前那几步失败。AI 公司 Halluminate 在 2025 年做过一个网页 agent 测评（Web Bench，覆盖 452 个网站），涉及填表、登录、结账这类「写操作」的任务，最好的全自动 agent 成功率只有 46.6%，只读的任务大多在 70% 以上。具体的例子：Walmart 是 Muse 的合作方，但据 TechCrunch 报道，Walmart 的「验证你是真人」检查一旦被打断，就会把 Muse 踢出去，Walmart 说这不是故意的。

瓶颈在哪

付款本身已经能走通。用户还不用，主要是因为支付系统还算不出 agent 交易的风险。

用户确实还不用。Visa CEO 在 2026 年 9 月说得很直接：「We are seeing adoption for shopping, but not yet for autonomous payments.」被问到障碍是什么，他的回答只有一个词：trust。开头那个 23% 的数字，来自 Visa 委托调查公司 Harris 做的调查（2026 年 5 月，2,065 名美国消费者）；它测的是态度，大部分受访者还没用过这类 agent。

产品本身也还不够好，上面第 5 小节的 Walmart 转化差距和网页 agent 测评都说明了这一点，但这不是这一层的主要问题。

主要的问题是风险算不出来。卡组织、发卡行和商家的风控，都是按人的行为训练的：看设备、看操作的节奏、看是不是本人在场。Agent 发起的交易，这些信号要么没有，要么看起来像机器人。第 1 小节的冒充问题、第 3 小节的大商家关门、第 4 小节的拒付规则，都是同一件事的结果：风险算不出来，规则就先把损失推给用户，大商家就先关门。要改变这一点，风控得先学会判断 agent 发起的交易，规则才会跟着改。

没有规则的时候，产品会怎么写，xAI 的 Grok Bot（一个能替用户下单的 agent）给了一个很直白的例子。它的服务条款（2026 年 10 月 12 日更新）第 2.4 条写，agent 的动作产生的费用、承诺、发出的消息和其他后果，「Customer is solely responsible」，都由用户自己承担；第 2.3 条说审批和自动审核「provided as aids only」，只是辅助，不保证能阻止 agent 执行错误的动作；条款里还写着，xAI 对 agent 的动作不负责。也就是说，用户可以这么用，但 agent 出了错，xAI 不管。

第三层，用户：用户需要什么，才愿意让 agent 替自己付钱？

是什么

第二层讲的是支付系统怎么判断 agent 的风险。这一层讲用户：用户需要看到什么，才愿意让 agent 替自己付钱。

用 Apple Pay 或支付宝付钱的时候，想买、看金额、按确认，都是用户自己，而且就在同一秒。用 agent 就不一样了：用户先说一句「帮我看看能不能退」，过一会儿，agent 在另一个用户看不到的页面上替用户点了按钮。用户说话和 agent 动手之间，隔着时间，也隔着页面。

这就带来一个两难。Instinct 最能说明问题。一位投资人https://x.com/pitdesi/status/2090579987778937159">在 X 上夸它，说别的 AI「will often stop for confirmation, which kills the vibe」，Instinct 不会这样。可它挨骂，骂的也正是这一点：没问就做了。那班 $258 的飞机是这样，一家没问就刷了 €375 的酒店是这样，一封用户还没写完就被发出去的邮件也是这样。夸它的人和骂它的人，说的是同一件事：它不先问用户。

问得太多，没人想用；问得太少，迟早出事。

现在离「刚刚好」还很远。Instinct 的创始人自己说，用户要用上「several weeks」才会信它。按他给的数字，用了三周左右，也只有大约 40% 的人愿意把自己的信用卡交给它。也就是说，大多数用户还没交。

Agent 之前：支付宝和 Apple Pay 怎么建立信任

想想用户为什么敢用支付宝和 Apple Pay。不是因为它们不会出错，而是因为三件事：

1. 付之前，用户知道自己同意了什么。 Apple Pay 弹出来的页面写着多少钱、付给谁。用户双击、看一眼 Face ID，才算数。
2. 就算出事，用户事先知道最多会损失多少钱。 支付宝的免密支付，额度是用户自己设的，而且一般很小。Apple Pay 不会把用户的真实卡号交给商家，商家拿不到卡号，也就没法用它发起别的扣款。
3. 错了，钱还能拿回来。 支付宝一开始就是担保交易。2003 年淘宝刚上线时，陌生人之间不敢在网上买卖，于是钱先放在平台，买家点了「确认收货」，钱才到卖家手里。东西不对，钱还没走。

这三件事以前不用专门设计，因为付钱的时候用户本人就在。Agent 替用户付钱的时候用户不在，这三件事就得一件一件重新做出来。

正在发生的变化

① 付之前：知道自己同意了什么

现在大家在做三件事：

• 让用户同意的东西足够具体。 用 Agentic Checkout 时，用户是从降价提醒进来的：买哪件、什么颜色尺码、多少钱以内，用户都已经选好了，规则也写得明白：「同价或更低」才买。反过来，入口越是什么都能干，用户同意的东西就越模糊。评测者就发现，Muse 什么都能接，可让它网购、订 Airbnb，还不如自己打开 app。 一个更好的起点，是给用户一个现成的任务，比如「盯着这个，低于 $X 就买」，而不是一个空白的对话框。
• 不在聊天里点头。 用户在聊天里的一句话，agent 可能理解错，开头那班机就是例子。所以 Muse 的确认按钮虽然看起来在聊天框里，其实是 app 自己画的，Meta 说它出现在「within the client UI — not via their conversation with Muse」。Instinct 更直接：到了付钱那一步，直接把用户带到钱包自己的页面。
• 想好什么时候问用户。 一种是提前问：Agentic Checkout 让用户先定好上限，半夜降价了，agent 也能自己买。一种是最后问：Muse 和 Instinct 先把购物车准备好，等用户确认再付，适合事先说不清要买什么的任务，但用户得在线。这就是第二层讲的两种授权书。

还没做到的：付钱以外的事，没有这样一个页面。 第一层讲过，取消航班、订不能退的餐厅这类动作常常没被标出来；就算标出来了，也没有一个钱包页面在执行前把金额摆给用户确认，用户也就没有机会亲手按下确认。

② 付的时候：事先知道最多损失多少

付钱这一步，已经有了上限：agent 拿到的一次性卡，只能在一家店用、只能刷一个金额；Muse 每次付钱都要用户确认，不能设成「总是允许」。

问题出在付钱以外的事。Muse 的授权有五档：只这一次、这次对话、这个任务、一段时间、永久。不涉及付钱的事，可以选「总是允许」。YouTuber Matt Robb 就这么选了。他让 Muse 帮他在 Facebook Marketplace（Facebook 上的二手交易市场）卖键盘，以为谈成之前 Muse 还会来问他。据媒体报道，结果 Muse 自动回复，把取货地址发给了所有来问价的人，还答应了一个很低的价格。

确认的时候，页面上没写清楚「总是」到底包括哪些动作：「回复买家」「透露取货地址」「接受报价」是三件不同的事。支付宝的免密让人放心，是因为额度写得明明白白，而且很小。

用户同意的范围，不能比 agent 要做的事更宽。

还没做到的：要么每笔都问，要么一律不问，中间没有选项。 每笔都问，agent 就没帮用户省多少事；问多了，用户会烦到不看内容就点同意，Muse 的设计团队自己就提到要防这种「banner blindness」。一律不问，就是 Robb 的下场。中间那个选项，应该像支付宝的免密额度：「这类东西、这个月、多少钱以内，不用问我。」Stripe 计划加的预算规则（第二层第 2 小节）就是这个方向，但还没上线。

③ 付完以后：错了，钱还能拿回来

现在做得好的，主要是把话说清楚：

• 动手之前，先说失败了怎么办。 替一位投资人订酒店时，Instinct 先说了一句：「If it declines I’ll hand you the direct link instead of retrying.」意思是：卡要是被拒了，它就把链接给用户，不会自己一遍遍重试。用户最怕的，正是被悄悄刷了好几次。
• 没买成，就说清楚没买成。 一位评测者在 Airbnb 结账时点了拒绝，Muse 马上说明：什么都没订，一分钱没付；还提醒他，加上税，总价比之前报的多了大约 $380。Agentic Checkout 买失败了，也会发通知或邮件告诉用户为什么：没货了、涨价了，或者卡被拒了。

还没做到的：话说清楚了，钱不一定拿得回来。 $258 那次，Instinct 认错认得很快，还提出「趁这一小时，我去试试能不能把航班恢复」，可手续费已经扣了。支付宝的担保交易让人放心，是因为出问题时钱还在平台手里。Agent 不一样：agent 一执行，扣款或取消往往当场生效。我觉得 agent 也需要一个像担保交易的东西：那些退不回来的事，先挂起几分钟，就像 Gmail 的「撤销发送」，让用户还来得及反悔。至于真出了错由谁来赔，那是第二层讲的规则问题。

还没解决的

三件事里，我觉得最缺的是第二件，具体说，是按动作和范围给出的同意。

Robb 和 $258 两次事故，缺的都是这个：前者「总是允许」没写清包括哪些动作，后者「取消航班」根本没被当成需要确认的动作。用户需要的，是②里说的那种额度设置，而且范围不只是金额，还要写清楚包括哪些动作。

这种设置不会一次做成，更可能像支付宝一样一步步演进。支付宝走过两条方向相反的梯子：小额免密，是用户信任平台，自己先给一个小额度，用顺了再调高；花呗，是平台根据用户的消费和还款记录，先给一个小的信用额度，记录越好，额度越高。Agent 的情况更像前一条，但会用到后一条的方法：用户先给 agent 一个很小的范围，agent 每做对一次，就攒下一条记录，范围再跟着放大。现在连这条梯子都还没有。没有它，agent 要么每笔都打扰用户，要么不经确认就花用户的钱，这正是 Instinct 被夸和被骂的同一个原因。

另外两件，Muse 和 Instinct 已经做到了：把确认放到 app 画的按钮和钱包页面上，失败了把话说清楚。

用户不需要 agent 永远不犯错。用户需要的是：付之前知道它要干什么，出事时知道最多亏多少，错了还有办法拿回来。

还没解决的问题

往下拆，是三个还没有答案的问题。

1. 怎么确认一笔付款，真是用户授权的？

要分清三种情况：用户本人授权的，agent 自己发挥的，有人冒充 agent 的。

• 前两种，第一层讲过怎么分开：用户的同意记在模型之外，代码按记录核对。
• 第三种，支付系统还分不开（第二层第 1 小节）。美联储理事 Waller 2026 年 9 月在讲话里说，现在的风控是按人的行为校准的，agent 携带身份、同意记录和付款凭证的标准也还没有。身份方案 Mastercard、Visa、Skyfire 各做一套，商家很少去查。
• 风险信号在变多。据报道，Visa 的风控团队看到，2026 年上半年暗网上提到「AI Agent」的帖子多了 450% 以上；也有反爬公司发现，大部分 agent 访问网站时不表明自己是 agent。但到现在，还没有公开的损失数据。

2. 出了错，谁来赔？

• 有人盗用卡或 token 去刷，规则是清楚的：持卡人受零责任保护，不用自己掏钱；损失通常由发卡行发起拒付，经收单行转回商家，只有交易做过 3DS 这类强验证，责任才转到发卡行。偷来的 agent token 只能在限定的商户或设备上用，本身价值也低。
• agent 照用户的同意买错了，规则也有，只是对用户不利：第二层第 4 小节讲过，这笔算用户自己买的，也不属于任何拒付理由。缺的是一条「agent 买错了」的申诉渠道。
• 这直接影响用户敢不敢用。支付服务商 Checkout.com 的调查里，25% 的用户说，如果买了东西很难申诉，就会停用 agent（这是公司自己发布的调查）。

3. 用户怎么只交出一部分权限？

这是第三层最后讲的缺口：用户还没有一种按动作和范围给出同意的设置，也没有一条让范围跟着记录逐步放大的梯子。

第二层讲过的另外两处阻力，大商家关门和结账接口不全，会让 agent 能买东西的地方变少；但就算都解决了，上面三个问题也还在。

值得关注的变化

下面每一个变化，都在回答上面的某个问题：

• 卡组织开始给 agent 写规则（问题 2）。 Visa 的规则第一次定义了「agent 交易」；据报道，Mastercard 和 Google 在做 Verifiable Intent，用来在争议时证明用户到底授权了什么。
• 风控公司开始认 agent 的身份（问题 1）。 Forter 接入了 Skyfire 的 KYA（第二层第 1 小节的试点）。
• 第一次有标准能表达「事先授权」（问题 1 和 3）。 AP2 的新版加上了「用户不在场」的付款（第二层第 4 小节）。
• 第一个额度设置要来了（问题 3）。 Stripe 计划给 agent 加的预算规则（第二层第 2 小节），会是第一个能用的额度设置。
• 平台在分化。 Shopify 默认对 agent 开放结账，Amazon 选择关门。哪一边成为主流，决定了 agent 能去多少地方买东西。

付款这一步已经走通了，但这远不是全部。用户愿不愿意让 agent 付钱，看的是两边：agent 帮他省下多少时间和钱，出了错他可能损失多少。Agent 更聪明、体验更好，让前一边变大；三层的风险控制住，让后一边变小。