关于 Browser Use 从 Playwright 到 CDP 的背景，咱们前面有介绍：
微软 Playwright 也被革命了？Browser Use 最新版改用Chrome DevTools协议，更高效，更安全！
今天 Browser Use 团队发布了为什么放弃 Playwright 改为基于 CDP 开发的技术文章「Closer to the Metal: Leaving Playwright for CDP」，讲述了团队为何放弃流行的浏览器自动化工具 Playwright，转而直接使用Chrome DevTools Protocol（CDP）的过程。文章深入探讨了浏览器自动化的复杂性、Playwright 的局限性，以及团队通过拥抱CDP实现的性能提升和新功能，咱们一起解读学习。
为什么放弃 Playwright？
Playwright 和 Puppeteer 是广受欢迎的浏览器自动化工具，代码简洁，适合快速编写测试和自动化脚本。然而，作者团队发现这些工具在某些场景下隐藏了浏览器的底层细节，导致性能瓶颈和功能限制。他们的目标是为AI驱动的浏览器自动化打造更高效的解决方案，而 Playwright 的抽象层开始成为绊脚石。
具体来说，Playwright 的问题包括：
· 额外的网络开销：Playwright 通过 Node.js 服务器中转与浏览器的通信，增加了延迟，尤其是在需要频繁调用 CDP（Chrome DevTools Protocol）来检查元素位置、透明度、事件监听器等时。
· 复杂场景的缺陷：比如处理超长页面截图（超过16,000像素）、弹窗、文件上传下载、特殊协议页面（如 chrome:// 或 PDF 页面），以及标签崩溃等，Playwright 的表现不尽如人意。
· 抽象层限制：Playwright 将底层的浏览器概念（如目标、框架、会话）抽象为简单的 Page 和 BrowserContext，虽然简化了操作，但在复杂场景下，这种抽象可能导致状态不同步或死锁，难以处理边缘情况。
最终，团队决定直接使用 CDP，绕过 Playwright 的中间层，以获得更精细的控制、更快的速度和更好的灵活性。
什么是 CDP，为什么重要？
CDP（Chrome DevTools Protocol）是 Chrome 浏览器暴露的底层协议，允许开发者直接与浏览器交互，比如导航页面、捕获截图、处理事件等。相比 Playwright 这样的高层工具，CDP 更“贴近底层”，就像直接跟浏览器对话，而不是通过翻译（Playwright）间接沟通。
通过直接使用 CDP，团队实现了：
· 性能提升：元素提取、截图等操作速度大幅提高。
· 新功能：支持异步事件响应和跨源 iframe（不同域名嵌入框架）操作。
· 更灵活的控制：可以处理 Playwright 难以应对的复杂场景，比如标签崩溃、下载监控等。
浏览器自动化的历史脉络
文章还回顾了浏览器自动化的发展，帮助理解为什么现在有这么多工具，以及为何团队选择“自力更生”：
· 早期（2011-2017）：没有无头 Chrome 时，PhantomJS 是主流，但可靠性差。Chrome 的远程调试协议（后来的 CDP）逐渐成型。
· 无头 Chrome 时代（2017-）：Chrome 推出无头模式，Puppeteer 作为 CDP 的 Node.js 封装出现，Playwright 则在2020年由前 Puppeteer 工程师开发，支持多浏览器。
· 现在（2025）：自动化工具百花齐放，包括 Puppeteer、Playwright、Selenium 等，每种工具各有侧重，但都建立在 CDP 或类似的底层协议上。
团队选择开发自己的 cdp-use 库，因为现有工具无法完全满足 AI 驱动自动化的需求。他们需要更直接的控制，而 CDP 提供了这种可能性。
迁移到 CDP 的挑战与成果
转向 CDP 并非易事，浏览器自动化本身就是个“雷区”。文章提到 Chrome 标签可能因多种原因崩溃，比如内存不足、GPU 进程出错、JavaScript 死循环等。Playwright 能处理一部分问题，但另一半则无能为力。而直接使用 CDP，团队需要自己解决所有这些问题。
不过，辛苦是值得的。他们开发了几个关键改进：
-
cdp-use 库：一个为 CDP 生成的类型安全的 Python 绑定库，直接从 CDP 协议规范生成代码，提供简单、直接的访问方式 https://github.com/browser-use/cdp-use。
-
事件驱动架构：过去，他们只在执行动作后更新页面状态，但这无法处理动态变化（如缓慢加载的内容或定时触发的脚本）。新的架构通过订阅 CDP 事件（如文件下载、页面崩溃），实时响应页面变化。
-
跨 iframe 元素处理：浏览器页面由多个目标（target）和框架（frame）组成，跨源 iframe 尤其复杂。他们设计了“超级选择器”（包含目标ID、框架ID、节点ID等），确保精准定位和操作元素，即使页面结构动态变化。
总结：为什么值得？
尽管开发自己的 CDP 库意味着更多工作，但团队认为这让他们更接近浏览器的“真实面貌”。直接使用 CDP，他们可以：
· 消除中间层的性能瓶颈。
· 更好地支持AI驱动的自动化需求，比如快速响应动态页面变化。
· 更灵活地处理复杂场景，比如跨源iframe和崩溃恢复。
最后提到，虽然浏览器自动化的挑战从2014年到2025年变化不大，但 AI 的出现为自动化带来了新希望。他们的目标是让用户和 AI 无需关心 CDP 的复杂细节，就能轻松完成任务。
我的感受
文章展现了技术团队在追求极致性能和控制时，愿意“从头开始”的勇气。Playwright 这样的工具适合大多数场景，但当需求非常特殊（如 AI 驱动的浏览器自动化）时，绕过抽象层、直接操作底层协议确实能带来显著优势。不过，这条路也需要更多工程努力，适合有能力处理复杂性的团队。如果你对浏览器自动化感兴趣，或者正在开发类似项目，不妨看看他们的cdp-use 库，也许能省不少力气！
信息卡：
原文地址：