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	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 这类工具拥有浏览器操作能力。

browser-harness 是什么

从结构看，browser-harness 更像一个给 Agent 用的浏览器运行时，而不是普通用户手动点击的浏览器插件。

它的核心思路有几个：

直接连接 Chrome 或 Chromium 浏览器。
通过 CDP WebSocket 操作页面。
让 Agent 用截图、坐标点击、DOM、网络请求和原始 CDP 组合完成任务。
把任务相关 helper 放在 agent-workspace/agent_helpers.py。
把站点相关经验沉淀到 agent-workspace/domain-skills/。
保持核心很薄，避免做成庞大的自动化平台。

README 中提到，项目核心架构大约是 4 个核心文件、约 1000 行代码，主要包括 install.md、SKILL.md、src/browser_harness/、agent-workspace/agent_helpers.py 和 agent-workspace/domain-skills/。

这种设计的重点不是“内置所有网站能力”，而是给 Agent 一个足够贴近真实浏览器的操作层，让它在具体任务里补齐缺失能力。

它和传统浏览器自动化有什么不同

传统浏览器自动化通常围绕测试框架展开，例如 Playwright、Selenium 或 Puppeteer。它们适合写确定性的测试脚本：打开页面、定位元素、点击、断言结果。

browser-harness 面向的是另一类任务：用户说一句目标，Agent 自己探索页面、判断状态、处理弹窗、补 helper、复用站点经验。它强调的是交互过程中的适应性。

差异可以这样理解：

Playwright 更适合人写脚本，Agent 执行脚本。
browser-harness 更适合 Agent 边看页面边行动。
传统自动化偏固定流程。
browser-harness 偏开放任务。
传统脚本常依赖选择器。
browser-harness 鼓励先截图、再按可见界面行动，必要时再退回 DOM 或 CDP。

这并不意味着它要替代 Playwright。对稳定测试来说，Playwright 仍然更成熟。browser-harness 的价值在于把真实网页变成 Agent 可操作的环境，尤其适合那些页面结构复杂、步骤不固定、需要临场判断的任务。

为什么强调真实 Chrome

很多浏览器 Agent 工具会使用隔离的无头浏览器。这样部署简单，也适合批量任务，但它有一个现实问题：用户真实工作里的登录态、扩展、历史记录、书签和日常浏览器环境并不一定能直接复用。

browser-harness 支持连接本机 Chrome，也支持 Browser Use cloud browser。对本机浏览器，它提供两种方式：

通过 chrome://inspect/#remote-debugging 允许当前 Chrome 实例被连接。
用 --remote-debugging-port=9222 --user-data-dir=... 启动一个隔离 profile。

如果要让 Agent 帮你处理真实账号里的任务，项目文档更倾向于第一种方式，因为它能复用日常 Chrome 的登录态、扩展和书签。如果要做无人值守自动化，或者不希望被弹窗打断，则更适合使用隔离 profile 或云浏览器。

这里的取舍很清楚：真实浏览器更贴近用户工作流，但安全边界也更敏感；隔离浏览器更适合自动化，但需要重新处理登录和环境。

可编辑 helper 和 domain skills

browser-harness 最有意思的地方，是它把“Agent 会学到什么”设计进了项目结构。

agent-workspace/agent_helpers.py 用来放任务中临时补出来的 helper。比如 Agent 做文件上传时发现现有能力不够，可以补一个稳定的上传函数；下次再遇到类似页面，就不用从零开始。

agent-workspace/domain-skills/ 则用来放站点级经验。README 里举的方向包括 LinkedIn outreach、Amazon 下单、报销系统等。项目建议不要手写这些 skill，而是让 Agent 在真实任务中发现可复用流程后再生成，这样更贴近实际页面行为。

这个思路很适合浏览器自动化。因为网页自动化的难点往往不是“怎么点击按钮”，而是：

某个网站的登录后页面怎么跳转。
哪些弹窗会挡住主流程。
哪些 selector 稳定，哪些只是临时样式名。
上传、下载、iframe、shadow DOM、跨域组件怎么处理。
某个后台系统有哪些隐藏等待和异步状态。

这些知识如果只留在一次运行日志里，很快就会丢掉。把它们沉淀成 domain skills，才可能让 Agent 越用越顺。

适合哪些场景

browser-harness 更适合以下任务：

帮用户操作真实网页后台。
在没有 API 的系统里完成重复流程。
登录态依赖强的个人或企业网页任务。
需要截图判断页面状态的复杂交互。
Agent 需要在执行中补工具、补站点经验。
多个子 Agent 各自使用独立浏览器执行任务。
研究浏览器 Agent 的运行时设计。

具体例子包括：整理网页表格、提交内部系统表单、下载账单、上传文件、处理报销流程、检查订单状态、在 SaaS 控制台里配置资源、从登录后的网页提取信息。

如果任务只是抓取静态网页，未必需要浏览器。项目自己的 SKILL.md 也提到，静态页面可以直接用 HTTP 批量获取；浏览器应该留给真正需要页面状态、登录态和交互的场景。

需要注意的风险

让 AI Agent 接管真实 Chrome，很强，也很危险。

第一，权限边界要清楚。真实 Chrome 里可能有邮箱、支付后台、云控制台、公司系统和个人账号。Agent 一旦能操作浏览器，就等于获得了这些网页权限的一部分。

第二，不要把凭据交给模型。遇到登录页、支付验证、二次确认等敏感步骤，应该让用户自己处理。Agent 可以等待登录完成，但不应该从截图里读取或输入密码、验证码、支付信息。

第三，自动化不等于可托管。很多网页任务看似简单，但中间可能出现风控、误点击、数据删除、批量提交、不可逆操作。适合先从只读、低风险、可回滚的流程开始。

第四，domain skills 需要避免泄露隐私。站点经验可以公开，但不要把账号、内部 URL、客户数据、坐标流水账或一次性任务细节写进去。

第五，真实浏览器连接方式要谨慎选择。如果要复用日常登录态，使用当前 Chrome 很方便；如果要跑长时间自动化，隔离 profile 或云浏览器更可控。

对 AI Agent 工具的意义

browser-harness 代表了一种很务实的 Agent 工具路线：少做平台，多给模型一个可以直接触达真实环境的接口。

过去很多 Agent 失败在两端。一端是模型会推理，但摸不到真实页面；另一端是自动化框架很强，但需要人先把流程写死。browser-harness 试图把这两端接起来：浏览器负责真实世界的状态，Agent 负责观察、判断和补工具。

这也是“自我改进 harness”的意义。它不是说 Agent 会神奇地变聪明，而是把可复用的操作经验放到项目结构里，让下一次任务少走弯路。

对开发者来说，browser-harness 的价值主要在三个层面：

作为个人 Agent 的浏览器控制层。
作为研究浏览器自动化和 Agent 工作流的样本。
作为把网页流程变成可复用技能的实验框架。

它不是所有浏览器自动化问题的答案，但它给出了一个清晰方向：当 Agent 真正要帮人做事时，工具层不只要能调用 API，也要能理解和操作人类每天使用的网页界面。

domain skills 是什么

可以把 domain skills 理解成“给 Agent 看的站点操作手册”。

它不是普通的用户文档，也不是一次性脚本。它更像一组经过实测的站点级知识：

这个站点适不适合用浏览器。
如果有 API，应该优先用哪个 API。
如果必须操作网页，应该从哪个 URL 进入。
哪些 DOM 结构、aria-label、按钮行为经过验证。
哪些常见写法会失败。
哪些场景要停止并请求人类介入。

这类内容既能被人类审查，也能被 Agent 在任务中读取。它把“临场摸索”变成“可维护经验”。

它不是让 Agent 盲目点击

一个好的浏览器 Agent，不应该把所有问题都变成打开网页、看截图、点按钮。

domain skills 里很重要的一类经验，恰恰是在告诉 Agent：什么时候不要用浏览器。

比如 ArXiv 这类站点，论文搜索、元数据和摘要可以通过 Atom API 或 HTML meta 标签直接拿到。用 HTTP 请求通常比打开浏览器更快、更稳，也更容易解析。

GitHub 也是类似思路。仓库、用户、release 数据优先用 REST API；文件内容优先读 raw.githubusercontent.com；只有 GitHub Trending 这类没有等价 API 的页面，才需要进入浏览器。

这说明 browser-harness 的思路不是“浏览器万能”，而是把浏览器放在正确位置：当 API、HTTP、静态页面无法解决问题时，再让 Agent 操作真实页面。

它记录的是站点级知识

传统自动化脚本通常围绕一次任务写，比如：

1

打开页面 -> 输入关键词 -> 点击按钮 -> 下载文件

这种脚本可以完成任务，但经验很容易散落在代码里。站点一改版，脚本失效；换一个任务，很多经验也没法复用。

domain skills 的粒度更接近站点级知识库。它关心的是：

Amazon 搜索结果里哪个容器选择器稳定。
GitHub 哪些数据应该走 REST API。
LinkedIn 邀请管理页的按钮 aria-label 有什么差异。
Shopify Admin 里哪些页面是嵌入式 app。
Shopify Polaris 输入框为什么不能只用普通 JS 设置 value。
Browser Use Cloud 的浏览器实例如何创建、列出和清理。

这些经验不是一次任务的步骤，而是以后很多任务都会用到的判断依据。

例子：Amazon 商品搜索

Amazon 商品搜索的经验，重点不只是“怎么搜索商品”，而是哪些路径更稳定。

比较可靠的做法是直接使用搜索 URL，而不是每次都打开首页再模拟输入。搜索结果可以从 [data-component-type="s-search-result"] 这样的容器中提取。字段提取也有细节：标题、价格、评分、评论数、是否赞助，都有各自更稳的 DOM 来源。

这种经验对 Agent 很有价值。没有它时，Agent 可能会从截图里猜按钮、反复尝试选择器；有了它之后，Agent 可以直接进入更稳定的数据提取路径。

更重要的是，这类 skill 还会记录陷阱。例如某些看似可用的选择器，在赞助结果或交叉推荐区域里会误读。这种坑只有实测过才知道。

例子：LinkedIn 邀请管理

LinkedIn 这类站点更接近真实账号工作流，风险也更高。

在邀请管理页里，Accept 和 Ignore 按钮的 aria-label 格式不同，不能简单地从一个推导另一个。有些邀请卡片里的 Accept 控件甚至不是 <button>，而是 <a>，普通 CDP 点击不一定能触发接受动作。

这种细节说明，真实网页自动化不是“定位到元素就结束”。按钮标签、事件绑定、软导航、组件实现方式，都会影响操作是否真的生效。

对 Agent 来说，这类经验还有一个安全含义：涉及社交账号、邀请、消息、发帖的操作，不应该完全托管。skill 可以记录路径和陷阱，但批量接受邀请、对外发送内容、修改账号资料这类动作，最好保留人工确认。

例子：Shopify Admin

Shopify Admin 的经验说明了另一个问题：后台系统往往不是一个页面，而是一堆嵌入式应用和复杂组件的组合。

很多 Shopify app 会运行在 iframe 里。Polaris React 输入框、Web Components、嵌入式 app 的交互方式也不同。某些输入框不能只用 element.value = ...，需要使用更接近真实键盘输入的 CDP keystrokes。

这类 skill 的价值在于，它让 Agent 先判断当前页面属于哪类 UI，再选择合适的操作方式。

同时，Shopify 的经验也强调“能不用浏览器就不用浏览器”：

只读商品和库存数据，优先用 Storefront API。
有 Admin API token 时，优先用 Admin API。
编辑主题代码时，优先用 Shopify CLI。
只有没有 API、一次性设置、探索后台时，才适合让浏览器介入。

这才是成熟的 Agent 工具选择逻辑。

例子：Browser Use Cloud

domain skills 不只服务网页点击，也可以记录围绕浏览器运行时的 API 经验。

Browser Use Cloud 的经验里，会记录如何通过 REST API 创建 cloud browser、列出正在运行的浏览器、清理 zombie browser、获取 liveUrl 和 cdpUrl 等信息。

这说明 skill 的边界并不局限于“某个网页按钮怎么点”。只要某类任务会反复出现，而且有稳定做法，就可以沉淀成 skill：

API 调用方式。
鉴权头格式。
请求和响应结构。
已验证状态码。
常见失败模式。
清理和回收资源的方法。

对 Agent 来说，这些都是可复用能力。

为什么这比临场推理更可靠

很多人期待大模型每次都能“自己看懂网页”。但真实任务里，只靠临场推理并不稳定。

原因很简单：

网页 UI 经常变化。
同一按钮可能有多种实现。
看得见不代表点得动。
能点击不代表操作真的生效。
有些任务本来就应该用 API，而不是浏览器。
有些操作需要人类确认，不能让模型自己决定。

domain skills 把这些经验写成文件后，有几个好处：

人类可以 review。
错误经验可以修正。
同一站点的经验可以持续积累。
新 Agent 可以直接继承旧经验。
临时任务发现可以变成长期知识。

这比把一切都塞进 prompt 或聊天上下文更稳。

团队可以怎么用

如果把 browser-harness 用在团队里，domain skills 可以变成一种轻量自动化知识库。

比较适合沉淀的内容包括：

内部后台的登录后路径。
报表导出流程。
常见弹窗处理方式。
哪些按钮需要人工确认。
哪些页面有 API 替代方案。
哪些选择器经过实测可靠。
哪些任务不允许 Agent 自动执行。

这类知识不必一开始就很完整。更实际的做法是从低风险、高频、可回滚的流程开始：先让 Agent 做只读、下载、整理、检查类任务。等流程稳定后，再把经验整理成 skill。

对团队管理者来说，skill 文件还有一个好处：它让自动化边界变得可见。你可以审查 Agent 知道什么、能做什么、应该停在哪里。

需要注意的边界

domain skills 能提高 Agent 成功率，但它不应该让高风险操作完全自动化。

几个边界要守住：

不记录密码、Cookie、token、客户数据和内部敏感 URL。
支付、删除、批量提交、账号变更、对外发布内容，要保留人工确认。
skill 要写明验证日期和适用范围。
站点改版后，要允许 skill 失效并重新验证。
不要把绕过风控、规避平台限制当成目标。

换句话说，domain skill 是让 Agent 更稳，不是让 Agent 无限制地做事。

三者核心对比

维度	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：

 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/