你以为 AI agent 只能靠截图猜按钮？今天 WebMCP 把这件事彻底变了

每次让 AI agent 帮你操作一个 Web 应用，它都要先截一张图，然后用视觉模型猜哪个按钮是「提交」、哪个是「取消」，点完再截一张，祈祷 CSS 没改。这是今天所有浏览器 agent 的默认工作方式——像素级逆向工程。

Chrome 149 把这个范式彻底推翻了。

WebMCP 是什么

WebMCP（Web Machine Context Protocol）是一个正在标准化进程中的开放 Web API，它让网站主动声明「我能做什么工具」，浏览器内的 AI agent 可以直接调用这些结构化工具，而不用再靠截图猜。

网站声明工具，agent 直接调用——这件事把「网站」和「agent」之间的关系从「被抓取的对象」变成了「带类型的 API」。

两种声明方式

Imperative API 用纯 JavaScript 注册工具：

document.modelContext.registerTool({
  name: "bookSlot",
  title: "预约时段",
  description: "预约30分钟咨询",
  inputSchema: {
    type: "object",
    properties: {
      date: { type: "string", format: "date" },
      time: { type: "string" },
      name: { type: "string" },
      email: { type: "string", format: "email" }
    },
    required: ["date", "time", "name", "email"]
  },
  annotations: { readOnlyHint: false },
  execute: async (input, client) => {
    return await api.book(input);
  }
});

Declarative API 更直接——给 HTML 表单加两个属性，浏览器自动把它变成一个可被 agent 调用的工具：

<form toolname="bookSlot" tooldescription="预约30分钟咨询时段">
  <input name="date" type="date">
  <input name="time" type="text">
  <input name="name" type="text">
  <input name="email" type="email">
  <button type="submit">确认预约</button>
</form>

浏览器自动生成 JSON Schema，agent 看到的是结构化参数而不是截图。

为什么快 8-12 倍

这是核心数据。Chrome 团队引用了早期第三方基准：在启用了 WebMCP 的页面上，agent 端到端完成任务比截图循环快 8 到 12 倍。

三个原因：

一、一次结构化调用 vs 多次截图循环。截图循环需要：截图→视觉模型定位→点击→再截图→验证，每次交互都多一个 RTT。

二、不怕 CSS 重构。像素级定位在按钮换个 class 或改个位置就崩了；typed tool 声明的是语义，和 CSS 无关。

三、安全边界清晰。agent 只能调用网站声明过的工具，没声明的按钮点了也没用——这是白名单，不是黑名单。

安全不是事后补的

WebMCP 从设计上是安全优先的。有两层限制：

Origin isolation 要求：WebMCP 只在 origin-isolated 文档中可用，document.domain 混用会直接禁用它——从架构上堵住了跨域工具泄漏。

Permissions Policy：默认只在同源上下文开启，跨域 iframe 要显式加 allow="tools" 才能暴露工具。

工具输出本身也可能成为攻击面——Chrome 文档里有专门的安全指南，要求开发者对 untrustedContentHint 做处理，对恶意文本输入做过滤。这是设计时就考虑进去的，不是补丁。

局限性：这不是万能药

一、需要一个打开的标签页。WebMCP 主要面向「有用户在操作」的本地浏览器工作流，不支持 headless 执行——想搭无人值守的 agent 爬虫，这条路走不通。

二、需要真实的应用状态。网站要真正接入工具，得把内部状态暴露出来，这通常意味着要写实际的 JavaScript 代码，不能只是加几个 HTML 属性。

三、目前唯一的消费者是 Chrome 里的 Gemini。一个 web 标准只有一个 browser 在用，严格来说还不算「标准」。Firefox 和 Safari 还没有明确表态，这是真实风险。

下一步：三件事

如果你想今天就开始：

第一步：打开 chrome://flags/#enable-webmcp-testing，把 WebMCP 启用，做本地开发测试。

第二步：在你的网站选两个高频操作——比如预约、查询、提交——用 Declarative API 把表单声明成工具，这是最小可行的起步。

第三步：装 WebMCP Inspector 浏览器扩展，用自然语言和 agent 对话，看它能不能正确找到并调用你声明的工具。

WebMCP 解决的不是「agent 能不能用」，而是「网站愿不愿意被用」。愿意把工具声明出来的网站，会成为 agent 优先访问的对象；继续靠截图猜的，会越来越难用。这是一个新的协议层，谁先接，谁先有优势。