一个购物者让浏览器里的 AI 代理帮他找一双 140 美元以内、防水的越野跑鞋，找到合适的款式后再让代理加进购物车。在这之前，AI 代理在网店里买东西，只能像人一样看网页，猜哪个位置是搜索框、哪个按钮负责加购；网页一改版，这套做法就可能失灵。现在，店铺页面会直接告诉浏览器里的 AI 代理：这里有搜索商品和加入购物车两个现成动作，按名字直接调用就行。这套让网页在浏览器里直接把可调用动作列给 AI 代理的做法，叫 WebMCP。
在 2026 年 10 月 21 日，Cloudflare和Commerce.com合作推出了一个案例，把这个能力做成了平台级别的默认配置，直接放到了商家的请求入口里。Commerce.com 原来是电商底座公司 BigCommerce，公司更换名称之后，它的商户管理后台和技术文档仍然沿用 BigCommerce 这个品牌名字，下文统一用 Commerce.com 指代这个平台。
这次上线的 WebMCP 支持是平台层的一次统一动作，不需要任何商城修改自己的前端模板代码。平台直接在商城请求的接入点这一层加上一段脚本，在请求入口处默认打开了这个开关；如果商家不想开放这项能力，商城管理后台也提供了一个开关，商家想关随时可以关掉。官方公告说，这次上线覆盖了近 10 万个域名，这是接入平台网络的自定义店铺域名数量，不是十万家活跃店铺。这近 10 万个店铺域名不用自己改代码，网页上就已经有了搜索商品和加入购物车这两个动作，访问者浏览器里的 AI 代理进来就能按名字直接调用。
平台把开关默认打开，看起来是替所有商家做了决定。可如果平台不替他们开，商家自己会改吗？大概率不会。拿一家年营收几百万美元的户外装备网店或区域服饰品牌来说，店主和运营团队每天都在忙选品、备货、广告投放回报率和仓储履约。要想让现有的店铺变成一个代理可以直接调用的站点，他们需要额外花钱请工程师重写店铺模板、梳理商品查询和库存接口，并且要跟进还在演进的协议不断发版维护。改造和维护要花的钱是确定的，但浏览器 agent 能给店铺带来多少实际订单，在月度财务报表上还是个不确定的未知数。面对确定的研发投入和不确定的订单回报，大多数商家都会选择先等等看。不是他们不懂技术，是这笔账站在单个店铺的角度算不过来。
Cloudflare 自己的网络里，AI agent 的请求一年增长 1,700%。但连最有工程能力的头部站点也几乎不动。按 Cloudflare 自己提出的站点代理能力设计，网站要先在最底下认出来访者是谁，再往上依次具备能读懂、能找到、能调用、能付款四层能力。Cloudflare 用它自己的网络做过高流量域名的准备程度扫描，看过 20 万个高流量域名的 Agent Readiness 表现：最基础的一层，也就是按需返回精简 Markdown，只有 3.9% 的站点做到，绝大多数站点依然只返回混杂着大量样式和脚本的原始网页。再往上的能力需要站点挂出标准的接口名片或接口目录，这两样东西叫 MCP Server Cards 和 API Catalogs，而这二十万个高流量域名里配好它们的加起来不到 15 个。连研发资源最充裕的头部站点都几乎没有主动部署，足以说明单站点各自改造的模式在工程经济性上走不通。
单点改造算不过账，直接把购物者的代理和商家困在互相等待的死结里。agent 等商家开放接口，商家等 agent 带来真实流量，两边谁都不愿先迈出第一步。浏览器厂商和代理客户端开发者看到二十万个高流量域名里只有十几个站点提供现成的工具目录，就没办法说服用户放弃传统的页面模拟点击去依赖新协议。反过来，分散在各处的商家看到代理流量不成规模，也不会抽调人手去写第一行适配代码。靠单个商家各自投入研发，打不破这个相互等待的循环。
要解开这个死结，只能让托管了大量商户的平台一次性全部改过来，默认打开给所有商家。Commerce.com 和 Cloudflare 合作落地的方案走的正是这条路，Commerce.com 在自己的近 10 万个店铺域名上默认开启 WebMCP，商家不用改任何店铺代码，店铺页面就有了浏览器代理可以直接调用的现成工具，想退出就在管理后台关掉。在默认关闭、等商家自愿接入的体系里，绝大多数中小商家会因为不懂新技术或腾不出研发人手而一直空着，客户端代理也难以拿到足够多可调用的店铺。在默认开启、允许退出的体系里，商家什么都不做就有了能力，只有少数在风控、品牌、价格方面有顾虑的商家需要去后台退出。这种默认开启加后台退出的机制，既帮绝大多数商家省去了理解新协议的认知与开发负担，又把是否开放的最终决定权留在了商家手里。
在新协议推广中，把接入工作留给分散的租户、等商家自己改，这不是策略，是希望。单个商户算不过单点改造的经济账，客户端也等不起成千上万家店铺逐个排期上线，只有握有统一入口的平台能用一次集中改造替所有商户省下重复折腾的成本。用平台默认开启加后台退出替代商户各自改造，让供给端在一夜之间跨过初始规模门槛，才是走出冷启动的可行路径。
要把这个默认开关落到工程上，Cloudflare 与 Commerce.com 的合作得同时解决两件事：一是给近 10 万个店铺域名装上同一套工具，不能一家一家去改店铺代码；二是让每个商家都能单独关掉，而且点下退出按钮就要对自家店铺生效。平台显然没法直接去改每家店的前端模板，因为各家店铺的历史模板版本五花八门，批量改代码容易和商家自己的脚本起冲突，出了问题也很难回滚。如果只在外层网络网关上硬塞一段通用脚本，后面却没有统一的接口可调，它也没法跟购物者正在浏览的页面共用同一个购物车。
Cloudflare
的思路是沿着网站现有的请求链路来工作。它本来就站在店铺服务器和购物者的浏览器中间，负责转发每一个网页访问。根据
Cloudflare 在 2026 年 8 月发布的 WebMCP
测试版官方介绍，店铺源站把普通网页发给购物者，网页先经过 Cloudflare
的边缘节点。Cloudflare 在那里用 HTMLRewriter
改写页面、插入一小段桥接脚本，店铺自己的代码和部署都不需要改动。这个脚本进浏览器后自己并不负责搜索商品，也不负责查库存、改购物车。它只负责传话：向浏览器里专门给
AI 代理登记工具的接口 document.modelContext
打个招呼，告诉浏览器里的代理，这家店有搜索商品和加入购物车两个动作，有需要可以直接按名字和参数调用，不用靠截屏猜按钮位置，也不用硬啃复杂的网页标签。
购物者真的让浏览器里的代理找一双合适尺码的越野跑鞋、把商品放进购物车，干活的链路才正式转起来。浏览器里的代理直接按名字发起调用，页面里的桥接脚本接住指令后，会在购物者当前的浏览器会话里，顺着这家店铺自己的域名往
/api/mcp
发请求，把调用转交给店铺平台后端早就统一好的网店接口服务，也就是
Commerce.com 的 Storefront
MCP。因为这个请求直接在购物者浏览器里用店铺自己的域名发出，浏览器会自动带上购物者当前的登录状态、会员价、币种设置和购物车会话。代理查到的价格就是这位用户眼前看到的价格，代理调完加购接口后，用户点开页面右上角的购物车图标，刚选好的跑鞋就已经躺在里面了。
送工具和调接口跑通之后，怎么让近 10
万个店铺域名各自拥有一个随时生效的退出开关？这些网店对外虽然挂着商家各自独立的品牌域名，但底层都由平台通过批量管理客户域名的
Cloudflare
for SaaS
集中托管，平台会给每个域名挂上一张记录配置状态的标签。商家在
Commerce.com
控制面板里选择退出，平台后台就把该域名标签改成退出状态。之后再有购物者访问这家店，Cloudflare
在边缘节点用配置规则读到这张标签（例如检查
cf.hostname.metadata.webmcp_opt_out eq "true"），就不再往页面里加脚本，直接把源站原本的网页发给访客。整个过程既不用重新部署代码，也不用额外查询，也不会影响其他店铺的访问。
从整个请求链路的角度看，这套方案之所以可行，并不在于边缘节点特别智能，而在于平台后端早就把这些店铺的搜索、加购接口统一了。在这套分工里，Cloudflare 的边缘节点仅仅负责在网页经过时把脚本注入到浏览器里，真正按条件筛选商品、核对实时库存、修改购物车的活，全靠 Commerce.com 的平台后端去做。因此，尽管近 10 万个店铺的前端页面可能千差万别，但它们都共享同一个标准接口底座。这也是其他平台能否复用这套做法的关键：如果一个平台的每个店铺背后都有自己的后端逻辑，缺乏统一的搜索和加购接口，那么即便边缘节点把脚本注入到更多页面中，脚本发出的请求也没有任何可调之处。
在这条链路的最后一步，系统还刻意留了一道人工确认的边界：代理可以帮助购物者进行搜索、比较不同商品的规格，甚至把这些商品加入购物车，但在最终的 checkout 结账付款这一步，还是要由用户亲自点击来完成。这样做的好处是，一方面能避免代理看错尺码或数量，或者干脆替用户把钱扣了；另一方面也让商家原有的支付合规、银行卡验证和风控流程都能照常使用，不需要改动。从网页经过边缘节点时顺手送进浏览器的桥接脚本，到通过店铺自己的域名调用回平台后端的统一接口，再加上按域名标签起效的退出开关和人工结账的边界，这整个流程串起来，才让平台不用改一行商户代码，就把开关装到了近 10 万个店铺域名上。
Cloudflare 能替 Commerce.com 的近十万个店铺域名打开代理开关，是因为它站在请求进入网站的必经入口。可 CDN 不是每个平台都有，大多数软件公司既不掌握边缘节点，也不替客户管域名解析。如果你做的是内容管理系统、建站平台、支付网关，或者某个垂直行业的 SaaS，这套在入口层批量改造的方法还成不成立？
剥开网络边缘这层外壳，真正的共同条件有三个：平台替租户托管了什么共同底座，租户在这件事上的动作有多一致，以及平台能不能替租户改默认，而不用一家一家去谈。反向代理只是入口的一种形态，代码注册表、页面渲染引擎、资金清算通道、多租户数据库同样是租户离不开的共同底座。用这把标尺衡量，并非所有平台都能把代理工具直接做成一键全开的默认项，真正的规律是：共同底座越统一，能默认的范围越大。
这三个条件听起来抽象，落到自家平台上，其实就是三个问题。三个答案合起来，决定你的平台能不能把这层接口做成默认，还是只能做一个可选项。第一，日常运转里哪一层基础设施由平台集中托管、租户不维护底层代码，而每次处理核心业务又必定经过它？第二，成千上万家租户落在这个底座上的动作，是各自写千差万别的自定义逻辑，还是在重复高度一致的标准流程？第三，如果平台在这个底座上加装代理协议转换器，有没有足够的权限边界和安全兜底，可以直接替所有租户把默认配置改掉，而不需要每家租户派工程师回来改代码或逐一签字确认？
这三个问题在每家平台上答案都不一样。拿四个大家熟悉的平台试一遍，就能看到四种不同的结果：WordPress、Wix、Stripe 和 Shopify。它们在这里扮演的不是产品推荐的角色。它们是同一组问题在四个平台上的四个答案。从松散的开源插件生态，到全托管的前端站点运行时，再到高度标准化的支付流与多租户电商底座，底座收拢得越紧，平台替租户改默认的范围就越大：
| 平台 | 它替租户托管了什么 | 租户动作有多一致 | 它能默认到什么程度 |
|---|---|---|---|
| WordPress | 插件注册表 | 插件各写各的，能力不统一 | 只能提供注册框架，插件自己决定公不公开 |
| Wix | 页面渲染和站点运行时 | 站点结构由平台统一 | 可以把浏览器层默认开给所有站点 |
| Stripe | 支付和交易流 | 支付动作全行业一致 | 可以把支付和目录层默认开给所有商户 |
| Shopify | 商品、库存、订单数据 | 商品和结账模型统一 | 可以把店铺工具默认开给所有商家 |
先看表格上半段贴近内容和页面的两个刻度，动作一致性直接拉开了默认范围的差距。WordPress
6.9 引入 Abilities API 让插件注册 ability，再由官方 MCP Adapter
转成 MCP 工具且默认服务端需带 meta.mcp.public
标记才对外开放；正因为插件各写各的、能力不统一，WordPress
只能提供注册框架，不能替所有插件默认一套工具。相比之下，Wix
直接控制页面渲染和站点运行时，站点结构由平台统一，因此在提供面向开发者的
Wix
MCP 与供访客代理连接单个站点的 Wix Site MCP 之外，可以把浏览器内的
Wix WebMCP 前端层默认开给所有站点。
继续沿着表格向交易和数据维度延伸，底座与动作的收敛进一步把平台对默认的控制带进核心交易层。Stripe 为商户托管支付和交易流，提供 Agentic Commerce Suite、ACP 和 Shared Payment Tokens，托管 ACP 端点、目录分发、税费运费与 Radar 风控，因为支付动作在整个行业高度一致，所以它能把支付和目录层默认给所有商户打开。在统一度更高的层面，Shopify 的商品、库存和结账都在自己的多租户底座上，商品和结账模型完全统一，因此可以用 UCP 和 Storefront MCP 把整套店铺工具默认给所有商家打开。
对平台而言，这个视角立刻就能用来排优先级：在动手之前，不用去羡慕别人的边缘网络或支付牌照，而是先问自己：我们替租户托管的是哪一层共同底座？租户在这件事上的动作有多一致？例如协同和人事软件托管的是权限表和审批流引擎，本地生活平台托管的是门店排期与预约接口。租户动作一致的部分可以直接默认，将来外部协议升级也只需平台更新一次转换层；不一致的部分就只能做注册框架，或者留给垂直供应商。
对围绕平台做产品的 AI Builder 而言，这张表也在提示，平台会拿走你所在生态中的哪一层。WordPress 的插件层很散，各家站点的业务能力难以用一套标准模具收拢，垂直工具仍有空间。相反，Shopify 的商品和结账层很统一，围绕查库存、找商品和标准结账的通用工具，平台很快会默认掉，真正的机会在平台管不到的那一段。
把近十万个店铺域名的工具调用默认打开，看起来像是一夜之间完成了批量改造，但这个平台的开关只在三个条件同时成立时才真正有用。这三个条件分别管页面、管浏览器、管动作，缺一个，平台就默认不了，剩下的工作会退回给商家自己，或者留给垂直行业的软件供应商。
第一个条件是店铺页面得走平台的标准渲染路径。BigCommerce 的官方 FAQ明确指出，这次 WebMCP 的默认接入只对用 Stencil 模板搭建的店铺生效。中小商家如果直接采用这套标准模板，就能一键启用。在平台上交易量更大的头部品牌往往把前端改成了前后端分离的 Headless 架构，只把 Commerce.com 当商品和订单后端，前端页面用 Next.js 等框架自己开发并托管在外部服务器上。只要商家绕开了 Stencil 模板的渲染链路和同源路由，Cloudflare 就无法进入页面注入脚本，默认开关也就覆盖不到这些大品牌。
第二个条件是购物者的代理需要运行在支持 WebMCP 的浏览器上，并且有一个浏览器页面会话。根据 Chrome Status 的 WebMCP 词条，这个功能在 Chrome 里仍处于试验阶段，Microsoft Edge 的源试验排期到 2027 年 3 月底，Firefox 和 WebKit 内核的 Safari 尚未支持，苹果设备上默认的浏览器暂时用不了。即使浏览器支持，这套往页面上下文里注入工具的设计，也要求用户当时正开着浏览器看网页。如果购物者用的是智能音箱、手机系统的语音助手，或者让运行在云端的代理在后台下单，没有浏览器的当前页面会话，这套机制同样用不上。
第三个条件是这个动作在各家店铺里长得一样。比如搜索商品、加入购物车，卖跑鞋的店和卖保温杯的店接口一样，平台能用同一套工具统一做好。但碰到牙科保险免赔额核验、物业报修分级派单，或者 B2B 采购里按年度协议和提货阶梯计算的合同价，各家商户的逻辑就千差万别了。这些行业特殊动作的业务规则和数据全都藏在每家商户自己的系统或线下合同里，原本就不走平台的共享入口，平台自然统一不了。
就算三个条件都成立，我们也不知道现在有没有人真的在用。Cloudflare 和 Commerce.com 的公告只提到功能上线的覆盖范围，没有公开实际的工具调用量、商户后台退出率或成交转化率。十万个店铺域名默认开启，只说明平台把接口单向铺了下去，并不等于平台上已经有了十万笔代理交易。到底有多少用户带着试验版浏览器在调接口，又有多少商家顺手关了开关，目前还没有任何运营数据可以回答。
看清楚这枚开关在哪儿能用、在哪儿不能用，企业的分工边界也就清楚了。三个条件都成立的通用动作，平台可以默认代劳；只要有一个条件不成立，剩下的部分就是企业要自己算清楚租、买、建的地方，这也是下一篇文章要讨论的问题。