Agent 操作浏览器的九条路线：从 Playwright 到 Computer Use

上个月一个团队来找我，说他们要做企业内部的 AI Agent，需要操作浏览器。

第一个问题就是：「用 Playwright 还是 Browser Use？」

我说这个问题本身就问错了。就像你问「盖楼用钢筋还是混凝土」——答案是都用，但用在不同的层。

Browser Automation 在 AI Agent 语境下，已经不是一道单选题。它是一张技术地图，九个梯队，各有适用场景。而真正在生产环境里跑通的企业 Agent，几乎都是 分层架构——API 优先，结构化浏览器控制居中，Vision 兜底。

评判标准

在展开九个梯队之前，先说清楚筛选标准。不是所有浏览器自动化技术都适合 Agent 场景。我的三条硬约束：

流行（Popular）+ 鲁棒（Production Ready）+ MCP / Agent 可集成

流行意味着社区活跃、文档齐全、踩坑有人答。鲁棒意味着能扛住生产环境的各种异常——弹窗、验证码、网络抖动、页面改版。MCP / Agent 可集成意味着它能被 LLM 驱动，而不是只能写死在脚本里。

不满足这三条的技术，不在这张地图里。

第一梯队：Playwright

定位：Browser Automation 的事实标准。

Microsoft 出品，GitHub 100k+ Stars。几乎所有主流 AI Browser Agent 的底层都是它：

Claude Code
OpenAI Computer Use
Browser Use
Stagehand
Skyvern
# generated by hugo AI

优点很硬：最稳定、API 最完整、跨浏览器（Chromium / Firefox / WebKit）、社区最大。你在 Playwright 上遇到的问题，Stack Overflow 上基本都有答案。

但它有三个结构性短板，恰好是 Agent 场景的痛点：

每次启动新 Browser——没有用户登录态，企业内网系统进不去
Session 不共享——Agent 和你看到的不是同一个浏览器
企业登录体验差——SSO、MFA、证书认证，Playwright 处理起来很痛苦

适合：测试、自动化、CI/CD。不适合：需要复用用户登录态的企业 Agent。

第二梯队：Chrome DevTools Protocol（CDP）

Browser MCP 的很多能力，其实建立在 CDP 之上。

Chrome
    ↓
CDP
    ↓
Client
# generated by hugo AI

CDP 是 Chrome 的官方调试协议，Puppeteer、Browser MCP、Chrome Extension、DevTools 底层都走它。

优点是官方支持、功能最完整、可以调试任何页面。缺点是 API 比较底层，需要自己封装——你拿到的是原始能力，不是开箱即用的框架。

很多 Browser MCP Server 的架构其实就是：

MCP
↓
CDP
↓
Chrome
# generated by hugo AI

CDP 不是一个「产品」，是一个「协议层」。你不会直接选 CDP，但你选的任何工具，底层大概率在用它。

第三梯队：Puppeteer

Google 官方出品，历史比 Playwright 更久。

很多早期 AI Agent 的浏览器控制层都是 Puppeteer：

LLM
↓
Puppeteer
# generated by hugo AI

比如 BrowserPilot、AutoGPT（早期）、AgentGPT（早期）。

Chrome 支持最好，这是它的主场。但 Playwright 后来居上——跨浏览器支持、更现代的 API、更活跃的社区，Puppeteer 在新项目里已经很少被优先选择了。

如果你今天从零开始，没有历史包袱，选 Playwright 而不是 Puppeteer。

第四梯队：Browser Use

最近 AI Agent 圈最火的浏览器框架之一。

它和前面三个的本质区别是：它不是 Browser Automation，而是 AI Native Browser Agent。

LLM
↓
Planner
↓
Browser Controller
# generated by hugo AI

它做了 DOM 理解、OCR、Vision、Action 的完整链路。你给它的指令不是 click(selector)，而是 Click the login button。

很多开源 Agent Demo 都基于 Browser Use，演示效果非常惊艳。

优点：AI Native、有 Planner、有 Agent Loop，天然适配 LLM。

缺点：底层还是 Playwright，生产成熟度一般。Demo 跑得好不等于生产扛得住——弹窗处理、异常恢复、长链路任务的稳定性，都还在打磨中。

我在 LLM 自动化 vs RPA 里分析过，这类 LLM 驱动的浏览器自动化，真正值钱的地方不是「智能」，而是 省掉了人工编排成本。Browser Use 的价值也在这里——它把「写 Selector」变成了「说人话」。

第五梯队：Stagehand

BrowserBase 出品，很多人叫它 Playwright for AI。

它的 API 设计完全围绕 LLM 优化：

await page.act("click checkout")
await page.extract("get the order total")
await page.observe("what's on this page")
# generated by hugo AI

而不是：

await page.locator("#checkout-btn").click()
# generated by hugo AI

act、extract、observe——三个动词覆盖了 Agent 操作浏览器的绝大多数场景。对 LLM 来说，生成 page.act(「click checkout」) 比生成正确的 CSS Selector 容易一个数量级。

非常适合 LLM 驱动的 Agent。生产成熟度比 Browser Use 好一截，但生态还在早期。

第六梯队：Skyvern

企业自动化方向。

核心卖点：不用写 Selector。直接给一个任务描述：

Complete this form.
# generated by hugo AI

Skyvern 同时用 Vision、OCR、DOM 三种方式理解页面，然后执行操作。

它更偏 Workflow 而不是单次操作——很多 SaaS Automation 场景在用它，比如自动填表、自动提交、自动下载报表。

生产成熟度不错，但灵活性不如 Browser Use 和 Stagehand。

第七梯队：OpenCLI / AutoCLI（网络拦截 + 内部 API 直调）

这是一条完全不同的路线。不操作 DOM，不截图，不写 Selector——直接拦截浏览器的网络请求，复用网站前端调用的同一个内部 API。

打开浏览器 → 触发页面加载 → 拦截网络请求 → 捕获 API endpoint → 直接复用 API 调用
# generated by hugo AI

OpenCLI（GitHub 16K+ Stars）是这个方向的开创者，AutoCLI 是它的 Rust 重写版，性能提升 12 倍（bilibili hot 命令从 20 秒降到 1.66 秒）。

opencli zhihu hot
autocli bilibili hot
# generated by hugo AI

一行命令，直接拿到结构化数据。不需要找 CSS 选择器，不需要处理动态加载，不需要和 Cloudflare 斗智斗勇。

它的核心洞察是： 你在从渲染结果反推数据，而不是直接拿数据本身。 就像去餐厅不看菜单，而是观察隔壁桌端上来的菜猜菜单内容。OpenCLI 直接去后厨拿菜单。

优点：

极快——跳过渲染，直接调 API，延迟是 DOM 方案的 1/10
极稳——不依赖 CSS 选择器，页面改版不影响（只要 API 不变）
数据完整——拿到的是 API 返回的原始字段，比 DOM 提取更丰富
自动带登录态——在浏览器上下文中 fetch，Cookie 自动携带

缺点：

只能做数据提取，不能做复杂交互（填表、点击、导航）
需要为每个网站适配（虽然社区已覆盖主流平台）
网站如果更换 API 接口，适配会失效

我在 OpenCLI vs AutoCLI：把网站变成 CLI 的技术革命里详细分析过这条路线的技术原理和成本模型。

对 Agent 来说，OpenCLI/AutoCLI 的价值在于： 如果任务只是「从某个网站拿数据」，它比开浏览器做 DOM 操作快一个数量级，而且完全不消耗 LLM Token。 它是分层架构里「API 优先」那一层的最佳实践——不是网站提供的公开 API，而是你自己「发现」的内部 API。

第八梯队：OpenAI Computer Use

OpenAI 的方向，和前面所有路线都不同。

不解析 DOM，不走 CDP，不用 Selector。纯粹靠视觉：

Screenshot
↓
Vision
↓
Mouse
↓
Keyboard
# generated by hugo AI

完全模拟人的操作方式。你看到什么，它就操作什么。

优点：什么都能操作——不限于浏览器，桌面应用、远程桌面、甚至游戏界面都行。

缺点：慢、Token 消耗大、精度不如结构化控制。每一步都要截图 + 推理，延迟和成本都是结构化方案的数倍。

第九梯队：Anthropic Computer Use

Claude 的 Computer Use，路线和 OpenAI 一样：

Vision
↓
Mouse
↓
Keyboard
# generated by hugo AI

很多 Computer Use 的早期 Demo 都来自 Anthropic。思路和 OpenAI 一致——放弃结构化解析，全面转向视觉操作。

两家的 Computer Use 目前都还在早期阶段，生产可用性不高。但方向很明确：当模型足够强、推理足够便宜时，Vision 会成为最终兜底。

Browser MCP 属于哪一类？

Browser MCP 比较特别。它不是 Vision，也不是 Playwright，而是：

真实 Chrome + Extension + CDP + MCP
# generated by hugo AI

架构长这样：

Agent
↓
MCP
↓
Browser Extension
↓
Real Browser
# generated by hugo AI

这是它最大的特点：操作的是用户 真实的浏览器，有登录态、有 Cookie、有历史记录。不需要新开一个干净的 Browser 实例，不需要重新登录。

对企业 Agent 来说，这个特性价值巨大——员工已经登录了 CRM、ERP、OA，Agent 直接在这个 Session 里操作，不用处理 SSO 和 MFA。

生产可用性排名

把九个梯队放在一起比：

技术	成熟度	鲁棒性	AI 友好	企业推荐
Playwright	⭐⭐⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐	⭐⭐⭐⭐⭐
CDP	⭐⭐⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐	⭐⭐⭐⭐⭐
Puppeteer	⭐⭐⭐⭐	⭐⭐⭐⭐	⭐⭐	⭐⭐⭐
Browser MCP	⭐⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐⭐
Stagehand	⭐⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐⭐
Browser Use	⭐⭐⭐	⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐
Skyvern	⭐⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐⭐
OpenCLI / AutoCLI	⭐⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐⭐
OpenAI Computer Use	⭐⭐	⭐⭐	⭐⭐⭐⭐⭐	⭐⭐
Anthropic Computer Use	⭐⭐	⭐⭐	⭐⭐⭐⭐⭐	⭐⭐

一个明显的规律： 成熟度和 AI 友好度几乎是负相关的。 越成熟的工具（Playwright、CDP）越偏底层、越需要人写精确指令；越 AI 友好的工具（Browser Use、Computer Use）越不成熟。

这不是巧合。成熟需要时间积累，而 AI Native 的范式才刚刚开始。

我的建议：四层分层架构

如果你的目标是构建企业级生产型 Agent，不要选一个框架，搭一套分层架构：

Agent
    │
    ├── API / OpenCLI / AutoCLI（最快、最稳定、零 Token）
    │
    ├── Browser MCP / Stagehand（真实浏览器 + AI 操作）
    │
    ├── Playwright / CDP（精确控制）
    │
    └── Vision Computer Use（最后兜底）
# generated by hugo AI

优先 API——能用 API 解决的事，绝不开浏览器。API 是最快、最稳定、最便宜的路径。没有公开 API 的网站，用 OpenCLI / AutoCLI 拦截内部 API 直调——一行命令拿到结构化数据，零 LLM Token 消耗。

其次结构化浏览器控制——Browser MCP 复用真实登录态，Stagehand 提供 AI 友好的操作抽象，Playwright / CDP 做精确控制。这一层覆盖 80% 的浏览器操作场景。

最后 Vision 兜底——只在 DOM 无法解析（Canvas、Flash 遗留、远程桌面）或页面结构完全不可预测时使用。慢、贵，但什么都能做。

这种分层架构比单纯依赖 Vision 或单纯依赖 Playwright 都更鲁棒。它也是目前不少企业级 Agent 系统正在演进的方向。

回到开头那个问题：「用 Playwright 还是 Browser Use？」

答案是：都用。但用在不同的层。

你的 Agent 在操作浏览器时踩过什么坑？欢迎留言讨论。