5月13日的 Android Show 上,Google 把 Chrome auto browse(自动浏览)扩展到 Android 版,这项功能 1 月 28 日已在桌面端美国区向 Google AI Pro($19.99/月,20 任务/天)和 Ultra($249.99/月,200 任务/天)订阅用户预览,由 Gemini 3 驱动,可以完成预订、购物、填表等多步骤网页任务。但在 auto browse 全面铺开之前,业界已经有两条成熟的"让 AI Agent 操作浏览器"的技术路径:Google 与 Microsoft 共同推动、2026 年 2 月在 Chrome 146 Canary 上线的 W3C 新标准 WebMCP,以及自 2013 年起就驱动 Puppeteer、Playwright 等所有浏览器自动化工具的底层协议 Chrome DevTools Protocol(CDP)。本文从执行位置、网站合作要求、Token 效率、可靠性、适用场景等维度,逐项拆解这三条路径的真实差异。 三条路径的本质区别:从外部控制到协议层暴露
要理解 Chrome auto browse、WebMCP、CDP 的差异,最直接的视角是看"AI 与浏览器以及网站之间是怎么通信的"。
CDP是 Chromium 浏览器原生的远程调试协议,通过 WebSocket 暴露在 9222 端口,允许外部进程发送命令操作浏览器(点击、滚动、执行 JavaScript、读取 DOM、抓截图)。Playwright 与 Puppeteer 都是 CDP 之上的高级封装。在 AI Agent 场景下,CDP 是"AI 从外部驾驶浏览器",浏览器与网站本身完全不知道有 AI 在操作,所有理解都靠 Agent 自己看截图、解析 DOM、推断按钮位置。
WebMCP走的是完全不同的路径——它让网站主动告诉 AI Agent 自己能做什么。网站通过 navigator.modelContext API 注册结构化工具(如"预订酒店",参数:日期、人数、价格区间),浏览器把这些工具暴露给 Agent。Agent 不再需要猜界面,直接调用工具即可。本质上是把 Anthropic 的 MCP 协议精神搬进浏览器,但实现完全 client-side,与 MCP 的后端 JSON-RPC 服务器互补。
Chrome auto browse则是 Google 把上述两种思路 + 自家 Gemini 3 模型 + 浏览器深度集成做成的封闭产品。auto browse 跑在 Chrome 内部,可以读取页面内容(发送到 Google 云端处理)、自动填表、自动登录(经用户授权调用 Password Manager)、自动结账(在敏感动作前暂停确认),并支持 Google 与 Shopify、Etsy、Wayfair、Target 共同制定的 Universal Commerce Protocol(UCP)作为电商动作的开放标准。
简而言之:CDP 是"AI 从外部硬控浏览器",WebMCP 是"网站主动暴露能力给 AI",Chrome auto browse 是"Google 把浏览器 + Gemini + UCP 打包成消费级产品"。
CDP:浏览器自动化的事实标准,但 Token 开销巨大
CDP 起源于 2013-2014 年 Blink 从 WebKit 分叉时,最初为 Chrome DevTools 服务,后来逐步成为浏览器自动化的事实标准。它的优势在于无视网站合作——任何网页都可以被 Agent 操作,因为 CDP 直接在浏览器进程层面工作,绕开网站的所有意图。
但在 AI Agent 场景下,CDP 有几个明显代价。一是 Token 开销巨大。Chrome DevTools 官方 MCP server 提供 29 个工具,光是工具描述就要占用约 17,000 token,Playwright MCP 约 13,700 token。这意味着 200K 上下文窗口在 Agent 启动时就已经被吃掉 9%。
二是速度不快。每一次 click、navigate 都要经过 WebSocket 往返 + DOM 重新解析 + Agent 推理,Playwright 之上的 AI 工具 Browser-Use 在 2025 年决定从 Playwright 切到原始 CDP,就是因为 Playwright 引入的 Node.js 中转层带来了显著延迟。
三是可靠性问题。CDP 暴露的是底层 DOM 与坐标信息,Agent 需要靠视觉模型 + accessibility tree 把界面"看懂",一旦页面用了非标 ARIA 属性、自定义组件、Canvas 渲染或反爬虫机制,Agent 就容易卡壳。
CDP 目前仍是构建自己 Agent 框架的主流选择:Browser-Use(78,000 GitHub stars)、Vercel 的 agent-browser、Cloudflare Browser Run、Browserbase、Stagehand 等都基于 CDP。Chrome 146 还将加入"AI agent access via MCP"的原生设置开关,把 CDP + MCP 的组合做成系统级能力。
WebMCP:让网站主动声明能力,W3C 正式标准
WebMCP 是 Google 与 Microsoft 工程师联合提交、由 W3C Web Machine Learning 社区组孵化的浏览器标准,2026 年 2 月在 Chrome 146 Canary 中以早期预览形式上线,Microsoft Edge 已纳入路线图,Safari 据报道也在 W3C 社区组中参与。
WebMCP 的核心机制是 navigator.modelContext API。网站通过这个 API 向浏览器注册可调用工具,每个工具有明确的输入 schema、参数定义、返回值定义,以及安全边界。Agent 进入页面后,可以列出工具(listTools()),直接调用,而不需要理解 DOM 或截图。
WebMCP 与 Anthropic 的 MCP 是"同名不同物"——MCP 走 JSON-RPC,部署在后端服务器,跨平台连接 AI 与服务;WebMCP 走 client-side,完全在浏览器内执行,共享用户已有会话(已登录、已填好的购物车、已授权的 OAuth 都直接复用)。一个电商网站可以同时维护后端 MCP 服务器(给 ChatGPT、Claude 等平台调用)和前端 WebMCP 工具(给浏览器内 Agent 调用),两者互补。 WebMCP 的优势是确定性。AI 不再用视觉猜界面,而是调用网站显式声明的工具,这意味着 token 消耗低、执行速度快、跨页面变化稳定。劣势是需要网站主动适配——任何没有部署 WebMCP 的网站都退回到 DOM 解析模式。
Chrome auto browse:Google 把 Gemini 3 + UCP + 浏览器深度集成做成消费产品
Chrome auto browse 是上述两条路径的"消费级产品化"形态。它在桌面端 1 月 28 日发布,基于 Gemini 3 模型,通过 Chrome 侧边栏的 Gemini 入口启动,可以完成多步骤任务:研究航班 → 比较酒店 → 预订餐厅 → 填表 → 在支付步骤暂停等用户确认。
技术实现上,auto browse 是一套混合栈。一方面它在 Chrome 内部直接访问页面内容(包括跨标签上下文,Gemini 可以理解多个打开的 Tab 作为同一 context 组),另一方面它会把页面内容发送到 Google 云端处理(根据 Ars Technica 的技术分析,所有页面内容会被上传到 Google 服务器,而非端侧推理),并临时记录到用户的 Google 账号 Activity 中。Google 没有明确说明这些数据是否会被用于未来模型训练。
auto browse 与 WebMCP/CDP 最大的差异是"非开发者也能用"。CDP 与 WebMCP 都是给开发者的协议,前者需要写 Agent 框架,后者需要网站接入。auto browse 是直接面向消费者的预订与购物 Agent,用户在侧边栏输入"帮我订 6 月 15 日去东京的航班,价格 800 美元以内,选直飞",Gemini 就会自己开标签、查 Google Flights、对比方案、生成 shortlist,在最终预订前停下等确认。
Google 同时推动的 UCP(Universal Commerce Protocol)是 auto browse 与电商网站的对接标准,与 Shopify、Etsy、Wayfair、Target 共同制定,定位接近"电商版 WebMCP"——网站声明商品数据与结账接口,AI Agent 通过 UCP 直接调用,而非反向解析购物车页面。auto browse + UCP 的组合实际上是 Google 在电商领域复现 WebMCP 模式的尝试。
9 维度横向对比:执行位置、Token 效率、可靠性、适用场景
把三条路径放在 9 个维度上对比,差异可以看得更清楚。
执行位置:auto browse 推理在 Google 云端 + 浏览器集成执行;WebMCP 完全在浏览器进程内、网站 JavaScript 中执行;CDP 推理在外部 Agent 进程、操作在浏览器进程层。
是否需要网站合作:auto browse 不强制(但 UCP 兼容站点体验更好);WebMCP 强制(网站不接入则无工具可调);CDP 不需要。
Token 效率:WebMCP 最高(直接调用结构化工具,典型页面 200-400 token);auto browse 次之(由 Google 内部优化,具体不公开);CDP 最低(Chrome DevTools MCP 约 17,000 token 仅工具定义)。
可靠性:WebMCP 确定性最强(工具契约不会随 DOM 变化失效);auto browse 中等(Gemini 3 + 安全防护 + 用户确认机制);CDP 最低(依赖 Agent 的视觉与 DOM 理解能力)。
会话共享:WebMCP 与 auto browse 都直接复用用户已有 Chrome 会话;CDP 默认隔离(Playwright MCP 创建新 context),需要通过 --cdp 等参数显式复用。
开放程度:CDP 与 WebMCP 都是开放协议,任何 Chromium 浏览器均可使用;auto browse 是 Google 闭源产品,目前仅 Chrome + 美国 + 付费订阅。
安全模型:auto browse 内置敏感动作暂停 + 确认机制(支付、登录、社交发布)、Google Password Manager 显式授权、prompt injection 防护;WebMCP 由浏览器仲裁工具调用权限,网站可声明安全边界;CDP 完全靠 Agent 自身设计,prompt injection 风险最高。
典型用户:CDP 适合开发者构建自己的 Agent 或测试自动化框架;WebMCP 适合网站方主动接入 AI 生态以获得 Agent 流量;auto browse 适合消费者完成日常多步任务。
演进方向:三者实际上在融合。Chrome 146 把 CDP + MCP 做成系统开关,auto browse 未来很可能优先调用 WebMCP 工具(若网站已注册),WebMCP 自身也在被纳入到 Cloudflare Browser Run、Vercel agent-browser 等基础设施。
选型建议:开发者、网站方、消费用户的三条路
对开发者:如果要构建自己的 AI Agent 框架(尤其涉及测试自动化、内部工具控制、跨网站抓取),CDP 仍是当前最完整的方案,Browser-Use、agent-browser、Stagehand 等开源工具都基于 CDP。需要兼顾 Token 效率和稳定性时,可以考虑接入 WebMCP 作为补充——目标站点支持 WebMCP 时优先调用工具,不支持时退回 DOM/视觉模式。
对网站方:WebMCP 是必选项。当 Chrome 146+ 推开 navigator.modelContext API,以及 Edge、Safari 跟进后,AI Agent 通过浏览器访问网站将成为流量入口,WebMCP 兼容性会直接决定网站是否"被 Agent 选中"。电商网站还应额外接入 UCP,作为 auto browse 与未来 Gemini 系 Agent 的对接通道。
对消费用户:在 auto browse 当前仅限美国 + Pro/Ultra 订阅的状态下,海外用户更可行的方案是 OpenAI Atlas、Perplexity Comet、The Browser Company Dia 等 AI 原生浏览器,或在通用浏览器内通过 Anthropic Claude in Chrome、Cowork 等扩展实现类似能力。Chrome auto browse 的全球扩展和价格策略将是 2026 下半年浏览器 Agent 竞争最值得跟踪的变量。 局限与待观察的问题
三条路径都有未解决的关键问题。CDP 的 Token 开销与 prompt injection 风险长期被 Agent 框架社区诟病,Chrome 146 即将上线的"MCP 系统开关"如何在安全性与开放性之间取舍尚未公布。WebMCP 作为 W3C 早期标准,接入网站数量仍少,Apple 尚未正式表态,生态规模能否在 2026 内成型是关键。Chrome auto browse 的数据隐私边界(页面内容是否用于训练)、跨国合规(欧盟 DMA 7 月裁定可能强制开放 Gemini 等价访问)、可靠性(浏览器 Agent 在动态页面、CAPTCHA、反爬虫场景下的真实成功率)都还没有公开的稳定数据。
从产业脉络看,2026 年浏览器 Agent 的格局正在从"单点工具"演化为"协议层 + 模型层 + 产品层"的三层分工——CDP 与 WebMCP 是协议层,Gemini 3、Claude、GPT 是模型层,Chrome auto browse、Atlas、Comet 是产品层。三层之间的标准化与互操作性,将决定下一代 Web 是被某家厂商垄断,还是真正成为 AI Agent 可访问的开放基础设施。