AI代理只能猜着用你的站，四个动作83个站里1个全通

摘要：131个英文电商站，取到类目页的83个。用四个最基本的动作去考它们——搜一个词、按条件筛一遍、翻到下一页、把商品加进购物车——判据只有一个：光看HTML，机器能不能推出该发什么请求。四个全能推出来的只有1个站，一个都推不出来的有23个。分平台看更有意思：61个Shopify站的默认主题出厂就把加购写成表单，可这些站里能找到加购按钮的35个，已经有15个在定制过程中把那层表单换掉了。平台给的默认值确实好用，但它只在没人动它的时候有效。

2026年8月25日，OpenAI给ChatGPT桌面端那个内置浏览器加了Site tools。同一周，Shopify说WebMCP工具已经在每一个Liquid店铺上线，Cloudflare放出了在边缘注入一行脚本就能开启的预览版。

这三家在同一周把WebMCP推进真实产品之前，它还只是个浏览器里的实验。这套东西解决的问题，OpenAI自己写得比谁都直白：与其把代理扔在你的界面里让它自己猜着用，不如由你来定义它到底能怎么用你的应用。

“猜着用”这三个字值得停一下。

它描述的是WebMCP出现之前、也是今天绝大多数站点上正在发生的事：一个代理打开你的页面，看到一堆按钮和输入框，靠标签文字、靠位置、靠试错，去推断点哪个能搜索、点哪个能筛选、点哪个能加购。这件事的成功率取决于一个从来没被量过的变量——你的界面到底有多好猜。

所以这一轮就量这个。不测WebMCP有没有用，也不测哪家代理更聪明，只测一件事：光看HTML，机器能不能推出该发什么请求。

代理在你的站上，到底是怎么“用”它的？

得先把两条路分清楚，不然后面的判据说不通。

第一条路是模仿人。截图或者读无障碍树，认出“这是个搜索框”，往里打字，再找到那个看起来像提交的按钮点下去。这条路什么站都能走，代价是每一步都可能出岔子：按钮文案改了、弹出一个订阅浮层、日期选择器是自定义组件。智能体读的其实是无障碍树而不是页面截图，这一点决定了它对标签和ARIA属性的依赖比对像素大得多。

第二条路是直接构造请求。看见一个<form method="get" action="/search">里有个name="q"的输入框，就知道/search?q=杯子能拿到结果，不必打字也不必点击。这条路稳、快、可重放，但它有个前提：页面必须把动作的参数写在HTML里。

WebMCP是在这两条之外加的第三条：站点主动注册一批带名字、带描述、带输入结构的工具，代理直接调用。Chrome那边有一句形容它的话很到位——不是你的应用做客在代理里，而是代理做客在你的平台上。

三条路的关系是这样的：第三条最好，但需要你专门去做，而且这份规范目前还只是W3C社区组的草案，不在标准轨道上。第一条路总能走，但脆。真正决定今天大多数任务成败的是第二条——它不需要任何新技术，只取决于你的HTML写成什么样。

四个动作，83个站，能构造出来的有几个？

口径先摆清楚，每一层的分母不一样：

• 起手131个英文电商与消费品牌站；
• 首页采集成功130个；
• 从首页进到类目页的83个，这是四项总分的分母；
• 进到产品页的80个，加购这一项在这里统计。

四个动作各自的判据，都取“机器光看HTML就能推出请求”这个最低标准：

• 搜索——页面上有搜索输入框，它在一个method="get"且带action的表单里，输入框有name；
• 筛选——类目页上存在带筛选参数的a[href]，也就是筛选结果有自己的地址；
• 翻页——存在真正的分页链接或者rel="next"；
• 加购——加购按钮在一个带action的表单里。

83个站的总分分布：

四项全通的那一个是snowpeak。三项的六个是baseus、flyingtiger、hellotushy、ice-watch、taylorstitch、wusthof。

零项的23个站里，有allbirds、gymshark、underarmour、rapha、casetify、eufy这些名字。它们的页面在浏览器里跑得又快又顺，动效也漂亮，用起来挑不出毛病。只是从HTML这一侧看过去，四个最基本的动作，一个都没有留下入口。

搜索框为什么是最容易过关、也最容易假过关的一项？

搜索是四项里通过率最高的，48个站，36.9%。但把中间几层拆开看，这个数字后面藏着不少东西。

第一层就掉了一半：67个站的首页上压根没有搜索输入框，只有一个放大镜按钮或者一个指向/search的链接，点了才会弹出输入框。这40个站属于“搜索功能是有的，但它不在这一页的HTML里”。代理要用它，得先点一下，再等一个动画，再判断焦点跑到哪儿去了——第一条路的所有风险全在这儿。

第二层也有讲究。5个站的输入框根本不在任何表单里：brompton、fromourplace、ikea、reebok、suitsupply。这类做法是纯JavaScript监听回车，把关键词拼进路由。人用起来毫无差别，机器面对的却是一个孤零零的input，既不知道往哪儿提交，也不知道参数叫什么。MDN对form元素的说明里那句话现在读起来别有意味：表单的作用就是把一组控件和一个提交目标绑在一起。绑没绑，人看不出来，机器只看这个。

还有10个站输入框在表单里，但表单不是GET，或者没写action——同样拼不出地址。

顺带说一句，站内搜索这条路对做SEO的人本来就有另一重价值。站内搜索数据是被低估的第一方选词金矿，而能不能拿到这份数据，前提往往也是搜索走的是一个规规矩矩的GET请求。至于这些搜索结果页要不要放进索引，站内搜索URL该不该Disallow是另一个话题，两件事别混在一起决定。

声明了SearchAction，却拼不出一个能用的地址，这23个站怎么了？

这是这一轮最像“自相矛盾”的一组数。

结构化数据里有个SearchAction，作用是告诉机器：我这个站的搜索地址长这样，把关键词填进这个占位符就行。130个首页里，49个（37.7%）写了它。

然后把这49个和前面那48个“有可用GET表单”的站对一下：

• 两边都有的：26个；
• 声明了SearchAction，但页面上没有可用GET表单的：23个；
• 有可用GET表单，但没声明SearchAction的：22个。

第二类里有aloyoga、bollandbranch、brooklinen、casetify、everlane、graza、harrys、quince、reebok这些站。它们的结构化数据在说“我的搜索在这里”，页面本身却没有把这条路铺出来。

严格说这不算错——SearchAction声明的是一个URL模板，机器照着拼理论上就能用，不依赖页面上有没有表单。但两边同时存在才是完整的：一个给读结构化数据的，一个给读HTML的。只有一边的时候，另一边那类客户端就只能回到猜。

更值得琢磨的是第三类那22个站：功能明明做对了，却没在结构化数据里说一声。产品页规格那一轮量到过一模一样的形态——价格64个站全写进了结构化数据，规格只有7个写了。能带来富媒体结果的字段大家都写，不带来展示效果的字段就长期空着，搜索这一项也没逃出这个规律。

筛选结果有没有自己的地址？

这一项是四项里通过率最低的之一：83个类目页，只有21个（25.3%）能找到带筛选参数的链接。

剩下的靠什么筛？靠复选框。70个站的类目页上有checkbox或radio，总数4799个，中位每站22.5个，最多的casetify一页596个，decathlon 437个，quince 394个。

问题出在这儿：4799个里只有1583个（33.0%）在表单里。更直观的说法是，70个站里有41个（58.6%）一个复选框都不在任何表单里。

不在表单里的复选框，对机器来说是一个纯粹的开关：勾上会发生什么，只有JavaScript知道。它既没有提交目标，勾选之后地址栏也不一定变。人点两下就看到结果刷新了，机器点两下之后没有任何可以复述的东西——它不知道刚才那一步该怎么记录，也没法把这个筛选条件传给下一次访问。

这件事的另一面做SEO的人反而更熟。筛选参数进URL意味着可能生成海量组合页，筛选器URL不爆炸的那套系统方案整篇都在讲怎么把这个量控制住，哪些筛选页该写Disallow也有成熟的判别法。所以过去十年的主流做法是往“不给筛选结果地址”那个方向走的——这在当时是对的，抓取预算实实在在。

但两件事得分开：给筛选结果一个地址，和让搜索引擎去抓这个地址，不是同一个决定。前者是可达性，后者是索引策略。用robots.txt或者canonical管住索引，同时保留一个规规矩矩的、带参数的地址，两边可以同时成立。现在的普遍状况是为了后者把前者一起砍了。

六成的类目页连“下一页”都没有，机器怎么往下翻？

分页这一项的数字最难看。83个类目页：

• 有真正的分页链接的：15个，18.1%；
• 有rel="next"的：17个；
• 只有一个“Load more”按钮、没有任何分页链接的：13个，15.7%；
• 两样都没有的：55个，66.3%。

那55个站不是只有一页商品，它们用的是滚动到底自动加载。人往下滑就行，机器要往下翻，得知道滚动这个动作会触发什么、要滚多少次、什么时候算到底。这里没有任何一个可以复述的地址。

分页和无限滚动那四种方案的老结论是：无限滚动必须配一套可寻址的分页作为底座，否则爬虫走不下去。这个结论在代理这一侧只会更硬——爬虫至少还能靠sitemap绕过去，代理没有sitemap可用，它要做的是“在这个筛选条件下再看20件”，这件事只能沿着分页走。分类页分页的五种配置里那套“加载更多按钮同时是一个真链接”的写法，是成本最低的一个折中：按钮上挂href指向第二页，JavaScript拦截默认行为做局部加载，机器读到的仍然是一个能走的链接。

13个只有“Load more”按钮的站，其实离这个折中只差一个属性。

加购按钮里机器看得懂的那部分，是谁做的？

这一节的结论被推翻过一次，推翻它的是一次补测。原样写在这里，因为翻车的过程比结论本身更有用。

先看基础数字。80个产品页里，49个（61.3%）能找到明确的加购按钮，其中47个是<button>，2个是<a href>。再往下：

• 按钮在某个表单里的：28个（占49个的57.1%）；
• 表单带action的：24个；
• 其中action指向/cart/add的：19个。

/cart/add是Shopify标准主题里购物车表单的提交地址。看到19这个数，第一版分组就是这么切的：把命中/cart/add的算成Shopify，其余算自研，然后算出一组非常好看的对照——19个里19个加购可构造，64个里只有5个。

那组数字是错的。/cart/add只是Shopify默认主题留下的痕迹，不是Shopify本身；主题被改过的站，这个痕迹就没了。而且这条路径也不为Shopify独有，decathlon同样命中了它。

改用首页HTML里的平台特征重判之后，情况完全变样：131个站里有61个是Shopify，占46.6%，不是19个。原来那把尺子低估了3.2倍。

按真实平台重新分组：

39.2%对13.8%，差距还在，但比原来那个100%对7.8%温和太多了。而真正有意思的是被这次修正翻出来的另一个数字：Shopify站里有加购按钮的35个，15个的按钮根本不在表单里，占42.9%。

这15个是aloyoga、anker、awaytravel、bollandbranch、eufy、glossier、graza、gymshark、kotn、liquiddeath、materialkitchen、nativecos、parachutehome、peakdesign、soundcore。

它们全都用着Shopify，而Shopify的默认主题十几年来一直把加购写成一个表单——那个写法之所以存在，是因为当年得让不支持JavaScript的浏览器也能下单。这15个站在做主题定制的时候，把那层表单换成了纯前端的按钮。

所以这一节的结论不是“平台替你做好了”，而是更绕一点的一句：平台给了你一个能用的默认值，然后四成人在改主题的路上把它弄丢了。

data-product-id算不算一个接口？

不算，值得单独说清楚，因为很多人会拿它当挡箭牌。

49个加购按钮里，29个挂着data-*属性，中位1个，最多的glossier挂了17个。出现频率最高的几个是data-testid（7次）、data-variant（4次）、data-add-to-cart（4次）、data-product-id（2次）。

看着挺像回事：商品ID有了，变体ID有了，动作名也有了。但这些名字是各家自己起的，没有任何一份规范说data-product-id意味着什么、要配什么端点、用什么方法提交。同一个概念，这家叫data-product-id，那家叫data-variant，还有一家用data-v-4e8f9ce7这种构建工具生成的哈希。

data-*属性本来就是给页面自己的脚本用的私有存储，它是暗号，不是接口。暗号的特点是只有约定过的双方能用，而外面来的代理从来没跟你约定过。

顺着这个思路看那18个“按钮自己带name属性”的站，性质就完全不同了：name是表单提交时的参数名，它有规范定义，机器知道该拿它干什么。一个私有属性和一个标准属性，肉眼看都是一串字符，能力差着一整个协议。八类语义标签对SEO的真实影响那篇里讲过同类的分野，这里是它在动作层的版本。

另外还有一个更基础的数字：130个首页上可见的按钮中位18个，最多的那个站313个，其中223个按钮连可访问名都没有（占7.3%），30个站至少有一个这样的按钮。一个既没有文字、又没有aria-label、也没有title的按钮，在无障碍树里就是一个“按钮”，没有别的信息。人靠图标认得出那是购物车，代理只能挨个试。

平台给的那份默认值，为什么四成人自己弄丢了？

把四项按平台逐项拆开，规律一下就出来了：

搜索和加购，Shopify明显领先；筛选和分页，两边基本持平，其余平台甚至还高一点点。四项总分是1.33对0.97，差距远没有第一版那个2.32对0.88那么夸张。

这个分布指向一个很干脆的解释：平台只在“平台自己实现的那一件件事”上给出优势。搜索表单和加购表单是Shopify主题的核心组件，出厂就是规范写法；筛选和分页各家主题自己写，或者装第三方应用，平台管不着，于是优势归零。

再把这条规律套到8月那批新闻上。Shopify的WebMCP文档写着：每一个Liquid店铺都提供10个工具，其中包括把当前购物车带进结账流程的proceed_to_checkout。这些工具的名字、描述、输入结构全部由Shopify定义，文档里没有说明商家能不能关掉某一个、能不能改描述。

同一周Cloudflare那份开发者预览走得更远：在控制台点一下，边缘就给每个HTML响应插一行脚本指向同源的桥接文件，站点源码一个字都不用改。

形状和十几年前那个表单一模一样：平台做了决定，商家没参与，结果比自己做要好。

区别在于后面那一半。加购表单被改掉之后，至少还有人能从HTML里看出来——这一轮就是这么看出来的。WebMCP工具被主题改动破坏之后，页面上看不出任何异常，只有拿着支持它的代理去试才会发现。上一次那42.9%用了十几年才被量出来，下一次恐怕更久。

这不是在夸平台，也不是在贬商家。它指出的是一个真实处境：你的站对机器友好到什么程度，很大一部分不由你决定，而是由你站在谁的默认值上、以及你把那份默认值改动了多少决定的。Google那套AI协议矩阵值不值得现在就接，判断依据也在这儿——先看你有没有那一层的控制权，再看要不要用它。

还有个信号别忽略：WebKit在标准立场里明确反对这份提案，列了API设计、功能重复、国际化、可移植性、隐私、安全、用例、议事场所八条理由；Mozilla的立场是中立。目前的实现集中在Chromium系加上ChatGPT桌面端。这意味着协议这条路短期内不会覆盖所有代理，而第二条路——把动作写进HTML——对谁都有效。

这一轮量的是“能不能猜出来”，不是“能不能用”

边界必须说清楚，不然这些数字很容易被过度解读。

第一，判据是静态的。看的是HTML里有没有表单、有没有带参数的链接、有没有action，并没有真的去提交一次。一个带action="/cart/add"的表单，实际提交能不能成功、要不要CSRF令牌、会不会被风控拦下，这一轮没测。所以这些通过率都是上界：能构造出请求，不等于请求能成功。

第二，没通过不等于代理做不到。第一条路一直在那儿——模仿人点击，成功率低但不是零。代理卡在六成成功率不动的那件事拆过这些失败到底出在哪一层，界面可猜性只是其中一层，不是全部。

第三，每个站只看了三个页面：首页、一个类目页、一个产品页，都是从首页两跳之内能到的。类目页有83个而不是130个，是因为47个站的首页上找不到符合判据的类目页链接——这本身也是个信号，但样本流失得说出来。

第四，筛选那一项的判据偏保守。认的是带筛选参数的a[href]，各家参数命名五花八门，这一轮的模式只覆盖了常见的那些，25.3%这个数大概率偏低。反过来说，如果连常见模式都匹配不上，代理要认出来同样吃力，所以这个偏差的方向和结论是一致的。

第五，也是这一轮最该记住的一条：两次分组判据都翻过车，方向还相反。用/cart/add认Shopify，把61个站认成了19个，低估3.2倍；上一轮量规格字段配对时用“下一行不是已知字段名就算它是值”这条规则，把51.9%算成了93.6%，虚高1.8倍。

两次的共同点很清楚：都是拿某个具体实现留下的痕迹，去代替那个东西本身。痕迹会被改掉，也会被别人碰巧留下。判据要么直接测那个东西（去首页HTML里找平台特征），要么就得承认自己量的是痕迹的分布，不是事实的分布。

顺带一提，这次补测平台特征时还写了一条Magento的正则，里面有个mage/，结果131个站里命中109个——它把所有image/都匹配上了。这条数据没进文章，但它是同一天里第三次尺子出问题。正则写宽一个字符，结论就能离谱到自己都不信，好在这次离谱得足够明显。

想让机器能在你站上做事，先补哪四处？

按成本从低到高。前三处都不需要引入任何新技术，改的是已经写好的HTML。

第一处：把搜索框放回表单里

一个<form role="search" method="get" action="/search">，里面一个<input name="q">。就这两行。你的JavaScript该拦截照样拦截，该做即时联想照样做，但HTML这一层留下了完整的说明书：往哪儿提交、参数叫什么、用什么方法。

那5个输入框不在表单里的站，改动量是包一层标签。67个首页上根本没有输入框的站要稍麻烦一点，最省事的做法是在页面里放一个隐藏的搜索表单——不需要显示出来，只要在DOM里。同时把结构化数据里的SearchAction补上，两边都留一份。

第二处：给筛选结果一个地址

复选框放进表单，加上name和value；筛选之后把参数同步进地址栏，用history.pushState就行，不用整页刷新。索引这一侧该管照管——canonical指回主类目页，或者在robots.txt里挡住组合参数。类目页那套集合页机制里的筛选器治理方案可以直接沿用，只是判断标准要加一条：“不给地址”从今往后不再是省事，是关门。

第三处：让“加载更多”同时是一个真链接

把按钮换成<a href="?page=2">，JavaScript拦截点击做局部加载。用户体验一模一样，机器读到的是一个能走下去的地址。rel="next"顺手加上。这一处的改动通常在半天以内，收益是把一个66.3%的坑填上。

第四处：加购按钮回到表单里

这一处最麻烦，因为它牵扯购物车的实现方式。但从数据看，做得到的人已经做到了——28个站的加购按钮在表单里，其中大部分只是没动主题自带的那份写法而已。自研站要补这一步，成本主要在把纯前端的购物车状态改成有服务端端点可提交，值不值得做要看你的客单价和代理下单在你这个品类里的现实程度。

如果你现在做的是Shopify店，好消息是这四处里最难的一处你已经有了；坏消息是前三处Shopify不会替你做，主题改动全归你。保哥自己排这个顺序时是按“改完能不能当天验”来排的，前三处都能，第四处不能，所以它放最后。

做完之后怎么验

不需要装代理，用curl就够。搜索能不能拼出?q=，筛选后地址栏变没变，第二页的地址是什么，加购表单的action指向哪儿——四条命令，一个站十分钟。这套自查和JS渲染那一轮的验法是配套的：渲染解决的是“内容在不在”，这一轮解决的是“动作能不能发起”，两件事都过了，才谈得上代理能在你站上完成任务。

顺带把结构里更基础的一层也看一眼。首页是不是一个空壳决定了代理有没有东西可读，站点架构的深度决定了它要走几跳才够得着商品，类目页有没有说清楚“你现在在哪”决定了它筛完之后知不知道自己筛的是什么。这几层任何一层断了，后面的动作做得再规范也用不上。

常见问题解答

接了WebMCP，是不是这四处就都不用改了？

不是。WebMCP的工具只在支持它的代理里可用，目前主要是Chromium系加ChatGPT桌面端，WebKit在标准立场里明确反对，Firefox中立。更关键的是它是页面级的，工具随着标签页存在、随着关闭消失，不参与索引也不参与召回。搜索引擎的爬虫、比价工具、你自己的数据管道，走的还是HTML这条路。把HTML这一层做对，收益覆盖所有客户端；接WebMCP，收益覆盖一部分客户端。先后顺序不该反过来。

给筛选结果加地址，会不会又把抓取预算的老问题引回来？

会有这个风险，所以两件事要分开做。可达性这一侧给地址，索引这一侧照旧管住：主类目页之外的组合页统一canonical回去，高基数参数在robots.txt里挡掉，需要索引的少量组合单独放行。过去很多站是把两件事合成一个决定处理的——不给地址就等于不会被抓——现在这个等式不成立了，因为代理不看robots.txt决定要不要走，它只看走不走得通。

零项通过的那23个站，是不是意味着代理完全用不了？

不是，只意味着代理必须走模仿人那条路：截图或读无障碍树、认按钮、点击、等待、再判断。这条路能走通，但每一步都可能失败，而且同样的任务重跑一次结果可能不一样。四项通过率高的站，代理可以走确定的那条路，快且可重放。这一轮量的是有没有第二条路可选，不是能不能用。

为什么把“表单有action”当判据，而不是实际提交一次试试？

因为实际提交会真的往这些站的购物车里加东西，也会触发它们的风控。判据停在静态HTML这一层，是有意的边界。代价是这些通过率都是上界——能构造出请求，不代表请求一定成功。要测真实成功率得另做一轮，而且需要拿到站主授权。

这批站是怎么选的，结论能推广到多大范围？

131个英文电商与消费品牌站，本工程一直在用的同一批样本，覆盖服饰、家居、消费电子、食品、户外这几个大类，规模从中型独立站到国际品牌都有。它反映的是“做得比较用心的英文DTC站现在长什么样”。中小型站、B2B站、平台型电商、中文站都没覆盖，把这些比例直接搬去描述其他类型的站会失真。

那个四项全通的snowpeak，是特意做过代理优化吗？

看不出有。它的四项分别是：搜索在一个GET表单里，筛选有带参数的链接，分页是真链接，加购表单指向/cart/add。最后一项说明它是Shopify，前三项则是主题没被改坏。它更像是把该保留的都保留了，而不是额外做了什么——这大概是整篇里最值得琢磨的一点：在这件事上领先，目前还不需要做加法。

权威参考资料