Hacker News 中文摘要

RSS订阅

更接近底层：从Playwright转向CDP -- Closer to the Metal: Leaving Playwright for CDP

原文链接 | HN讨论 | 2025-08-21 04:57:37

文章摘要

文章讨论了从使用Playwright转向直接使用Chrome DevTools Protocol (CDP)的决定。尽管Playwright和Puppeteer在编写QA测试和自动化脚本时非常方便，但它们有时会掩盖浏览器底层的重要细节。通过直接使用CDP，团队显著提高了元素提取、截图等操作的速度，并增加了异步反应能力和跨域iframe支持。文章还提到，构建AI浏览器自动化就像在复杂的积木塔上工作，每一层都有其抽象漏洞和潜在崩溃。

文章总结

告别Playwright，拥抱CDP

Playwright和Puppeteer在编写QA测试和自动化脚本时表现出色，但过去一年中，AI浏览器公司逐渐意识到，这些工具有时会掩盖底层浏览器的重要细节。我们决定深入探究浏览器的实际运作机制，最终决定放弃Playwright，直接使用浏览器的原生语言——Chrome DevTools Protocol（CDP）。

通过切换到原生的CDP，我们大幅提升了元素提取、截图等操作的执行速度，并为代理增加了新的异步响应能力，同时实现了跨域iframe的支持。

抽象层的诅咒

构建AI浏览器自动化就像在复杂的积木塔上搭建，每一层都有其自身的漏洞、崩溃和资源限制。依赖适配器库并围绕其构建大型代码库时，最终会发现适配器库不再通过“隐藏复杂性”来节省时间。对于Browser-Use和playwright-python来说，这一时刻已经到来。

尽管抛弃成熟的适配器库看似不明智，但AI浏览器的需求远比Playwright提供的功能范围狭窄。我们相信，通过更专业的逻辑实现所需调用，可以更好地适应AI驱动的需求。此外，Playwright通过Node.js服务器进行通信，增加了网络延迟，尤其是在进行大量CDP调用时，这种延迟尤为明显。

浏览器自动化的历史

要理解浏览器自动化的现状，我们需要回顾其发展历程：

  • 2011-2017：PhantomJS填补了无头浏览器的空白，但可靠性参差不齐。
  • 2011：Chrome引入远程调试功能。
  • 2012：WebKit远程调试协议v1.0发布。
  • 2013-2014：Blink从WebKit中分离，协议在Chromium中固化，成为CDP。
  • 2014：Chrome的chrome.automation扩展API出现。
  • 2017：无头Chrome和Puppeteer发布。
  • 2018：Puppeteer 1.0发布，WebDriver成为W3C标准。
  • 2019：Puppeteer团队在Google I/O上推广现代测试。
  • 2019-2020：Puppeteer核心工程师离开Google，创建Playwright。
  • 2020：Playwright 1.0发布，开始支持多语言。
  • 2023：ChromeDriver支持WebDriver BiDi。
  • 2024：Puppeteer支持WebDriver BiDi。

如今，我们有许多高质量的驱动库可供选择，如pydoll、go-rod、puppeteer、playwright、selenium、cypress和appium。然而，我们选择开发自己的cdp-use库，以更接近底层并实现更精细的控制。

浏览器驱动的工作原理

浏览器暴露的自动化API包括Chrome扩展API、CDP API、操作系统级辅助功能API和Chromium内部C++ API。这些适配器库和驱动主要通过传递消息和调用这些底层API来实现自动化。

Playwright通过客户端-服务器模型实现多语言支持，但其双重RPC机制导致状态在浏览器、Node.js中继进程和Python客户端之间漂移，尤其是在处理边缘情况时，这种机制显得力不从心。

从零开始

在底层组件不可靠的情况下提供稳定的体验是一项巨大的工程挑战。Chrome中有至少10种方式导致标签页崩溃，Playwright只能处理其中一半，因此我们决定切换到CDP，并自行解决所有问题。

迁移中的关键变化

我们开发了新的cdp-use库，提供Python类型绑定，直接从CDP协议规范生成类型安全的Python客户端。我们还引入了事件驱动架构，以更好地适应CDP的事件驱动特性。此外，我们改进了元素提取处理，使其能够跨域iframe工作。

时间是一个循环

从2014年使用PhantomJS到2025年处理CDP，浏览器自动化的核心问题依然存在。幸运的是，AI的出现为我们带来了新的希望。我们致力于解决浏览器自动化和CDP的复杂性，让用户无需深入了解CDP的细节即可完成任务。

尝试我们的新库和测试版本，并告诉我们您的反馈！

评论总结

评论内容总结：

  1. 对现有工具的质疑与建议

    • 一些评论者认为重新发明轮子没有必要，建议直接使用现有的工具如Puppeteer或Selenium。
    • 引用：
      • "Puppeteer uses CDP under the hood. Just use Puppeteer."（Puppeteer底层使用CDP，直接用Puppeteer吧。）
      • "Selenium was very usable before 2011."（Selenium在2011年之前就很好用了。）

  2. 对浏览器自动化技术的讨论

    • 评论者讨论了不同浏览器自动化技术的优缺点，如CDP、Webdriver Bidi等，并提到在浏览器扩展中实现自动化的挑战。
    • 引用：
      • "The most difficult part is managing the lifecycle of Windows, Pages, and Frames and handling race conditions."（最困难的部分是管理窗口、页面和框架的生命周期，以及处理竞态条件。）
      • "Umm, will this run on Firefox too? They deprecated CDP and favors Webdriver Bidi."（这能在Firefox上运行吗？他们弃用了CDP，转而支持Webdriver Bidi。）

  3. 对项目前景的悲观态度

    • 部分评论者对项目的前景持悲观态度，认为其可能失败，尤其是当它试图重写已有成熟软件时。
    • 引用：
      • "This is a project doomed to failure. Using VC money to re-write better built software which has been around for years."（这个项目注定失败，用风投的钱重写已经存在多年的更好软件。）

  4. 对技术历史的回顾

    • 一些评论者回顾了浏览器自动化技术的发展历史，提到了早期工具如Selenium的使用体验。
    • 引用：
      • "Back in my day, we used Selenium and hated it."（在我那个年代，我们用Selenium并且讨厌它。）

  5. 对特定技术应用的探讨

    • 评论者讨论了CDP在爬虫社区中的应用，以及如何通过浏览器扩展控制用户浏览器。
    • 引用：
      • "direct CDP has been used by the scraping community for a long time."（爬虫社区长期以来一直直接使用CDP。）
      • "later we switched to taking control of the users browser through a browser extension."（后来我们通过浏览器扩展控制了用户的浏览器。）

总结：评论者围绕浏览器自动化工具的选择、技术挑战、项目前景以及技术历史展开了讨论，观点多样，既有对现有工具的推崇，也有对新项目的质疑。