Chrome 146 的早期预览版里多了一个 flag，叫 WebMCP（Web Model Context Protocol，Web 模型上下文协议）。这个东西让 AI 智能体可以直接绕过网页的图形界面，不看你那些精心设计的按钮、下拉菜单和交互动效，直接调你网站后端的函数。
用开发者 Alex Volkov 的话说：「WebMCP 相当于 UI 的 API。」
什么意思？
Agent 不再需要截你的屏、猜你的按钮在哪、抖着手模拟鼠标点击。它可以直接问网站：「你有什么功能？说明书给我看看。」然后以函数调用的方式把事情办了。
这不是渐进式改良。这像是给互联网重新铺了一层地基。
先看现状：Agent 用网站的样子有多荒诞
如果你见过一个 AI Agent 操作网页，它的工作流程大致是这样的：
1. 截一张网页截图
2. 把图片丢给多模态大模型（Gemini、Claude），问「蓝色的方块是提交按钮吗？」
3. 大模型猜一遍，告诉它大概位置
4. Agent 移动鼠标、点击
5. 页面变了，再截一张新图，重复循环
一次简单的搜索，可能要消耗几千个 token 来解析截图和 DOM。而且网站只要换个样式，Agent 就懵了——按钮不蓝了，它就不认识了。
VentureBeat 的报道说得挺形象：「一个 AI Agent 访问网站，就像一个不会说当地语言的游客。」它猜按钮、猜表单、猜链接，有时候能蒙对，但多数时候在烧钱。
现在 Bots 已经占到全网流量的 51%。但大部分 Bot 活得挺憋屈的，靠着截屏和 DOM 抓取苟着。它要改变的就是这件事。
WebMCP 是什么：让网站给 Agent 发一本「操作手册」
它是由 Google 和 Microsoft 的工程师联合开发，在 W3C 的 Web Machine Learning 社区组孵化的一个提案标准。它定义了一个新的浏览器 API：`navigator.modelContext`。
通过这个 API，网站可以向浏览器里的 AI Agent 暴露结构化的工具。说白了就是：
> 别再猜了，我直接告诉你我能干什么。你需要什么参数，返回什么格式，白纸黑字写清楚。
它提供了两套接入方式：
声明性 API（Declarative）：直接在 HTML 表单上加属性。不需要写 JavaScript。
<form toolname="search_flights" tooldescription="Search for available flights" toolautosubmit="true"><br>
<input name="origin" placeholder="Departure city"><br>
<input name="destination" placeholder="Destination"><br>
<input name="date" type="date"><br>
<button type="submit">Search</button><br>
</form>加上 `toolname` 和 `tooldescription` 之后，Chrome 自动读取这些标签，给 AI 生成一份 schema。Agent 看到这个表单就知道：哦，这里有一个叫 `search_flights` 的工具，接受三个参数，我可以直接调用。
命令式 API（Imperative）：用 JavaScript 注册更复杂的工具。
navigator.modelContext.registerTool({
name: "book_flight",
description: "预订机票，包含乘客信息和支付",
inputSchema: {
type: "object",
properties: {
origin: { type: "string", description: "出发城市代码" },
destination: { type: "string" },
date: { type: "string", format: "date" },
passengers: { type: "number" },
},
},
execute: async (params) => {
// 复用你现有的前端逻辑
return await flightAPI.book(params);
},
});两种方式的核心逻辑一致：从「让 Agent 猜网站怎么用」，变成「网站告诉 Agent 怎么用」。
为什么说这是降维打击
从结果看，它带来了几个巨大的变化。
成本断崖式下降。 有技术分析做了对比：一次结构化的工具调用大约消耗 20-100 个 token，而以前靠截图的方式一次就要 2000+ token。效率提升了近 89%，任务准确率能推到 98% 左右。
开发量没有想象的大。如果你的 HTML 表单本身结构清晰，加三个属性就够了。复杂场景也就是写个 JavaScript 注册函数，用的大多是你现有的前端代码，不需要重新搭后端服务。
人类还在驾驶座上。它明确排除了「全自动化」和「无头浏览器」场景。Google 和 Microsoft 的设计文档很清醒地强调了三个词：Context（上下文）、Capabilities（能力）、Coordination（协调）。Agent 辅助用户，而不是替代用户——这是有意设计的哲学选择，不是补丁。
一个函数调用替代几十次点击。 一个电商网站注册了 `searchProducts(query, filters)` 工具后，Agent 一次调用就能拿到结构化结果。以前它需要：点筛选下拉 → 翻页 → 截屏 → 识别产品卡片 → 再翻一页……循环往复。
它和 MCP 是什么关系
很多人会搞混这两个东西。
MCP（Model Context Protocol）是 Anthropic 在 2024 年 11 月推出的，运行在服务端。它通过 JSON-RPC 把 AI Agent 连接到外部的数据源、工具和工作流，用的是 Python 或 Node.js 的 SDK。
WebMCP 是浏览器的原生协议。网站本身就是 MCP 服务器，工具定义和执行都在浏览器标签页里完成，不需要额外部署。
Google 自己的文档说得很清楚：它不是 MCP 的替代品，也不是 MCP 的扩展。MCP 管后端，它管前端。最好的方案是两者一起用——MCP 处理核心业务逻辑和数据层，它处理浏览器里的实时交互。
未来的智能应用架构大概是这样的：
1. MCP 服务器：管核心逻辑、数据检索、后台任务，平台无关
2. WebMCP：管浏览器里的上下文交互，让 Agent 在用户打开网站时能实时操作
3. 两者协作：MCP 提供基础服务，WebMCP 处理最后一公里的浏览器交互
对开发者意味着什么：你的网站可能已经分成两层了
开发者 Nikoloz Turazashvili 在他的分析里提了一个有意思的概念：如果 它真的成为标准，未来的互联网会自然分化成两层——
给人类看的 UI：视觉、品牌、动效、情感设计
给 Agent 用的工具界面：结构化数据、契约接口、极速响应
你不会再因为「页面做得漂亮」而在 AI Agent 的世界里胜出。赢家是那些拥有最清晰工具契约的网站。
这对前端开发者意味着什么？
短期内，你只需要在表单上多写几个 HTML 属性。中期你会开始用 `navigator.modelContext` 注册工具。长期看，「为 AI 设计接口」会成为前端工程师的标配技能，就像十年前「做响应式」一样。
这是一个新的岗位分化方向——从「前端工程师做 UI」，到「前端工程师做 AI 接口」。
Google 在 I/O 2026 上还重申了另一件事：它不只是给 Agent 用的。它同样能让无障碍辅助技术直接执行高层级的页面操作，而不是靠逐个模拟点击。这不是个小众场景——WCAG 合规往往需要大量额外工作，它提供了一条更直接的路径。
什么时候能用
目前它在 Chrome 146 Canary 中可用，开启 `chrome://flags` 里的对应 flag 就能体验。Google I/O 2026 已经确认它会在稳定的 Chrome 中推出。
如果你想自己试试，Chrome Web Store 上有一个 Model Context Tool Inspector 扩展，可以帮你调试。
已经有开发者做了旅行预订的 demo（travel-demo.bandarra.me），去看一眼就能直观感受到「声明一个工具 → Agent 直接调用」的全流程。
最后说两句
上一个改变 Web 底层交互逻辑的标准，大概要数 2010 年前后的 HTTP/2 和 WebSocket。WebMCP 有没有到这个级别现在还不好说，但逻辑是类似的：它让浏览器不再只是一个「文档展示器」，开始变成一个「协议网关」。
AI Agent 不再需要在像素和 DOM 节点里摸爬滚打了。网站可以明确地说「我能做什么、你需要什么参数、数据怎么传回来」。
对于开发者来说，现在开始了解它应该不会亏。不是因为它明天就会颠覆一切，而是因为——
当互联网真的分成「给人看」和「给 AI 用」两层的时候，早一天理解这个模型，就早一天做出选择。等到所有竞品都在 HTML 上加了 `toolname` 而你还没动手，那时候再追可能就慢了。
📖 推荐阅读
这些是跟大模型相关的文章，你可能会感兴趣：
本地运行开源大模型指南：从Ollama到DeepSeek，手把手搭建你的私人AI