Playwright vs CDP 浏览器控制方式对比
问题
对于 OpenClaw 来说，Playwright 方式调用浏览器和 RDP（实为 CDP）调用浏览器工具，区别是什么？
解答
小概念澄清
RDP（Remote Desktop Protocol）是 Windows 远程桌面协议，在浏览器控制语境下实际指的是 CDP（Chrome DevTools Protocol），即通过 9222 端口（Remote Debugging Port）进行通信的 Chrome 远程调试协议。
核心区别
1. 抽象层级与控制粒度
| 方式 | 原理 | 类比 |
|---|---|---|
| Playwright（高级封装） | 发送指令如”点击 Login 按钮”，自动寻元素、等待、计算坐标、模拟鼠标 | 自动驾驶系统 |
| CDP（底层协议） | 直接发送原始 JSON 报文，需先获取 DOM 树找到节点 ID，再发送 Input.dispatchMouseEvent | 直接控制方向盘和油门 |
2. 对 AI “视觉”与 DOM 解析的影响（核心差异）
- Playwright 方式：依赖注入 JavaScript 遍历 DOM 元素计算 Bounding Box，易被复杂 CSS 或 Shadow DOM 阻挡
- CDP 方式：直接调用 Chrome 底层的 Accessibility Tree（无障碍树），精准获取所有可交互元素的坐标和层级，不受前端代码干扰
目前最先进的 Web Agent（如 Claude Computer Use 或基于 MCP 的实现）深度依赖 CDP 获取页面空间信息。
3. 浏览器接管与隐蔽性（反爬虫）
| 方式 | 特点 |
|---|---|
| Playwright | 默认启动纯净新浏览器实例，带 webdriver 标记，易被识别为机器人 |
| CDP 直连宿主机 | 通过 host.docker.internal:9222 连接真实 Chrome Profile，带着长期 Cookie 和正常指纹，隐蔽性极高 |
4. 运行开销与依赖
| 方式 | 资源消耗 |
|---|---|
| Playwright | 容器内需安装庞大 Playwright 依赖库及浏览器内核包，容器体积大，内存占用高 |
| CDP | 仅需轻量级 WebSocket 客户端（如 chrome-devtools-mcp），所有渲染计算在宿主机 |
总结对比
| 比较维度 | Playwright 方式 | CDP 方式（DevTools MCP） |
|---|---|---|
| 工作原理 | 高级 API，自动处理等待、查找和点击 | 底层 WebSocket，原始 JSON 报文 |
| 适用场景 | 固定自动化脚本、后台静默运行 | AI 接管当前屏幕、复杂精准坐标映射任务 |
| 接管现有浏览器 | 支持（connectOverCDP），非默认设计 | 完美契合，生来为此设计 |
| 容器资源消耗 | 高 | 极低 |
| 反爬风控风险 | 较高（除非专门配置 Stealth） | 较低（借用真实用户指纹） |
结论
对于 OpenClaw 直接操作宿主机浏览器主 Profile 的场景，CDP (DevTools MCP) 协议连接 9222 端口是最优选择：
- 完美复用已有 Cookie 实现免登录
- Accessibility Tree 让 AI 更准确理解网页结构
- 资源占用极低，隐蔽性最强
本质：Playwright 是封装好的高级工具，CDP 是浏览器底层的”机器语言”。