两种姿态，同一个问题
Walmart 为购物 agent 开放了一个受限通道，其规则限定了 agent 可以浏览、购买和代表的范围。Amazon 则在边界处阻止 agent。两种姿态都站得住脚，且都不是标准之争。分歧在于争议交易的成本落在谁头上。
当商家接纳一个 agent 时，它接纳的是一个其激励、日志和身份都不受自己控制的当事方。委托人后来否认的购买、基于误读产品数据拼凑的购物篮、超出条款范围使用的优惠券——每一项都会变成拒付或退款，且没有清晰的证据链。Walmart 的受限通道是在交易发生前就让这条证据链存在的一种方式。Amazon 的边界封锁则是不接受这条证据链的方式。两种选择都与 agent 能否在技术上完成交易无关。Cloudflare 面向 agent 的基础设施工作和 Commerce.com 的店面集成表明，管道大体上已经就绪。尚未解决的是裁决：当 agent 介导的购买出问题时，由谁、依据什么记录来裁定。
只有把问题框定为协议采用，这两个公开信号才显得矛盾。若框定为责任分配，它们就是在技术栈不同节点做出的同一个决定——一个商家构建合规闸门，另一个则拒绝成为交易对手，直到出现它信任的闸门。
Agent 必须携带什么
授权是让 agent 对商家可读的文件。它应当经过签名、范围狭窄且机器可校验，并且至少携带四项事实：
- 委托人。 agent 代表其行事的法律主体，其身份形式须让商家能够独立于 agent 自身的声明进行验证。
- 预算封套。 一个最高金额、一种货币和一个有效期窗口——而不是 agent 自我报告的运行余额。
- 目录范围。 agent 被允许交易的产品、类别或 SKU，以机器可校验的谓词表达，而非散文描述。
- 过期。 一个硬性截止点，此后授权失效，使泄露或重放的授权降级为被拒绝的请求。
除了授权，商家还需要一份无需信任 agent 供应商日志即可验证的回执：一份经过签名的记录，说明请求了什么、返回了什么，以及哪条授权条款授权了它。回执是商家在争议中的证据，必须在边界处生成，而不是事后从 agent 的叙述中重建。
最后，一条不经过 agent 供应商的争议路径。如果对失败购买的唯一描述是 agent 自身的遥测数据，那就是在要求商家信任行为正受质疑的当事方。裁决需要双方都能对照共享签名方案核验的记录。
这不是什么奇特的密码学。它与带作用域令牌的签名 API 请求形状相同，外加一个持久、可独立验证的审计工件。难的部分是在第一笔交易之前就工件必须包含什么达成一致，而不是构建它。
为什么严格规则是一种责任设计
受规则约束的 agent 为商家在边界处提供了合规测试。商家可以在任何库存移动之前拒绝超出授权范围、预算或有效期的请求，而且拒绝的成本很低：对签名文档做一次检查。这比事后欺诈审查要便宜得多，后者需要在资金已移动、货物可能已发出之后，从残缺的日志中重建意图。
开放式 agent 将这一成本转嫁给商家。如果 agent 的范围模糊，商家无法在边缘测试合规性；它只能观察结果并在事后裁决争议。每一笔模糊的购买都变成一次审查，每一次审查都消耗利润。这比任何关于创新的说法都更好地解释了封锁姿态。无法为争议路径定价的商家会理性地拒绝集成，因为裁决的预期成本无界，而预期收益是投机性的。
诚实的权衡是严格规则会抑制交易量。一份指定狭窄目录和硬性预算的授权会拒绝一些人类购物者本会做出的合法购买。商家接受较低的 agent 驱动转化率，以换取有界的争议成本。这是有意的权衡，而非雄心不足。开放受限通道的零售商买的是可预测性；封锁的零售商拒绝的是未定价的责任。两者都在做同样的算术，只是对需要裁决的频率假设不同。
集成的设计规则
将授权视为一份经过签名、范围狭窄且具有机器可校验范围的文档。将 agent 视为店面的不可信客户端——因为它就是。店面应在边界处验证授权、记录签名回执，并在触及库存之前拒绝任何超出范围的内容。agent 关于自己做了什么的主张不是证据；签名记录才是。
在第一笔交易之前，将争议路径的成本计入集成。这意味着提前决定：有效回执包含什么、谁可以验证它，以及当授权有效但购买仍被争议时会发生什么。如果这条路径没有被设计，它将在第一次拒付时被发现，在最不方便的时刻，且由商家承担费用。
协议层正在趋同。责任层没有，而且不会自行趋同。授权记录正是欢迎与封锁的商家之间分歧的实际所在，也是集成团队应首先设计的界面。
先构建什么
在评估 agent 框架或店面插件之前，先写下授权模式和回执模式。用三种真正重要的失败模式来测试它们：范围外的购买、范围内但委托人否认的购买，以及过期后重放的授权。如果这些模式无法在不借助 agent 供应商日志的情况下裁决这三种情况，那么无论它支持多少协议，集成都尚未就绪。已经行动的零售商——无论朝哪个方向——都已就裁决做出了决定。其余的则在推迟。