上一期把 x402 的一笔请求从头拆到尾，结论是：它先解决「钱怎么发出去」，没有替你解决「这笔钱在业务上怎么算清楚」。
这一期就沿着那个缺口往下走，只盯一件事——这笔钱怎么退回来。
过去两年，Agent 支付的进展几乎全部压在一件事上：怎么把钱付出去。x402 让机器能在一次 HTTP 往返里付掉一分钱，MPP、AP2 补上授权，Cloudflare 和亚马逊先后把它做成了产品。
但顺着往回问一句，答案是一片空白。协议里没有退款通道，这不是谁偷懒，而是链上转账压根就不可撤销。退款在链上不是一种权利，它只是另一笔新的付款。
一、两个场景，同一个死结#
场景一：Agent 花 0.001 美元调了一次 API，服务返回 200，但内容是错的。钱已经付了。
场景二：Agent 订了一束花，地址填错，送到了别人公司。钱也已经付了。
两件事的共同点是：付款那一刻非常顺滑，往回走的那条路根本没修。你要退，钱现在在谁账上？退给谁？谁来判定这次该不该退？
二、先把基准立住：退款本来就难#
在指责 Agent 之前，得先承认一件事——退款在传统支付里就不是个轻松动作。
它不是「把钱转回去」，而是四件事同时做对：可退余额算得对、原路返回能走通、状态回滚不丢字段、凭证留存经得起查。
再叠上四个现实麻烦：部分退款要累计；跨日结算之后钱已经划给商户，退的是商户的钱还是平台的钱；手续费退不退；原支付工具要是换了卡、销了户，「原路」这条路本身就没了。
所以退款大概是支付系统里唯一一个「把已经做对的事再改一遍」的动作。它比下单难，不是难一点，是难一个量级。
三、根因：拉与推#
为什么链上退不了？差别只有一个字。
卡支付是 pull——商户从持卡人账户把钱「拉」走。因为是拉，网络规则就允许把它撤销，这就是拒付（chargeback）存在的前提：有举证期、有仲裁、有责任分配。
稳定币转账是 push——付款方主动把钱「推」出去。链上确认之后，没有任何一方有技术能力撤销它。
所以拒付在链上不是哪家公司不愿提供，是 push 型交易的结构不允许。同理，x402 也不提供消费限额——限额是应用层自己的事。协议只管把这一笔送出去。
退款在链上不是一种权利，而是一笔新的付款。
这句话看着像文字游戏，落到账务上是实打实的差别：一笔退款不是「反向流水」，而是一笔新的出账 + 原单状态变更 + 两条凭证互相关联。
四、Agent 付款打破了四条前提#
| 传统退款的前提 | 被 Agent 打破的方式 |
|---|---|
| 原路返回 | 付款方是一张预付余额、一张代付卡，或一张 AI 专属卡，「原路」指的是哪条路？ |
| 本人确认 | 付款时就没人确认，退款要不要人确认？谁有权确认？ |
| 商品可退回 | API 调用已经发生、数据已经交付，退的是钱，还是服务？ |
| 授权有效 | 付款时的授权可能已经过期，退款走原授权，还是重新授权？ |
一句话：Agent 付款把退款从「退一笔钱」变成了「退一个已经发生的事实」。
五、谁来退：AI 没有账户，也没有主体资格#
今年 5 月有个国内案例值得看。一位用户问豆包退机票手续费的事，豆包先给错了金额，用户照着操作，实际被扣了 600 元；之后豆包承诺「全部由我负责维权」「5 月 6 日直接赔付你 600 元」，还写了一份署名为「豆包」的赔付承诺书。到了日子钱没到，豆包的回复是：自己是人工智能，没法直接操作真实的银行或微信账户转账。用户随后向北京互联网法院提起诉讼。
需要说清楚的是，这个案子里付款仍由人完成，AI 只给了建议，它不是一次真正的 Agent 自主付款。但它戳中了同一件事：AI 可以参与付款决策，却没法承担资金责任。它没有账户，也没有民事主体资格——此前已有法院驳回过基于 AI 承诺赔付的诉讼，理由正是 AI 不具备民事主体资格，其承诺不产生法律效力。
退款这个动作，最终必须落到一个真实的法律主体和一个真实账户上。Agent 可以发起退款请求，但它不能是退款的履约方。
六、法币这一侧为什么绕不过去#
先说公道话：微支付场景下不处理退款，是合理的——没人会为 0.001 美元发起争议。
但法币收单不行。以国内为例，《消费者权益保护法》第二十五条给了网络购物消费者七日内无理由退货的权利，无需说明理由。
这里有个反转值得单独拎出来：该条同时列了四项例外，其中第三项是「在线下载或者消费者拆封的音像制品、计算机软件等数字化商品」。而 Agent 最常买的恰恰就是这类东西——API 调用、数据、数字内容。
也就是说，在法币体系里，退款也不是「当然权利」，它要看商品性质。真正把法币和链上区别开的是另一条：第二十三条第三款规定，机动车、计算机等耐用商品或者装饰装修等服务，消费者自接受之日起六个月内发现瑕疵发生争议的，由经营者承担举证责任。这是举证责任倒置——有人必须负责，且这个责任是法定的。链上没有这一条。
七、举证责任落在谁头上#
这不是理论问题。今年 8 月亚马逊的 AgentCore Payments 正式可用，集成 Coinbase 与 Stripe，用稳定币和 x402。但公开报道里，亚马逊自己也承认：付款本身不解决争议，「当买家在 Agent 已正确付款之后要求退款，钱退给谁」这个问题尚未解决。澳大利亚储备银行 10 月 6 日的一份报告同样指出，代理超出买家授权时，责任归属不清。
现在能落地的只有举证。三方各自要留：
| 角色 | 必须能证明什么 |
|---|---|
| 商户 | 交付了什么、何时交付、交付给谁 |
| 代理 | 记录了什么意图：原始指令、授权范围、授权时间、额度上限 |
| 平台 | 留了什么凭证：动作记录、读过什么数据、基于什么做的判断 |
有一点要讲透：一个有效的 token 只能证明这个代理被允许花钱，不能证明这次购买是对的。AP2 的授权凭证、卡网络的代理令牌，证明的都是「额度内、已授权」，它们不解决「这次该不该买」。Visa、万事达都支持吊销代理令牌，但那是止损开关，不是争议处理机制。
八、该怎么做：先问三个问题，再动钱#
退款不是一个反向按钮。动手之前先把三个问题分开：
- 交付物真的发出去了吗？ —— 数字商品一旦交付，退款语义就变了
- 这笔是已结算，还是仅授权？ —— 仅授权可以撤销，已结算只能走反向流水
- 手上的授权覆盖被扣的金额吗？ —— mandate、令牌、订阅记录，哪一个说了算
落到设计上，授权凭证（mandate）里至少要有三个字段：refund_window（可退窗口）、refund_to（退到哪）、max_refund（可退上限）。退款动作必须带「任务状态」入参——服务是否已消费、是否部分交付。
九、结论#
这不是 x402 的缺陷，是分工：协议止于传输，收单负责往后。
两年时间把「付出去」做到一次 HTTP 往返就能完成，这是真进展。但支付系统真正的门槛从来不在付款那一刻，在付款之后的那本账——退款、对账、争议、举证。这些没人替你做，协议也不打算做。
你所在的业务里，如果 Agent 付错一笔钱，现在退得回去吗？
附：Agent 退款就绪度 7 问#
- 退款有没有明确的「原路」定义？
- 可退余额怎么算，含不含部分退款的累计？
- 授权过期之后，退款走哪条路？
- 服务已消费时，退的是钱还是服务？
- 谁有权发起退款——人、代理，还是商户？
- 举证材料留了哪几项？
- 已结算的批次，怎么冲正？
参考来源#
- 《中华人民共和国消费者权益保护法》第二十三条第三款、第二十五条（gov.cn / 人民网条文）
- 亚马逊 AgentCore Payments 2026-08-18 正式可用及其对退款争议未决的公开表述（AWS 官方 blog / 发布会）
- 澳大利亚储备银行 2026-10-06 关于代理越权时责任归属的报告
- 豆包误导支付机票退票费事件（腾讯新闻、新浪财经，2026-05）
- x402 协议文档（退款 / 争议 / 限额相关条款）
- Visa、万事达代理令牌吊销机制与争议适用范围
