浏览器自动化技术全景：CDP、Playwright 与 AI Agent 的架构关系

发表于

随着 AI Agent、自动化运营、数据抓取和自动化测试的发展，浏览器自动化逐渐成为重要的技术基础设施。当前生态中存在多种技术路线，例如：

  • 浏览器调试协议
  • 自动化框架
  • AI Agent 浏览器接口
  • 浏览器扩展自动化
  • 视觉自动化
  • 操作系统级自动化

这些技术并不是彼此替代关系，而是处于不同的控制层级与抽象层级。本文从系统架构角度，对浏览器自动化技术进行系统分类，说明其能力边界与工程实践选择。

一、浏览器调试协议（Browser Protocol Layer）

浏览器自动化最底层是浏览器提供的调试协议，其中最重要的是 Chrome DevTools Protocol（CDP）。

CDP 是 Chromium 系浏览器的调试接口，主要用于 DevTools、自动化、性能分析和调试，基本通信方式是 WebSocket：

1
2
3
4
5
6
7
controller
↓
WebSocket
↓
CDP
↓
browser process

通过发送 JSON 指令即可控制浏览器，例如：

1
2
3
4
Page.navigate
Runtime.evaluate
Input.dispatchMouseEvent
Network.enable

需要注意的是，CDP 只适用于 Chromium 系浏览器。其他浏览器有各自的调试协议：

  • Firefox Remote Protocol
  • WebKit Inspector Protocol

因此，浏览器自动化并不等同于 CDP，CDP 只是其中一种浏览器协议实现。

二、浏览器自动化框架（Automation Framework Layer）

为了简化浏览器协议的使用，出现了自动化框架，例如 Playwright、Puppeteer、Selenium。这些框架提供更高层 API：

1
2
3
await page.goto(url)
await page.click("button")
await page.fill("#input", "text")

框架内部再将操作转换为浏览器协议指令。

需要特别说明的是，Playwright 并不等同于“CDP 封装”。从官方公开 API 看：

  • Playwright 提供自己的高层控制协议与运行时抽象
  • 在 Chromium 场景下，可以显式通过 connectOverCDP 连接到现有浏览器实例
  • 但对于 Firefox 和 WebKit，官方文档并没有把其底层实现简单定义成一张固定的“协议对照表”

因此更准确的描述是：

1
2
3
4
5
Playwright
↓
browser-specific protocol
↓
browser

只有在特定 Chromium 接管场景下，官方明确暴露了 connectOverCDP 这类 CDP 能力。此外，Playwright 还有 connect() 等基于自身协议的连接方式。

三、AI Agent 浏览器接口层

随着 LLM Agent 的发展，一些工具专门为 AI 提供浏览器操作接口，例如 agent-browser、browser-use。这类工具并不是新的浏览器技术，而是 AI 适配层，核心思想是：

把复杂网页结构转换为 AI 可理解的操作表示。

例如，传统 DOM：

1
<button class="login-btn">

转换为 AI 友好表示：

1
2
3
@1 Login button
@2 Email input
@3 Submit button

AI 只需输出 click @1 即可完成操作。其典型架构为：

1
2
3
4
5
6
7
8
9
AI Agent
↓
Agent Browser
↓
Playwright / Puppeteer
↓
Browser protocol
↓
Browser

这类系统的主要价值在于：

  • 降低 LLM token 消耗
  • 减少 selector 复杂度
  • 提高 AI 自动化稳定性

四、浏览器扩展自动化

另一类浏览器控制方式是 浏览器扩展（Chrome Extensions / WebExtensions）。扩展通过 content script 注入页面：

1
2
3
4
5
extension
↓
content script
↓
DOM

优点：

  • 可访问 DOM、读取 cookies
  • 可与用户真实浏览器环境结合

缺点：

  • 生命周期受浏览器控制
  • background service worker 可能被回收
  • 页面刷新会导致脚本重新注入

因此，在长期无人值守自动化中，扩展方案稳定性通常低于浏览器协议方案。

五、视觉自动化

视觉自动化不依赖 DOM，而是基于页面截图进行 UI 操作：

1
2
3
4
5
6
7
screenshot
↓
vision model
↓
UI element detection
↓
mouse action

相关研究项目包括 WebVoyager 等。优点是不依赖页面结构、适用于未知 UI；缺点是成本高、执行速度慢、稳定性较差，因此多用于研究或 AI Agent 实验。

六、操作系统级自动化

最底层的自动化方式是 操作系统 GUI 自动化，例如 PyAutoGUI、AutoHotkey，通过鼠标、键盘、屏幕识别控制界面。

优点是完全模拟用户行为；缺点是稳定性很差，不适合复杂系统，通常只用于简单自动化任务。

七、稳定性对比

从工程经验来看，不同技术路线稳定性大致为：

1
2
3
4
5
6
7
8
9
Browser protocol（直接协议控制）
>
Automation framework（框架封装）
>
Browser extension（扩展注入）
>
Vision automation（视觉识别）
>
GUI automation（系统级控制）

越靠近底层，控制粒度越细，稳定性通常越高，但编程复杂度也越高。

自动化框架构建于浏览器协议之上，稳定性略低于直接协议控制，原因在于框架封装引入了额外的抽象层，选择器匹配、等待策略等高层逻辑都可能成为不稳定因素。

但对于绝大多数工程场景而言，框架提供的稳定性已经足够。直接操作协议通常只在高规模或强反爬场景下才有必要。

八、工程实践中的技术选择

数据抓取场景

一般存在三种路线：

1. 直接 API 请求

1
HTTP request → JSON data

性能最高、资源消耗最低，但容易触发风控，需要逆向接口。

2. 浏览器自动化

1
2
3
4
5
browser automation
↓
simulate user actions
↓
extract data

行为更接近真实用户，风控风险较低，但性能较低。

3. 混合模式

很多系统采用：

1
2
3
4
5
6
7
browser automation
↓
登录 / 获取 token
↓
捕获 network API
↓
后续直接调用 API

这种方式兼顾稳定性与效率，是实践中最常见的选择。

不同场景的技术组合

场景 推荐技术组合
AI 自动操作网页 Agent Browser + 自动化框架
自动化测试或浏览器爬虫 Playwright / Puppeteer
高规模自动化或复杂反爬 直接使用 browser protocol
简单数据抓取 HTTP API

结论

浏览器自动化技术形成了从底层协议到 AI Agent 的完整技术体系，从下到上依次为：

1
2
3
4
5
6
7
8
9
10
11
OS automation（操作系统级）
↑
Vision automation（视觉识别）
↑
Browser extension（扩展注入）
↑
Browser protocol（浏览器调试协议）
↑
Automation framework（自动化框架）
↑
AI Agent interface（智能代理接口）

其中：

  • 浏览器协议是最底层能力：直接控制浏览器进程
  • 自动化框架是最常见工程方案：封装协议细节、提供跨浏览器支持
  • AI Agent 接口是新兴抽象层：面向 LLM 的语义化操作适配

在实际系统设计中，应根据稳定性、性能、风控风险与开发复杂度选择合适的技术组合，而非依赖单一技术方案。