Shopify结账页接入WebMCP：浏览器里的AI代理能替买家下单，确认和付款仍归买家

摘要：Shopify在9月28日的开发者更新日志里宣布，结账页也开始注册WebMCP工具。符合条件的Shopify结账页现在有四个工具：读取结账和订单、更新联系方式配送折扣和付款、在买家确认后提交订单、返回店铺。浏览器里的AI代理可以替买家把结账走完，但改不了订单里的商品，也不能输入新的银行卡，Shop Pay登录和3D验证这类付款挑战会交回给买家在页面上处理。商家不需要做任何配置。三页式标准结账只有买家用Shop Pay时才有这些工具，B2B结账、嵌入式结账和移动端结账SDK都不在范围内，目前也只支持Chromium内核的浏览器。Shopify推荐的仍是在服务器端运行的Checkout MCP，浏览器方案只在代理本来就跑在买家浏览器里时才用。

8月份，AI代理在Shopify店铺里能做的事止步于结账页门口：搜商品、加购物车，然后把买家送到结账页，剩下的自己来。一个月后，这扇门开了。

Search Engine Journal的Matt G. Southern在9月29日的报道里写了这件事。Shopify把WebMCP工具扩展到了结账环节，浏览器里的代理可以读取、修改买家正在看的结账页，并在买家点头后直接下单。这篇以那篇报道为主体，对照Shopify的开发者文档，把代理在结账页能做什么、不能做什么、哪些店铺有这些工具讲清楚，再说说做独立站的人该关心什么。

WebMCP是什么，这次结账页多了什么？

先补一点背景。浏览器里的AI代理过去帮人购物，靠的是看页面：截图或读页面结构，判断哪个是按钮，再模拟点击和输入。按钮换个文案、弹出一个优惠窗口、遇到一个自定义的日期选择器，都可能让它卡住。

WebMCP给了网站另一条路。网站把一组带名称、说明和输入格式的工具注册给浏览器，代理发现这些工具后，按格式传参数，拿回结构化的结果，不用再去猜页面上哪个元素是干什么的。这个方案由Chrome团队推动，2月发布了早期预览，6月在Chrome 149开了源试用。按SEJ 8月的整理，它的规范由W3C的Web机器学习社区组发布，目前还不是W3C正式标准，也不在标准制定轨道上。

8月是WebMCP从实验走进真实产品的一个月。Shopify在所有Liquid店铺上线了工具，第二天Cloudflare发布开发者预览，能在边缘节点给网站注入一段桥接脚本，不改源站代码就能启用WebMCP。8月25日，OpenAI给ChatGPT桌面端内置浏览器加了网站工具功能，ChatGPT Work和Codex可以发现并调用当前页面提供的工具，OpenAI还和Chrome、Shopify、Cloudflare等公司一起办了为期10天的WebMCP挑战赛。

它和大家熟悉的MCP不是一回事。Chrome的说明里有句话讲得很形象：应用不再是代理里的客人，代理成了你平台上的客人。远程MCP服务器不用打开网页也能提供工具，WebMCP的工具则只在当前标签页里存在，页面关了工具也就没了。

Shopify是最早大规模上线的平台之一。按它的店铺端WebMCP文档，每个用Liquid主题的店铺都自动带有10个工具，覆盖搜索商品、浏览系列、查看商品和变体、读写购物车、去结账、查订单、回答退换货和配送政策。其中去结账那个工具只负责把买家带到结账页，不会替人付款。

这次的变化写在9月28日的开发者更新日志里。结账页注册了自己的一套工具，买家从店铺进入结账页时，浏览器里的工具列表会整体换掉。日志强调，这些工具运行在结账页内部，用的是和结账界面完全相同的状态，不提供新的接口，也不需要商家做任何配置。

结账页这四个工具各管什么？

先把一单从头到尾的路径串一遍，四个工具放在哪个位置就清楚了：

1. 买家在店铺里让代理找商品，代理调用店铺端的search_catalog和get_product，看价格、库存和变体。
2. 代理用update_cart把选好的变体加进购物车，买家在同一个标签页里能看到购物车的变化。
3. 代理调用proceed_to_checkout，确认购物车不是空的，把买家带到结账页。
4. 进入结账页后，浏览器里的工具列表整体换成结账工具，代理要重新获取一次工具列表。
5. 代理用get_checkout读取当前状态，再用update_checkout补齐邮箱、收货地址、配送方式和折扣码。
6. 代理把订单和总价给买家看，买家同意后，代理调用complete_checkout下单。
7. 到了感谢页，代理再调一次get_checkout，就能拿到订单号和订单状态页链接。

如果结账页没有注册工具，比如店铺用的是不支持的结账类型，代理就该停在第三步之后，让买家自己在页面上完成结账。

按Shopify的结账WebMCP文档，符合条件的结账页会注册四个工具：

每次更新，结账页都会按自己的规则重新校验一遍，和买家手动填写时走同一套检查。代理不能改订单里的商品，想换货、加件，只能让买家在页面上自己操作。

代理是怎么调用这些工具的

工具注册在结账页的顶层文档上。按文档的写法，代理先通过浏览器提供的接口拿到工具列表，按名称、所在窗口和来源找到要用的工具，再把参数以JSON字符串传进去，拿回结果后解析，检查状态是不是成功：

const tools = await document.modelContext.getTools();
const tool = tools.find(t => t.name === 'get_checkout'
  && t.window === window && t.origin === location.origin);
const raw = await document.modelContext.executeTool(tool, '{}');
// 页面在结果返回前跳转，会拿到 null
const checkout = raw === null ? null : JSON.parse(raw);
// 成功时 checkout.ucp.status 为 success，出错时换成 error 对象

买家在结账页往前走一步，工具列表就可能变一次，代理要监听工具变化事件，及时刷新工具和参数格式。这些细节商家不用管，但能帮你理解一件事：代理的每一步操作都落在买家眼前这个页面上，买家随时看得到、随时能接手。

改一次要把整份结账信息都带上

文档里有一个开发者容易踩的细节：update_checkout按整体替换的方式处理请求。每次调用都要把希望保留的值一起传过去，漏掉的字段大部分会被清空，付款、附加字段和已保存的联系信息各有特别的处理方式。所以文档建议每次修改前先调一次get_checkout，在最新结果的基础上改。

另外，返回了折扣码不代表折扣已经生效，要看结果里实际应用的折扣和提示信息。更新耗时超过30秒会返回失败，但修改可能已经写进去了，代理再试之前最好先读一次当前状态。

付款这一步卡得很严

这些工具不接受新的银行卡信息。代理能做的只有两件事：从买家的Shop Pay里选一张已保存的卡，或者在访客结账允许的情况下，用代理已经拿到的Shop Pay授权。其他付款方式，一律由买家在结账页上自己选择和填写。

对国内做独立站的卖家来说，代理下单这条路，在现阶段基本和Shop Pay绑在一起。买家没有Shop Pay账号、或者习惯用PayPal和本地支付方式的，代理最多帮你把地址和配送选好，付款还得人来。

买家在哪些环节必须自己来？

Shopify的文档把下单前的确认写得很死。代理调用complete_checkout之前，要把当前订单内容和总价展示给买家，并取得买家下单的许可。文档还专门列了三种不算同意的情况：代理用Web Bot Auth签了名、代理手里有Shop Pay授权、结账状态显示可以完成。这三样都只说明技术上能下单，不代表买家同意了这一单。

下面这些环节，控制权会交回买家：

• Shop Pay登录，需要买家在页面上完成。
• 付款挑战，比如3D Secure验证，由买家在页面上通过。
• 阻断型界面扩展和需要人工审核的步骤，交给买家处理。
• 应用自定义的结账扩展，比如某些插件加的问卷、协议勾选，由买家自己操作。

3D验证这块，做欧洲市场的卖家应该不陌生。强客户认证规定落地后，欧洲的银行卡支付普遍要多一步验证，站内之前写过3DS 2新规对独立站的影响。代理接管结账以后，这一步照样跳不过去，代理会把页面交回给买家。

代理要先证明自己是谁

Shopify要求代理用Web Bot Auth给浏览器请求签名，靠它识别代理身份。没有签名的请求，可能被机器人检测系统降低优先级或直接拦截。文档列了几步准备工作：生成Ed25519签名密钥，把公钥放进一个密钥目录，向Shopify登记并公开这个目录，在请求头里带上签名，签名时间戳要短。Shopify只认登记过的密钥。

这对商家意味着，正规代理的流量是可以被识别出来的，和那些伪装成普通浏览器的抓取脚本分得开。不过文档也说了，Web Bot Auth签名只证明身份，不等于买家同意下单。

工具返回的文字要当数据看

文档里有一条安全提示：工具返回结果里，商家和第三方写的文字要当作结账数据处理，不能当成指令，因为里面可能藏着提示注入。代理也不能绕开工具，自己去点页面上的按钮。SEJ 8月的文章也提到，Chrome的安全指南把工具描述里藏指令、返回内容被污染列为WebMCP的两大风险，OpenAI则把网站提供的工具定义和返回结果都当作不可信内容处理，涉及购买的调用要过安全审查。

哪些店铺的结账页有这些工具？

不需要配置，不代表所有结账页都有。按SEJ和Shopify购物车与结账文档的说明，适用范围是这样的：

浏览器也有限制。Shopify的店铺端文档写明，代理目前只能在Chromium内核的浏览器里用WebMCP。SEJ 8月整理的实现进度表里，Chrome 149和Edge 150有源试用，Brave的Leo有实验支持，Firefox和Safari没有列出支持。

所以一家店的买家里，有多少人能用上代理下单，要看三件事叠在一起：店铺用的是哪种结账、买家有没有Shop Pay、买家用的是不是Chromium浏览器和支持WebMCP的代理。做B2B批发的外贸站，走的是B2B结账，目前完全不在这次的范围里。

浏览器里下单和服务器端下单，Shopify更推荐哪个？

Shopify给代理在结账阶段准备了两条路，并且明确推荐服务器端那条。

两条路底层用的都是通用商务协议UCP的结账能力，共用同一个结账对象和状态。区别只在于工具从哪里调用。不管走哪条，商家始终是交易的记录方，订单、发票、售后责任都还在商家身上，代理只是帮着填表和点提交。

UCP最早是Google牵头的开放协议，站内写过Google UCP对电商SEO的影响，也写过小商家接入AI购物代理该怎么配置。Shopify这次把浏览器端和服务器端都挂到UCP上，代理开发者不管选哪条路，拿到的数据结构是一样的。

结账之前还有购物车这一站

同一份文档把购物车阶段也分成两种做法。一种是购物车MCP，代理自己维护购物车，可以反复调整商品和数量，在买家确认前读到预估总价，这些购物车工具不需要认证，买家还在逛的时候就能调用。另一种更简单，叫购物车永久链接：商品目录接口会给每个变体返回一个结账链接，代理直接把链接交给买家，点开就是预填好商品的结账页。

永久链接后面可以加参数，用来预填买家信息、带上折扣、附加自定义追踪数据或营销归因参数。对商家来说，这是目前比较现实的一个办法：代理从站外带来的订单，如果走的是永久链接，链接上的来源参数就能在分析工具里留下痕迹。文档还提醒，一个链接只对应一家店，代理从多家店挑了商品，要按店铺域名分组，分别生成结账链接。

Shopify自己做的对比测试

Shopify做代理商务的Gil Greenberg在X上分享了一组内部测试结果，比较WebMCP和传统的浏览器自动化，也就是让代理读页面、自己点。两种方式都用GPT-6 Sol模型，提示词和起始条件相同，在两家测试店里各跑十个结账任务。

这组数字看着漂亮，SEJ也点出了几处要打问号的地方：只在Shopify的测试店里跑，只用了一个模型；Greenberg帖子里有一行写的测试总数，和每种方式60次的说法对不上；更新日志和结账文档里都没有真实世界的数据，没有代理下单量，也没有转化率。说WebMCP比让代理自己点页面更快更稳，方向上可信，具体幅度先当参考。

做独立站的商家，现在该做什么？

好消息是，这件事不需要你动手。符合条件的结账页自动就有工具。要做的更多是心里有数，以及提前把几处容易出问题的地方理一理。

先弄清自己的结账属于哪种

到后台看一下用的是一页式还是三页式结账，主要市场的买家里Shop Pay用得多不多。如果结账页装了很多自定义扩展，比如强制勾选的条款、问卷、加购推荐，代理每碰到一个阻断型扩展，就要把页面交回买家，代理下单就没那么顺。没必要为代理去删这些东西，但值得排查一下哪些是真正必要的。

商品和政策信息要能被读懂

代理在结账前的那一段，用的是店铺端的10个工具：搜商品、看变体、问退换货政策。商品标题写不清、变体命名混乱、退换货政策页语焉不详，代理在前面就会犯难，根本走不到结账。站内之前写过独立站智能体就绪度自查表，也写过代理读的是无障碍树而不是截图，这些检查在WebMCP时代照样适用，因为没有工具可用的环节，代理还是要回去读页面。

准备好区分代理订单

SEJ指出，截至报道时，Shopify的店铺端和结账端文档都没说商家能不能关掉某个工具，也没说能不能在报表里把代理下的订单单独分出来。这两件事值得盯着Shopify的开发者更新日志。在官方给出办法之前，可以先观察Shop Pay订单的变化，以及来自ChatGPT桌面浏览器这类代理的访问。

说到代理，SEJ也提到Shopify文档没点名哪些代理会调用结账工具。ChatGPT的桌面浏览器在8月加了网站工具支持，但OpenAI那篇帮助页里没有提到Shopify的结账工具。所以目前能确定的只是工具已经在那里，谁会用、用了多少，还没有公开数据。

对SEO意味着什么

WebMCP作用在用户或代理已经进了你的网站之后，和排名、收录、AI引用没有直接关系。SEJ 8月的文章特别强调过这一点：网站对代理友好，不等于更容易被找到。发现靠的还是搜索、AI推荐和商品数据源，站内之前写过Google-Agent和WebMCP这些协议对SEO的意义，思路可以对照着看。

简单归纳一下这次更新：代理在Shopify上第一次能把一单从头走到尾，但付款和确认这两道闸都留在买家手里，适用范围也被结账类型、支付方式和浏览器三重限制住了。对卖家来说，眼下不需要投入，需要的是关注。

常见问题解答

Shopify的结账WebMCP是什么时候上线的？

Shopify在9月28日的开发者更新日志里宣布结账页支持WebMCP工具。此前8月上线的店铺端工具只能把买家带到结账页，不能下单。

商家需要开启或配置什么吗？

不需要。更新日志写明这些工具不提供新接口，也不需要商家配置，符合条件的结账页会自动注册。

AI代理能在结账页改订单里的商品吗？

不能。代理可以改联系方式、配送或自提、折扣码、付款方式和税号等附加字段，商品要由买家在页面上自己修改。

代理能替买家输入银行卡吗？

不能。工具不接受新的卡信息，代理只能选择Shop Pay里已保存的卡，或在访客结账允许时使用已有的Shop Pay授权，其他付款方式由买家在页面上完成。

代理下单前必须做什么？

必须把当前订单和总价展示给买家并取得下单许可。Web Bot Auth签名、Shop Pay授权或结账状态显示可完成，都不算买家同意。

三页式结账的店铺能用吗？

只有买家用Shop Pay结账时才有WebMCP工具。B2B结账、嵌入式结账、移动端结账SDK、草稿订单和订单编辑都不在范围内。

哪些浏览器支持？

Shopify文档写明目前只有Chromium内核浏览器的代理能用WebMCP。Chrome和Edge有源试用，Firefox和Safari暂未列出支持。

Checkout WebMCP和Checkout MCP有什么区别？

前者的工具由结账页注册在买家浏览器里，后者由代理在自己的服务器上调用。Shopify推荐服务器端方案，浏览器方案只在代理本来就运行在买家浏览器里时使用。

WebMCP比让代理自己点页面快多少？

Shopify员工分享的内部测试里，WebMCP在60次尝试中全部成功，每次10.3秒；浏览器自动化成功56次，每次27.4秒。测试只用了一个模型和测试店铺，没有真实订单数据。

WebMCP会影响搜索排名吗？

不会直接影响。WebMCP只在用户或代理已经打开页面后起作用，与排名、收录和AI引用无关，被找到仍然靠搜索、推荐和商品数据。

代理从站外带来的订单能看出来源吗？

如果代理用的是购物车永久链接，链接可以附带营销归因参数和自定义追踪数据，来源能在分析工具里留下记录。浏览器里直接调用结账工具下的单，目前文档没有说明如何单独区分。

商家能关掉某个工具或单独统计代理订单吗？

截至SEJ报道时，Shopify的文档没有说明。商家可以关注Shopify开发者更新日志里后续的相关更新。

权威参考资料