摘要

WebMCP 是 Google 提出的浏览器标准，让页面向 AI 智能体暴露 search_products、add_to_cart 等结构化工具。Cloudflare 自 8 月起在边缘实现该标准的 beta 版，只需打开开关就会在边缘注入一小段脚本，站点拥有者无需写一行代码。Commerce.com 用 Cloudflare 运行着近 10 万个域名，双方合作把 WebMCP 一次性铺到全部店面，并提供了按商家粒度的边缘退出机制。

正文（译文）

Commerce.com 与 Cloudflare 如何让店面为 AI 智能体做好准备

AI 能写代码、能通过律考，但它在网上买一双鞋这件事上依然吃力。

原因在于网站是为人类建的，不是为智能体建的。今天大多数替人购物的智能体都基于站点的 HTML 工作：它们看页面、猜测哪个按钮是干什么的、点击，错了再试。这个过程很慢、消耗大量 token，而且一次看似无害的主题改版就能让它失效。

WebMCP 正是为此而来：这是 Google 提出的一项浏览器标准，在页面上为 AI 智能体提供结构化工具，例如 search_products。智能体不必再四处找按钮，而是直接调用它需要的那个确切工具，让购物更快、更便宜、也更可靠。由于 WebMCP 目前仍处于早期预览阶段、是一项实验性的拟议浏览器标准，它当前在实验性 Chrome 开关（chrome://flags/#enable-webmcp-testing）之后可用，也存在于 Chrome Origin Trials、部分智能体浏览器，以及 Cloudflare Kitesurf 等开发者环境中。

今年 8 月，我们以 beta 形式推出了 WebMCP 的边缘实现。打开开关，Cloudflare 就会在边缘注入一段极小的脚本，自动让这些工具可用，站点拥有者无需编写任何代码。

Commerce.com 是一个为 AI 时代构建的灵活商务平台，已经在使用 Cloudflare 运行其近 10 万个域名。所以当预览版发布时，他们提出的问题是：我们能不能一次性为所有商店打开它？

下面是 Commerce.com 为什么需要 WebMCP、我们如何构建边缘级退出机制以把控制权交给每个商家，以及我们一路上的收获。

Commerce.com 为什么需要 WebMCP

Commerce.com 产品管理总监 Kristina Pototska 解释了这对店面为何重要：

"商家一直在问我们如何跟上智能体购物。当购物者让智能体去找某样东西时，商家希望自己的店铺出现在答案里。他们想留住顾客、想掌控结账环节，而且不希望为此重建站点。WebMCP 在这三件事上都帮得上忙：智能体获得了真实可用的工具，可以搜索商品、查看详情、建立购物车、拿到结账链接，因此不必在页面上瞎猜。人类购物者留在商家站点上，商家也就保住了这段关系。

我们希望以一种安全的方式打开它，并且不要求商家去改主题或手工做任何事。这正是与 Cloudflare 合作最契合的地方。

WebMCP 也与我们服务端的 MCP 协同工作，二者合起来覆盖了人们用智能体购物的不同方式。服务端 MCP 支持那些直接连到商店的智能体，比如帮某人在多个站点之间比价的助手；WebMCP 则支持在购物者浏览器里工作的智能体。两种情况下是同一套购物工具，所以商家不必二选一，也不必分开管理。"

在底层，这次集成依赖两条关键原则。第一，WebMCP 工具直接在店面域名上购物者活跃的浏览器会话中执行，确保智能体看到同样的价格与购物车；没有凭据流向第三方，访问仍然发生在商家的站点上。第二，Cloudflare 作为 Commerce.com 后端 MCP 服务器的边缘交付层，原样代理工具定义与动作，因此商家完全掌控自己的工具逻辑。

购物者的智能体看到了什么

当访问一个已启用的 Commerce.com 店面时，AI 助手不再需要猜测如何浏览站点，而是可以通过 WebMCP 即时发现工具。

假设你对智能体说："帮我在 140 美元以下找一双防水的越野跑鞋，10 码，加进购物车。"

没有 WebMCP：智能体试图模拟人类点击，结果被 cookie 横幅挡住、误读变体下拉框，或者被那些用来区分自动化流量与真实顾客的机器人挑战绊倒。

有了 WebMCP：智能体在 document.modelContext 上检测到商店的工具，并发出两次干净的调用：

• search_products（查询："越野跑鞋"，最高价：140，尺码：10）

• add_to_cart（商品 ID："shoe_123"）

由于智能体运行在商店域名上你活跃的浏览器会话之内，你的购物车会实时更新。Commerce.com 的后端 MCP 服务器决定商务流程：当你准备完成购买时，由你自己点击结账——既保证了支付信息安全，也把最终购买的完全控制权留在你手里。

我们一起构建了什么

当 Commerce.com 提出要在近 10 万个店面上打开 WebMCP 时，我们遇到一个现实挑战：WebMCP 最初被设计成针对整个域区（zone）的单一开关。

Commerce 想要启用我们的 mcp-server-client 工具包，它充当一座边缘桥梁——把工具定义与请求从 Commerce.com 的后端 MCP 服务器直接代理到访客浏览器。由于 Commerce.com 使用 Cloudflare for SaaS 在共享域区上托管数千个商家的专属域名，我们需要一种既能平台级交付、又能让单个店主轻松退出的办法。

一、对 Commerce.com 上所有商店默认开启，每个商家可单独退出

我们没有构建复杂的自定义白名单，而是把 WebMCP 挂接到 Cloudflare 既有的"配置规则"与自定义主机名元数据这两个概念上。

Commerce.com 在其主域区上打开 WebMCP，然后在边缘添加一条检查商家元数据的规则。如果某位商家在自己的 Commerce.com 后台拨动了"退出"开关，Cloudflare 就会自动为该店面绕过 WebMCP：

动作：set_config 表达式：cf.hostname.metadata.webmcp_opt_out 等于 "true" 动作参数：webmcp_enabled 为 false

由于 Cloudflare 在提供页面之前就在边缘评估这些规则，被退出的商店不会有任何额外延迟、远程查询或注入脚本。

二、可定制的端点与安全回退

与任何预览版一样，和真实世界的伙伴合作暴露出几个我们此前没有考虑到的实际细节：

自定义 MCP 路径：启用 mcp-server-client 工具包时，我们的桥梁原本预期每个站点的 MCP 服务器都在 /mcp。而 Commerce.com 的服务器位于 /api/mcp。为此，我们在域区层面增加了一个可配置的 MCP URL 设置。设置后，我们会把自定义路径传进注入的脚本标签：

脚本标签：类型为 module，源为 /.webmcp/bridge.js，data-packs 为 c2pa,mcp-server-client，data-mcp-url 为 /api/mcp

无缝回退：如果某个商店的 MCP 服务器离线，或顾客的浏览器不支持 WebMCP，脚本就会退出。店面照常加载，人类购物者不受影响。

接下来

随着标准演进，我们将持续投入 WebMCP，首先会从帮助智能体更容易地发现站点工具开始。Cloudflare 与 Commerce.com 将继续合作，让用智能体购物对商家与购物者都快速、可靠、安全。

如果你 2026 年 10 月 21 日在旧金山参加 Cloudflare Connect，欢迎来看我们的专场讨论"让你的店面为旺季的智能体做好准备"，嘉宾包括 Kristina Pototska（Commerce 产品管理总监）、Justis Blasco（Popmenu 联合创始人兼 CTO）、Ross Harvey（Fruugo 基础设施负责人）与 Josh Mills（Gopuff 工程副总裁）。