How Commerce.com and Cloudflare are getting storefronts ready for AI agents

Commerce.com 与 Cloudflare 如何为 AI 代理准备商店前端 | Cloudflare 博客

post

WebMCP

代理

AI

电子商务

2026 年 10 月 21 日

Commerce.com 与 Cloudflare 如何为 AI 代理准备商店前端

Jenny Lea , Max Brosnahan , Matthew Conroy

6 分钟阅读

复制链接

AI 可以编写代码并通过司法考试，但在线购买一双鞋仍然困难。

这是因为网站是为人设计的，而非代理。目前大多数代理在为客户购物时，需要通过网站的 HTML 进行操作——它们查看页面，猜测哪个按钮对应什么功能，点击尝试，如果出错就重复这个过程。这个过程效率低下，消耗大量令牌，甚至像主题变更这样看似无害的改动都可能导致功能失效。

WebMCP 的出现改变了这一现状：这是 Google 提出的一项浏览器标准，为 AI 代理提供页面上的结构化工具，例如 search_products。代理不再需要寻找按钮，而是可以直接调用所需的精确工具，使购物过程更快、更便宜且更可靠。由于 WebMCP 目前仍处于实验性浏览器标准的早期预览阶段，目前仅通过 Chrome 实验性功能标志（chrome://flags/#enable-webmcp-testing）、Chrome Origin Trials、部分代理浏览器以及 Cloudflare Kitesurf 等开发者环境可用。

今年 8 月，我们在边缘节点推出了 WebMCP 的 Beta 版本实现。启用该功能后，Cloudflare 会在边缘节点注入一个微型脚本，无需网站所有者编写任何代码即可自动提供这些工具。

Commerce.com 是一家专为 AI 时代打造的灵活电商平台，目前使用 Cloudflare 管理其近 10 万个域名。当预览版发布后，他们提出问题：能否一次性为所有商店启用该功能？

以下将介绍 Commerce.com 选择 WebMCP 的原因、我们如何构建边缘级别的退出机制以赋予每位商家控制权，以及在此过程中学到的经验。

为什么 Commerce.com 选择 WebMCP

Commerce.com 产品管理总监 Kristina Pototska 解释了这对商店前端的重要性：

“商家一直在询问我们如何应对代理购物的挑战。当顾客要求代理寻找商品时，商家希望自己的店铺能出现在搜索结果中。他们希望留住客户、掌控结账流程，同时无需重建网站。WebMCP 在这三个方面都能提供帮助：代理可以使用真实工具搜索商品、查看详情、构建购物车并获取结账链接，无需在页面上反复猜测。人类顾客始终留在商家的网站上，商家也能维持客户关系。我们希望以安全的方式启用该功能，且无需商家修改主题或手动操作。这正是 Cloudflare 合作的完美契合点。WebMCP 还能与我们后端的 MCP 服务器端实现协同工作，两者共同覆盖了人们通过代理购物的不同场景。服务器端 MCP 支持直接连接商店的代理（例如协助用户跨多个网站购物的助手），而 WebMCP 支持在顾客浏览器中运行的代理。两种场景下都提供相同的购物工具，商家无需在两者之间做出选择或分别管理。”

在幕后，这一集成依赖于两个关键原则。首先，WebMCP 工具直接在顾客访问的 storefront 域名浏览器会话中执行，确保代理看到的价格和购物车与用户完全一致。没有任何凭证传递给第三方，整个访问过程仍发生在商户站点上。其次，Cloudflare 作为 Commerce.com 后端 MCP 服务器的边缘传输层，原样代理工具定义和操作，使商户能够完全掌控工具逻辑。

代理看到的购物体验

当访问启用 WebMCP 的 Commerce.com 商店时，AI 助手无需猜测如何导航网站。它可以通过 WebMCP 瞬间发现可用工具。

假设你告诉代理："帮我找一双防水越野跑鞋，价格低于 140 美元，尺码 10，并加入购物车。"

没有 WebMCP 时：代理尝试模拟人工点击，却可能被 cookie 弹窗拦截，误判变体下拉菜单，或被用于区分自动化流量与真实顾客的反爬虫机制绊住。

使用 WebMCP 时：代理在 document.modelContext 上检测到商店工具，并执行两个清晰的调用：

• search_products({ query: "trail running shoe", max_price: 140, size: 10 })
• add_to_cart({ product_id: "shoe_123" })

由于代理在商店域名的浏览器会话中运行，你的购物车会实时更新。Commerce.com 后端 MCP 服务器控制交易流程：当你准备完成购买时，你将自行点击结账按钮——这既保护了你的支付信息安全，也让你完全掌控最终购买过程。

我们共同构建的方案

当 Commerce.com 要求在近 10 万个 storefront 启用 WebMCP 时，我们遇到了实际挑战：WebMCP 最初设计为整个域名区域的全局开关。

Commerce.com 希望启用我们的 mcp-server-client 工具包，该工具包作为边缘桥接器——直接将 Commerce.com 后端 MCP 服务器的工具定义和请求代理到访客浏览器。由于 Commerce.com 使用 Cloudflare SaaS 在共享域名区域托管数千个商户自定义域名，我们需要一种既能全局部署平台功能，又能让单个商店所有者轻松退出的方案。

1. Commerce.com 所有商店默认启用，支持商户单独退出

我们没有构建复杂的自定义白名单，而是将 WebMCP 集成到 Cloudflare 现有的配置规则和自定义主机名元数据概念中。

Commerce.com 在主域名区域启用 WebMCP，然后在边缘添加规则检查商户元数据。如果商户在 Commerce.com 控制面板中启用"退出"开关，Cloudflare 会自动绕过该特定 storefront 的 WebMCP：

{
"action"
:
"set_config"
,
"expression"
:
"cf.hostname.metadata.webmcp_opt_out eq
\"
true
\"
"
,
"action_parameters"
: {
"webmcp_enabled"
:
false
}
}

由于 Cloudflare 在服务页面前就在边缘评估这些规则，退出的商店不会产生额外延迟、远程查询或注入脚本。

2. 定制化接口与安全回退机制

与任何预览版一样，与合作伙伴在实际环境中的协作揭示了一些我们未预料到的细节：

自定义 MCP 路径：当启用 mcp-server-client 工具包时，我们的桥接器最初预期在 /mcp 路径下找到每个站点的 MCP 服务器。Commerce.com 的服务器实际位于 /api/mcp 路径下。为了解决这个问题，我们在区域层级添加了可配置的 MCP URL 设置。当设置此参数时，我们会将自定义路径传递到注入的脚本标签中：

<
script
type
=
"module"
src
=
"/.webmcp/bridge.js"
data-packs
=
"c2pa,mcp-server-client"
data-mcp-url
=
"/api/mcp"
></
script
>

无缝回退机制：如果商店的 MCP 服务器离线，或客户的浏览器不支持 WebMCP，脚本将自动退出。商店前端将正常加载，人工购物者不会受到影响。

下一步计划

我们将持续投资 WebMCP 的发展，随着标准的演进，首先从帮助代理更轻松地找到站点工具开始。Cloudflare 和 Commerce.com 将继续合作，使代理购物体验对商家和购物者都更加高效、可靠且安全。

如果您将于 2026 年 10 月 21 日参加在旧金山举行的 Cloudflare Connect，欢迎参加我们的展位活动 "为旺季做好商店代理准备"，该活动将由 Kristina Pototska（Commerce 公司管理总监）、Justis Blasco（Popmenu 联合创始人兼首席技术官）、Ross Harvey（Fruugo 基础设施负责人）和 Josh Mills（Gopuff 工程副总裁）进行主题讨论。

目录列

讨论列

相关标签及社交媒体链接

相关标签

关注社交媒体

• Cloudflare

电子邮件订阅