<!-- title: 浏览器Agent感知六栈Token实测 -->

# 浏览器Agent感知六栈Token实测：从DOM到截图的生产力账单

2026年，AI Agent操控浏览器不再是Demo级噱头，而是每天消耗数亿Token的生产级负载。但一个核心分歧撕裂了整个生态：**Agent到底该怎么"看"网页？** DOM无障碍树派（Browser-Use、Playwright MCP、Stagehand）用结构化文本压缩页面信息，Token消耗可控；截图/视觉派（Anthropic Computer Use、OpenAI Operator CUA）直接喂像素给多模态模型，精度高但Token烧得凶；Hybrid派（Skyvern、Tappi）则试图兼得两者。本文实测八大浏览器Agent感知栈的架构原理、Token账单、精度曲线和冷启延迟，给出从Demo到生产的全栈选型。

## 一、核心分歧：三大感知范式的架构哲学

浏览器Agent的第一个架构决策不是"用什么LLM"，而是"怎么感知页面"。这个选择决定了后续一切的Token成本、行动精度和鲁棒性。

```mermaid
graph TB
    subgraph 感知范式
        A[DOM/无障碍树派] --> A1[结构化文本]
        A1 --> A2[Token成本低]
        A1 --> A3[动态页面脆弱]

        B[截图/视觉派] --> B1[像素级感知]
        B1 --> B2[通用性强]
        B1 --> B3[Token成本高]

        C[Hybrid派] --> C1[DOM+视觉融合]
        C1 --> C2[按需切换]
        C1 --> C3[工程复杂度最高]
    end

    D[页面状态] --> A
    D --> B
    D --> C

    E[感知结果] --> F[LLM推理]
    F --> G[行动决策]
    G --> H[执行操作]
    H --> D
```

**DOM/无障碍树路线**的核心思路：浏览器内部已有结构化的DOM树和Accessibility Tree，将其序列化为文本喂给LLM。优点是Token效率极高（一个复杂页面的无障碍树序列化后约2K-8K tokens），缺点是动态渲染页面（Canvas、SVG动画）无法捕获，且DOM变更时Agent容易"迷路"。

**截图/视觉路线**的核心思路：直接截取浏览器屏幕截图，作为图像输入多模态LLM。优点是万能——任何人类能看到的界面都能感知，包括Canvas、视频、游戏；缺点是每张截图约1K-2K tokens（GPT-4o image token计算），多步操作时Token消耗指数级累积。

**Hybrid路线**试图用DOM做粗定位、用截图做精验证，或者用"索引元素"等创新方法绕过两边的弱点。

## 二、八大感知引擎多维度对比

| 引擎 | 感知范式 | 语言 | GitHub Stars | 每步Token消耗 | 冷启时间 | 上手难度 | 生产就绪度 |
|------|---------|------|-------------|-------------|---------|---------|-----------|
| **Browser-Use** | 无障碍树 | Python | 91k+ | 3K-8K | ~5s | 低 | 中 |
| **Stagehand** | Hybrid (Playwright+AI) | TypeScript | 15k+ | 2K-6K | ~3s | 低 | 高 |
| **Skyvern** | 视觉优先+Smart DOM | Python | 12k+ | 5K-15K | ~8s | 中 | 中 |
| **Playwright MCP** | 无障碍树 | Any (MCP) | 25k+ | 8K-20K | ~2s | 低 | 高 |
| **Vercel agent-browser** | DOM压缩 | CLI/Any | 4.6k+ | 1K-3K | ~1s | 低 | 中 |
| **Anthropic Computer Use** | 截图/视觉 | API | N/A (API) | 15K-40K | ~10s | 中 | 中 |
| **OpenAI Operator CUA** | 截图/视觉 | API | N/A (API) | 20K-50K | ~12s | 中 | 低(Preview) |
| **Tappi** | 索引元素 | Python | 14k+ | 0.5K-2K | ~1s | 低 | 中 |

> 注：Token消耗为单步页面感知+LLM推理的总估算，基于中等复杂度页面（电商商品页）的典型操作。实际值随页面复杂度和LLM选择大幅波动。

## 三、深度拆解：八大引擎架构与实战

### 1. Browser-Use：无障碍树的事实标准

Browser-Use是2026年增长最猛的AI Agent项目之一，GitHub星标突破91k，Python生态的浏览器Agent首选。其核心架构是将Playwright控制的无头浏览器与LLM推理循环绑定，通过Accessibility Tree提取页面结构。

**架构原理**：Agent启动后，每一步都从浏览器获取Accessibility Tree（而非原始HTML），将其序列化为紧凑文本格式，连同任务描述和历史操作一起发送给LLM。LLM返回结构化的行动指令（click、type、scroll、navigate等），Agent通过Playwright执行，然后获取新的页面状态，形成感知-推理-行动的闭环。

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

controller = Controller()

# 自定义Action扩展能力
@controller.action("搜索商品并比价")
async def search_and_compare(browser, query: str):
    page = browser.page
    await page.goto(f"https://www.example.com/search?q={query}")
    # 提取比价结果...

agent = Agent(
    task="在三个电商平台上比较iPhone 17的价格，找到最低价",
    llm=ChatOpenAI(model="gpt-4o"),
    controller=controller,
    max_steps=50,
)
result = await agent.run()
```

**优点**：生态最活跃，社区贡献了大量Action模板；支持所有主流LLM（OpenAI、Claude、Gemini、本地模型）；自定义Action机制灵活。**缺点**：无障碍树在SPA应用中经常"脏"——大量不可见元素被包含，导致Token浪费；多标签页管理仍有Bug；反检测能力依赖外部方案。**变现评估**：作为训练营教材极好——从安装到第一个Agent只需5分钟，视觉效果强。

### 2. Stagehand：Playwright的AI增强层

Stagehand由Browserbase团队打造，定位是"Playwright的AI外挂"。它不追求完全自主的Agent Loop，而是提供三个精准的AI原语：`act()`（执行操作）、`extract()`（提取数据）、`observe()`（理解页面状态），让开发者像写Playwright测试一样写AI Agent。

**架构原理**：Stagehand在Playwright的Page对象上挂载AI能力。每个原语内部走的是：截图+DOM快照→LLM推理→返回结构化结果。与Browser-Use不同，Stagehand保留了开发者的控制权——你决定何时调用AI，何时用传统选择器。

```typescript
import { Stagehand } from "@browserbasehq/stagehand";
import { z } from "zod";

const stagehand = new Stagehand({ env: "LOCAL" });
await stagehand.init();

await stagehand.page.goto("https://news.ycombinator.com");

// AI驱动的精准操作
await stagehand.page.act("click on the first post about AI agents");

// 结构化数据提取
const posts = await stagehand.page.extract({
  instruction: "extract the top 5 posts",
  schema: z.array(z.object({
    title: z.string(),
    points: z.number(),
    url: z.string().url(),
  })),
});
```

**优点**：TypeScript生态友好，与现有Playwright测试无缝集成；结构化提取（配合Zod schema）的可靠性远高于自由文本输出；Browserbase云基础设施提供生产级无头浏览器。**缺点**：不是完全自主——需要开发者编排步骤；Token消耗在复杂页面上仍然偏高；免费层限制严格。**变现评估**：适合"从测试工程师到AI Agent工程师"的训练营定位，现有Playwright用户迁移成本最低。

### 3. Skyvern：视觉优先的Hybrid路线

Skyvern在2025年获得270万美元融资，其核心差异化是"视觉优先"。它不依赖DOM结构，而是用视觉模型理解页面布局，再用自研的"Smart DOM"做精准元素定位。这条路线的优势是对页面变更鲁棒——换一套CSS甚至重构整个前端框架，只要视觉布局不变，Agent照常工作。

**架构原理**：Skyvern的感知管线是：截图→视觉模型识别可交互区域→Smart DOM映射到实际DOM元素→执行操作。它维护了一个"视觉-结构"映射表，即使DOM ID、class name完全变化，只要视觉位置不变，映射关系保持。

**优点**：对页面变更的抗性最强；能处理Canvas、SVG等非标准元素；MCP协议支持使其可嵌入任意Agent框架。**缺点**：视觉模型推理延迟高（每步额外1-3秒）；Token消耗是DOM路线的2-3倍；对中文/日文等CJK文字的OCR精度仍有缺陷。**变现评估**：面向企业RPA替代场景，客单价高但销售周期长。

### 4. Playwright MCP：微软官方的Agent基础设施

Playwright MCP是微软在2025年底推出的官方MCP服务器，让任何支持MCP的AI客户端（Claude Code、Cursor、Windsurf等）直接获得浏览器控制能力。它不自带LLM，而是作为"浏览器能力提供者"接入Agent框架。

**架构原理**：Playwright MCP通过MCP协议暴露浏览器操作工具。AI客户端调用`browser_navigate`、`browser_click`、`browser_snapshot`等工具，MCP服务器返回Accessibility Tree快照。关键设计：它提供两种快照模式——完整的无障碍树和精简的"可交互元素"视图。

**优点**：微软官方维护，稳定性有保障；与Claude Code、Cursor等工具深度集成，开箱即用；支持连接已有浏览器标签页（Chrome Extension模式）。**缺点**：Token消耗是所有DOM方案中最高的之一——原始Accessibility Tree未做充分压缩，一个中等页面可达10K-20K tokens；慢操作时页面状态可能已变但快照未更新。**变现评估**：作为工具而非产品，适合技术教程而非训练营。

### 5. Vercel agent-browser：Token效率极致压缩

Vercel的agent-browser以"周末项目"发布，却在Token效率上一鸣惊人。它的核心创新是将页面状态压缩为极简的文本表示——不是完整的无障碍树，而是只保留Agent需要知道的"可操作信息"。

**架构原理**：agent-browser使用自定义的DOM遍历算法，只提取可交互元素（按钮、链接、输入框）及其文本标签，忽略所有装饰性DOM。输出格式是紧凑的纯文本（不是JSON），每个元素一行，格式类似`[1] "Submit" button`。这种格式比Playwright MCP的原始无障碍树输出小约5-10倍。

```bash
# 命令行使用
npx agent-browser "go to github.com/trending and list the top 5 repos"
```

**优点**：Token消耗极低（每步1K-3K tokens，是Playwright MCP的1/5到1/10）；CLI设计简洁，零代码即可使用；Vercel基础设施支持云端扩展。**缺点**：信息损失大——复杂表格、嵌套结构经常被扁平化丢失；社区生态较新，文档不完善；缺乏自定义Action机制。**变现评估**：作为"最快上手浏览器Agent"的教学案例极好。

### 6. Anthropic Computer Use：截图派的标杆

Anthropic的Computer Use API是最纯粹的"截图感知"方案。Claude不通过DOM、不通过无障碍树，而是直接"看"屏幕截图——就像人类一样。这条路线的理论优势是终极通用性：不限于浏览器，任何有GUI的桌面应用都能操控。

**架构原理**：Agent Loop中，每一步都截取屏幕截图，发送给Claude的视觉模型。模型返回鼠标/键盘操作指令（移动到坐标、点击、输入文本）。没有DOM、没有Accessibility Tree，只有像素和坐标。Anthropic在2026年3月发布了重大更新，引入了"Browser Use"模式——在Computer Use基础上增加了对浏览器的语义理解能力。

**优点**：真正的"万能Agent"——不限浏览器，可操控任何桌面应用；对视觉布局的理解最接近人类；Canvas、视频、游戏等非DOM内容完全覆盖。**缺点**：Token消耗最高——每张截图约1.5K-3K tokens，多步操作累计惊人（一个10步任务可能消耗30K-50K tokens纯感知）；延迟高（视觉推理比文本慢2-5倍）；坐标点击精度在缩放/分辨率变化时不稳定。**变现评估**：适合高端企业客户和"AI万能助理"叙事，但Token成本是规模化瓶颈。

### 7. OpenAI Operator (CUA)：GPT-4o的浏览器之手

OpenAI在2025年1月发布Operator，基于Computer-Using Agent (CUA)模型——GPT-4o的视觉能力+行动推理的特化版本。与Anthropic Computer Use类似，CUA走截图路线，但专门针对浏览器环境优化。

**架构原理**：CUA模型的训练数据包含大量浏览器操作轨迹（截图-行动配对）。在推理时，它不仅看截图，还结合浏览器提供的辅助信息（URL、标签页状态等）。与Anthropic不同的是，CUA在浏览器内运行而非桌面级——这限制了它的通用性但提高了浏览器场景的可靠性。

**优点**：OpenAI生态集成紧密（ChatGPT Pro用户可直接使用）；浏览器场景的精度经过专项优化。**缺点**：目前仍为Preview状态，API稳定性差；第三方评估在OSWorld基准上仅约45%得分；自定义能力极弱——不能接入自己的LLM、不能自定义Action。**变现评估**：作为ChatGPT内置功能存在，无法独立商业化。

### 8. Tappi：索引元素范式的颠覆者

Tappi是2026年浏览器Agent领域的一匹黑马，14k+ GitHub星标，核心创新是"索引元素"（Indexed Elements）感知方式——不传DOM树、不传截图，而是给页面上每个可交互元素一个数字索引，Agent只需说"点击索引3"即可。

**架构原理**：Tappi在浏览器中注入JS脚本，为所有可交互元素分配唯一索引。页面状态被表示为极简列表：`[0] "Search" input, [1] "Go" button, [2] "Login" link`。这种表示方式的Token消耗极低（通常<1K tokens），同时保留了精确的元素定位能力。在Token基准测试中，Tappi以59K tokens完成全量测试，而Playwright MCP需要超过1M tokens。

```python
from tappi import TappiBrowser

async with TappiBrowser() as browser:
    await browser.goto("https://example.com")
    # 页面状态自动变为索引列表
    await browser.act("在搜索框输入AI agents")  # 自动匹配索引
    await browser.act("点击搜索按钮")
    result = await browser.extract("提取前5条结果标题")
```

**优点**：Token效率最高——比Playwright MCP节省90%+ tokens；精度高（索引直接映射DOM元素，不存在坐标偏移问题）；冷启极快。**缺点**：社区和生态最年轻；文档和示例偏少；对动态加载内容的索引更新偶有延迟。**变现评估**：Token成本优势使其适合高频、大规模浏览器自动化场景（价格监控、竞品分析）。

## 四、Token经济学深度拆解：一次操作的真实账单

```mermaid
graph LR
    subgraph 感知成本
        A1[Tappi<br/>0.5-2K/步] --> A2[agent-browser<br/>1-3K/步]
        A2 --> A3[Stagehand<br/>2-6K/步]
        A3 --> A4[Browser-Use<br/>3-8K/步]
        A4 --> A5[Skyvern<br/>5-15K/步]
        A5 --> A6[Playwright MCP<br/>8-20K/步]
        A6 --> A7[Computer Use<br/>15-40K/步]
        A7 --> A8[Operator CUA<br/>20-50K/步]
    end

    subgraph 十步任务总成本估算
        B1[Tappi: ~5K-20K tokens<br/>≈$0.01-0.05]
        B2[agent-browser: ~10K-30K<br/>≈$0.02-0.08]
        B3[Browser-Use: ~30K-80K<br/>≈$0.06-0.20]
        B4[Playwright MCP: ~80K-200K<br/>≈$0.15-0.50]
        B5[Computer Use: ~150K-400K<br/>≈$0.40-1.20]
    end
```

以上成本估算基于GPT-4o的定价（$2.5/M input tokens），使用Claude或Gemini时价格不同。关键发现：

- **Tappi的十步任务成本是Playwright MCP的1/15到1/10**，是Computer Use的1/30。在大规模部署（每天百万次操作）中，这个差异意味着每月数万美元的成本差。
- **DOM压缩是Token效率的胜负手**。Browser-Use和Playwright MCP都用无障碍树，但Browser-Use的压缩更激进（省略不可见元素、折叠嵌套结构），因此Token消耗约为Playwright MCP的1/3到1/2。
- **截图方案的Token税不可忽视**。以Anthropic Computer Use为例，一个需要20步的电商比价任务，仅页面感知就可能消耗300K-800K tokens，加上LLM推理的总成本可轻松超过$2/任务。

## 五、精度与鲁棒性：感知方式的真实能力边界

| 场景 | DOM/无障碍树 | 截图/视觉 | Hybrid/索引 |
|------|------------|----------|------------|
| 标准HTML表单 | ★★★★★ | ★★★★ | ★★★★★ |
| SPA动态页面 | ★★★ | ★★★★ | ★★★★ |
| Canvas/WebGL | ★ | ★★★★★ | ★★ |
| 反爬严格网站 | ★★★ | ★★★★ | ★★★ |
| 多语言页面(CJK) | ★★★★ | ★★★ | ★★★★ |
| 响应式布局 | ★★★★ | ★★★ | ★★★★★ |
| 页面结构变更后 | ★★ | ★★★★★ | ★★★ |

核心结论：**没有万能感知方案，只有场景适配方案**。电商比价（结构化页面、高频调用）选Tappi或agent-browser；桌面应用自动化选Computer Use；混合场景选Stagehand或Browser-Use。

## 六、生产部署关键决策树

```mermaid
graph TD
    START[需要浏览器Agent] --> Q1{操控目标?}
    Q1 --> |浏览器| Q2{需要完全自主?}
    Q1 --> |桌面应用| CU[Anthropic Computer Use]

    Q2 --> |是| Q3{页面类型?}
    Q2 --> |否,开发者编排| SH[Stagehand]

    Q3 --> |标准HTML/SPA| Q4{Token预算敏感?}
    Q3 --> |Canvas/游戏/视频| SK[Skyvern 或 Computer Use]

    Q4 --> |极度敏感| TP[Tappi]
    Q4 --> |中等| BU[Browser-Use]
    Q4 --> |不敏感| PW[Playwright MCP]

    Q5{是否需要MCP集成?}
    BU --> Q5
    Q5 --> |是| PW2[Playwright MCP]
    Q5 --> |否| BU2[Browser-Use 生态完善]
```

## 七、场景推荐与变现路径

| 场景 | 首选方案 | 理由 | 变现潜力 |
|------|---------|------|---------|
| 电商比价/监控 | Tappi + agent-browser | Token成本最低，结构化页面 | 高（SaaS月付模式） |
| 自动化测试 | Stagehand + Playwright MCP | 与CI/CD集成，开发者友好 | 高（企业级工具链） |
| 数据采集/爬虫 | Browser-Use + 反检测方案 | 生态成熟，自定义能力强 | 中（按量计费） |
| RPA替代 | Skyvern / Computer Use | 视觉鲁棒性，抗页面变更 | 高（企业客单价） |
| AI Agent产品内嵌 | Playwright MCP | MCP协议标准化，接入成本零 | 中（基础设施收费） |
| 快速Demo/教学 | Browser-Use | 5分钟上手，视觉效果最强 | 高（训练营教材） |
| 桌面应用自动化 | Anthropic Computer Use | 唯一桌面级方案 | 高（企业级） |

## 八、趋势判断：2026下半年走向

三个关键趋势正在重塑浏览器Agent格局：

1. **MCP标准化加速融合**。Playwright MCP的成功证明，"浏览器能力作为MCP工具"是正确的抽象层。预计2026下半年，Browser-Use和Tappi都会提供原生MCP服务器，让任何Agent框架都能直接接入。

2. **Token效率竞赛白热化**。Tappi和agent-browser证明，DOM感知方案仍有巨大的压缩空间。预计Playwright MCP将在未来版本中引入智能压缩（仅传递当前任务相关的DOM子树），Token消耗有望降低5-10倍。

3. **视觉-结构融合成为标配**。Skyvern的"视觉定位+DOM操作"混合模式正在被Browser-Use和Stagehand借鉴。纯DOM或纯截图的方案都将演变为Hybrid——先用DOM做粗定位（低成本），遇到不确定的元素时再切换截图验证（高精度）。

**最激进的判断**：到2026年底，"感知栈"将不再是用户需要选择的维度。Agent框架会自动判断页面类型和任务复杂度，在DOM、截图、索引之间动态切换——就像TCP拥塞控制自动调节窗口大小一样。开发者只需写任务描述，框架负责优化感知策略。

## 参考来源

1. [Browser Tools for AI Agents Part 2: The Framework Wars](https://stevengonsalvez.com/blog/browser-tools-part2-frameworks) — browser-use vs Stagehand vs Skyvern DOM-first vs vision-first 架构对比
2. [5 Ways to Automate a Browser with an AI Agent](https://screencli.sh/blog/browser-automation-frameworks-for-ai-agents) — 2026年五大浏览器自动化框架实战对比
3. [AI Browser Agents in 2026: Browser Use, Stagehand, and the New Web](https://noqta.tn/en/blog/ai-browser-agents-browser-use-stagehand-web-automation-2026) — Browser Use、Stagehand、Skyvern全面对比评测
4. [Agent-Browser vs Playwright MCP: Token Cost and Reliability](https://www.morphllm.com/agent-browser-vs-playwright-mcp) — Token成本基准测试与可靠性分析
5. [The Hidden Token Cost of Browser Automation](https://github.com/moc-com/browser-automation-token-benchmark) — 浏览器自动化Token成本基准测试开源项目
6. [Accessibility Tree vs Screenshot Perception](https://www.perea.ai/research/accessibility-tree-vs-screenshot-perception) — 无障碍树与截图感知范式的学术级对比研究

> [!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)