Cloudflare与Commerce.com联合推动WebMCP在电商店面层面的接入，让浏览器内AI智能体可调用商家提供的商品搜索、详情查询和购物车工具，但最终结账仍由用户在商家网站完成。该方案重点解决跨店面交付、店家退出控制、端点适配与不兼容回退等工程细节，未宣称普及或证明大规模交易数据。
Cloudflare与Commerce.com正在把电商网站改造成浏览器内AI智能体可以直接调用工具的购物界面。双方披露的WebMCP集成，不再要求智能体主要依靠识别网页按钮、模拟点击来寻找商品，而是让它调用商家提供的商品搜索、详情查询和购物车工具。不过，购物准备与完成交易仍有明确分界：智能体可以取得结账链接，用户需要在商家网站核对订单并完成购买。
这次披露不是WebMCP的首次发布。Cloudflare的合作技术文章围绕2026年10月21日的Cloudflare Connect活动介绍了双方的实现，并回顾称，其WebMCP边缘实现已在8月进入beta阶段。此次重点是如何将这套能力交付到电商平台的多个店面，同时保留单个商家的退出权，而非宣布一种已经普及到所有浏览器的购物标准。
从“猜按钮”转向商家提供的工具
传统网页是为人设计的：消费者能看懂尺码选项、促销提示和购物车按钮，智能体却可能误解这些元素，也可能在页面布局调整后失去原有操作路径。WebMCP尝试让网站明确告诉浏览器内的智能体，自己提供哪些能力、需要哪些输入，而不是让模型从页面外观猜测。
在这项合作中，Cloudflare在边缘处理店面的HTML响应，加入指向同域桥接脚本的引用。脚本在支持WebMCP的浏览器中，通过document.modelContext注册店面的工具；商品数据和购物车操作仍由商家的MCP服务处理。按照双方的技术说明，工具沿用购物者当前的浏览器会话，因此智能体与消费者面对的是同一套价格和购物车状态。
BigCommerce的WebMCP文档列出的流程是：智能体搜索商品、核对规格和尺码，再将选定商品加入购物车，最后取得结账链接。实际工具包括search_products、get_product_details、add_item_to_cart和create_checkout_url，也支持修改或移除购物车条目。
这不是给智能体另建一家商店，而是给现有店面增加机器可调用的入口。商家仍决定工具逻辑，消费者仍在商家的交易流程中完成购买。Commerce.com产品管理总监Kristina Pototska在Cloudflare文章中表示，商家希望在AI帮助消费者寻找商品时被发现，同时继续掌握客户关系与结账流程。
“默认接入”不等于“默认开放购物工具”
Cloudflare称，Commerce.com已有近10万个域名使用其服务，并将此次合作描述为跨店面交付WebMCP的实现。这一数字需要谨慎解读：域名数量不是独立商家数量，也不能证明同等数量的店面已经开放全部购物工具，更不能当作智能体活跃使用量或成交数据。
合作伙伴文档给出了更具体的适用条件：WebMCP默认用于所有Stencil店面，以及托管在Cloudflare上的Catalyst店面。托管在Cloudflare上的自定义无头店面，则需要联系BigCommerce支持团队启用。
即使桥接层已经开启，商品搜索、购物车和结账链接工具也不会因此自动全部可用。BigCommerce的MCP服务说明要求，由店主开启Storefront MCP并接受服务条款，随后其购物工具才会自动同步给WebMCP。文档还提示，开启MCP服务后，完全可用可能需要最多10分钟。
未开启Storefront MCP时，默认工具主要读取页面图片中的C2PA内容凭证元数据，包括扫描图片、查看凭证记录等。这不等于商品搜索，也不等于验证图片真实性：文档明确说明，这些工具读取并报告凭证，不进行密码学签名验证，结果中的signatureVerified为false。
因此，平台能够交付脚本、店面实际启用哪些工具，以及消费者的智能体能否调用这些工具，是三个不同层面，不能用一个“已接入”概括。
商家能退出，但关闭并非即时生效
此次集成的一项工程重点，是让共享Cloudflare基础设施的多个商家分别控制是否参与。最初的WebMCP开关作用于整个域区域，而Commerce.com需要在平台统一交付的同时，允许单个店面退出。
Cloudflare的做法是将配置规则与自定义主机名元数据结合。商家在后台选择退出后，边缘规则依据对应标记跳过该店面的WebMCP脚本注入。这避免了为每家店单独改主题，也不要求消费者访问另一个购物网站。
但规则如何执行，与退出设置何时传播到位，并不是一回事。BigCommerce文档特别警告，WebMCP完全关闭可能需要几天；退出后若想重新启用，需要联系支持团队。因此，不能将Cloudflare所说的边缘规则自动生效，理解成商家点击关闭后所有访问都会立即停止加载桥接脚本。
双方还调整了MCP端点的配置方式：桥接层原先默认寻找/mcp，Commerce.com使用的路径则是/api/mcp，因此增加了可配置的MCP地址。按照技术说明，如果店面的MCP服务不可用，或者浏览器不支持WebMCP，脚本会退出，网站仍按原有方式供人访问。对于商家，这种渐进增强的意义在于，不必把正常购物流程押在实验性浏览器能力上。
支付留给用户，不等于自动消除风险
双方强调，工具在店面域名和购物者会话内运行，请求无需把商店凭据交给另一个工具服务。这描述的是工具调用路径，并不构成对智能体整个数据处理过程的安全保证，也不能证明推荐、规格选择或购物车修改一定正确。
最终结账仍由用户完成，是这套方案的重要边界。AI可以协助缩小选择范围、整理购物车，但消费者仍需检查商品、数量、价格及购买条件。这与Safeway接入ChatGPT后将结账交还零售商平台的安排有相似的流程分工，但两者入口不同：Safeway的相关体验从ChatGPT开始，此次WebMCP面向的是访问商家网站、在购物者浏览器内工作的智能体。
浏览器支持也是现实限制。Chrome官方文档仍将WebMCP称为拟议的Web标准，并介绍了Origin Trial及本地实验开关。该文档指出，客户端和浏览器需要实际访问网站，才能知道网站是否提供可调用工具。这意味着，开放WebMCP不会自动使店面进入所有AI助手的商品推荐结果，也不能替代商家的商品数据质量和获客能力。
Cloudflare和BigCommerce均认为，结构化工具能减少页面导航与重试，从而改善速度、可靠性及token开销。但本次合作公开材料没有给出足以独立比较的端到端购物成功率、成本或转化率测试，也没有证明近10万个域名都已产生真实智能体购物行为。
这次合作更明确的进展，是把“网站向AI提供工具”从单站点配置推进到电商平台级交付，并补上商家退出、端点适配和不兼容回退等环节。它降低的是智能体理解和操作店面的接口摩擦；浏览器普及、商家授权、用户信任以及最终交易是否可靠，仍需要分别验证。