跳转到主要内容

Agent 商务是委托语法问题,而非店面问题

Walmart 和 Amazon 争论的不是机器人。它们对购物者的授权如何在结账时被表达、限定和证明,给出了不同的答案。

复古电路板的特写,展示错综复杂的铜走线和电子元件

两道边界,缺失的一层

Walmart 已在严格的交互规则下向 agent 驱动的购买开放了其商品目录。Amazon 则保持边界封闭,拦截它不认为是授权 agent 的流量。从政策角度看,这像是一家零售商拥抱自动化、另一家抵制自动化。从工程角度看,事情更狭窄也更有趣:对同一个双方都尚未完全明确的问题,给出了两种不同的答案。

那个问题不是“agent 可以买东西吗?”而是“依据谁的授权、在什么范围内、商家如何得知?”Walmart 的规则集试图定义 agent 可以行动的条件。Amazon 的边界则试图在那些条件能够被确立之前拒绝行动。两者都是授权立场。两者都不是店面立场。

同样的缺口也出现在基础设施工作中:Cloudflare 和 Commerce.com 为 agent 流量构建店面就绪能力是有用的,但就绪并不等于委托。终止 agent 的请求、对其限流、为其签名,或暴露机器可读的商品 feed,描述的都是请求如何到达。它们都没有描述 agent 被允许代表购物者承诺什么。缺失的那一层位于身份与结账之间。

一份授权实际必须承载什么

授权是在承诺时刻代替购物者的凭证。它不是会话 cookie,也不是 API key。要在结账时可用,它至少必须承载:

  • 主体。 agent 代表谁行动,其身份识别方式必须让商家能够独立于 agent 本身进行验证。
  • 商家范围。 该授权在哪些商家处有效。授予某一家零售商的授权在另一家应当无效,且商家应当能够看出这一点。
  • 支出上限。 最大承诺额度,其表达方式要能经受货币和税费变化,而不是从购物车复制来的一个数字。
  • 商品约束。 类别、数量和排除项,编码的是购买的目的,而不仅仅是花费多少。
  • 有效期。 一个足够短的有效窗口,使过期的授权无法在之后被重放。
  • 撤销通道。 主体可以撤回授权的路径,以及商家侧查询该通道的义务。

硬性要求是:无需为每个购物者共享密钥即可验证。如果每个商家都需要与每个购物者建立双边凭证,系统就无法扩展到少数几个集成之外。授权必须是一个已签名、有范围的断言,商家可以对照主体公开的授权进行核验,而不是购物者交给每个店面的密码。

Close-up of a high-precision CNC milling machine cutting a metal piece

第二个硬性要求是抗重放。一个在超时后重试结账的 agent,从商家角度看,与下了重复订单的购物者无法区分。因此授权需要一个绑定到交易的唯一性属性,使同一意图的第二次提交被拒绝或去重,而不是被扣款。没有这一点,agent 发布的每一条重试策略都会变成重复计费的 bug。

为什么支出限额不是授权

数字上限限定的是数量。它不限定意图,而意图才是购物者实际委托的东西。

设想一份上限为几百个货币单位、没有类别约束的授权。十笔小额订单,每一笔都稳稳落在上限之内,造成的危害可能超过一笔会被上限阻止的大额订单:购物者的账户在一系列各自看似合理的交易中被掏空,没有一笔触发限额。上限自始至终都被满足。授权从第二笔订单起就被违反了。

类别和商家约束才是编码意图的东西。“本周从这家零售商更换坏掉的水壶”是购物者可以推理、商家可以核验的委托。“最多花费 X”则不是,因为它连同购买的权力一起,把买什么的判断也委托了出去。这一区别正是授权为何是比限额更丰富的对象。

撤销也是同样的形态。只在会话开始时生效的撤销不是撤销通道,而是通知。如果主体在 agent 会话进行中撤回授权,商家必须在承诺时看到这一点,这意味着授权是在承诺点而非连接点被检查。这是大多数店面就绪工作跳过的设计约束,因为它是唯一一个要求商家在结账路径中调用一个它无法控制的权威的设计约束。

诚实的权衡:承诺时授权检查会给漏斗中对延迟最敏感的部分增加一个依赖,而且它会失败关闭。无法访问撤销或验证端点的商家,必须在阻止一笔合法购买和接受一笔无法验证的购买之间做选择。为会话缓存授权的有效性可以减少依赖,但恰恰重新引入了会话中撤销本应关闭的那个窗口。没有任何配置能消除这种张力;只有关于窗口多长、以及窗口关闭时由谁承担代价的选择。

Close-up of brutalist architecture with geometric concrete shapes and rough textures

没人打分的评估问题

大多数购物 agent 基准测试给任务完成度打分。agent 找到商品了吗?它结账了吗?订单通过了吗?按这个标准,在授权之外完成的购买是成功,因为购买发生了。对于一个本应在委托授权下行动的系统来说,这是错误的评分函数。

购物 agent 的测试框架应当首先给授权一致性打分,其次才是完成度。具体来说,它应当能够按每个 episode 回答:

  • 每一笔已承诺的交易是否都在商家范围、支出上限和商品约束之内?
  • agent 是否在过期后或撤销后尝试承诺,该尝试是否被拒绝?
  • 重试是否产生了重复承诺,还是已对照原始意图去重?
  • 当授权与任务冲突时,agent 遵循了哪一个?

在授权之外的正确购买是失败。在授权之内、由 agent 自身错误导致的被拒购买也是失败,但是另一种失败。把两者都归入“任务未完成”,会掩盖商家在决定是否接受 agent 流量时唯一重要的信号。

这就是为什么信任徽章不够。徽章断言某个 agent 在某个时刻通过了某人的评估。一致性报告则让商家能够对照 agent 出示的授权,审计它在实际尝试的交易上做了什么。前者是声明;后者是证据。集成 agent 端点的商家需要后者,因为前者无法事后核验。

这场分歧真正关乎什么

Walmart 的规则和 Amazon 的边界都是临时的。一个说:行动,但只能在我们定义的条款之内。另一个说:在授权能够被确立之前不要行动。两者都在等待同一种缺失的语法——一种表达购物者授权的方式,它要有范围、有边界、可撤销、抗重放,并且商家无需为每个购物者持有密钥即可验证。

这种语法不是店面功能。它不会通过暴露商品目录或对请求头签名来交付,也不会由哪家零售商先行动来决定。它是一个关于委托的规范问题,把它当作规范问题对待的工作室和标准组织,将产出商家真正可以审计的东西。其余的则只会继续围绕一个他们尚未写下的问题构建边界。

分享XLinkedIn永久链接6 分钟阅读

相关阅读

这能回答的问题

Why is agent commerce described as a delegation problem rather than a storefront problem?

Because the unresolved question is not how an agent reaches a catalogue but how a shopper's authority is expressed, bounded and proved at the moment of commitment. Storefront readiness describes how a request arrives; a mandate describes what the agent may commit.

What should a purchasing mandate contain?

A principal the merchant can verify independently, merchant scope, a spend ceiling, item constraints that encode intent, an expiry window, and a revocation channel the merchant checks at commit time. It also needs replay resistance so that an agent retry is not charged as a duplicate order.

Why are spend limits insufficient on their own?

A ceiling bounds quantity, not intent. Several small orders can each sit inside the limit while together exceeding the harm of one large blocked order. Category and merchant constraints are what encode what the purchase was actually for.

How should shopping agents be evaluated?

Primarily on mandate conformance rather than task completion. A correct purchase made outside the mandate is a failure, and a conformance report that a merchant can audit is more useful than a trust badge asserting a past evaluation.