让 AI Agent 操作浏览器，看起来像一个简单需求：打开网页、点击按钮、读取内容、检查报错。但一旦要把它用于真实工程，问题会马上出现：

  • 我是在控制 Chrome，还是在做跨浏览器测试？
  • 为什么有的工具要求启动远程调试端口，有的却要求 WebDriver？
  • CDP、WebDriver BiDi、Playwright 和 MCP 到底是替代关系还是分层关系？
  • Agent 能操作日常登录的 Chrome 时，安全边界在哪里？

这些概念经常被放在同一层比较，因而造成很多不必要的选型争论。本文给出一个面向工程实践的框架：先分层，再选协议，最后才选 MCP Server。

先给结论

CDP、WebDriver BiDi 和 MCP 不在同一层，因此不是互斥的浏览器自动化产品：

  • CDP（Chrome DevTools Protocol）：Chrome/Chromium 的调试与自动化协议，适合深入检查页面、网络、性能和浏览器内部状态。
  • WebDriver BiDi：W3C 定义的双向浏览器自动化协议，目标是让跨浏览器自动化能获得实时事件能力。
  • MCP（Model Context Protocol）：让 AI Agent 调用外部能力的工具接口协议。一个浏览器 MCP Server 可以在内部使用 CDP、Playwright 或其他实现。

如果你要调试当前 Chrome 的 Console、Network、性能问题，优先考虑 CDP 或 Chrome DevTools MCP；如果你要让 Agent 稳定完成页面交互和回归验证，优先考虑 Playwright MCP；如果你关心跨浏览器自动化的长期标准化方向，则持续关注 WebDriver BiDi。

先分清三层：浏览器能力、自动化协议与 AI 工具接口

把这些东西放在一张图里，关系会清楚很多：

AI Agent
  │ 调用结构化工具
  ▼
MCP Client
  │ stdio / HTTP
  ▼
Chrome DevTools MCP 或 Playwright MCP
  │ CDP / Playwright
  ▼
Chrome / Chromium

WebDriver Client
  │ WebSocket
  ▼
WebDriver BiDi
  │
  ▼
Browser 或 Browser Driver

最容易混淆的地方在于：MCP 描述的是 Agent 如何发现并调用工具；CDP 与 BiDi 描述的是工具如何和浏览器通信。

因此，“我已经装了 Chrome DevTools MCP，还需要了解 BiDi 吗？”并不等于“二选一”。前者解决 Agent 接入，后者解决浏览器自动化协议的可移植性和事件模型。一个 MCP Server 完全可以在未来增加 BiDi 支持，或者把不同协议封装成不同工具。

CDP：最贴近 Chrome 的调试与控制能力

Chrome DevTools Protocol 是 Chrome DevTools、Puppeteer 和大量 Chromium 自动化工具背后的协议。通常，Chrome 启动后会提供 HTTP 发现端点和 WebSocket 连接，客户端通过 JSON 命令与事件和浏览器通信。

CDP 以 Domain 组织能力。几个最常用的 Domain 包括：

Domain 常见用途
Page 导航、生命周期、截图、打印 PDF
Runtime 执行 JavaScript、读取 Console、处理对象引用
DOM / CSS 检查节点、样式与布局
Network 观察请求、响应、缓存与失败原因
Debugger 断点、调用栈、脚本调试
Performance / Tracing 性能指标、时间线、性能分析
Emulation 视口、设备像素比、网络和设备条件模拟
Target 标签页、iframe、worker 等调试目标管理

它的基本消息模型并不复杂。客户端发送带 id 的命令，浏览器返回同一 id 的结果；浏览器生命周期、网络请求、Console 输出等则作为事件主动推送：

{
  "id": 1,
  "method": "Runtime.evaluate",
  "params": {
    "expression": "document.title"
  }
}

{
  "method": "Network.requestWillBeSent",
  "params": {
    "requestId": "request-id",
    "request": {
      "url": "https://example.com/api"
    }
  }
}

CDP 的优势在哪里

CDP 的优势是它离 Chrome 很近。你可以检查页面为什么白屏、某个接口为什么失败、首屏为什么慢、Service Worker 是否接管请求、某个 iframe 或 worker 是否存在。对前端排障而言，这类信息通常比“点击是否成功”更重要。

这也是 Chrome DevTools MCP 的价值：它把 DevTools 中原本需要人工点击、筛选和阅读的信息，变成 Agent 可以按需调用的结构化工具。面对“这个页面为什么没有渲染”“这个请求为什么是 401”“这个交互造成了什么 Layout Shift”之类的问题，CDP 是自然的底层选择。

CDP 的边界

CDP 不是跨浏览器标准。Firefox、Safari 对 CDP 的支持范围与 Chrome 不同，或者根本不以 CDP 作为主要自动化接口。其次，CDP 的能力很强，强到不适合被默认暴露给不受信任的本地进程或远程网络。

在工程上，把 CDP 当成“Chrome 深度诊断和控制通道”是合理的；把它当成唯一的跨浏览器测试抽象，则会让测试体系逐渐绑定 Chromium。

WebDriver BiDi：面向跨浏览器的双向自动化协议

传统 WebDriver 的核心模型是 HTTP 请求与响应：客户端执行“导航”“查找元素”“点击”等命令，驱动返回结果。这种模型适合基础自动化，但浏览器发生网络请求、Console 报错、页面导航或弹窗时，客户端很难实时获得统一事件流。

WebDriver BiDi 中的 BiDi 是 Bidirectional。它通过 WebSocket 让客户端和浏览器实现双向、事件驱动通信：客户端继续发送命令，浏览器也可持续推送事件。当前规范仍是 W3C Working Draft，模块与浏览器实现支持度会继续演进，因此实际项目仍应按目标浏览器和框架版本验证。W3C WebDriver BiDi 规范

一个典型的 BiDi 订阅会话类似这样：

{
  "id": 1,
  "method": "session.subscribe",
  "params": {
    "events": [
      "log.entryAdded",
      "network.beforeRequestSent",
      "network.responseCompleted"
    ]
  }
}

随后，浏览器会通过同一 WebSocket 主动发送匹配的事件。它把“等待某种状态发生”和“轮询浏览器状态”转变为协议级的订阅机制。

BiDi 中值得关注的模块

  • browsingContext：创建与管理标签页、窗口、iframe，导航、截图、处理页面生命周期。
  • script：在指定浏览上下文或 sandbox 中求值、调用函数、注册 preload script。
  • network：订阅请求与响应事件，配置请求拦截、额外 Header、缓存行为。
  • input：键盘、鼠标和触摸输入。
  • browser：窗口、下载行为与用户上下文。
  • emulation：视口、设备像素比与网络条件等模拟。

这些能力并不意味着 CDP 会立刻被替代。两者的工程重心不同：CDP 常常更早暴露 Chrome 的新调试能力；BiDi 更关注在不同浏览器之间形成可互操作的自动化行为。

BiDi 与 Chrome 的一个重要区别

Chrome 的远程调试端口暴露的是 CDP 端点，而不是“把任意 WebSocket 客户端直接接入 BiDi”的通用开关。BiDi 往往通过 WebDriver 实现、浏览器驱动或框架建立会话。不要把 CDP 调试端口与 BiDi 端点混为一谈。

这也是为什么测试框架会帮你处理协议细节：框架会根据浏览器、驱动和可用能力选择合适通道，而不是要求每个测试项目手写 WebSocket 消息。

MCP：把浏览器能力交给 AI Agent 调用

MCP 不负责规定“浏览器如何加载网页”或“网络事件长什么样”。它关注的是 Agent 如何列出工具、传递参数、获得结构化结果，并在一次任务中保持必要的上下文。

从使用者角度，常见的浏览器 MCP 可以分成两类：

  1. DevTools 型：通过 CDP 检查或控制 Chrome，适合诊断、网络分析、性能排查和当前页面探索。
  2. 自动化测试型：通过 Playwright 等高层 API 操作页面，适合稳定交互、可访问性快照、截图和验证结果。

Microsoft Playwright MCP 属于第二类。它使用 Playwright 的自动化能力，并以页面可访问性快照为主要交互依据，减少 Agent 依赖视觉坐标点击的需要。它还能运行隔离浏览器、使用持久 profile，或通过 CDP 连接已有 Chromium 实例，具体模式应根据登录态与测试隔离要求选择。

这里有一个务实的原则：不要因为两个 MCP 都能“点击网页”，就同时把它们用于同一个问题。

  • 调试请求失败、Console 报错、性能问题时，使用 Chrome DevTools MCP。
  • 验证“选择文件、填写表单、点击提交、断言页面结果”时，使用 Playwright MCP。
  • 两者同时高频控制同一标签页，可能相互干扰导航、页面状态、网络拦截或浏览器上下文。

工程选型：不同任务应该选什么

场景 首选 原因 注意事项
排查当前 Chrome 页面白屏、报错或接口失败 CDP / Chrome DevTools MCP Network、Console、DOM、Performance 信息最完整 使用隔离 profile，调试端口仅本机监听
分析 Core Web Vitals、长任务或性能回归 CDP / Chrome DevTools MCP Tracing 与 Performance 是 Chrome 的强项 不要把单次本地性能数值当成生产结论
让 Agent 完成表单、上传、页面断言 Playwright MCP 交互与可访问性快照模型更适合稳定自动化 业务测试仍应沉淀为 Playwright E2E，而非只依赖对话
本地功能回归 Playwright Test 或 Playwright MCP 可以使用隔离上下文、固定 viewport、可重复脚本 MCP 适合探索；固定回归测试更适合代码化
跨 Chrome、Firefox、WebKit 的长期测试策略 WebDriver / BiDi 生态 协议目标是浏览器互操作性 先核对具体浏览器与框架的模块支持
操作日常 Chrome 的已登录页面 仅在必要时使用扩展或已有浏览器连接方案 可复用登录态 权限最高，应限制 MCP 来源、标签页范围与操作范围
让 Agent 调查一个动态网站 先用 Chrome DevTools MCP，再按需用 Playwright MCP 一个负责诊断，一个负责交互 不要并发驱动同一页面

对于多数前端团队，一个简单且有效的组合是：

Chrome DevTools MCP：问题定位、网络与性能诊断
Playwright：可重复的 E2E 自动化测试
Playwright MCP：Agent 驱动的探索、验证和辅助排障
WebDriver BiDi：持续关注标准化与跨浏览器能力成熟度

Windows 最小实践：安全启动并验证 Chrome CDP

如果目的是让本机工具连接 Chrome 的 CDP，不要直接拿日常 profile 开启一个对外可见的调试端口。更安全的做法是使用独立用户目录，并且只绑定本机回环地址：

$chrome = "$env:ProgramFiles\Google\Chrome\Application\chrome.exe"

Start-Process $chrome -ArgumentList @(
  "--remote-debugging-address=127.0.0.1",
  "--remote-debugging-port=9222",
  "--user-data-dir=$env:TEMP\chrome-cdp-profile",
  "--no-first-run",
  "--no-default-browser-check"
)

Invoke-RestMethod http://127.0.0.1:9222/json/version

这段命令的含义很明确：

  • remote-debugging-address：只允许本机进程连接，不要改成 0.0.0.0。
  • remote-debugging-port：开启 CDP 调试端口。9222 只是常用端口，不是协议要求。
  • user-data-dir：使用独立 profile，避免把真实浏览器 Cookie、扩展和日常状态混进自动化环境。
  • /json/version：用 HTTP 发现端点确认 Chrome 已启动并提供调试信息。

从 Chrome 136 起，Chrome 强化了远程调试开关的安全约束：当使用默认 Chrome 用户数据目录时，远程调试端口和远程调试 pipe 不再按旧方式生效；开发者应指定非默认 user-data-dir，或者在特定自动化场景使用 Chrome for Testing。Chrome 官方说明

如果你已安装 Chrome DevTools MCP，MCP Client 的配置则是另一件事。例如在 Codex 中，MCP Server 可通过 npx 启动：

[mcp_servers.chrome-devtools]
command = "cmd"
args = ["/c", "npx", "-y", "chrome-devtools-mcp@latest"]
startup_timeout_ms = 20000

这段 TOML 配置描述的是“如何启动 MCP Server”，不是“如何启动 Chrome”。两者可独立存在：MCP Server 可以自行启动受控浏览器，也可以在支持的模式下连接一个已经开启 CDP 的 Chrome。

安全边界与常见误区

误区一：调试端口只是开发便利，不算高权限接口

错误。能连上 CDP 的进程通常可以浏览页面、执行脚本、读取页面内容、修改网络行为和创建新标签页。把它暴露给局域网或公网，相当于扩大了浏览器的控制面。应始终限制到回环地址，并在不需要时关闭浏览器实例。

误区二：直接复用日常 Chrome profile 最省事

它确实省事，也因此风险最高。日常 profile 往往包含登录会话、浏览记录、同步数据和扩展。应优先使用独立 user-data-dir 或隔离浏览器上下文；只有必须处理已登录业务系统时，才在明确授权、受信任 MCP 和受控标签页范围内连接已有浏览器。

误区三：解决自动化问题的通用方法是关闭浏览器安全机制

不是。disable-web-security、ignore-certificate-errors 这类参数会掩盖真实问题，并改变应用的安全模型。对于跨域、证书或认证问题，应修正本地服务配置、测试 mock 或信任链，而不是把安全绕过写进日常启动脚本。

误区四：MCP 能替代正式测试体系

MCP 很适合让 Agent 探索页面、复现问题、收集证据和辅助编写测试。但长期回归仍应使用版本控制下的 Playwright、WebDriver 或其他测试代码。测试代码有稳定选择器、可审查断言、CI 记录和可重复执行环境；对话驱动操作不应成为唯一质量保障。

误区五：BiDi 已经让所有浏览器自动化行为完全一致

BiDi 的方向是正确的，但它仍在标准与实现持续演进中。使用某个网络拦截、脚本执行或浏览器管理能力前，应检查目标浏览器、驱动和自动化框架的实际支持范围，而不是只根据协议名称做假设。

结语

AI Agent 控制浏览器的关键不在于安装更多 MCP，而在于把能力放到正确层级：

  • 想深入理解 Chrome 正在发生什么，选择 CDP 与 Chrome DevTools MCP。
  • 想让 Agent 稳定完成交互和验证，选择 Playwright MCP，并把关键路径固化成 E2E。
  • 想建立长期跨浏览器自动化能力，关注 WebDriver BiDi 与工具链的成熟度。

先用协议边界约束工具选择，再用隔离 profile、最小权限和可重复测试约束运行方式，浏览器自动化才会从“Agent 能点按钮”变成可靠的工程能力。

参考资料

# 人工智能 # chrome devtools # 自动化 # 功能测试
Logo
亚马逊云科技技术品牌专区

更多推荐

cover

一次 API 调用搞定时序预测：时序大模型 TimechoAI 使用与能力全解析

avatar 亚马逊云科技技术品牌专区

AI Agent 面试题 353：A2A协议的服务发现和注册机制详解

A2A 协议 是 AI Agent 技术体系中的重要组成部分。简单来说，它涉及到 Agent 如何在 工具使用与函数调用 层面实现智能化的行为和决策。在实际应用中，A2A 协议 的核心目标是让 Agent 能够更加高效、准确地完成特定任务。这需要我们深入理解其底层原理和实现机制。从学术角度来看，A2A 协议 的研究可以追溯到人工智能的早期阶段。早在 1950 年代，Alan Turing 就提出了

avatar 亚马逊云科技技术品牌专区
cover

PyTorch框架使用

avatar 亚马逊云科技技术品牌专区