购物智能体上线前，先锁住下单授权

购物 Agent 可以帮用户找商品、比价格、准备购物车，但能做好这些，不代表它就有权花钱。原文提出的发布原则很明确：付款必须经过服务端授权，用户确认的具体订单，要与最终提交的订单完全一致。

这篇文章的价值，在于把「购买前让用户确认」拆成了可以检查的工程约束：确认什么、订单变化后怎么办、超时能不能重试、拒绝后如何证明没有扣款。不过，它提供的是合成测试方案，并没有实际支付系统的验证结果。

用户确认的应该是一张订单快照

聊天中的一句「可以」，究竟批准了什么？是继续比价、加入购物车，还是立即付款？如果商品、卖家和金额仍在变化，单独保存这句话，很难成为可靠的授权凭据。

作者建议在确认前，由服务端刷新商品、库存、价格、税费和配送条件，然后冻结一份规范化的订单快照。它应包含商家与卖家身份、商品标识、规格、数量、币种、单价、税费、运费、可选费用、地址引用、支付方式引用、总额、有效期和幂等键。

用户看到的确认页与服务端提交的交易请求，都应使用这份快照。

用户批准的是这笔具体交易，订单的重要条件变化后，旧授权就应该失效。

这里的「重要」不能交给模型临场解释。换卖家、换尺码、增加订阅、提高总价、更改配送国家，都需要重新确认；刷新库存后发现条件完全没变，则可能不必。具体比较规则应落在交易服务中。

确认页也是控制措施的一部分。「Add to cart」不能触发付款，「Save this basket」不能创建订单。原文用「Place order for EUR 84.20」说明，按钮应该明确表达动作与付款后果，但没有把这个文案当成全球通用的法律要求。

长期偏好同样不能直接当作交易许可。「优先环保包装」只是偏好；「库存低于两个就买补充装」若要自动执行，还需要明确商品范围、卖家集合、数量、金额上限、时间窗口、配送目的地和取消路径，并由服务端逐次检查。

把支付权限放在模型够不到的地方

作者引用 OWASP LLM06:2025 Excessive Agency，强调工具功能和权限都应收窄。对应到购物流程，可以拆成只读搜索、草稿购物车、结算、取消和退款几类能力，各自使用独立权限。

搜索工具不需要支付凭据，编辑购物车也不该顺便创建支付授权。尤其应避免一个通用的「execute commerce action」函数，再让模型决定参数和执行范围。

原因很实际：卖家描述、评论、优惠券文本、配送备注、图片 OCR 和导入偏好，都可能包含不可信指令。这些内容可以影响推荐，却不能修改服务端策略，更不能授予付款权限。

原文给出一个 Node.js 演示，文件名为 checkout-gate.mjs，要求 Node.js 20 或更新版本，通过 node checkout-gate.mjs 运行。下面保留其中的授权判断函数，它检查当前订单能否使用已有许可：

function maySubmit(currentOrder, permit, now = Date.now()) {
  return Boolean(
    permit &&
    permit.action === "place_order" &&
    permit.userId === currentOrder.userId &&
    permit.orderHash === snapshotHash(currentOrder) &&
    permit.expiresAt > now &&
    permit.idempotencyKey === currentOrder.idempotencyKey
  );
}

要看的是 permit.orderHash === snapshotHash(currentOrder)：当前订单必须与批准时的订单匹配。这里是原脚本片段，依赖前面定义的 snapshotHash，不能单独运行。

演示使用整数分表示金额：两件商品单价各为 1800，税费 720，运费 490，总计 4810，币种为 EUR，有效期为 60_000 毫秒。下面这段验证总额增加 500 后，旧授权会被拒绝：

const changedOrder = { ...order, totalCents: order.totalCents + 500 };
if (maySubmit(changedOrder, approval)) {
  throw new Error("Unsafe: changed amount reused the old approval");
}
console.log("PASS: changed total invalidates prior approval");

要看的是 changedOrder 那一行。它证明的只是示例函数能发现总额变化，没有证明支付链路安全。

作者也承认，演示不处理身份认证、签名验证、税费计算或真实付款。生产环境需要可信后端签发受密码学保护的授权令牌，结算接口检查调用者、权限、签名、有效期、订单哈希与幂等键，再调用支付服务。

快照本身也需要规范化。示例用 JSON.stringify、按 SKU 排序和 sha256 生成哈希，但仅排序商品还不够。字段顺序、重复行项目、数量与金额表示都要有明确规则；数据结构应带版本，并拒绝未知字段，避免未来新增自动续费选项时被比较逻辑漏掉。

发布测试要证明「没有发生」，不能只看提示语

原文把验收方案称为「16 个合成场景」，其中 8 个覆盖允许执行或安全准备，另 8 个覆盖阻断、授权失效或人工确认。它明确说明：没有测试真实商店、Agent、支付系统、用户或模型输出，不能据此计算通过率和事故概率。

而且，提供的原文没有列出完整的 16 行测试矩阵，结尾还停在「A consulting outlook」。读者拿到的是设计原则与测试流程，仍需自行补齐用例。

每个用例应写清初始状态、用户身份与权限、用户意图、可信和不可信输入、允许与禁止的工具调用、预期快照、界面反馈、审计事件，以及回滚或对账步骤。

拒绝用例通过的标准，是副作用没有发生，而不是界面出现了拒绝提示。

如果 Agent 说不能购买，支付 API 却执行了，用例失败；如果后端拒绝付款，前端却显示订单完成，也失败。检查范围应延伸到订单数据库、支付测试账本、邮件或短信队列、库存预留和下游 webhook。

超时尤其容易出问题。商家可能已经创建订单，只是响应没回来。此时应使用同一个幂等键查询原操作，不能换一个键重新创建。「Unknown」可以是合法状态，不应自动解释为失败。

发布顺序则从只读发现开始，再开放无支付权限的草稿购物车，随后在预发布环境验证绑定授权的单笔交易。生产环境还需要模型之外的停用开关，在 API 或凭据层关闭下单，并配合限额、限速和异常告警。取消也有时限，包裹出库之后，「可以撤销」就未必成立。

我的判断

我赞同它把重点放在服务端授权上。提示词适合约束 Agent 的行为，交易服务才适合决定请求有没有执行资格。前端确认弹窗能帮助用户理解操作，但浏览器里的布尔值无法替代授权记录。

它的证据边界也划得比较清楚。Wharton Generative AI Labs 在 2026 年 8 月 27 日发布的研究，主实验使用 6 个前沿模型、每个条件运行 200 次，观察信息顺序和注入记忆对选择的影响；它没有测试真实购买或授权控制。它能支持「选择可能受上下文影响」，不能证明这套结算方案有效。

其他数字也不能扩大解读：2026 年 11 月 1—8 日，特定 Search Console 属性中「agent e commerce」只有 2 次展示，平均排名 27.5；餐饮协会 2024 年报告的在线样本超过 1,000 人，研究的是数字点餐与支付偏好，都不是自主购物授权的用户证据。

欧盟消费者指引和 C‑249/21 Fuhrmann-2 判决，也只能支持各自适用范围内的信息披露与付款表达要求。AI Act 概览并不提供通用结算授权协议。

因此，这是一套有用的工程验收建议，仍缺真实系统与对照数据。如果业务只需要推荐和比价，保留商家链接或草稿购物车，通常已经能完成任务，没有必要仅为自动化体验开放支付权限。

能拿来做什么

• 做购物助手时，先把商品搜索、购物车编辑与付款拆成不同工具和凭据，根据业务需要逐步开放权限。
• 做确认页时，让页面与结算请求使用同一份服务端快照；卖家、规格、地址或金额变化后，展示差异并重新确认。
• 在 Node 服务中，把授权验证和幂等处理放在真实交易调用之前，超时后查询原操作，避免自动重建订单。
• 编写端到端测试时，同时断言界面结果与下游副作用，尤其检查拒绝之后是否仍有订单、扣款或后台重试。