一个让 AI 从"看网页"进化到"调网页"的范式革命
引言：一个让所有人兴奋，但工程师头疼的方向
2025 年以来，Browser Use 彻底火了。
你只需要对 AI 说一句"帮我上携程订一张明天去上海的机票"，然后就能看着 AI 像真人一样打开浏览器、搜索、选择、填表、点击支付——整个过程行云流水，仿佛科幻电影照进现实。
GitHub 上 Browser Use 的 Star 数一路狂飙，无数创业者高呼"RPA 已死，Agent 时代来临"。
但如果你是一个真正在生产环境跑过 Browser Use 的工程师，你大概率经历过以下噩梦：
目标网站改了一个 CSS 类名，你的 Agent 集体瘫痪； 一个"点击提交按钮"的动作，Agent 要截 3 张图、推理 2 次、等待 5 秒； 一个简单的表单填写任务，Token 消耗高达数十万，成本比雇人还贵； 网页弹出一个你没预料到的广告弹窗，Agent 彻底迷路……
于是，一个灵魂拷问浮出水面：既然 Browser Use 这么脆弱、这么慢、这么贵，为什么我们还需要它？以及，有没有一种更好的方式？
答案就是今天的主角——WebMCP。
一、先搞清楚：Browser Use 到底在干什么？
Browser Use 的核心思路，用一句话概括就是：让 AI 假装自己是人，去"看"网页、"点"网页。
它的工作循环（ReAct Loop）是这样的：
# Browser Use 典型代码示例（简化版）from browser_use import Agentfrom langchain_openai import ChatOpenAIagent = Agent(task="去携程搜索明天北京到上海的航班，选最便宜的",llm=ChatOpenAI(model="gpt-4o"),)result = await agent.run()
看起来非常优雅，对吧？但底层发生的事情是：
- 截取当前页面的完整 DOM 树（或者截图）；
- 将 DOM/截图发送给大模型
，让它理解页面结构； - 模型推理后输出动作
：“点击第 37 个 <button>元素"或"在坐标 (542, 318) 处点击”； - 通过 Playwright 执行动作
，等待页面响应； - 重复以上步骤
，直到任务完成。
本质上，Agent 是在"猜"网页的结构，然后模拟人类的鼠标键盘操作。
二、Browser Use 的三宗罪
理解了原理，我们再来看它在生产环境中的致命问题：
🔴 罪状一：极度脆弱（Fragile）
网页的 DOM 结构是视觉展示层，它天然就是多变的。前端工程师改个组件库、加个弹窗、调整个布局，都会让 Agent 的"认知"瞬间失效。
“我们花了 3 天调好了一个爬取流程，结果第二天目标网站升级了前端框架，全挂了。” ——某创业公司 CTO
🔴 罪状二：慢到令人发指（Slow）
每一次操作都需要：截图/获取DOM → 发送多模态大模型 → 等待推理 → 执行动作。一个 5 步的表单填写任务，可能需要 30-60 秒。
🔴 罪状三：Token 消耗巨大（Expensive）
一个中等复杂度的网页，DOM 树可能有数万 Token。Agent 每走一步都要重新"看"一遍整个页面。一个简单任务下来，轻松消耗 50万-100万 Token。
所以，Browser Use 不是不好，而是它解决的问题太"重"了。它在用一把瑞士军刀去切牛排——能用，但费劲。
三、WebMCP：换一种思路，让网页"自报家门"
2025 年下半年，Google/Chrome 团队提出了一个名为 WebMCP（Web Model Context Protocol） 的 Web 标准提案。
它的核心理念只有一句话：
不要让 Agent 去"猜"网页能干什么，让网页主动告诉 Agent “我能干什么”。
WebMCP 是什么？
WebMCP 是一项 Web 标准提案，它允许网页开发者通过 JavaScript API 或 HTML 表单注解，将网页的功能声明为结构化的工具（Tools），直接暴露给 AI Agent 调用。
网页不再是一堆需要被"阅读"的 HTML 标签，而是变成了一个自带说明书的"能力集合"。
四、代码说话：WebMCP 长什么样？
4.1 网页端：暴露工具（开发者视角）
假设你有一个电商网站，你想让 AI Agent 能帮用户操作购物车。使用 WebMCP，你只需要在网页中加入如下代码：
// 网页端：通过 WebMCP 暴露结构化工具// 挂载入口：document.modelContext（Chrome 149+ Origin Trial）document.modelContext = {name: "MyShop-Cart",description: "电商购物车操作工具集",tools: [{name: "addToCart",description: "将商品加入购物车",inputSchema: {type: "object",properties: {productId: { type: "string", description: "商品ID" },quantity: { type: "number", description: "数量", default: 1 },},required: ["productId"],},handler: async ({ productId, quantity }) => {// 这里直接调用你网站原有的业务逻辑const result = await api.post("/cart/add", { productId, quantity });// 网页内部自动更新界面（React/Vue 状态更新）updateCartUI(result);return { status: "success", message: `已加入 ${quantity} 件商品` };},},{name: "removeFromCart",description: "从购物车移除商品",inputSchema: {type: "object",properties: {productId: { type: "string", description: "商品ID" },},required: ["productId"],},handler: async ({ productId }) => {await api.post("/cart/remove", { productId });updateCartUI();return { status: "success" };},},{name: "getCartItems",description: "获取当前购物车所有商品",inputSchema: { type: "object", properties: {} },handler: async () => {const items = await api.get("/cart/list");return { items };},},],};
就这么简单。 你不需要改变任何现有的前端架构，只需要额外声明一份"工具清单"。
4.2 HTML 表单也能直接变成工具
如果你懒得写 JS，WebMCP 还支持直接注解 HTML 表单：
<!-- 传统 HTML 表单，加上 WebMCP 注解 --><form data-tool="searchFlights" data-tool-description="搜索航班信息"><input name="departure" type="text" placeholder="出发城市" /><input name="destination" type="text" placeholder="目的城市" /><input name="date" type="date" /><button type="submit">搜索</button></form>
浏览器会自动将这个表单解析为一个可调用的工具，Agent 直接传入参数即可。
4.3 Agent 端：调用工具（对比 Browser Use）
现在，让我们看看 Agent 调用这个网页时，代码有多简洁：
# WebMCP 模式下的 Agent 调用（伪代码）# Agent 不再需要截图、解析DOM、模拟点击# 1. 发现当前网页暴露的工具tools = await webmcp_client.list_tools(current_tab)# 返回：["addToCart", "removeFromCart", "getCartItems"]# 2. 直接调用工具，传入结构化参数result = await webmcp_client.call_tool(tool_name="addToCart",arguments={"productId": "SKU_12345", "quantity": 2})# 返回：{"status": "success", "message": "已加入 2 件商品"}# 搞定。没有截图，没有DOM解析，没有坐标点击。
对比 Browser Use 的调用方式：
# Browser Use 模式（对比）# Agent 需要：# 1. 截取整个页面截图 → 发送给多模态模型# 2. 模型识别出"加入购物车"按钮的位置# 3. 输出指令："在坐标 (847, 523) 处点击"# 4. Playwright 执行点击# 5. 等待页面响应，再次截图确认结果# 每一步都充满不确定性
五、灵魂拷问：Agent 到底在哪里？
这是很多人第一次接触 WebMCP 时最困惑的问题。
答案是：Agent 运行在网页之外。
| Agent（大脑） | |||
| WebMCP（桥梁） | |||
| 网页 UI（脸面） |
很多人会问：“WebMCP 为什么要让 Agent 更新界面？”
真相是：Agent 根本没有去更新界面。
真实流程是：
外部 Agent 调用网页暴露的 removeFromCart工具；网页内部的 handler函数执行，调用后端 API 删除数据；网页内部的前端框架（React/Vue）检测到状态变化，网页自己重新渲染了界面； 网页把 "status": "success"返回给外部 Agent；Agent 告诉用户：“已帮您删除。”
Agent 只是下达了一个"调用工具"的指令，界面更新是网页自己的事。
六、那 WebMCP 需要打开网页吗？
需要。这是绝对前提。
因为 WebMCP 是一个运行时标准——网页的 JavaScript 必须被执行，工具才会被注册到浏览器上下文中。没有浏览器环境去跑这段代码，工具就不存在。
但"打开网页"有两种形态：
| 前台打开 | ||
| 无头浏览器（Headless） |
⚠️ 注意：不是普通的 Chrome 后台 Tab！ Chrome 会对后台 Tab 进行性能节流（Throttling），导致 JS 执行变慢甚至挂起，WebMCP 工具无法正常注册。真正的自动化使用的是 Headless Browser。
七、终极对比：一张表看清两种范式
| 核心隐喻 | ||
| 操作对象 | ||
| 网页的角色 | ||
| Agent 的角色 | ||
| 界面更新 | ||
| 单次操作耗时 | ||
| Token 消耗 | ||
| 稳定性 | ||
| 需要网页配合？ | ||
| 适用场景 |
八、那 Browser Use 是不是要死了？
绝对不是。
Browser Use 和 WebMCP 不是替代关系，而是互补关系。它们解决的是不同层面的问题：
🟢 Browser Use 的不可替代场景：
目标网站没有任何 API，也没有适配 WebMCP； 需要操作第三方网站（你无法让别人改代码）； 任务涉及视觉判断（如"找到页面上那张红色的图片"）； 需要跨多个独立网站完成复杂流程。
🔵 WebMCP 的碾压级优势场景：
你在开发自己的产品，想让它支持 AI； 任务需要高可靠性（不能因为前端改版就挂）； 任务需要低延迟（毫秒级响应）； 任务需要低成本（不想每次操作都烧几十万 Token）； 需要细粒度权限控制（只暴露特定操作给 Agent）。
🔮 未来的终极形态：
能用 WebMCP 解决的，绝不用 Browser Use；Browser Use 兜底那些还没有适配 WebMCP 的存量网站。
就像 HTTP API 出现后，我们不再用爬虫去解析 HTML 获取数据；但当面对一个没有 API 的旧系统时，爬虫依然是唯一的解决方案。
九、给开发者的行动建议
如果你是一个 Web 开发者，现在应该做什么？
1. 如果你有自己的产品
可以开始了解 WebMCP，在你的核心页面添加 document.modelContext 工具声明。这就像当年给网站加 robots.txt 一样——谁先适配，谁就先被 AI 时代的流量红利覆盖。
2. 如果你在做 AI Agent 产品
优先对接支持 WebMCP 的网站（通过标准协议调用），对于不支持的网站，再降级使用 Browser Use 作为兜底方案。
3. 如果你在做企业自动化
评估你的目标系统。如果是内部系统，直接推动适配 WebMCP；如果是外部第三方系统，短期内仍然需要 Browser Use。
结语
Browser Use 的火爆，证明了人类对"让 AI 替我操作电脑"这件事有着巨大的渴望。
但热情不能替代工程理性。用模拟鼠标点击的方式去调用一个明明可以用函数调用的功能，就像用飞鸽传书去发一条微信——能用，但何必呢？
WebMCP 的本质，是让 Web 从"给人看的界面"进化为"给人和 AI 共同使用的能力平台"。
网页不再只是被观看的对象，它开始主动对话。
而这，才是 AI 与 Web 真正融合的起点。
参考链接：
- Chrome WebMCP 官方文档：developer.chrome.com/docs/ai/webmcp
- WebMCP GitHub 仓库：github.com/webmachinelearning/webmcp
- MCP 协议官网：modelcontextprotocol.io
💬 你觉得 WebMCP 会取代 Browser Use 吗？还是两者会长期共存？欢迎在评论区聊聊你的看法。