<!-- title: 给Agent配浏览器：四派横评 -->

# 给Agent配浏览器：四派横评

## 概述

本期是浏览器自动化赛道的同门横评。这个赛道近一年从「一个 browser-use 独跑」卷成了「四条流派同场」：Vercel 的 agent-browser 用一条命令行把浏览器开成纯文本快照；微软官方的 playwright-mcp 把无障碍树做成了 MCP 工具集；老牌选手 browser-use 依旧走「自带 Agent 循环」的整车路线；谷歌 Chrome 团队则递上 chrome-devtools-mcp，不帮你开车、专帮你修车。核心发现一句话：**这个赛道的竞争焦点已经不是「能不能操作浏览器」，而是「每一步操作烧多少上下文」**——截图派全线退场，快照派成了最大公约数。

## 为什么「配浏览器」突然成了红海

先说清楚这四件在争的是什么。Claude Code 这类编码 Agent 的默认外设是终端和文件系统，遇到「去页面上点一下」「看看这个按钮为什么点了没反应」「把竞品价格抄回来」这类活，就得给模型配一副能看见网页的手眼。

问题在于，网页对模型来说是出了名的贵：一张 1280×720 的截图喂进去几千 token，滚动一次再喂一张，一个十步的网页任务能烧掉几十万 token 的上下文。于是 2025 年下半年起，整个赛道集体转向同一个答案——**别给模型看图，给它看无障碍树（accessibility tree）**。浏览器自己就知道每个元素是什么按钮、什么输入框、什么文字，把这棵树序列化成文本，体积小一个数量级，还能给每个节点发一个稳定的编号（ref），模型点 `@e12` 比看图猜坐标靠谱得多。

四条流派的分歧，就在这棵树的「递法」和「谁负责循环」上。

## 四位选手速写

### 1. agent-browser：命令行里的驾驶舱（Vercel）

**定位**：把整套浏览器操作压缩成一条 CLI 命令，专为编码 Agent 设计。Vercel 出品，是这个赛道最新的大厂入场券。

**设计亮点**：它看准了 Claude Code 的原生习惯——模型最顺手的是 Bash 工具，于是不做 MCP、不做库，直接做 CLI：`agent-browser open <url>` 打开页面，`agent-browser snapshot` 吐出带 ref 编号的文本快照，`agent-browser click @e12` 用 ref 精确点击。核心用 Rust 写成常驻 daemon，命令秒回；会话、标签页、等待条件都做成子命令，整条交互就是「文本进、文本出」。它附带的 Agent 说明书里通篇在劝模型三件事：**别截图、用快照、拿 ref**——把省 token 写成了使用纪律。

**短板**：太年轻。iframe 嵌套、canvas 重交互、复杂验证流程这类边界场景，成熟度还需要时间验证；ref 编号每次快照后都会变，长链路操作对模型的状态记忆是个考验。

### 2. playwright-mcp：微软的官方式样

**定位**：Playwright 官方团队维护的 MCP 服务器，把浏览器操作拆成一格格标准工具：导航、点击、填表、快照、标签页管理、网络请求检查、控制台消息。

**设计亮点**：它是「无障碍快照」范式的定型之作——每次操作后返回一棵可访问性树，节点挂 ref，模型对着 ref 下一步操作；工具集覆盖面是四家里最全的，连 emulate 媒体特性、文件上传、对话框处理、无障碍快照内全文搜索都有独立工具。最大的护城河是**通用性**：任何支持 MCP 的客户端（Claude Code、IDE、其他 Agent 框架）都即插即用，一套工具四处复用。

**短板**：MCP 形态的通病——几十个工具的 schema 常驻上下文，还没干活先吃一笔固定开销；每次操作是一次完整的工具调用往返，比起 CLI 一条命令串多步，链路更长。

### 3. browser-use：自带司机的整车

**定位**：这个赛道最早出圈的名字，2025 年就是它把「让大模型开浏览器」变成了 `pip install` 一件事。它不是给现有 Agent 配外设，而是**自带 Agent 循环的 Python 库**。

**设计亮点**：拿到任务后自建循环——把 DOM 打上编号标签喂给 LLM，模型挑元素、库执行动作、再观察、再决策，支持任意主流模型，多标签页并行。社区声量四家最大，demo 传播度也最高，「20 行代码订机票」的套路就是它带火的，如今还延伸出了云端托管版本。

**短板**：在 Claude Code 的语境里它是异类——你等于雇了个外包司机：主 Agent 发任务，browser-use 内部再跑一轮自己的模型调用，**同一件事烧两份 token**；Python 环境依赖也是四家里最重的。它是好库，但作为「Claude Code 的外设」并不是最优接法。

### 4. chrome-devtools-mcp：不帮你开车，帮你修车

**定位**：谷歌 Chrome 团队官方出品，接的是 Chrome DevTools 的调试能力：性能轨迹（performance trace）分析、网络请求档案、CPU/网络节流模拟、脚本执行、页面快照。

**设计亮点**：它是四家里唯一有「体检科」的——前三件回答「怎么点这个页面」，它回答「**这个页面为什么慢**」：跑一次性能轨迹让模型读火焰图、按请求列出网络瀑布、模拟弱网环境复现问题。对「调试前端性能」「复现慢接口」这类任务，目前没有平替。

**短板**：通用操作（填表、多步流程）的丰富度明显弱于前两家，定位就是调试位而非操作位，作为主力浏览器外设会捉襟见肘。

## 评测对比表

| 维度 | 权重 | agent-browser | playwright-mcp | browser-use | chrome-devtools-mcp |
|------|------|------|------|------|------|
| 功能完整度 | 25% | 4.0 | 4.5 | 5.0 | 4.0 |
| 设计质量 | 25% | 5.0 | 4.5 | 4.0 | 4.0 |
| 实战效果 | 20% | 4.5 | 4.5 | 4.0 | 3.5 |
| 上手难度 | 15% | 4.5 | 4.5 | 3.5 | 4.0 |
| 社区活跃度 | 15% | 4.0 | 4.5 | 5.0 | 3.5 |
| **加权总分** | 100% | **4.43** | **4.50** | **4.33** | **3.83** |

## 逐项深拆

### 交互范式：ref 快照是公约数，差异在「谁看屏幕」

四家里三家的技术底座已经收敛：无障碍树 → 文本快照 → ref 编号 → 按 ref 操作。真正的分歧在循环归属——agent-browser 和 playwright-mcp 是「**无循环**」设计，主 Agent 每一步自己决策，上下文里留有完整操作轨迹，出错能回看；browser-use 是「**内循环**」设计，子 Agent 自己走完观察-决策链，主 Agent 只拿到结论，省主上下文但丢了过程可审计性。任务需要逐步把关选前者，任务需要批量跑量选后者。

### 集成形态：CLI、MCP、库三种接法

| 形态 | 代表 | 接法 | 上下文开销 |
|------|------|------|-----------|
| CLI | agent-browser | Bash 直接调，按需输出 | 零常驻，最省 |
| MCP | playwright-mcp / chrome-devtools-mcp | 服务器常驻，工具即调用 | schema 常驻，中 |
| 库 | browser-use | 写 Python，内嵌循环 | 常驻最省，但烧第二份模型费 |

这其实是个信号：**Skill/CLI 形态正在向 MCP 形态发起价格战**。MCP 的强项是标准化和跨客户端复用，弱项是每个工具的描述文本都是固定税；CLI 把「说明书」压进一条 `--help`，用的时候才进上下文。agent-browser 是第一个把这条路走通的大厂产品。

### token 账：截图是奢侈品

以典型十步网页任务粗算：截图派每步一张图，全程轻松吃掉十万级 token；快照派每步一张文本树，通常只有几千 token，差出一个数量级。这就是为什么四家不约而同把「禁用截图」写进各自说明书——不是截图没用，是**上下文窗口才是这个赛道真正的稀缺资源**。chrome-devtools-mcp 是唯一保留重截图场景的，因为性能分析确实需要视觉证据，属于「该花的钱」。

### 边界与坑

四家共同的软肋：登录态（涉及真实账号的页面操作务必限定授权范围）、反爬与验证码（别让 Agent 碰验证码，合规风险自负）、canvas 与虚拟滚动列表（无障碍树抓不到的内容快照就是盲区）。另一个反直觉建议：**有 API 就别开车**——浏览器是最后手段，不是默认手段。

## 工作流对比

```mermaid
flowchart TD
    T["用户一句话任务"] --> CC["Claude Code 主控"]
    CC -->|CLI 文本流| AB["agent-browser"]
    CC -->|MCP 工具调用| PW["playwright-mcp"]
    CC -->|MCP 工具调用| CD["chrome-devtools-mcp"]
    CC -->|Python 子进程| BU["browser-use"]
    AB --> S1["文本快照 ref 引用"]
    PW --> S2["无障碍树 ref 引用"]
    CD --> S3["性能轨迹与网络档案"]
    BU --> S4["DOM 打标内循环"]
    S1 --> B["真实浏览器"]
    S2 --> B
    S3 --> B
    S4 --> B
```

## 选型速查

```mermaid
flowchart TD
    S["先问要 Agent 干什么"] --> A["有 API 就别开车"]
    S --> B["调性能查网络"] --> C["chrome-devtools-mcp"]
    S --> D["通用操作求稳"] --> E["playwright-mcp"]
    S --> F["编码 Agent 省 token"] --> G["agent-browser"]
    S --> H["批量跑量多模型"] --> I["browser-use"]
```

## 安装命令速查

**agent-browser**（CLI 形态，ref 编号以当次快照输出为准）：

```bash
npm install -g agent-browser
agent-browser open https://example.com
agent-browser snapshot
agent-browser click @e12
```

**playwright-mcp**：

```bash
claude mcp add playwright -- npx @playwright/mcp@latest
```

**chrome-devtools-mcp**：

```bash
claude mcp add chrome-devtools -- npx chrome-devtools-mcp@latest
```

**browser-use**（Python 环境，自带循环）：

```bash
pip install browser-use
```

```python
from browser_use import Agent
from langchain_openai import ChatOpenAI

agent = Agent(task="打开 GitHub 首页，报出今日趋势榜第一的项目名", llm=ChatOpenAI(model="gpt-4o"))
await agent.run()
```

## 推荐排行榜

- **综合第一：playwright-mcp（4.50）**——功能、生态、稳定性的最大公约数，不知道选谁时的默认答案。
- **设计奖：agent-browser（4.43）**——把「省上下文」做成产品哲学，CLI 接法是本赛道最新的设计范式，值得所有 Skill 作者抄作业。
- **跑量奖：browser-use（4.33）**——要批量、要多模型、要自带循环，它仍是唯一解；代价是两份模型费。
- **独门奖：chrome-devtools-mcp（3.83）**——性能调试位目前无人可替，但别让它干操作位的活。

一套实用的家庭组合：**playwright-mcp 常驻 + chrome-devtools-mcp 待命 + agent-browser 装在 Claude Code 里跑轻量任务**，browser-use 留给脱离 Claude Code 的独立批量场景。

## 参考来源

1. [agent-browser（GitHub 仓库）](https://github.com/vercel-labs/agent-browser) — Vercel 出品的 Agent 浏览器 CLI，快照与 ref 用法以仓库 README 为准
2. [playwright-mcp（GitHub 仓库）](https://github.com/microsoft/playwright-mcp) — 微软 Playwright 官方 MCP 服务器，工具集与接入命令来源
3. [browser-use（GitHub 仓库）](https://github.com/browser-use/browser-use) — Python 库用法与示例代码来源
4. [chrome-devtools-mcp（GitHub 仓库）](https://github.com/GoogleChromeLabs/chrome-devtools-mcp) — 谷歌 Chrome 团队官方 DevTools MCP，性能与网络工具来源

> [!tip] 51学通信知识星球
> **星主：爱卫生**（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。
> **星球定位**：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。
> **当前规模**：5200 篇主题 / 990 个回答，198 元/年。
> **加入福利**：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。
> **AI 加持**：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。

![51学通信知识星球海报-扫码加入](https://wiki.500nian.com/images/zhixingqiu_qrcode.png)
