Chrome 团队宣布,WebMCP 刚刚从藏在 flag 后面的原型转入了 Chrome 中的公开 Origin Trial,运行范围为 Chrome 149 至 156。它是一个为 agentic web 提议的开放 web 标准:网站声明结构化工具,浏览器内的 AI agent 可以直接调用,而不必去看渲染后的页面再猜。有两种声明方式,一个用于以纯 JavaScript 定义工具的 Imperative API,以及一个把带注解的标准 HTML 表单变成工具的 Declarative API。面向模型的表面又小又清晰:document.modelContext.getTools() 列出一个页面提供什么,executeTool() 运行其中一个,每个工具带有 readOnlyHint 和 untrustedContentHint 之类的注解,好让 agent 知道自己在碰什么。配套文档在五月上线,试用在 Google I/O 2026 上揭晓。
为什么重要,在于它与今天浏览器 agent 工作方式的对比。当前的默认是视觉循环:对页面截图、按像素定位一个按钮、点击、再截图、祈祷布局没有移动。WebMCP 用一次带类型的函数调用取代了它。Chrome 团队把收益框定为更快(一次调用对一个截图循环,早期第三方基准称在 WebMCP 页面上端到端完成任务快 8 到 12 倍)、更可靠(没有会在 CSS 改变时崩掉的逐像素搜寻),以及更安全(agent 无法调用网站未声明的工具)。这次试用中专门新增的:列出和执行工具、一个 permissions policy,以及跨源 iframe 工具支持,这些是一个真实网站在能暴露超出演示的任何东西之前所需的管线。
这是 agent runtime 的竞争一路向下伸进了 web 页面本身。我们一直追踪的关于谁托管、谁编排 agent 的争夺,如今在文档层面有了一条战线:网站不再是一个被抓取的对象,而变成一个带类型的工具表面,一个面向 agent 的 API,无论它是否曾为开发者发布过一个。如果 WebMCP 标准化,agentic web 就不再是猜谜游戏。诚实的隐患是,一个只有一个消费方的 web 标准还不是标准:今天唯一读取 WebMCP 工具的 agent 是 Gemini in Chrome,即谷歌的浏览器内助手,所以采纳与中立性都仍是开放问题。对 builder 来说具体的动作又小又便宜:注册 origin trial,把你最有价值的两三个动作声明为工具,然后衡量相对视觉基线,可靠性收益是否真的出现。