WebMCP：让AI直接调用网站功能的新协议
AI操作网页，现在有了新办法。
Chrome团队最近推出了WebMCP（Web Model Context Protocol）。这是一个浏览器自带的协议，让网站可以通过原生API向AI暴露功能。AI不用再看图猜按钮，直接调用网站能力就行。
WebMCP是什么
简单说，WebMCP让网站给AI一份调用接口说明。AI照着说明调用，网站返回结果。
举个例子，在网页上添加一个任务：
没有WebMCP的时候，AI得打开浏览器，截图，分析页面找到输入框和按钮在哪，模拟键盘输入和鼠标点击，再截图确认操作成没成功。
有了WebMCP，AI直接调用addTask({title: "买牛奶", priority: "high"})，网站返回成功或失败，完事。
WebMCP定义了三个角色：
网站：通过registerTool()把能力注册到Chrome
Chrome浏览器：维护每个标签页的工具注册表，当中间人
AI Agent：查注册表拿工具列表，选工具填参数，拿结果
核心概念：工具 = 函数 + 格式说明
在WebMCP里，一个工具由四部分组成：
name：工具名称，比如addTask，AI用它来选工具
description：描述工具做什么，AI理解语义用
inputSchema：JSON格式，定义参数类型和规则，AI照这个填参数
execute：实际执行的函数，Chrome在网站环境里调用
看一个完整的工具定义：
{
name: 'addTask',
description: 'Add a new task to the task list.',
inputSchema: {
type: 'object',
properties: {
title: { type: 'string', description: 'The title of the task' },
priority: { type: 'string', enum: ['low', 'medium', 'high'] }
},
required: ['title']
},
execute: async (params) => {
return TaskApp.addTask(params.title, params.priority);
}
}AI拿到的只有前三项（名称、描述、格式说明）。AI不能直接执行代码，它只能点菜，Chrome负责上菜。
技术链路怎么走
WebMCP的技术链路分四步：工具注册、工具发现、工具调用、结果返回。
第一步：页面加载，工具写入注册表
浏览器加载页面时，两件事同时发生：
JS方式：代码调用navigator.modelContext.registerTool()，这是Chrome Canary提供的浏览器原生API。每次调用，Chrome就把一个工具写入当前标签页的内存注册表。
HTML方式：浏览器解析HTML时，发现带toolname属性的表单，自动从表单字段推导出格式说明，也写入同一个注册表。
navigator.modelContext就是Chrome内置的工具注册表API。它不是第三方库，不是网络请求，是浏览器引擎本身提供的接口。
第二步：AI查询，拿到菜单
当AI Agent连接到当前标签页时，它通过Chrome的内部通道查询工具注册表。Chrome返回所有已注册工具的列表，包含名称、描述、格式说明。AI拿到的是一份结构化的菜单，不是像素，不是DOM树。
第三步：AI调用，Chrome路由执行
AI根据菜单选工具，填参数，比如addTask({title: "买牛奶", priority: "high"})。调用请求到Chrome后，Chrome在注册表里找到对应的execute()回调，在网页的JS环境里执行这个回调，函数返回值通过Chrome回传给AI。
整个过程中Chrome是中间人。网站把能力注册给Chrome，AI向Chrome查询和调用，Chrome负责路由和隔离。AI从未直接接触网页的DOM或JS代码。
两种注册方式
命令式：手写注册
开发者手写工具定义和执行逻辑：
await navigator.modelContext.registerTool({
name: 'addTask',
description: 'Add a new task to the task list.',
inputSchema: {
type: 'object',
properties: {
title: { type: 'string', description: 'The title of the task' },
priority: { type: 'string', enum: ['low', 'medium', 'high'] }
},
required: ['title']
},
execute: async (params) => {
return TaskApp.addTask(params.title, params.priority);
}
});声明式：HTML表单加属性
开发者只需给form加三个属性，浏览器自动从字段推导格式说明：
<form toolname="addTask"
tooldescription="Add a new task with title and priority"
toolautosubmit="true">
<input name="title" type="text" required />
<select name="priority">
<option value="low">低</option>
<option value="medium">中</option>
<option value="high">高</option>
</select>
</form>声明式路径下，还需要处理AI触发的表单提交，返回结构化结果：
form.addEventListener('submit', (e) => {
if (!e.agentInvoked) return;
e.preventDefault();
e.respondWith(resultPromise);
});真实调用例子
用Chrome官方的Travel Demo看下实际效果。AI收到一段自然语言：
"我需要订两个人的往返机票，从纽约到洛杉矶，2026年3月15日出发，3月22日返回。"
AI调用searchFlights工具，参数如下：
{
"destination": "LAX",
"outboundDate": "2026-03-15",
"inboundDate": "2026-03-22",
"tripType": "round-trip",
"origin": "NYC",
"passengers": 2
}从这条调用可以看出AI做了什么：
从自然语言里判断用户要搜航班，选searchFlights工具
把"New York"转成"NYC"，"Los Angeles"转成"LAX"（因为格式要求三字母机场代码）
把"March 15th, 2026"转成"2026-03-15"（符合日期格式）
用户没提舱位偏好，AI也不编造，只填有对应信息的字段
AI不是在图里猜按钮，它是在做自然语言到格式说明的映射。格式说明定义了每个字段的类型和规则，AI根据这些规则把模糊的人话翻译成精确的函数调用。
跟现在的方式比有什么不同
现在主流的浏览器自动化方案是Playwright。它从浏览器外部操控页面，通过CDP协议连接浏览器，模拟人的操作路径：打开浏览器加载页面，截图或读DOM，让大模型分析输入框在哪按钮叫什么，生成选择器模拟点击输入，再截图判断操作成不成功。
这条链路里，大模型至少被调用三次：规划操作、分析页面结构、判断执行结果。每一步都可能出错。UI一变，按钮改名或布局调整，整条链路就断了。
Playwright的假设是"你得阅读网页，然后自己想办法"。Playwright是AI假装是人，WebMCP是网站知道AI要来。
WebMCP链路里，大模型只需要一次决策：从工具列表里选一个，填参数。格式说明是确定的，不依赖页面长什么样。
目前的问题
WebMCP有一个绕不开的问题：需要网站开发者主动适配。
Playwright的成本在AI端，写选择器，处理各种UI边界情况。WebMCP把这个成本转移到了网站端，开发者需要定义格式说明，注册工具，处理respondWith()返回值。
换个角度看
WebMCP的核心成本是需要开发者手动写格式说明和注册工具。但如果代码本身就是AI写的呢？
现在AI辅助编程（Copilot、Cursor、Claude Code）越来越普及。WebMCP的适配可以变成自动化的事：
AI生成代码时自动注册工具：AI写完一个表单组件，顺手生成对应的registerTool()调用，就像现在AI写代码会自动加类型注解一样自然
从现有代码推导格式说明：AI分析已有的API接口和表单结构，自动生成WebMCP工具定义，存量网站的适配成本大幅降低
声明式路径有天然优势：给form加toolname这种HTML属性，对AI来说成本几乎为零
到那时候，WebMCP适配不再是额外的开发工作，而是代码生成的默认输出。网站就变成了自然支持人和AI共同用的状态。
本文内容仅供个人学习、研究或参考使用，不构成任何形式的决策建议、专业指导或法律依据。未经授权，禁止任何单位或个人以商业售卖、虚假宣传、侵权传播等非学习研究目的使用本文内容。如需分享或转载，请保留原文来源信息，不得篡改、删减内容或侵犯相关权益。感谢您的理解与支持！