Commerce.com与Cloudflare如何让店铺为AI代理做好准备
内容提要
Commerce.com与Cloudflare合作，为近10万个商户店铺启用WebMCP，使AI代理能通过结构化工具直接搜索商品、加入购物车并获取结账链接，无需模拟点击，速度更快、更可靠。Cloudflare在边缘注入脚本，并借助配置规则和商户元数据支持逐个店铺退出，退出店铺不会产生额外延迟。这些工具在用户浏览器会话内执行，价格与购物车保持一致，支付仍由用户完成。
延伸解读
WebMCP 与服务器端 MCP 的分工
文章指出，WebMCP 与 Commerce.com 已有的服务器端 MCP 并行工作，覆盖不同的代理购物方式。服务器端 MCP 面向直接连接商店的代理，例如跨多个网站比价的助手；WebMCP 则面向在购物者浏览器内运行的代理。两者提供同一套购物工具，商户无需二选一或分别管理，这降低了同时支持两类代理的复杂度。
边缘规则实现逐店退出且不增延迟
Commerce.com 使用 Cloudflare for SaaS 在共享区域托管大量商户域名，因此需要平台级开启、单店可退出的机制。方案将 WebMCP 接入 Configuration Rules 和主机名元数据：商户在后台开启退出后，边缘规则在页面返回前即判定跳过，不注入脚本、不做远程查询，退出店铺不会产生额外延迟。这为多租户平台提供了可复用的控制思路。
代理在用户会话内执行，支付仍由人完成
WebMCP 工具在购物者当前浏览器会话、商店域名下执行，代理看到的价格和购物车与用户一致，凭证不交给第三方。代理可搜索商品、加入购物车并获取结账链接，但最终结账由用户自己点击完成，支付信息仍由用户掌控。这种设计在提升代理效率的同时，保留了商户与客户的关系和交易安全边界。
预览阶段的现实限制与回退
WebMCP 仍是实验性的浏览器标准提案，目前需在 Chrome 实验标志、Origin Trials 或部分代理浏览器中启用。实际集成中还暴露出自定义 MCP 路径的需求，Commerce.com 的服务器位于 /api/mcp 而非默认 /mcp，Cloudflare 因此增加了区域级可配置 URL。若商店 MCP 服务器离线或浏览器不支持，脚本会直接退出，普通购物不受影响。
Q&A
WebMCP是什么？它如何让AI代理购物更高效？
WebMCP是Google提出的浏览器标准，为AI代理提供页面上的结构化工具（如search_products）。代理无需模拟点击按钮，而是直接调用所需工具，从而更快、更便宜、更可靠地完成购物。
Commerce.com为什么要在所有店铺启用WebMCP？
商家希望跟上代理购物趋势，当顾客让代理找商品时，店铺能出现在答案中，同时保留客户关系、控制结账流程，且无需重建网站。WebMCP让代理获得真实工具来搜索商品、构建购物车并获取结账链接，而人类顾客仍留在商家网站上。
Cloudflare如何为近10万个店铺实现WebMCP的逐个店铺退出？
Cloudflare利用配置规则和商户元数据：Commerce.com在主区域启用WebMCP，并添加边缘规则检查商户元数据。若商户在仪表板中开启退出开关，Cloudflare会自动绕过该店铺的WebMCP，且退出店铺不会产生额外延迟。
使用WebMCP时，AI代理如何执行购物操作？支付由谁完成？
代理在用户浏览器会话内直接调用工具，如search_products和add_to_cart，购物车实时更新。支付仍由用户自己完成：当用户准备购买时，需亲自点击结账，支付细节保持安全，用户完全控制最终购买。
WebMCP与服务器端MCP有什么区别和联系？
WebMCP支持在购物者浏览器中工作的代理，而服务器端MCP支持直接连接商店的代理（如跨多个网站购物的助手）。两者提供相同的购物工具集，商家无需二选一或分别管理。
如果店铺的MCP服务器离线或浏览器不支持WebMCP，会影响正常购物吗？
不会。脚本会退出，店铺正常加载，人类购物者不受影响。这提供了无缝回退机制，确保兼容性和稳定性。
