5月5日消息,Chrome 146 Canary 已开放 WebMCP 早期预览,通过 chrome://flags 中的"WebMCP for testing"开关即可启用,开发者可加入 Chrome Early Preview Program 获取完整文档与示例。该协议由 Google 与 Microsoft 工程师联合起草,在 W3C Web Machine Learning 社区组孵化,核心目标是让网站直接向 AI Agent 暴露结构化工具,跳过当前主流浏览器 Agent 依赖的 DOM 抓取、视觉识别和坐标点击链路。Microsoft Edge 147 已在 3 月跟进实现,Safari 与 Firefox 参与了 W3C 工作组但尚未给出落地时间表。
WebMCP 在浏览器侧引入了一个全新的 navigator.modelContext 命名空间,提供 registerTool()、unregisterTool()、provideContext()、clearContext() 四个核心方法。每个工具的描述结构包含 name、description、inputSchema 和 execute() 函数,与 Anthropic 在 2024 年 11 月公布的 MCP 协议保持语义一致,但运行环境从独立的 Python/Node.js 后端迁移到了浏览器 tab 内的 JavaScript 上下文。这意味着工具调用直接复用用户当前会话与认证状态,不需要为 Agent 再单独搭建后端 MCP Server,也不必额外管理一套凭证。
声明式与命令式两套 API 覆盖不同场景
WebMCP 同时提供两条接入路径。Declarative API 以 HTML 原生 form 元素为载体,网站只需在表单上添加 agent-ready 属性,浏览器即会自动把字段映射成结构化的工具 schema 暴露给 Agent。Agent 调用时,浏览器会聚焦表单并预填字段,默认仍由用户点击提交,只有显式开启 autosubmit 才会跳过人工确认,这一设计明显是为了在自动化效率与用户控制之间留出缓冲。Imperative API 则面向更复杂的状态依赖型交互,开发者通过 JavaScript 注册工具,可处理多步流程、实时数据和应用状态变化。
配套生态方面,Chrome 团队同步发布了 Model Context Tool Inspector 扩展,允许开发者在任意页面查看已注册工具、手动触发执行,或通过 Gemini API 直接以自然语言调用,降低调试门槛。官方还提供了一个 travel-demo 演示页,完整呈现 searchFlights 这类工具从声明到 Agent 调用的全链路。 与 CDP 是两条完全不同的路径
外界容易把 WebMCP 与现有的 Chrome DevTools Protocol(CDP)混为一谈,但两者解决的根本不是同一个问题。CDP 是浏览器底层调试协议,Puppeteer、Playwright、Selenium 这些自动化框架都建立在它之上,通过 WebSocket 向 Chrome 发送 Page.navigate、DOM.querySelector、Input.dispatchMouseEvent 等指令,操作的是浏览器引擎本身,网站对此完全无感知,本质是"模拟人类操作"。WebMCP 反过来,主语从 Agent 切换到了网站,网站主动声明自己提供哪些业务级工具,Agent 通过浏览器读取这些声明并直接调用,操作的是网站显式开放的语义接口。
落到实际差异上,CDP 操作粒度停留在 DOM 节点和像素坐标,Token 消耗高、对前端改版极其敏感,但优势是零适配成本,任何网站都能爬;WebMCP 操作粒度直接对齐业务语义,Token 消耗低、接口稳定,代价是必须由网站主动适配。两者并非替代关系,更可能是分层共存——网站愿意开放的部分走 WebMCP,没有适配的部分则继续走 CDP+视觉模型作为兜底,这与目前 Anthropic Computer Use、OpenAI Operator 走的纯视觉路线形成了明显分野。VentureBeat 在报道中将 WebMCP 类比为"AI Agent 与网页交互的 USB-C",指向标准化接口替代当前各家自建抓取策略的趋势。
早期预览阶段仍有大量未解问题
需要明确的是,WebMCP 目前仍处于 DevTrial 阶段,未进入稳定通道。Chrome 团队已公开承认 prompt injection、工具链调用导致的数据泄露、破坏性操作的强制确认等安全议题尚未完全解决,因此官方建议仅用于实验和原型验证,不要部署到处理敏感数据的生产工作流。工具发现机制也是明显短板——目前 Agent 只有在打开页面后才能识别该站提供哪些工具,类似早期搜索引擎在 robots.txt 出现前的状态,业界正在讨论 .well-known/webmcp 这类基于 manifest 的发现方案。多 Agent 同时操作同一页面会出现冲突,提案中的锁机制类似 Pointer Lock API,但尚未定稿。此外,当前 spec 仅规范 JSON 响应,图像、文件、二进制等非文本返回类型的处理方式仍是开放问题,DevTools 也尚未提供专属调试面板。
更深层的挑战来自采用侧。让网站主动暴露工具接口本身是个鸡生蛋的问题,Amazon 在 3 月获得法院禁令阻止 Perplexity Comet 在其平台上的 AI 购物代理,与 WebMCP 鼓励"声明式 Agent"的方向恰好形成对照——前者代表平台方对未授权 Agent 的强硬封堵,后者则提供了一条"被授权 Agent 走标准管道"的协作路径。Stripe 联合 OpenAI 推出的 Agentic Commerce Protocol 也在做类似尝试,只不过把战场放在结账环节。WebMCP 能否真正成为标准,取决于浏览器厂商的覆盖速度和头部网站的适配意愿,目前 Google I/O 与 Cloud Next 2026 被业界视作可能的正式公告窗口。