浏览器自动化：12 个同类技能，到底该装哪个
同一件事有 12 个方案时，「推荐」必须给出理由
先看结论
- 12 个技能底层只有三条路线：CDP 直连（本地 CLI）、Playwright/Puppeteer 驱动（本地库）、云浏览器 API（第三方代跑）。
- 真正的差异不是「能不能自动化」，而是四件事：执行位置（本地/云）、登录态在哪、反爬能力、数据是否出本机。
- 80% 的日常需求（登录后抓取、填表、截图、取正文）：本地 CLI 方案足够，首选 agent-browser，或直接用平台内置浏览器。
- 想让 AI 用自然语言操作复杂页面：browser-use（11.9 万 star，MIT）是当前最成熟的开源选项，但要把页面数据和 API Key 交给第三方服务，先想清楚值不值。
- 绕过 Cloudflare / 自动过验证码（stealth-browser 一类）：技术和合规风险都高，普通用户不要装。
一、技术分层
12 个技能，只有三条路线。名字不同、卖点相似，看底层是哪一层在做差异，就知道该比什么。
浏览器对外暴露的控制协议。CDP（Chrome DevTools Protocol）是事实标准，WebDriver / BiDi 是跨浏览器方案。这一层决定了能控制多细——从打开页面到拦截网络请求都在这里。
CDP · WebDriver · BiDi把协议封装成人能写的 API。Playwright 和 Puppeteer 是两个主流驱动，决定了稳定性、等待策略、多浏览器支持。技能市场里大多数「浏览器技能」本质上都在这一层换皮。
Playwright（9.9 万 star）· Puppeteer · Selenium把驱动包装成 agent 能调用的形态：CLI 命令、MCP 服务、HTTP 接口。这一层决定了「安装门槛」和「AI 调用友好度」，也是 12 个技能名字各异的主要原因。
agent-browser · clawbrowser · browserwing · stagehand最后落在 WorkBuddy 技能市场或 DSH 内置工具里。平台层只决定「怎么装、装在哪」，不改变底层能力上限。
WorkBuddy 市场 12 个 · DSH 内置浏览器工具二、方案对比
按「执行位置 / 反爬 / 成本 / 安装门槛」四个真正影响选择的维度对比；星标与许可取自上游仓库。
| 方案 / 形态 | 底层实现 | 执行位置 | 反爬 | 成本 | 安装门槛 | 证据 |
|---|---|---|---|---|---|---|
| DSH 内置浏览器工具 平台内置 |
内置浏览器宿主（无需安装） | 本地 | 中 | 免费 | 无 | 本会话可用 |
| agent-browser / agent-browser-core 本地 CLI · ★ 45,037 · Apache-2.0 |
Rust 实现 + Node 回退，CDP 直连 | 本地 | 中 | 免费 | 装 CLI + 本地浏览器 | 上游核验 |
| browser（Puppeteer） 本地库 |
Puppeteer headless | 本地 | 弱 | 免费 | Node 环境 | 市场目录核验 |
| playwright-browser-automation / playwright-scraper-skill 本地库 · ★ 98,992 · Apache-2.0 |
Playwright 直接调用（后者自带一些反爬调参） | 本地 | 弱到中 | 免费 | Node/Python 环境 | 市场目录核验 |
| clawbrowser 本地 CLI |
Playwright CLI 封装 | 本地 | 中 | 免费 | 装 Playwright CLI | 市场目录核验 |
| browserwing 本地 HTTP 服务 |
本地浏览器 + HTTP API | 本地 | 中 | 免费 | 需常驻一个服务进程 | 市场目录核验 |
| browser-use Python 库 + 云服务 · ★ 119,684 · MIT |
LLM 驱动浏览器（本地库开源，云端托管收费） | 本地或云 | 中到强 | 开源库免费；云服务按量付费 | Python + 模型 API Key | 上游核验 |
| browser-cash 云浏览器 API |
第三方托管浏览器，主打反爬绕过 | 云 | 强 | 按量付费 | API Key + 付费 | 市场目录核验 |
| stagehand-browser-cli（Browserbase） 云浏览器 + 自然语言 CLI |
Browserbase 托管 + Stagehand 封装 | 云 | 中到强 | 按量付费 | BROWSERBASE_API_KEY + 付费 | 市场目录核验 |
| stealth-browser 本地（对抗型） |
反检测 + Cloudflare 绕过 + 付费验证码求解 | 本地 | 极强 | 免费 + 验证码求解器付费 | 2captcha / anticaptcha / capsolver 的 Key | 市场目录核验 |
三、每个方案适合什么
适合一次性打开页面、取正文、点按钮、截图；本会话已可直接调用
避开长期批量任务、需要精细控制并发和重试时
适合登录后抓取、定时任务、多步骤操作、截图留档；日常首选
避开强反爬站点；没有本地运行环境时
适合渲染 JS 重的公开页面、简单正文抓取
避开复杂交互、需要登录态的流程
适合网页回归测试、批量截图、表单自动化、结构化抓取
避开希望「装完即用」的非技术用户
星标为底层驱动 microsoft/playwright
适合已经装过 Playwright、想直接用 CLI 的场景
避开没装过 Playwright 的新手（不如直接用 agent-browser）
适合多步骤流程、跨语言/跨进程调用同一浏览器
避开只是偶尔用一次，多一个进程不值
适合用自然语言描述任务、页面结构复杂多变、愿意为省心付费
避开数据不能出本机、不想付 API 费用
适合目标站点反爬强、需要多地域出口、企业有预算
避开处理账号密码/隐私数据；个人日常使用
适合快速验证自动化想法、不想自己维护浏览器
避开长期高频任务（按量计费成本会上去）
适合不建议普通用户使用
避开所有未经目标站点授权的场景——合规与封号风险远大于收益
四、按场景选：直接抄
| 你的情况 | 选它 | 为什么 |
|---|---|---|
| 只是想打开一个页面、取正文、点一下按钮、截个图 | DSH 内置浏览器工具 | 零安装；内置工具已经覆盖导航、点击、取文本、截图、执行 JS |
| 需要登录态，而且要每天/每周定时跑 | agent-browser | 登录态在本地，批量任务和重试可控；CLI 形态容易套进脚本 |
| 页面需要多步点击填表、流程固定 | agent-browser 或 browserwing | 前者适合单次/脚本化，后者适合让多个流程共享一个常驻浏览器 |
| 想让 AI 自己看懂页面、按自然语言完成任务 | browser-use | 开源里最成熟；但先确认数据能不能出本机、是否愿意承担模型调用费用 |
| 做网页回归测试、批量截图、响应式检查 | Playwright（playwright-browser-automation） | 测试场景的等待策略和断言能力，比通用抓取技能更合适 |
| 目标站点反爬很强，或需要多地域 IP | 云浏览器（browser-cash / Browserbase），或直接找官方 API | 本地方案拼不过专业云服务；但先确认业务合规、数据不敏感 |
| 想绕过 Cloudflare、自动过验证码 | 不推荐 | 多数情况违反目标站点条款；用官方 API 或拿到授权再谈自动化 |
五、风险与边界
- 账号风险：自动化操作容易被风控识别，轻则要验证，重则封号；主账号不要用来跑自动化。
- 数据外发：云浏览器和 browser-use 云服务会把页面内容、有时还有登录态送到第三方，处理敏感数据前先确认。
- 权限过大：能操作浏览器的技能，等于能读你所有已登录的网站和应用；装之前看它要什么权限。
- 不可逆操作：批量删除、批量提交、付款类流程，第一次一定先用测试账号或 dry-run。
- 合规边界：robots、服务条款、个人信息保护都要看；抓别人平台的数据做二次分发，风险不在技术层。
六、最终推荐
默认组合：DSH 内置浏览器工具（零安装、日常够用）+ agent-browser（需要登录态、批量、定时任务时）。
第二梯队：页面复杂且愿意付模型费用，再上 browser-use；它有 11.9 万 star 和 MIT 许可，是当前最稳的开源选择。
云浏览器和反检测方案：不是不能选，但要先回答「数据能不能出本机」「目标站点是否授权」这两个问题，再谈强弱。
一句话：先问合规和隐私，再问场景，最后才问哪个技能更强。
本文是依据仓库公开数据、市场清单与平台文档做的结构与选型分析，不是跑分实测；性能与反爬效果会随站点更新变化，以你自己的场景验证为准。
数据来源
- 2026-10-27
- WorkBuddy 公开市场清单（浏览器类技能 12 个）
- 2026-10-31
- agent-browser 仓库
- 2026-10-31
- browser-use 仓库
- 2026-10-31
- microsoft/playwright 仓库
发现错误？提交纠错，核实后更新。