商户实际看到的是什么
在库存层面，由 agent 驱动的购买看起来并无异常。库存被预留，购物车完成定价，订单被创建，支付授权通过与其他任何有卡或无卡交易相同的通道到达。在支付层面，这笔订单是正常的。在欺诈层面，则不然。
产生该订单的会话具有自动化的形态：无头客户端、没有鼠标移动、在产品页面上没有停留时间、请求节奏不像浏览行为，以及可能与账户历史默认地址不同的收货地址。欺诈系统被训练成将这种形态视为信号。它们这样做并没有错。相同的会话指纹也会由撞库工具和下达测试订单的爬虫机器人产生。
因此，商户对同一事件持有两种相互矛盾的解读。支付凭证是有效的。会话是异常的。订单记录中没有任何字段表明用户将此次购买委托给了第三方进程，也没有任何字段能将受委托的 agent 与盗取卡片并通过脚本驱动它的攻击者区分开来。
当唯一可用的信号是会话形态时，阻止便是理性的默认选择。这不是针对 agent 的政策立场。这是一个未被赋予任何可验证主张的系统的行为。
同意需要的是记录，而非复选框
商户账户中的设置开关不是同意记录。它没有逐笔交易的绑定、没有范围、没有有效期。它只表明用户曾经启用过某项功能；它并不表明这笔订单被授权做什么。
委托应当产生一份签名的范围。至少，该范围应当绑定：
- 它所适用的商户或商户类别
- agent 可以购买的商品类别或品类
- 每笔交易及每段时期的支出上限
- 一个有效期，超过后该范围即失效
- 持有该委托的 agent 身份
该范围随订单一同传递。当争议出现时，商户可以通过将范围与订单进行核对来解决，而不是从日志中重建会话。这一区别很重要，因为会话重建是取证工作：它缓慢、具有概率性，并且产生的是争论而非答案。
范围还会改变失败模式。超出上限的 agent 会被规则拒绝，而不是被欺诈启发式规则拒绝。在商品类别之外购买的 agent 会被规则拒绝。商户的欺诈系统随后便可自由地寻找实际的入侵，而不是寻找自动化的一般形态。
账本位于何处
支付网络已经在运营授权通道，在收单方、发卡方和商户之间传递结构化主张。委托范围是同一条消息上的附加主张，而非新的网络。实际问题不在于通道是否存在，而在于验证路径是什么样子。
商户需要在不信任 agent 供应商断言的情况下验证委托。这意味着该范围应当由商户能够独立核验的东西签名，并且验证结果应当与授权一同记录，而不是保存在供应商的系统中。如果确认委托的唯一方式是调用 agent 的 API，那么商户只是用一种信任问题替换了另一种。
这一权衡是真实存在的，值得坦诚说明。在授权消息中加入签名范围会增加载荷复杂度，需要在不共享发布周期的各方之间进行协调，并会创造一类新的失败：一笔有效订单因范围验证超时或签名密钥轮换而被拒绝。商户将需要为验证失败定义明确的行为，而安全的默认选择往往是拒绝。这是一项成本，但它小于将每一笔 agent 订单都作为潜在欺诈案件来裁定的成本。
退货和拒付需要同样的
75.jpg)
限定范围的支出凭证是商业的前提条件，而非差异化优势。无法出示其委托范围的 agent 会被每一家严肃的商户当作机器人对待，因为从商户的角度看，它与机器人无法区分。这种封锁并非对 agent 的敌意；而是缺少商户能够验证的主张。
这改变了工程投入的方向。有趣的问题不再仅仅是任务规划和工具使用。它们包括：
- 范围如何被签发并绑定到特定的用户意图
- agent 如何在购买时刻证明其行为在范围之内
- 当用户改变主意时，范围如何被撤销
- 当原始范围不再匹配最终订单时，部分履约、退款和替换如何处理
这些问题都无法通过更好的浏览器自动化层来解决。它们是授权问题，要求 agent 参与授权协议，而不仅仅是填写结账表单。
还有一个二阶效应。一旦范围存在，商户就可以对 agent 流量进行不同的定价和路由，因为受委托的订单与匿名会话承载着不同的风险。这是一个商业决策，但只有在底层主张存在之后才可行。没有它，唯一的杠杆就是阻止按钮。
重新表述这一错配
零售商阻止购物 agent，是在对一种授权错配做出反应：agentic checkout 产生了一个有效的支付凭证，却没有相应的同意记录。库存、定价和履约系统不是问题所在。问题在于，在决定是否接受订单的系统看来，一笔购买和一次入侵呈现出相同的证据。
解决办法不是要求商户更加信任 agent。而是给 agent 一些可以出示的东西：一份签名的、限定范围的、会过期的委托，它随订单一同传递，并且可以在不信任供应商的情况下被验证。在这一机制存在之前，阻止仍是理性的默认选择，而最先落地的 agent 将是那些能够证明自己被允许做什么的 agent。
封面照片：Jakub Pabis / Pexels。