OpenAI 已经用上 WebMCP：Browser Agent 要变天了
以后 AI 操作网站，真正的进化可能不是“更会点按钮”，而是根本不用点按钮。
以前让 Browser Agent 帮你订一个预约，它可能要：
看网页 → 找日期 → 找时间 → 找输入框 → 填姓名 → 填邮箱 → 找提交按钮。
中间任何一个 DOM、按钮位置或页面状态发生变化，都可能让 Agent 重新判断。
WebMCP 想改变的，就是这一层。
网站可以直接告诉 AI：
“别猜我的页面怎么操作，我把能做什么、需要什么参数，直接告诉你。”
比如：
bookSlot ├─ date ├─ time ├─ name └─ email
AI 不再先研究“预约按钮在哪里”。
而是直接发现：
这个网站有一个 bookSlot 工具。
生成参数。
调用工具。
网页自己执行。
这不是让 AI 更像人一样使用网页，而是让网页开始为 AI 提供另一套操作接口。
01｜先纠正一个很重要的信息
最近看到不少内容把 WebMCP 写成：
OpenAI 发布全新 WebMCP 协议。
这个说法不准确。
WebMCP 目前是在 W3C Web Machine Learning Community Group 中推进的提案。
当前规范状态仍然是：
CG-DRAFT。
最初公开版本发布于 2025 年 8 月 13 日，早期贡献者来自 Microsoft 和 Google；目前规范编辑包括 Microsoft 的 Brandon Walderman，以及 Google 的 Khushal Sagar、Dominic Farolino。
所以更准确的说法是：
WebMCP 是一个正在推进中的 Web 标准提案，OpenAI 现在已经开始支持它。
而且 OpenAI 官方已经明确确认：
ChatGPT Desktop 的 Site tools 使用的就是 WebMCP。
这才是最近真正值得关注的变化。
02｜WebMCP 到底解决什么？看一个预约网站就明白了
传统 Browser Agent 面对网页时，经常需要通过：
截图；
DOM；
Accessibility Tree；
网页结构；
来判断页面上有什么。
然后模拟：
点击；
输入；
滚动；
提交。
WebMCP 官方规范也明确把这种传统方式列为现有 Browser Agent 常见的操作方法。
问题在于：
网页 UI 原本是设计给人看的，不是设计给模型调用的。
假设页面有：
日期：[] 时间：[] 姓名：[] 邮箱：[] [立即预约]
AI 得自己理解：
哪个是日期；
哪个是时间；
哪个按钮负责提交。
WebMCP 换了一种方式。
网站直接注册：
document.modelContext.registerTool({ name: “bookSlot”, description: “Reserve a consultation slot”, inputSchema: { type: “object”, properties: { date: { type: “string” }, time: { type: “string” }, name: { type: “string” }, email: { type: “string” } } }, execute: async (input) => { return await
(input); } });
这个模式就是 Chrome 当前官方 WebMCP Imperative API 的核心写法：网站通过 document.modelContext.registerTool() 注册工具，并给出名称、描述、参数 Schema 和执行函数。
于是 Agent 看到的就不再只是一个页面。
而是一份类似：
Tool：bookSlot 参数： date time name email
的能力说明书。
网页第一次开始主动告诉 Agent：“我能做什么，以及你该怎么调用我。”
03｜这和普通 MCP 有什么不同？
很多人看到 WebMCP，第一反应可能是：
MCP 都还没学完，怎么又来一个？
其实不需要把它想复杂。
传统 MCP 更常见的是：
ChatGPT / Claude ↓ MCP Server ↓ 数据库 / SaaS / API
Agent 和后端服务直接通信。
而 WebMCP 更强调：
AI Agent ↓ Browser ↓ 当前正在打开的网页 ↓ 网页提供的 WebMCP Tools
它可以直接利用当前页面：
登录状态；
页面状态；
当前操作上下文；
已有前端逻辑。
WebMCP 官方 Explainer 甚至直接把这种模式描述成一种客户端替代方案：开发者可以直接把页面里的 JavaScript 能力暴露为 Tool，而不一定为了 Agent 再额外搭一套后端服务器。
所以你可以简单理解：
MCP 更偏“Agent 连服务”。
WebMCP 更偏“Agent 操作眼前这个网页”。
04｜OpenAI 现在已经怎么用了？
这里才是普通用户真正能碰到的部分。
OpenAI 最新的 ChatGPT Desktop 里有一个功能叫：
Site tools
OpenAI 官方已经明确写明：
Site tools 使用 WebMCP。
如果你打开一个支持 WebMCP 的网页，
ChatGPT 可以直接发现这个网页暴露出来的工具。
比如：
搜索文档；
修改文档；
操作白板；
查询 Dashboard；
规划旅行；
更新购物车。
这些都是 OpenAI 官方目前列出的 Site tools 使用场景。
而不是每一次都：
“找一下页面上的按钮在哪里。”
05｜怎么体验？照着做就行
这里有一个很容易搞错的地方。
不要打开 Chrome Extension 找 WebMCP。
截至目前，OpenAI 官方明确说明：
Site tools 只在 ChatGPT Desktop 的内建 Browser 中可用，目前不在 Chrome 中使用。
所以正确路径是：
第一步：打开 ChatGPT Desktop
进入 ChatGPT 桌面客户端。
第二步：打开 ChatGPT 自带 Browser
不是：
Chrome。
不是：
。
而是 ChatGPT Desktop 自己的 built-in browser。
第三步：进入支持 WebMCP 的网站
如果网页暴露了 Site tools，
地址栏会出现一个箭头图标。
灰色：
代表当前页面存在 Site tools。
蓝色：
代表 ChatGPT 正在调用。
点击以后，你还能看到：
这个网页有哪些 Tool；
哪些只能读取；
哪些会修改内容。
这是 OpenAI 当前官方提供的使用流程。
第四步：直接说人话
例如：
找出这个文档里关于 Authentication 的内容，并整理核心步骤。
或者：
把这个白板里的任务按照优先级重新整理。
或者：
比较页面里的三个旅行方案，只整理价格、时间和优缺点。
如果当前网页存在匹配工具，
ChatGPT 可以自动发现并调用。
第五步：检查它到底调用了什么
任务执行后，
再次点击地址栏的 Site tools 图标。
进入：
Recently used
你可以查看刚刚调用过哪些 Tool。
这一步很重要。
不要只看“AI 最后回答了什么”，还要学会看“Agent 实际调用了什么”。
06｜注意：它不会直接继承你 Chrome 的登录状态
这一点也很容易被误解。
ChatGPT Desktop 的 built-in browser 有自己独立的浏览状态。
所以：
你已经登录 Chrome：
Google Notion 某个 SaaS
并不代表 ChatGPT built-in browser 已经登录。
OpenAI 官方明确提醒：
如果你在 Chrome 已经登录某网站，在内建 Browser 里仍可能需要重新登录。
所以：
Chrome Extension
和：
Site tools / WebMCP
一定不要混在一起。
前者主要解决：
复用你现实中的 Chrome 环境。
后者解决：
网站直接向 Agent 暴露结构化能力。
这是两个不同层级的问题。
07｜如果你是开发者，10 分钟就能看懂 WebMCP
如果你会一点 HTML，
甚至不用先学 registerTool()。
WebMCP 现在提供两套 API：
Imperative API
以及：
Declarative API。
最适合新手的是第二种。
假设你本来就有这样一个客服表单：
以前 Agent 只能把它当：
“网页上的一个表单。”
现在加入两个属性：
最关键就是：
toolname tooldescription
浏览器就可以把这个 Form 转成结构化 Tool。
Chrome 官方 Declarative API 当前就是这么设计的。
甚至字段还可以加入：
toolparamdescription
告诉 Agent：
这个字段到底意味着什么。
这才是我认为 WebMCP 最值得开发者关注的地方。
你不一定要：
开发 MCP Server；
搭 Node 服务；
写一整套 API；
才能让 Agent 理解网页能力。
已有 Form 本身就可能直接升级。
08｜提交按钮继续保留给人
这个设计我很喜欢。
默认情况下，
Agent 调用 Declarative Tool 后可以：
帮你找到表单；
填写字段；
然后：
停在 Submit。
由人自己点击。
Chrome 官方文档明确提供了这种模式。
如果开发者明确希望自动提交，
才可以加入：
toolautosubmit
例如：
