无头浏览器选型指南：Playwright、Puppeteer与Selenium实战对比

把无头浏览器塞给Agent用，这件事我最近和几个做自动化项目的老朋友反复聊过好几次。大家遇到的痛点高度一致：模型已经把任务拆解得很像样了，结果一到“打开页面、点击按钮、取回数据”这一步，手里没有一套趁手的浏览器操作工具，整个Agent就只能干瞪眼。而所谓无头浏览器，说白了就是一个没有界面的浏览器内核，它依然会加载JavaScript、渲染页面、维护Cookie，只是所有动作都通过代码驱动，运行在服务器或者容器里。Agent有了它，才算真正长出“眼睛和手”，能去真实网页里完成登录、查询、填表、下载、截图这一系列操作。这篇文章我会把几款主流方案逐个拆开，讲清楚它们各自适合什么场景、有什么坑，并给出我在真实项目里反复验证过的配置写法。不管你是在搭自己的Agent项目，还是正在给现有系统补自动化能力，都值得往下看。

1. 为什么Agent离不开无头浏览器：场景与选型逻辑

1.1 Agent到底需要浏览器做什么

很多人一开始会误以为Agent要浏览器就是为了爬数据。实际上在我接触到的项目里，Agent操作浏览器的需求比这宽得多。最典型的是这几类：一是自动登录并维持会话，比如每天早上定时去后台拉经营报表；二是在交互复杂的SPA应用里完成流程，比如创建订单、审核工单、填写表单提交；三是需要读取JavaScript渲染后的真实页面内容，因为很多网站的数据接口加密或者鉴权复杂，直接发HTTP请求拿不到完整数据；四是对页面状态做断言与监控，比如定时检查核心页面是否可用、关键文案是否被篡改。

这些场景如果硬用requests或者httpx去模拟，很快就会碰壁。现代网站的登录流程往往带设备指纹校验、滑块验证、加密参数，页面数据又常由异步接口动态渲染，你如果不让Agent操作一个真实的浏览器环境，很多请求根本到达不了业务层。无头浏览器在这里扮演的，是一个“真正的人坐在电脑前用Chrome操作”的等价物。

1.2 无头浏览器与普通HTTP客户端的分界线

我自己的判断标准很简单：如果你只需要稳定调用公开接口或能轻松复现的API，直接走HTTP请求，省时省力。一旦目标页面依赖登录态、反爬参数、动态渲染，或者你的Agent需要做多步骤交互，再犹豫就不值当了，直接上无头浏览器。两者不是替代关系，而是互补关系。

一个特别直观的例子：某些系统导出Excel报表的按钮，实际上是前端在拿到数据后通过JavaScript库在本地生成文件再触发下载。这种情况下你直接请求接口拿到的可能是一串加密数据，而用无头浏览器点击导出按钮，文件就自然出现在你指定的目录里。Agent的无头浏览器价值，恰恰体现在这些“不那么标准”的网页交互上。

1.3 选型前先想清楚的四件事

我在给项目做技术选型之前，一定会让团队回答四个问题：

1. 你们的主力开发语言是Python还是Node？这会直接锁定主方案。
2. 业务页面是传统多页应用还是重度SPA？后者对等待策略和渲染完成判断要求更高。
3. 并发规模有多大？是单Agent串行执行任务，还是一次需要拉起几十上百个并发浏览器实例？这决定了你需不需要引入浏览器实例池。
4. 是否已经有Selenium/WebDriver体系的历史资产？如果有，迁移成本必须算进去。

把这四个问题答完，选型方向基本就清晰了大半。下面进入正题，聊聊我实测过的主流方案。

2. 主流方案横评：Playwright、Puppeteer、Selenium以及Agent专用浏览器框架

2.1 Playwright：Agent场景的综合首选

如果今天有人问我第一次给Agent配无头浏览器该选什么，我大概率会推荐Playwright。倒不是因为它功能最多，而是它在“贴近真实用户”这件事上做得最省心。

Playwright有几个点对Agent开发极其友好。第一是自动等待机制，它会持续重试元素定位直到元素可操作，不用你在代码里到处Sleep。这对LLM决策驱动的Agent来说太重要了——模型给出的操作指令有时并不精确到像素级，自动等待能消掉很多不确定性。第二是浏览器上下文隔离，一个BrowserContext就相当于一个独立的浏览器会话，Cookie、LocalStorage、缓存全部分开。Agent并行跑多个任务时，给每个任务一个独立Context，互不污染，比自己在代码里管理会话干净得多。第三是多浏览器内核支持，Chromium、Firefox、WebKit都行，遇到只在WebKit渲染下有问题的页面也不用推翻重来。

下面是一个基础用法，我用的是Python版本：

from playwright.sync_api import sync_playwright with sync_playwright() as p: browser = p.chromium.launch(headless=True) context = browser.new_context( viewport={"width": 1280, "height": 720}, user_agent="Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 Chrome/124.0.0.0 Safari/537.36" ) page = context.new_page() page.goto("https://example.com", timeout=30000) page.get_by_role("button", name="登录").click() page.wait_for_load_state("networkidle") html = page.content() context.close() browser.close()

在Agent场景里，我建议用new_context()而不要在同一个页面里反复goto不同任务目标，因为历史网页里的脚本可能污染后续操作。

2.2 Puppeteer：Node生态里的轻量选择

如果你的Agent主体是Node.js写的，Puppeteer是切入成本最低的选择。它由Chrome团队官方维护，API调性和Chrome DevTools Protocol一脉相承，文档丰富，遇到问题搜起来也方便。

Puppeteer默认只支持Chromium系，对Firefox和Safari的支持相对弱。这个限制在大多数Agent场景里影响不大，毕竟只要产品团队没有“必须兼容Firefox”的硬性要求，Chromium内核已经能覆盖绝大多数真实用户环境。它的内存占用和启动速度在几款方案里属于中上水平，bug修复也比较及时，适合直接嵌入到已有的Node服务里。

但要说缺点，Puppeteer在稳定性方面比Playwright稍微“糙”一点。你经常要自己处理元素加载、自己判断页面是否完成渲染，代码写多了以后，等待逻辑会占掉很大篇幅。如果你打算让Agent自动决定操作步骤，这种额外的心智负担会被放大。我的建议是：Node技术栈且对自动化复杂度要求不高的项目选Puppeteer；一旦流程复杂度上来，哪怕用Python侧调用Playwright，也比在Puppeteer里堆一堆waitForTimeout强。

下面是一段Puppeteer的经典写法：

const puppeteer = require('puppeteer'); (async () => { const browser = await puppeteer.launch({ headless: 'new', args: ['--no-sandbox', '--disable-setuid-sandbox'] }); const page = await browser.newPage(); await page.setUserAgent('Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 Chrome/124.0.0.0 Safari/537.36'); await page.goto('https://example.com', { waitUntil: 'networkidle2', timeout: 30000 }); await page.waitForSelector('button.login-btn', { timeout: 10000 }); await page.click('button.login-btn'); await browser.close(); })();

注意headless: 'new'，这是新版无头模式，和旧版相比对现代Web特性的兼容性更好，不容易被网站识别为异常环境。

2.3 Selenium：老牌方案适合什么场景

Selenium是很多测试团队的“原配”，WebDriver协议也一度是事实上行业标准。如果你们团队之前已经用Selenium维护了大量测试用例，或者被测系统里有大量针对WebDriver做的兼容适配，那我不会劝你立刻迁移，继续用Selenium完全合理。

不过放在Agent场景里，Selenium的短板比较明显。首先是API风格偏底层，写起来啰嗦，明明一个简单点击动作，要显式等待、定位元素、再调用点击方法，代码量比Playwright多出一截。其次是并发性能一般，每个WebDriver会话的管理成本较高，想在单机跑几十个并发Agent实例会比较吃力。还有就是等待策略不够智能，经常需要靠time.sleep或者WebDriverWait配合自定义条件兜底。

如果你确实要为已有Selenium体系接入Agent，我会建议把Selenium封装成一层工具服务，让Agent通过接口调用，而不是让模型直接去写Selenium代码。这样既保留历史资产，又能把自动化细节和Agent决策逻辑隔离开。不过对新项目来说，我不会主动推荐它做首选。

2.4 面向Agent的专用框架：browser-use与Skyvern

过去一年冒出了不少给Agent定制的浏览器框架，主题思想都是“让LLM通过自然语言直接操作浏览器”。典型代表有browser-use和Skyvern。browser-use的思路是把Playwright封装成Agent可调用的工具集，再配合LLM的视觉或DOM提取能力，让模型“看懂”页面然后决定下一步动作。Skyvern则更激进，主打免训练的场景理解，靠视觉模型识别页面元素完成操作。

这类框架的上手体验确实惊艳：你只需要写几行声明式配置，模型就能完成“去某网站搜索某关键词，把第一条结果标题取回来”这类任务。但要注意，目前它们离生产级稳定还有距离。LLM决策存在不确定性，页面稍微改版或者出现可预期之外的弹窗，就可能翻车。我比较推荐的做法是：把这类框架用于原型验证或低风险的流程，核心业务链路还是用Playwright写好固定逻辑作为兜底，Agent只负责在关键分支上做选择。

2.5 关键技术指标对比

说实话，给Agent用无头浏览器，本质上是选执行层的稳定性方案。模型负责“想”，浏览器负责“做”，执行层稳定性不够，任务拆解得再好都会塌。

3. 围绕Agent场景的实操配置：环境准备与核心调用模式

3.1 环境安装与依赖处理

以Playwright为例，安装过程有几个常见坑。直接用pip install playwright只能装Python包，真正能跑还得加一步playwright install chromium，这一步会下载浏览器二进制文件，体积不小，大概两三百兆。在容器里跑的话，还要额外装系统依赖库，建议用官方提供的基础镜像，或者执行playwright install-deps。

如果你发现下载慢，可以设置镜像环境变量。不过镜像地址经常变，这里我建议优先直接使用官方下载，毕竟这部分属于一次性成本，稳定比速度重要。装完之后可以用下面这条命令验证环境是否就绪：

python -c "from playwright.sync_api import sync_playwright; sync_playwright().start(); print('ok')"

没有报错，再看Chromium能否拉起无头模式。如果服务器缺少依赖，启动时会报类似“libnss3 not found”的错误，直接对照错误信息安装对应系统包即可。

3.2 浏览器生命周期与上下文隔离

Agent项目最容易出问题的，是忽略浏览器实例和上下文的生命周期管理。一个Python进程里，browser.launch()对应一个浏览器进程，而browser.new_context()对应一个独立的会话。每一个new_page()都是会话里的标签页。

我建议的模式是：浏览器实例全局复用，为每个Agent任务创建一个新Context，任务结束就context.close()。这样浏览器进程只需启动一次，开销小；每个任务之间又互不共享Cookie和缓存，数据隔离干净。如果直接把多个任务塞进同一个Page里轮番goto，很可能会出现登录态串号、存储污染、元素定位互相干扰等诡异问题，排查成本极高。

from playwright.sync_api import sync_playwright class BrowserAgent: def __init__(self): self._pw = sync_playwright().start() self.browser = self._pw.chromium.launch( headless=True, args=["--disable-blink-features=AutomationControlled"] ) def new_session(self): context = self.browser.new_context( locale="zh-CN", timezone_id="Asia/Shanghai" ) page = context.new_page() return context, page def close_session(self, context): context.close() def shutdown(self): self.browser.close() self._pw.stop()

当然，这只是一个极简骨架。实际项目里你还需要给Context挂载请求拦截、注入脚本、绑定事件回调等能力。

3.3 页面信息的结构化提取

Agent拿到页面后，不能只靠原始HTML做推理，token太长，噪声也大。我更推荐把页面转成结构化数据再喂给Agent。常用的做法有两种：一种是靠选择器精准提取关键字段，另一种是把整个DOM简化成带语义标签的文本骨架。

第一种适合固定页面、固定流程，比如提某个工单列表的标题和状态：

def extract_order_list(page): rows = page.locator("table.order-table tbody tr").all() result = [] for row in rows: cells = row.locator("td").all() if len(cells) >= 3: result.append({ "order_id": cells[0].inner_text().strip(), "title": cells[1].inner_text().strip(), "status": cells[2].inner_text().strip() }) return result

第二种适合不确定页面结构，需要大模型来做理解的情况。我一般会把可见的文本、链接href、按钮文案、输入框placeholder抽成紧凑的JSON或者Markdown树，控制长度之后再交给模型。这样既保留了操作所需的关键信息，又不会让模型被海量DOM标签淹没。

3.4 登录态持久化

Agent跑任务不可能每次都重新登录。Playwright提供了storage_state，可以把登录后的Cookie和LocalStorage保存到文件，下次直接复用。

保存阶段：

context = browser.new_context() page = context.new_page() # 这里执行一遍真实登录操作 page.goto("https://admin.example.com/login") page.get_by_label("用户名").fill("tester") page.get_by_label("密码").fill("password") page.get_by_role("button", name="登录").click() page.wait_for_load_state("networkidle") context.storage_state(path="agent_state.json")

复用阶段：

context = browser.new_context(storage_state="agent_state.json")

这里有两个要注意的细节：一是登录态会过期，复用前最好加一个快捷的登录状态校验，比如访问某个需要鉴权的接口，发现跳转到登录页就重新登录；二是如果你跑的是对安全性比较敏感的系统，不要把明文密码写在代码里，用环境变量或者密钥管理服务去存。

3.5 超时、重试与任务级兜底

无头浏览器跑在服务器上，网络波动、页面假死、CDN限流都是家常便饭。一套健壮的超时重试机制是必备的。我的习惯是给每次导航设置30秒超时，元素定位设置10到15秒；单步操作失败后，最多重试3次，前两次间隔较短，最后一次把页面截图和DOM快照存下来，方便事后排查。

更关键的是，要给Agent的整体任务设定一个总时间预算。比如单个页面操作序列最多执行5分钟，超时就强制关闭Context。这个做法能避免模型在一个错误循环里反复横跳，把服务器资源白白耗掉。你可以给Agent提供两个工具：一个叫snapshot_page，另一个叫close_and_restart，让它在自我感知到状态异常时主动恢复。

4. 踩坑实录：无头浏览器在Agent项目里的高频问题与排查链路

4.1 被网站识别为自动化环境，怎么定位和处理

这是大家在社区里问得最多的一个问题。现象是：本地手动浏览器打开页面一切正常，换成Playwright无头模式后，要么弹验证码，要么接口返回异常数据，要么直接403。

排查看三个点：第一，User-Agent是否被换成了默认的无头UA；第二，是否暴露了navigator.webdriver标记；第三，浏览器的自动化指纹如window.chrome、permissions状态是否和正常Chrome有明显差异。

处理方式是逐项修复。先显式设置真实的User-Agent；再通过启动参数--disable-blink-features=AutomationControlled来去掉webdriver标记；还有，不要一上来就追求隐身和绕过，很多网站的防护强度并没有那么高，只要UA和行为节奏看起来像真人，就能通过。配合随机滚动、可变输入速度、真实鼠标轨迹这些操作，比追求指纹完全一致成本低得多，也稳定得多。

这里必须提醒一句：自动化操作必须在你拥有合法授权的前提下进行。技术本身是中性的，但越过了授权边界，后面的一切都不成立。

4.2 内存泄漏和长稳运行问题

Agent服务和普通爬虫不太一样，它可能会持续跑几天甚至几周。这时候内存泄漏问题会被放大。最常见的原因是：全局只创建了一个Page，任务循环里反复goto，每切换一个页面就积累一批DOM节点；或者创建了很多Context但忘记close()，导致浏览器进程里残留大量会话数据。

排查内存问题的一个有效方式是监控浏览器进程的RSS内存。你可以用psutil在任务循环里定期打印占用：

import psutil, os def memory_mb(): proc = psutil.Process(os.getpid()) return proc.memory_info().rss / 1024 / 1024

如果每次任务结束内存都在上涨，优先检查Context是否关闭、Page是否被显式释放、事件监听器是否被移除。Playwright提供的事件回调，比如page.on("request")、page.on("console")，如果绑定后没有解绑，也会成为隐藏的内存增长点。我的做法是把所有事件监听都收敛到一个独立的监听管理器里，任务结束时统一清理。

4.3 等待逻辑与实际渲染状态不一致

SPA页面最大的坑是“你以为加载完了，其实还没”。goto()返回时，只代表导航请求被响应，不代表页面里的异步数据都渲染完成。很多时候你急着定位元素就会失败。

应对策略是分层次等待。第一步用page.wait_for_load_state("networkidle")等待网络空闲只是个粗粒度保障；第二步精确等待你要操作的那个元素可见可点，Playwright会自动重试。如果业务页面有骨架屏或者加载动画，最好再补一个“动画结束”判断。

有一个灵活的技巧是轮询页面里的关键文本或数字，等到它符合预期再继续。比如价格、订单数量这类动态数据，你直接等它稳定下来再提取。这在做数据采集的Agent任务里非常实用，能大幅降低误抓半成品数据的概率。

4.4 元素定位在多级iframe和Shadow DOM下的失效

很多后台系统里嵌了iframe，Playwright定位默认只处理顶层文档，对于跨iframe的元素，需要先切换到对应frame。我见过不少人在这一步卡住，报错倒是直白：找不到元素。排查时先确认元素是否在iframe里，用page.frames列出当前页所有frame，再逐个看内容。

Shadow DOM是另一个重灾区。如果页面用了自定义组件，元素可能在Shadow Root内部，常规选择器碰不到。Playwright支持穿透实现，定位符默认可以穿透open类型的Shadow DOM，但遇到closed类型的就没办法了。遇到这种页面，我的建议是优先和业务侧沟通，看能否给关键元素加可访问性属性，这比技术绕过省力得多。

4.5 并发场景下的浏览器资源水位控制

Agent一旦需要并行执行任务，CPU和内存会被迅速打满。我跑过20个并发Context的实验，单机器很快就出现明显卡顿和响应延迟。后来采用的策略是做一个简单的信号量控制并发上限，并根据任务类型动态调整。例如消息采集类任务并发线程控制在8以内，报表截图类任务控制在4以内。

另外一个便宜好用的优化是拦截无用资源。很多页面会加载一堆统计脚本、字体文件、图片素材，而Agent只关心核心DOM和接口数据。通过路由拦截把CSS、图片、字体请求直接放弃，页面加载速度和资源占用都能改善不少。

def block_unused_resources(route): if route.request.resource_type in ("image", "font", "stylesheet"): route.abort() else: route.continue_() context.route("**/*", block_unused_resources)

我用这个规则在日常项目中把页面平均加载时间压缩了将近一半，效果非常直观。

5. 我的选型建议与几个提升Agent体验的偏方

5.1 不同体量项目的选型组合

我按项目体量给三条明确的建议，你照着套就行：

• 个人脚本或小工具：单看开发效率，直接选Playwright，Python或Node都行。功能完善、API顺手，几乎没有需要额外补的轮子。
• 成熟Web平台的Agent服务：Playwright做核心执行层，再用browser-use这类框架做动态决策的试验田。固定流程写死，动态分支交给模型，两侧各司其职。
• 有大量遗留前端自动化资产的大型团队：先用Selenium把旧用例保住，同时新模块逐步切换到Playwright，形成双轨过渡。过急的迁移很容易让原本稳定的回归体系崩掉。

5.2 降低资源占用的几个参数

很多人不知道Playwright启动浏览器时可以通过参数大幅降低资源占用。在我本机压测中，下面这个组合能让单实例内存占用降不少：

browser = p.chromium.launch( headless=True, args=[ "--disable-gpu", "--disable-dev-shm-usage", "--no-sandbox", "--disable-extensions", "--disable-background-networking", "--disable-sync", ] )

--disable-dev-shm-usage在容器里几乎必加，否则/dev/shm太小容易导致渲染崩溃。--disable-gpu在纯无头环境里没有副作用，却能少一块显存占用。--disable-extensions也能避免无关扩展加载带来的开销。

5.3 给Agent记忆系统准备的浏览器交互记录

Agent的记忆不是一句“记住上次做到哪了”就完了，它需要可检索、可回溯的任务状态。我在项目里会把每一次浏览器关键操作记录成结构化的JSON事件，存进消息队列或者数据库。事件内容包含动作类型、目标URL、元素描述、截图路径、时间戳、结果摘要。当Agent在后续对话中需要回忆时，这些记录就是它的短期记忆。

更近一步，我还会每隔一段时间对当前页面做全量快照，包括页面标题、可见文本、关键表单值、Cookie摘要。这样即使Agent进程中途崩溃重启，也能从最近一次快照恢复上下文，而不是从头开始。

5.4 个人经验的最后补充

给Agent配无头浏览器，选型只是第一步，后面更多功夫花在稳定性和错误恢复上。我自己的体会是：不要一开始就追求让模型自由操作一切，先用固定脚本把核心链路跑通，再逐步把分支决策开放给模型。这个顺序反过来，你大概率会收获一堆莫名其妙的重试和报错。

还有一个小技巧，值得多说一句：执行无头浏览器任务的机器，最好单独隔离，不跟业务应用混部署。浏览器进程的资源占用波动很大，它崩溃了不应该把主业务拖垮。用Docker或者Kubernetes Job去承载这类任务，配上资源限制和自动重启策略，比在裸机进程里裸奔稳得多。

无头浏览器的生态更新很快，新框架层出不穷，但底层逻辑始终没变：让Agent能像人一样看到页面、操作页面、从页面里学习。把这个执行层打磨扎实了，Agent的能力上限才真正有保障。