BigCommerce 接入 Cloudflare WebMCP：Stencil 店铺默认开启，浏览器 AI 导购零改代码加购
一台浏览器里的 AI 智能体走进你的店铺，不用点任何按钮，就能检索真实商品、比价、把东西加进购物车——10 月 21 日起，BigCommerce 上符合条件的店铺，这件事默认发生，卖家什么都不用做。
Commerce.com（Nasdaq: CMRC，BigCommerce、Feedonomics、Makeswift 的母公司）与 Cloudflare 于 10 月 21 日联合发布 WebMCP 集成。按照官方新闻稿的说法，符合条件的店铺无需写代码、无需改站，功能自动开启；购物者浏览器内的 AI 智能体可以直接检索店铺真实商品与价格、比较、加购并回传链接，结账仍回到卖家自己的店铺完成。卖家可以在 BigCommerce 后台新增的 MCP 设置菜单里一键关掉，该菜单同时管理 Commerce 的全部 AI 连接。
官方稿里没有出现任何一个量化数字：没有店铺数、没有覆盖率、没有转化提升，也没有定价。这本身就是一个信号——它卖的是一个开关，不是一个已验证的增长曲线。
技术底座分成两层。BigCommerce 侧的 B2C 与 B2B Storefront MCP 提供商品检索与购物车管理这些商务工具，运行在 BigCommerce 自己的服务器上；Cloudflare 提供浏览器连接层，把工具定义代理到边缘。Commerce 产品管理总监 Kristina Pototska 的说法是，商家想要的是三件事：出现在智能体的答案里、留住客户、保住结账环节，而且不用重建站点。
一、让 AI 不用猜按钮
WebMCP 要解决的，是智能体逛街的老毛病。
今天绝大多数替人购物的智能体是基于 HTML 工作的：读页面、猜哪个按钮是干什么的、点下去、错了再试。Cloudflare 在官方博客里把这套流程描述为慢、吃 token、而且脆弱——一次看起来无害的主题改版就能让它失效，cookie 横幅和反爬挑战更是常见坑。
WebMCP 换了个思路。这是谷歌提出的浏览器标准，让页面直接向智能体暴露结构化工具，比如 search_products 与 add_to_cart，挂在 document.modelContext 上。官方给的例子是：购物者对智能体说「找一件低于 140 美元、10 码的防水越野跑鞋并加进购物车」，智能体把它拆成两次工具调用，而不是几十次点击模拟。
价格与库存直接从店铺后端拉取，这一点是 Commerce 反复强调的。Commerce AI 产品高级副总裁 Sharon Gee 的说法很直白：每个 AI 助手都将变成购物助手，而它们大多还在像机器人一样点击和抓取，把价格和库存搞错；WebMCP 用一次「握手」取代猜测——智能体直接问店铺有什么尺码、什么价、多少库存，店铺给出准确答案。
对卖家来说，这意味着一件更实际的事：错价错库存的代价变了。过去一个变体数据写错，代价是一个困惑的购物者；现在可能是人类还没看到页面，这单就已经没了。
二、默认开启这个开关
「无需设置」是这次发布最值得琢磨的四个字。
官方博客写得很清楚：符合条件的店铺默认开启，可在 BigCommerce 控制面板新增的 MCP 设置菜单中随时退出。Cloudflare 侧的方案是 8 月就上线的边缘 beta——打开开关，Cloudflare 在边缘注入一小段脚本，站点拥有者不用写一行代码；Commerce.com 的工具逻辑仍留在自己的后端 MCP 服务器，Cloudflare 原样代理工具定义与动作。
之所以要专门为「退出」做工程，是因为 Commerce.com 通过 Cloudflare for SaaS 在共享区域上跑着成千上万个独立域名。Cloudflare 需要用配置规则与自定义主机名元数据，才能做到按单个商家粒度退出。另有一层兜底：如果店铺的 MCP 服务器离线，或者访客浏览器不支持 WebMCP，脚本直接退出，店铺按原样加载。
B2C 与 B2B 的能力边界也不同。B2C Storefront MCP 支持访客购物，并通过 Storefront Session Sync 让已登录购物者保留既有购物车与个性化定价；B2B Storefront MCP 支持采购清单与报价，按买家权限生效。
一个你没选过的默认值，仍然是一个决定。卖家至少应该打开那个新菜单，看看开了什么，然后有意识地选一次。
三、只有 Stencil 能上车
官方博客在 FAQ 里给了明确限制：起步阶段，只面向基于 Stencil 架构搭建的符合条件店铺，后续会继续增加受支持的店铺类型。
这条限制值得单独拎出来，因为 Cloudflare 官方博客给的是另一个量级——Commerce.com 用 Cloudflare 运行着近 10 万个域名，双方的合作把 WebMCP 一次性铺到了这个规模。有开发者文档进一步提到，Stencil 店铺以及托管在 Cloudflare 上的 Catalyst 店铺默认启用，但商品检索、购物车管理与结账链接这些工具仍需 Storefront MCP 处于开启状态。
两个口径之间的空隙，官方没有填：新闻稿没有定义什么叫「符合条件」，也没有给出实际生效的店铺数量。对大量已经迁移到 Catalyst 或无头架构的 BigCommerce 卖家来说，这次发布暂时和他们无关。
定价同样是空白。Commerce 与 Cloudflare 都没有公布这项能力的收费方式或收费标准，也没有说明是否会并入现有套餐。
四、标准还在变
更大的不确定性在浏览器这一侧。
WebMCP 目前仍是实验性的拟议标准，处于早期预览阶段，没有正式可用日期。公开资料显示，它藏在实验性 Chrome 开关（chrome://flags/#enable-webmcp-testing）后面，同时存在于 Chrome Origin Trials、部分智能体浏览器，以及 Cloudflare Kitesurf 这类开发环境。微软 Edge 的 Origin Trials 目录把 WebMCP 列为进行中的试验，有效期已延长至 2027 年 3 月 30 日，取代此前公布的 2026 年 11 月 17 日。
标准本身还在动。Chrome 150 中已经废弃了早期 navigator.modelContext 的写法，说明这套 JavaScript 接口并不稳定；Chrome 文档还补充了生命周期、取消与跨源控制。Edge 与 Chrome 同为 Chromium 系，试验条款里明确写着可能不稳定、可能终止，需要特性检测与优雅降级。
换句话说，这是一次把实验性标准铺到近 10 万个店面上的大规模部署，不是浏览器普遍支持的证明，更不是转化提升的证明。Cloudflare 与 Commerce 都没有给出有多少购物者或智能体真正用上了这些工具。
五、商品数据成了基建
把视角拉远一点，这件事的意义不在「AI 能加购了」，在于独立站要开始为机器准备门面。
当智能体替消费者逛街，商品数据的机器可读性就从 SEO 优化项变成了基础设施：标题与描述要能说清产品是什么，变体要对应真实可买的 SKU，价格、库存、可用性要与实际一致，结构化数据要在改价与变体变动后同步更新。这些要求此前散落在 feed 优化里，现在被 WebMCP 一次性收拢到了店铺前台。
卖家还得多看两件小事。一是结账页的加载速度——智能体已经替购物者做完决策，慢一步的结账页会丢掉一个已经下定决心的客户。二是分析口径：直接满载到达、没有任何浏览轨迹的购物车会污染转化率数据，趁量小的时候把它单独标记出来。
真正的考验，是 WebMCP 会不会走出 Chrome 的试验期。如果 Firefox 与 Safari 始终不接，这套握手就只是一部分智能体浏览器的特权；如果接了，独立站的商品数据就要同时服务人和机器两套读者。到那时，「默认开启」到底是省了卖家的麻烦，还是替卖家做了一个没经过同意的决定，答案才会真正浮出水面。
六、参考资料
- Commerce.com 官方新闻稿：《Commerce and Cloudflare Bring AI Shopping Assistants to BigCommerce Merchants' Online Stores with WebMCP》
- BigCommerce 官方博客：《WebMCP: Bringing Browser-Based AI Agents to BigCommerce Storefronts》
- Cloudflare Blog：《How Commerce.com and Cloudflare are getting storefronts ready for AI agents》
- Beyond the News：《WebMCP gives websites a structured tool layer for browser agents》
- Web Pulse：《Commerce.com turns on WebMCP for nearly 100,000 storefronts》
- 艾瑞网：《Cloudflare 与 Commerce.com 让近 10 万个店面接上 AI 智能体》