WebMCP 进了 Chrome 149 与 Edge 150 的测试：前端为什么要提前准备

你让 AI 助手替你订一张机票，它打开航空公司官网，先做一次截图，再做文字识别，定位搜索框，模拟一次点击，填出发地、目的地和日期，最后提交。 中间任何一步不对，这一趟就白跑：按钮挪了位置，下拉菜单慢半拍，日期控件跟别家的交互逻辑不一样。 一个会推理、会写代码的模型，为什么会卡在"点对一个按钮"这种小事上？更别说这一趟跑下来烧掉的时间和算力，远高于你自己点两下。 这套笨办法，W3C 的一个提案正在把它换掉。 它做的事其实很朴素：让网页主动交出自己的功能 WebMCP 是一套浏览器侧的协议，名字直译过来是"Web 模型上下文协议"。按 W3C 仓库里的说明，开发者可以把网页应用的功能——一段脚本函数，或者一个 HTML 表单——包装成"工具"交给 AI Agent 调用，工具自带自然语言描述和结构化的参数说明。 能调这些工具的角色不止一种：浏览器里内置的 Agent、嵌在页面内嵌框里的 Agent、浏览器扩展里的 Agent，都算。 它给了开发者两条接入路径。 一条是命令式：把工具挂到页面文档对象下的模型上下文命名空间里。注册时交代四件事——名字、描述、参数结构、真正干活的函数。有个细节值得留意：注册方法会接收一个信号对象，以后想撤掉这个工具，把信号中止掉就行。官方还专门建议，工具多的应用应该跟着页面状态动态注册和注销，理由是别让 Agent 的上下文窗口被塞满。 另一条是声明式：浏览器可以直接从表单元素里自动生成工具定义，开发者一行脚本都不用写。 那为什么不干脆只留声明式？仓库里的回答很实在——网站不可能只用表单搭出来，有一部分能力天生只有脚本才能实现，想让协议完整表达网页的能力，就必须允许脚本注册。 顺带说一句，静态清单方案被否决过。用类似应用清单的静态文件声明工具，离线发现是方便，但开发者没法按页面状态和登录状态动态增删，而且清单里放不了可执行代码，最后还是得靠命令式接口来挂执行逻辑。 这次不是纸上提案：两家浏览器都开了测试通道 评估一项标准值不值得投入，最实在的指标是看它有没有走出幻灯片。这个提案已经走出来了。 按仓库那份实现状态清单：谷歌的测试通道在 149 版本开放，本地想试，把实验开关打开即可；微软的测试通道在 150 版本上线。 客户端一侧也没闲着。ChatGPT 桌面版已经能直接用；另有一家浏览器把它做成了实验特性；Meta 的智能眼镜也排在计划里，让眼镜上的 AI 调用页面注册的工具，默认关闭、按设备开启。 还在观望的是两家老牌浏览器，目前都停在标准立场评审阶段，议题号分别是 1412 和 670。 时间线也值得看一眼：这份提案由微软和谷歌的工程师在 2025 年 8 月 13 日首次发布。一年出头，从提案走到两家浏览器同时开测试通道。 对前端来说，变的是"到底谁在用你的页面" Web 这三十年有一条几乎没被挑战过的假设：人用眼睛看内容，用手点按钮。这个提案把假设撬开一道缝——你的页面开始有两类使用者，人读的是视觉布局，Agent 读的是工具定义和参数结构。 由此有三件事值得提前想清楚。 第一，"可操作性"开始追上"可发现性"的分量。搜索优化解决的是被找到，这个协议解决的是被可靠地使用。一个用一堆 div 加点击监听堆出来的页面，人眼看着没问题，Agent 可能完全无从下手。 第二，语义化标签的分量被抬高了。button 不只是能点的东西，它是"这里可以交互"的信号；form 不只是容器，它是"这里有结构化输入"的信号。以前这算代码习惯，现在算工程基础。 第三，现在还不急，但也没法一直拖。真正在生产环境里用上它的网站还很少，两家老牌浏览器也没表态，此时把全部表单翻一遍，性价比不高。成本最低的起步顺序反而很清楚：第一步，先给标准的搜索、预订、注册表单补上声明式工具；第二步，把那些只有脚本才做得出来的交互，用命令式接口包一层。 有人把无障碍这件事说得很透：平时给屏幕阅读器做的基本功，恰好也是 Agent 稳定操作你的前提。这个说法我在官方仓库里没找到一字不差的原文，但方向站得住——每个可交互元素有能读出来的名字、有正确的角色、表单项关联着标签，这些要求本来就该做。 从"猜按钮"到"被告知"，这次改的其实不是模型的能力，而是网页这一侧的约定。模型早就准备好了，缺的是网页先把门打开。 参考链接： · W3C 的 WebMCP 提案仓库：https://github.com/webmachinelearning/webmcp · 一篇讲这套协议进测试通道的中文文章：https://juejin.cn/post/7690467043259383850