购物 Agent 的正确性不能只验支付

购物 Agent 能把钱付出去，不代表它买对了东西。选错规格、漏掉数量、把商品标价当成含运费总价，都可能让一次技术上成功的支付变成失败的采购。原文的核心主张是：购买系统必须分别验证选品、交易条款、支付授权和履约，不能用支付成功替它们盖章。

文章以 WebAZ 的公开文档为例，讨论这些边界怎样落实到系统设计。对开发 Agent 的程序员，最有用的是授权边界和异常状态处理。但要先划清证据范围：开场案例是假设，验收测试是建议，作者没有提供新的端到端支付实验。

商品找到了，为什么还不能直接付款

作者举的场景很具体：买家想在总预算内购买两把便携雨伞，送到新加坡。Agent 找到了商品，却选成大号、漏掉数量，还把展示价格当成到手总价。钱包签名和支付流程都没出错，买家依然拿不到想要的结果。

问题在于，几个不同阶段被混成了一个「购买」动作。作者建议区分四类对象：

• 买家意图记录需求、硬性约束和可以接受的替代方案。
• 商品选择记录准确的规格、数量、目的地，并显式保留未知信息。
• 报价与订单记录买家或委托策略已经接受的交易条款。
• 支付授权规定可以执行哪笔转账，以及适用的支出限制。

这不是要求所有商城使用同一套数据库结构，而是要求系统保留这些边界。搜索结果只能证明某个商品可能合适，既不是确定的到手报价，也不是花钱许可。

未知信息也不能悄悄变成默认值。折叠尺寸缺失，就不能根据照片推断它足够便携；运费未知，就不能按零运费结算。缺少的信息应该阻止依赖它的决定，同时允许系统继续查证或提出附带说明的替代选项。

商品描述还有另一层风险：商家写的文字属于不可信数据。它可以帮助识别商品，却不能指挥 Agent 绕过预算、修改收款人或调用支付工具。

付款依据应该来自订单，谁能付款还要单独判断

作者称，其在 2026 年 10 月 23 日核对了 WebAZ x402 公开指南。文档中的 Direct Pay 流程是先报价，再创建符合条件的订单，随后读取订单的支付资源。

其中，HTTP 402 支付要求里的金额和收款人来自订单冻结快照，调用方不能通过支付请求修改它们。这避免了让模型生成的「给卖家支付大约五美元」直接成为执行依据。

支付必须绑定服务器确认的具体订单，订单也必须对应买家选定的商品。

后半句同样重要。冻结快照只能固定已有选择，不能证明选择正确。规格、数量或其他重要条款发生变化后，客户端仍需重新检查买家批准的范围。

授权也分两条路线。拥有 payment:request 权限的 OAuth Agent，只能请求所有者批准，不能自行签名或转账。钱包支持的 Agent 则依赖所有者启用的 autopay、适用凭证和支出限额。

即便是权限更窄的 payment-only key，也包含创建符合条件的订单和付款等重要能力。「只与支付有关」不代表风险很小。超过委托预算时应该转交所有者，不能拆成几笔购买绕开限制，界面也应清楚区分「申请付款」与「执行付款」。

还要看清交易保障。WebAZ 文档中的 Direct Pay 使用 Base 上的 USDC，资金直接进入卖家钱包，平台不会持有余额等待交付。WebAZ 不核验收款方或支付方式，不保证交付，也不代卖家退款。结算验证无法替代卖家可信度判断。

支付超时之后，为什么不能直接再付一次

支付请求超时，可能是没有执行成功，也可能是资金已经转出，只丢了响应。把两者都当成失败，再生成一次签名，是危险的恢复方式。

根据作者引用的指南，重复提交同一份已签名请求具有幂等性，也就是重复请求不会重复产生效果。如果同一订单已经有活跃或成功的结算，使用另一份授权会被拒绝。遇到超时或 409，应先读取订单状态；处于 settling 状态也不能认定失败。

原文给出下面的设计伪代码，用来表达每个阶段允许采取的动作：

selection unresolved -> clarify
selection resolved -> quote and validate terms
terms accepted -> create and inspect order
authorization missing or limit exceeded -> owner handoff
payment submitted -> reconcile authoritative state
settlement uncertain -> remain pending; do not re-sign
payment confirmed -> track fulfillment separately

关键看 settlement uncertain 那一行：结算结果不确定时，保持等待，不重新签名。这不是可执行的 WebAZ SDK 示例，也不是经过新增故障测试验证的实现。

最后一行则提醒前端：付款确认之后，还要单独跟踪履约。支付成功页面不能顺手宣称商品已经交付。

我的判断

我认可作者对边界的划分，尤其是把未知信息和不确定结算保留为独立状态。相比让模型读完商品页就连续调用购买工具，这种设计更容易审查，也更方便定位责任：到底是选错商品、条款不完整，还是授权和结算出了问题。

不过，文章证明的是一套设计思路，并没有证明采用它之后能减少多少错单，也没有与普通电商结算接口、人工确认流程做对照。这部分应视为基于文档的设计建议，不能当成效果数据。

它也依赖服务端提供可靠的订单快照、状态查询和幂等机制。接入其他商城时，不能默认这些能力都存在；只有客户端状态机，无法补齐服务端缺失的交易保证。

此外，文章代表 WebAZ 发布，并披露由 AI 根据公开文档生成、未经人工编辑。因此，通用的边界思路可以借鉴，WebAZ 的具体行为仍应在实际接入时核对。

能拿来做什么

• 开发购物 Agent 时，先完成只读的搜索和选品流程，把规格、数量、目的地及必需但缺失的信息明确记录下来，再接支付。
• 在 Node 服务端用确定的订单标识关联支付要求，并在付款前重新核对选择和条款；重要条件变化后，重新检查已有批准是否有效。
• 为前端分别展示等待批准、支付处理中、结算待确认和待履约状态，超时后先查询权威订单状态，避免把重新签名当成通用重试。
• 把作者提出的五种情况加入验收：报价后改规格、尺寸或运费缺失、超出预算、支付响应丢失，以及付款成功但履约未完成。这些是待执行的测试建议，不是文章已经验证的结果。