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

在浏览器自动化和自动化测试领域，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 的优势在 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 更像直接控制 Chrome：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

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 和自动等待：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

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/