browser-harness、Playwright、Puppeteer 怎么选？浏览器自动化工具对比

Sun, 24 May 2026 17:51:28 +0800

在浏览器自动化和自动化测试领域，Playwright 和 Puppeteer 是最常被拿来比较的两个工具。它们都可以控制浏览器、点击页面、抓取内容、生成截图或 PDF，也都和 Chrome DevTools Protocol 有很深关系。

但如果把 browser-use/browser-harness 放进来，问题就不只是“哪个测试框架更强”，而是变成了两类工具的对比：

Playwright / Puppeteer：面向人类工程师写确定性脚本。
browser-harness：面向 AI Agent 操作真实浏览器。

前者适合测试、爬虫和工程化自动化；后者更像给 Claude Code、Codex CLI、Gemini 这类 Agent 准备的浏览器控制层。

Playwright 和 Puppeteer 的关系

Puppeteer 最早由 Google Chrome 团队推出，天然服务于 Chromium 和 Chrome 自动化。它的 API 简洁，生态成熟，特别适合围绕 Chrome 做截图、PDF、页面抓取和轻量自动化。

Playwright 由微软维护，背后团队和早期 Puppeteer 有很深渊源。它吸收了 Puppeteer 的很多经验，同时把跨浏览器、自动等待、上下文隔离、测试报告和调试工具链做得更完整。

简单说：

只围绕 Chrome 做轻量任务，Puppeteer 仍然很顺手。
做跨浏览器 E2E 测试、复杂 SPA 自动化和团队测试工程，Playwright 通常更合适。

核心区别总览

维度	Puppeteer	Playwright
主导方	Google	Microsoft
浏览器支持	主要面向 Chrome / Chromium	Chromium、Firefox、WebKit
语言支持	主要是 JavaScript / TypeScript	JavaScript / TypeScript、Python、Java、.NET
自动等待	需要更多显式等待	Locator 和 auto-waiting 更完整
多上下文隔离	支持，但不是最突出的优势	BrowserContext 体验很强
工具链	简洁、成熟、偏基础	Codegen、Trace Viewer、测试报告更完整
典型场景	Chrome 自动化、截图、PDF、轻量抓取	跨浏览器 E2E 测试、复杂前端应用自动化

浏览器支持

Puppeteer 的优势在 Chrome。它和 Chromium 结合紧密，如果你的目标就是控制 Chrome、生成 PDF、截图、跑简单爬虫，Puppeteer 的心智负担很低。

Playwright 的优势在跨浏览器。它原生支持 Chromium、Firefox 和 WebKit。WebKit 这一点很关键，因为很多 Safari 相关问题不能只靠 Chrome 测出来。对需要覆盖桌面端、移动端和不同浏览器内核的应用来说，Playwright 更适合作为主力工具。

这也是两者选择的第一道分界线：只看 Chrome，可以用 Puppeteer；要认真做跨浏览器测试，优先 Playwright。

自动等待和稳定性

浏览器自动化最烦人的问题，往往不是“不会点击”，而是页面还没准备好。元素可能还没挂到 DOM，可能被遮挡，可能正在动画中，可能按钮还是 disabled。

Puppeteer 里经常会写：

1
2

await page.waitForSelector('#submit-btn');
await page.click('#submit-btn');

这没有问题，但等待逻辑需要工程师自己想清楚。页面越复杂，脚本里越容易出现各种 waitForSelector、waitForTimeout 和重试逻辑。

Playwright 的 Locator 机制和自动等待更完整：

`1`	`await page.locator('#submit-btn').click();`

在点击之前，Playwright 会自动检查元素是否可见、可操作、稳定、没有被遮挡，并在合理时间内重试。这对 React、Vue、Next.js 这类异步渲染很多的现代 Web 应用尤其重要，可以明显减少 flaky test。

多账号和上下文隔离

如果你要模拟多个用户，或者想让多个任务共享同一个浏览器进程但隔离 Cookie、LocalStorage 和 Session，BrowserContext 就很重要。

Puppeteer 也支持上下文隔离，但 Playwright 把这件事做成了核心能力。你可以在一个浏览器实例里快速创建多个独立 context，每个 context 像一个干净的浏览器环境，却不需要反复启动完整浏览器进程。

这对这些场景很有价值：

多账号并发测试。
多角色协作流程测试。
电商、IM、协作文档等多用户场景。
需要隔离 Cookie 和登录态的爬取任务。

工具链差异

Playwright 是更“工程化”的方案。它内置了很多测试开发会用到的工具：

codegen：在网页上操作，自动生成脚本。
Trace Viewer：失败后回看每一步的截图、DOM、网络请求和 console 日志。
Test Runner：支持断言、并行、重试、报告和项目矩阵。
Locator：支持按文本、角色、label、test id 等方式定位元素。

Puppeteer 则更像一个轻量浏览器控制库。它不臃肿，API 直接，适合嵌入脚本、服务端任务和自定义自动化流程。

如果你要搭企业级测试体系，Playwright 的配套工具会省很多事。如果你只是要写一个 Node.js 脚本，把网页转 PDF 或定时截图，Puppeteer 反而更干脆。

browser-harness 放在哪里

browser-harness 和 Playwright、Puppeteer 不是同一类工具。

Playwright 和 Puppeteer 主要假设“人类写脚本”。人类工程师要决定选择器、等待条件、断言逻辑和异常处理。它们追求的是确定性：同样的脚本，在同样的页面状态下，应该给出同样的结果。

browser-harness 主要假设“AI Agent 操作浏览器”。它的目标不是提供一套巨大的高级 API，而是通过 CDP 连接真实 Chrome，把截图、坐标点击、DOM、网络请求和 helper 暴露给 Agent。Agent 可以观察页面、判断下一步、遇到缺能力时补 helper，再把站点经验沉淀成 skill。

这就让它更适合开放任务：

登录后台后下载账单。
在内部系统里填一组表单。
处理经常改版的 OA 或 SaaS 页面。
按用户目标探索页面，而不是执行固定脚本。
让 Claude Code、Codex CLI 这类工具拥有浏览器操作能力。

三者核心对比

维度	Puppeteer	Playwright	browser-harness
面向对象	人类工程师	人类工程师和测试团队	AI Agent
主要目标	控制 Chrome	稳定跨浏览器自动化	让 Agent 操作真实浏览器
脚本方式	手写 JS/TS 自动化	手写脚本 + 测试框架	用户下目标，Agent 分步执行
元素定位	CSS、XPath、DOM API	Locator、文本、角色、CSS	截图视觉、坐标、DOM、CDP
等待机制	更多手动控制	自动等待很强	由 Agent 观察和调整
浏览器环境	通常启动自动化浏览器	通常启动测试浏览器	常连接真实 Chrome
最适合	Chrome 脚本、截图、PDF、轻量抓取	E2E 测试、跨浏览器验证、复杂 SPA	AI 助手、开放网页任务、真实账号工作流

代码体感对比

Puppeteer 更像直接控制 Chrome：

const puppeteer = require('puppeteer');

(async () => {
  const browser = await puppeteer.launch();
  const page = await browser.newPage();
  await page.goto('https://example.com');

  await page.waitForSelector('#submit-btn');
  await page.click('#submit-btn');

  await browser.close();
})();

Playwright 更强调 Locator 和自动等待：

const { chromium } = require('playwright');

(async () => {
  const browser = await chromium.launch();
  const page = await browser.newPage();
  await page.goto('https://example.com');

  await page.locator('#submit-btn').click();

  await browser.close();
})();

browser-harness 的使用体感则完全不同。你通常不是写完整脚本，而是在 Agent 环境里下达目标：

`1`	`帮我打开后台，下载上个月的账单，并整理成报销用的文件。`

Agent 会借助 browser-harness 反复执行类似流程：

截图，理解当前页面。
点击某个坐标或定位某个元素。
输入文字、上传文件、下载文件。
遇到弹窗时判断如何关闭。
缺少 helper 时补充代码。
把可复用流程沉淀为 domain skill。

这不是传统测试脚本的写法，而是浏览器 Agent 的工作方式。

怎么选

选择 Puppeteer，通常是因为：

项目主要跑在 Node.js 里。
只需要 Chrome 或 Chromium。
任务是截图、PDF、简单页面抓取或轻量自动化。
你希望 API 简洁，依赖少，自己控制更多细节。
你对 Chrome DevTools Protocol 有较深依赖。

选择 Playwright，通常是因为：

你要做标准 UI 自动化或 E2E 测试。
需要覆盖 Chromium、Firefox 和 WebKit。
团队主语言可能是 Python、Java 或 C#。
页面是复杂 SPA，异步状态多，容易出现 flaky test。
你需要 codegen、Trace Viewer、测试报告和并行测试。

选择 browser-harness，通常是因为：

你在开发或使用 AI Agent。
你希望模型像人一样操作真实浏览器。
任务步骤不固定，需要边看页面边判断。
目标网站经常改版，或者弹窗、iframe、shadow DOM 很多。
你想把真实网页工作流交给 Claude Code、Codex CLI 等工具处理。

简单结论

Playwright 和 Puppeteer 是浏览器自动化工具，核心是让人写出可靠脚本。两者相比，Puppeteer 更轻、更贴近 Chrome；Playwright 更完整、更适合跨浏览器测试和复杂前端应用。

browser-harness 则是另一个方向：它不是为了取代 Playwright 或 Puppeteer 写测试，而是为了让 AI Agent 接管真实浏览器。它牺牲了一部分传统脚本的确定性，换来更强的开放任务适应能力。

所以答案不是三选一，而是按任务分层：

测试工程：优先 Playwright。
Chrome 轻量脚本：Puppeteer 很合适。
AI Agent 上网办事：看 browser-harness。

参考资料：

browser-use/browser-harness：https://github.com/browser-use/browser-harness
Playwright 官方文档：https://playwright.dev/
Puppeteer 官方文档：https://pptr.dev/
Chrome DevTools Protocol：https://chromedevtools.github.io/devtools-protocol/

Puppeteer on KnightLi的博客