Shopify 结账换了工具清单：权限不是会话常量

结账页注册的是另一组工具，所以 agent 的能力边界会跟着流程阶段换组。会话开始时取到的那份清单不能当常量用，记录也不能按会话开头存。

一个浏览器里的购物助手陪你把跑鞋挑好了：尺码对、颜色对、加进了购物车。它接着往下走，去结账。就在这一步，它手里那套工具被换掉了。它照着开场拿到的清单去改收货地址，页面回它一个未知工具，因为店面那一组已经不在册。

这不是哪一方出的故障。Shopify 把它写成了文档里的正常路径，而这条路径对我们有用，是因为它给「agent 的权限从哪来」这个问题补上了一个具体的形状。

一、结账页注册自己的工具

Shopify 的 WebMCP 工具分两处注册。店面那一边管找货与购物车：search_catalog、browse_store、get_product、show_variant 负责搜目录、逛集合、看商品详情与可选规格；get_cart、update_cart、cancel_cart 负责看和改购物车。结账页那一边是另一组，负责读取和更新结账，以及提交订单。

官方文档里这句话是整件事的起点：「Checkout registers its own WebMCP tools, so the tool list changes when the shopper moves from your storefront into checkout.」买家从店面走进结账的时候，工具清单变了。

这套工具服务的是购物者自己带进浏览器的 agent，不是服务端跑的第三方 agent。所有动作都发生在买家正看着的那个标签页里：agent 改购物车，买家眼前的购物车跟着变；agent 导航，买家的页面跟着跳。同一份文档还写明，agent 改购物车走的是主题与插件共用的那套标准动作，所以如果主题给加购配了抽屉动画，agent 加购也会把抽屉拉出来。

再看工具自身的描述方式：每个工具都带一段说明，写给 agent 看，告诉它什么情况下该用这个工具。也就是说，清单不只是能力表，它同时是操作手册。清单换组，等于操作手册也换了一本。

还有一层变化来自浏览器。文档写明这套工具今天只对 Chromium 系浏览器里的 agent 开放，而且调用参数的传法正在改：在 Chrome 153 里传对象会因为解析失败被拒，要传 JSON 字符串；Chrome 155 计划接受对象并弃用字符串。也就是说，同一份工具面在浏览器版本之间还会换一次形状。把能力当成常量，实际上要同时赌流程阶段和运行时版本都不变。

把这些放在一起，有一句话可以说完：agent 在某一刻能做什么，由它此刻处在流程的哪一段决定。会话开始时那份授权只是一个起点，不是边界。

二、文档把「重读清单」写成了必需动作

比工具列表更有信息量的是文档对失败的处理。结账工具调用出错、被取消或超时之后，文档要求 agent 按顺序做三件事：先刷新工具清单，再调 get_checkout 读当前状态，然后拿读到的状态与自己的请求比对，最后才决定要不要重试。原文写得很直白：「After an error, cancellation, or timeout, refresh the tool list and call get_checkout. Compare the current state with your request before retrying.」

为什么必须先读状态？因为有一类错误的语义是「结果不明」。文档对 update_failed 的定义是更新失败或超时，并且可能已经部分应用。这不是一个可以自动重放的状态：地址、折扣、运费、库存这些字段里，可能有一半已经写进去了。在这种情况下直接重试，等于拿一个不知道起点在哪的请求去改一份已经改过一半的账单。

另外两处也要求重读清单。导航工具返回空值时，导航可能已经成功，文档要求页面加载完之后重新读一次清单，才能拿到店面那一组工具；提交阶段失败时返回的错误消息直接写着，要用 get_checkout 去读当前状态和它附带的话，不要试图通过操作页面来完成结账。

同一份文档里还有一条关于身份的写法值得记下来：浏览器请求要用 Web Bot Auth 签名来标识 agent，而不是把身份写进工具参数；只有注册过的签名密钥才算数，没有签名会被降级或直接拦住。顺着这句话，agent 在流程里「是谁」的依据是请求签名，不是它在对话里怎么自称。参数可以伪造，签名不行，这个区别在事后追责时是决定性的。

错误分类里还有一组不是失败、而是「等」的状态：买家的动作还没做完、结账正忙、已经有一次提交在跑。这三种情况下的正确反应是等待或把动作交回给买家，不是重试。把它们和 update_failed 放在一起看，能看出这套接口对 agent 的期待：它要能分辨「没成功」和「还不知道成没成功」，前者可以再试，后者必须先读。

把这几处放在一起看，工具清单在这套流程里不是初始化参数，而是每次跨越阶段边界或从异常里恢复时都要重新获取的运行时输入。这个区分对工程实现有直接后果：一个把清单在会话开始时取一次、写进系统提示、之后每轮复用的客户端，功能上看起来一直正常，直到流程走到最贵的那一步才失效。

三、协议早就假定清单是活的

这件事在 MCP 协议里其实早有位置。服务端如果支持工具清单变更，会声明 listChanged 能力；清单变化时它应当发出 notifications/tools/list_changed 通知，客户端收到后重新发一次 tools/list 取新清单。规范原文写的是：声明了 listChanged 能力的服务端在可用工具列表变化时应当发送通知。

也就是说，「清单会变」是协议给过的表达方式，「把清单当常量」是实现侧的选择。这个选择通常是为了省一次往返、让提示缓存更稳定，写在代码里只是一行缓存，代价要到流程出现阶段切换时才显形。同一份规范里还有一句对这类流程很应景的话：为了信任与安全，应当始终有一个能拒绝工具调用的人在场。在 Shopify 这条链上，那个在场的人的落点很明确——订单在买家确认之后才提交。

四、同类模式在 OAuth 里已经标准化

流程中途抬高要求、并要求一次新的确认事件，这不是 agent 时代才有的问题。OAuth 在 2023 年把它写成了标准：RFC 9470 定义的升级认证，让资源服务器可以告诉客户端「当前这个请求关联的认证事件不满足我的要求」，以及怎么满足。文档举的例子和电商贴得很近，一个电商接口按购买金额是否超过某个阈值来要求不同的认证强度。

这套设计的价值在于它把两件事分开表达：要求可以在流程中途提高，而每一次提高都对应一次新的、有时间点的认证事件，而不是复用此前那次模糊的「用户同意过」。和前面那条一样，它不是新技术的产物，是一个老问题的标准解法。

顺带说一句这个标准的适用范围：RFC 9470 写的是资源服务器与客户端之间的挑战与应答，也就是说这套「要求会提高、确认要重来」的机制在服务端之间已经跑熟了，缺的不是机制，是把它接到 agent 的流程记录上。这一段的用处也在这里：它说明我们要的东西不是一个新发明，而是一套已有标准的对齐。

五、我们的判断

会话级的权限快照是错的抽象。agent 的有效能力是「流程阶段乘以时点」的函数，所以「当时它能做什么」必须按决策时点留存，不能按会话开头留存。这一条不依赖任何厂商的实现方式，它是记录设计的必然要求。

理由可以拆成一段。任何事后复算都只能从记录出发。一份只记了「会话开始时被授权」的记录，能回答的问题是它有没有被授权过；它回答不了「它做那一步的时候能调什么」。当流程阶段会换组、工具清单会在异常后被重读时，这两个问题是两个不同的结论：前者说授权存在，后者说动作落在授权范围内。举证要的是后者。

对正在写这类 agent 的团队，有三个可以今天就做的检查：

• 工具清单是每次决策前读的，还是会话开始时取一次写进提示或上下文？在代码里搜系统提示的拼装处，通常能直接看到那份快照。
• 有没有接工具面变更的通路？是订阅了清单变更通知、在阶段边界强制重读，还是只有调用失败之后才知道清单变了？
• 记录里存的是会话开始时的授权，还是每一次动作决策时在册的工具面，加上最近一次授权事件的时点？

反过来说也成立：如果每次决策都重读清单，流程会多出几次往返，这是真实的代价。取舍的位置应该在阶段边界，而不是每一轮。一条从店面走到订单的流程，阶段切换是个位数量级的事件，把它当成必须重读的点，成本可以忽略；把它当成每一轮都做的事，才会拖慢系统。差别不在成本大小，在把变化放在哪一层消化。

这套做法不是所有流程都需要。触发条件是阶段边界：如果一条链路从头到尾只有一段能力面，比如一个只读查询工具，会话级快照没有毛病，因为清单本来就不会变。阶段越多，快照失效的概率越高；跨过支付、身份、外部系统这几类边界之后，它就不再是可以省掉的优化，而是一处必须补上的缺口。

六、记录里该有哪几个字段

把上面的判断落到字段上，我们建议的记录至少有五项：动作是什么；发生时点；那一刻在册的工具面（工具名及其版本）；发出该动作时生效的授权事件，也就是谁在什么时刻确认了什么；以及动作前的状态摘要，用于处理「可能已部分应用」这类结果。前四项回答「它当时能做什么、凭什么能做」，第五项回答「到底改成了什么样」。

第五项最容易被省掉，但它在 update_failed 这类错误上是唯一的判据。当失败语义是「结果不明」时，事后要判断这次动作到底改了多少，只能靠状态摘要，不能靠 agent 自己的叙述，因为叙述发生在同一套判断逻辑里。这就回到那条老规矩：能被独立复算的记录，比能自我解释的日志有用。

七、这篇不主张什么

先把边界说清楚。这是消费端的例子：定权限的是平台，不是企业客户；agent 是购物者自己带进浏览器的。它能说明「授权面随流程阶段变化、且授权有一个可定位的时点」这件事已经出现在公开产品里，不能说明企业端的委派、举证与审计已经解决。

还有一个容易读错的点：文档写明订单在买家确认之后才提交，所以不能读成「agent 可以不经买家确认直接下单」。另外，浏览器侧的 agent 支持目前只覆盖 Chromium 系浏览器，这条限制决定了它今天能用在哪。本文没有可量化的结果可以引用，没有成交数据、没有纠纷率，我们不拿它当效果证据。文中引用的机制描述都来自 Shopify 的开发者文档、MCP 规范与 OAuth 标准，链接列在下面。

八、留给买方的决策问题

如果你在做浏览器里的 agent，上面那三个检查今天就能做完，成本是一个下午。如果你在做企业端的委派架构，值得把「授权面随时间变化」写进记录规格里，因为它已经在最普通的购物流程里跑起来了，而企业内部流程只会更频繁地跨阶段。

最后留一个问题给正在评估的团队：你的 agent 在最贵的那一步，用的是哪一刻取到的工具清单？如果答不上来，说明那份清单从来没有被当成会变的东西。

参考来源

• Shopify WebMCP tools 文档（结账注册自己的工具、工具清单在进入结账时变化、目录与购物车工具清单）
• Shopify Checkout WebMCP 文档（工具发现与调用、出错后先刷新清单再读状态、update_failed 可能已部分应用、Web Bot Auth 签名）
• MCP 规范 Tools 章节（listChanged 能力、notifications/tools/list_changed、人工拒绝调用的要求）
• RFC 9470: OAuth 2.0 Step Up Authentication Challenge Protocol（2023 年 9 月，电商金额阈值示例）
• TechCrunch 相关报道（2026-09-28，本轮只取题名与时间，正文细节未直读）