Chrome推出WebMCP让AI代理告别截图瞎点，网页交互进入精准调用

Chrome 浏览器最新发布的第 145 版本，悄悄塞进了一个叫 WebMCP 的实验功能，目的就一个：让这些 AI 代理别再装人类了，直接跟网站“说人话”。

WebMCP 是啥？就是给网站装个“遥控器说明书”

电视遥控器上有一堆按钮，但没人告诉你哪个是音量、哪个是频道。你只能盯着电视屏幕，看到画面变亮了就知道刚才按的是亮度键，声音大了就猜是音量加。这多累啊！

WebMCP 干的事，就是让网站自己写一份“遥控器说明书”。比如一个订票网站，它可以在自己的网页代码里加几行标记，告诉所有来访的 AI 代理：嘿，我能干三件事——查余票、选座位、下单支付。你要查余票？直接调用我的‘checkAvailability’工具，把日期和车次传给我就行；别傻乎乎地去点日历控件，也别试图从像素里抠出‘余票：23张’这几个字。

这样一来，AI 代理再也不用靠眼睛（其实是靠视觉模型）去“看”网页了，它直接读这份说明书，精准调用对应功能，就像你按遥控器一样干脆利落。这本质上跟当年金融行业搞“开放银行”是一个路子——以前银行机器人要查你余额，得模拟登录、截图、OCR 识别，现在直接给你一个 API 接口，安全又高效。WebMCP 就是要把这套逻辑推广到整个万维网。

现在的 AI 浏览工具到底有多“卷”

说到这儿，可能有人要跳出来：“等等！我用的 agent-browser 根本不用截图！”没错，有用户吐槽说 agent-browser 默认其实走的是轻量级文本解析，类似屏幕阅读器看到的内容，压根不是全屏截图。

但问题在于，现实世界太复杂了。有些网站做得跟迷宫似的，JavaScript 动态加载内容，按钮藏在三层弹窗后面，文字颜色跟背景色几乎融为一体……这时候，哪怕是最聪明的文本解析也会懵圈。

于是像杰·皮卡帕拉斯这样的重度用户，就会祭出“暴力美学”——直接让 agent-browser 截图，然后把这张图同时扔给 minimax vision mcp 和 zai vision mcp 这两个视觉 AI 模型，让它们俩“吵架”：“我觉得该点左边那个图标！”“放屁！右边那个才是提交按钮！”吵完取共识，再让子代理去执行。

听起来很疯是不是？但他说这招在科研场景下反而比单靠 Claude大模型自己判断更稳，因为 Claude 有时候会突然“上头”，莫名其妙点进广告页面，半天回不来。所以你看，不是大家不想优雅，是有些网站逼得 AI 不得不“开天眼”。

WebMCP 怎么用？加两行 HTML 就行

那 WebMCP 到底怎么实现呢？好消息是，对网站开发者来说，门槛低到令人发指。你不需要重写整个后端，也不用申请什么特殊权限，只要在现有的 HTML 表单或者按钮上加几个自定义属性就行。

以下只是推测，比如你有一个搜索框，原本是这样：

<form action="/search" method="get">
  <input type="text" name="q">
  <button type="submit">搜一下</button>
</form>

现在你想让 AI 代理知道“这个表单能用来搜索”，只需改成：

<form action="/search" method="get" data-mcp-tool="searchTool" data-mcp-description="根据关键词搜索内容">
  <input type="text" name="q" data-mcp-param="query">
  <button type="submit">搜一下</button>
</form>

就这么简单！data-mcp-tool 告诉代理这个工具叫啥名，data-mcp-description 用大白话说明它能干啥，data-mcp-param 则标注输入参数。AI 代理一进页面，扫一眼这些标记，立刻心领神会：“哦，这有个 searchTool，需要传 query 参数。”直接构造请求，连 DOM 树都不用遍历。而且 WebMCP 设计成“渐进增强”模式——就算用户的浏览器不支持，普通人类访问时一切照常，完全无感。这种“向前兼容”的思路，大大降低了网站采用的心理门槛。

浏览器大战：各家都在憋大招

当然，Chrome 不是唯一想解决这个问题的。苹果的 Safari、Mozilla 的 Firefox 估计也在内部画蓝图。毕竟谁都看得出来，如果任由 AI 代理继续靠截图横冲直撞，网页性能会越来越差，用户体验越来越烂，最后大家都没好处。

但 Chrome 作为市场份额老大，率先推出 WebMCP，相当于抢到了标准制定的话语权。

目前 WebMCP 还只是 W3C 社区小组的草案，GitHub 上一堆 open issue，比如怎么处理认证、如何描述复杂工作流、是否支持异步回调等等。

但 Chrome 敢在正式版里塞实验性开关，说明谷歌已经押注这条技术路线。其他浏览器厂商要么跟进，要么就得另起炉灶搞一套自己的“AI 交互协议”，那可就真成“方形轮子配偏心轴”了——评论区那位吐槽“API 轮子造得歪”的老哥，其实点出了关键：如果每个浏览器都搞私有协议，开发者得适配 N 套标准，那还不如继续截图省事。

开发者现在该干嘛？上手试试 Polyfill

虽然 WebMCP 还没正式落地，但已经有热心开发者等不及了。

比如 Reddit 用户 Cold-Measurement-259（冷测259）就开源了一套 polyfill（垫片库），让你现在就能在旧浏览器里体验 WebMCP 的效果。他还配套做了 React Hooks 和修改版的 Chrome DevTools 插件，可以直接调用 WebMCP 工具。

据他实测，相比传统的截图+DOM 解析方案，token 消耗能省下九成！要知道，每次把整页 HTML 或截图喂给大模型，都是按 token 收费的，省九成等于直接砍掉九成成本。
他的项目地址是 docs.mcp-b.ai，感兴趣的朋友可以去薅羊毛。还有：https://github.com/webmachinelearning/webmcp/issues

这种“标准未至，工具先行”的做法，正是开源社区最迷人的地方——大家一边骂着“Chrome 又推非标功能”，一边默默写代码帮它铺路。