网站不再需要被「猜」：WebMCP 源试用今日开放，AI Agent 与 Web 的交互范式正在重写

Agent「看」网页的方式，今天开始变了

过去两年，AI Agent 用网页的方式令人尴尬：截图、猜按钮、模拟点击、等 DOM 更新、再截图。ChatGPT Atlas、Perplexity Comet 们完成一个结账流程的成功率大约 30%。这不是智能，是用亿级参数模型在玩像素级「找茬」。

今天，Chrome 149 的 WebMCP 源试用正式开放。这个由 Google 和 Microsoft 联合提交给 W3C 的提案，用一句话概括就是：让网站主动告诉 Agent 自己能做什么，而不是让 Agent 去猜。

效果立竿见影——接入基本 WebMCP 支持后，Agent 任务完成率从 30% 飙升至 91%，结构化调用比视觉抓取减少 67% 的错误。

两套 API，从零代码到全控制

WebMCP 提供两种实现路径，门槛差异极大：

声明式 API：零 JavaScript

在现有 HTML 表单上添加几个属性，浏览器自动生成工具 Schema：

<form toolname="searchFlights" tooldescription="搜索航班">
  <input name="origin" toolparamdescription="出发城市代码" />
  <input name="destination" toolparamdescription="目的城市代码" />
  <input type="date" name="outboundDate" />
  <button type="submit">搜索</button>
</form>

Agent 直接调用 searchFlights({origin: "PEK", destination: "JFK", outboundDate: "2026-06-15"})，一个结构化调用替代八次 UI 交互。不需要写 JavaScript，不需要改后端，现有表单加几个属性，一个下午就能上线。

命令式 API：全编程控制

通过 navigator.modelContext.registerTool() 注册工具，处理动态状态、多步流程、实时数据等复杂场景：

if ('modelContext' in navigator) {
  navigator.modelContext.registerTool({
    name: 'add_to_cart',
    description: '添加商品到购物车',
    inputSchema: {
      type: 'object',
      properties: {
        product_id: { type: 'string', description: '商品 SKU' },
        quantity: { type: 'number', description: '数量' }
      },
      required: ['product_id']
    },
    readOnly: false,
    async execute(input) {
      const result = await addToCart(input.product_id, input.quantity);
      return { success: true, cart_count: result.total };
    }
  });
}

('modelContext' in navigator) 的特性检测确保在不支持的浏览器中静默降级，不会破坏现有功能。

WebMCP ≠ MCP，但必须一起用

名字相似容易混淆，但架构完全不同：

关键洞察：两者互补，不是替代。 一个旅行 Agent 可以用 MCP 查询后端航班 API，再用 WebMCP 在第三方预订网站上完成下单——无需该网站的 API 凭证。Google 官方建议两者同时建设。

六家平台的信号

Booking.com、Expedia、Instacart、Intuit、Shopify、Redfin 已在 I/O 2026 上公开承诺接入。企业不会出于善意拥抱未完成的标准——它们赌的是 Agent 驱动流量即将爆发，先发者有选择权。

电商跑得最快，41% 已开始实施。逻辑简单：Agent 在 WebMCP 启用的站上完成购买的速度是抓取式站的三倍。当 Gemini 原生支持 WebMCP API 后，每个开启 Gemini 的 Chrome 用户都是潜在的 Agent 访客。没有注册工具的站点？Agent 要么用脆弱的抓取方式，要么直接跳过。

安全隐忧不能忽视

WebMCP 继承了用户浏览器会话——这是效率的来源，也是风险的起点：

• 会话权限不可独立审计：Agent 直接使用用户的登录态，安全团队无法单独审计或撤销 Agent 的访问权限
• 提示注入仍是活靶：恶意页面可能通过精心构造的工具描述操纵 Agent 的调用行为
• toolautosubmit 是双刃剑：允许 Agent 自动提交表单，用于搜索没问题，用于付款就需要三思

Google 的权限策略默认为 self（同源上下文可注册工具，跨源 iframe 默认禁用），需要显式添加 allow="tools" 才能开放——这是最小权限的起点，但还不够。

浏览器覆盖率的硬伤

Chrome 149 + Edge 147 已支持，合计约 70% 浏览器市场份额。但：

• Firefox：承诺 Q3 2026，尚未交付
• Safari：Apple 参与了 W3C 工作组，但没有任何交付时间表

Safari 占移动端流量超过三分之一。如果 Apple 不跟进，WebMCP 在移动端存在显著的覆盖缺口。目前可通过 MCP-B polyfill 做跨浏览器兜底。

开发者现在该做什么

1. 映射工具面：梳理站点的搜索、筛选、提交、导航等可操作能力
2. 声明式先行：在现有表单上加 toolname / tooldescription，成本极低
3. 注册源试用：Chrome 149 origin trial 现已开放注册
4. 本地验证：Chrome Canary 中启用 chrome://flags/#enable-webmcp-testing，安装 Model Context Tool Inspector 扩展调试
5. Lighthouse 新审计：新增「Agentic Browsing」分类，评估站点对 Agent 的友好程度

从 robots.txt 到 WebMCP

1994 年 robots.txt 诞生时无人问津，当搜索爬虫流量达到阈值后，它悄无声息地变成了生死攸关的基础设施。WebMCP 走在同一条轨迹上——只是 AI Agent 流量的增长速度远超当年搜索爬虫。

Agent 在你的站点上完不成任务，它不会重试，它会去别处。从今天开始，网站和用户之间的契约不再只有视觉层——还多了一层结构化的 Agent 契约。主动写这份契约，远比让 Agent 猜你的 HTML 要好。