Web 信息采集与浏览器自动化驱动技术选型调研

1 前言与背景

在 AI Agent 时代，"驱动浏览器识别交互、执行动作、拿到信息"已从传统爬虫/测试的工程问题，演变为 Agent 工具链的核心基础设施。典型需求场景包括：

• 信息采集与轻量爬取：从动态渲染页面提取结构化数据，应对 SPA/CSR 等传统 HTTP 抓取难以覆盖的场景。
• 功能验收与回归测试：开发者写完代码后，让 IDE Agent（如 Claude Code / Cursor）自动打开浏览器"点点点"验收功能。
• 后台操作自动化（RPA）：登录、表单提交、筛选、下载等重复性流程的脚本化。
• AI 代理执行网页任务：让 LLM 通过工具接口操控浏览器完成用户意图。

围绕这些需求，当前主流技术路线出现了清晰的分野——<mark>确定性脚本、结构化引用、视觉意图</mark>三种范式各有所长，工具生态也随之分化。本文将对 agent-browser、Playwright MCP、Midscene、BettaFish/MindSpider 等代表性工具进行深度分析与横向对比，并延伸到移动端场景，最终给出按场景的选型建议。

市场趋势

AI 浏览器自动化市场预计从 2024 年的 45 亿美元增长到 2034 年的 768 亿美元（CAGR 32.8%），79% 的企业已在某种形式上采用 AI Agent 技术。

2 核心概念：浏览器自动化的三种交互范式

理解不同工具的根本差异，需要先建立三种交互范式的心智模型。

2.1 确定性脚本范式

代表工具：原生 Playwright / Selenium / Puppeteer

开发者在代码中通过 CSS 选择器、XPath 或 data-testid 等方式精确定位元素，编写确定性的操作脚本。运行时不依赖任何模型推理，<mark>执行路径完全可预测</mark>。

const page = await browser.newPage();
await page.goto('http://example.com');
await page.locator('.submit').click();

优势：稳定、可重复、失败可定位、CI 友好。
代价：编写成本高，UI 变更后维护成本高，强依赖 DOM 结构稳定性。

2.2 结构化引用范式

代表工具：agent-browser / Playwright MCP

通过<mark>可访问性树（Accessibility Tree）</mark>对页面状态进行结构化快照，为可交互元素分配短引用（如 @e1、@e2），后续操作基于引用而非脆弱的选择器。核心思路是把"页面当前有什么可交互元素"压缩为 LLM 友好的紧凑表示。

agent-browser open https://example.com
agent-browser snapshot -i        # 得到 @e1 @e2 @e3 ...
agent-browser click @e3
agent-browser fill @e1 "text"

优势：比原始 DOM 更轻量（token 消耗降低约 93%）、不强绑 CSS 选择器、适合 Agent 工具调用。
代价：仍依赖可访问性树能否暴露目标元素；refs 有生命周期（页面变化后失效）。

2.3 视觉意图范式

代表工具：Midscene

通过<mark>视觉语言模型（VLM）</mark>对页面截图进行理解，用自然语言描述交互目标（"点击右上角的登录按钮"），由模型定位元素并生成执行动作。v1.0 后转向纯视觉路线，不依赖 DOM。

await agent.aiAct('点击登录按钮');
await agent.aiWaitFor('出现用户头像');
await agent.aiAssert('页面显示"欢迎回来"');

优势：脚本高度抗 DOM 变化、对图形化/非标准控件友好、编写直觉化。
代价：依赖模型推理（成本、延迟、不确定性）；失败归因更难（模型判断错/歧义）。

2.4 三种范式的数据流对比

flowchart TB
    subgraph deterministic ["确定性脚本范式"]
        D1["开发者编写 selector"] --> D2["Playwright 定位元素"] --> D3["执行 click/fill"] --> D4["断言验证"]
    end

    subgraph structured ["结构化引用范式"]
        S1["snapshot 生成可访问性树"] --> S2["分配 refs: @e1 @e2"] --> S3["Agent/脚本用 ref 操作"] --> S4["wait + diff 验证"]
        S4 -.->|"页面变化"| S1
    end

    subgraph vision ["视觉意图范式"]
        V1["截图 + 自然语言意图"] --> V2["VLM 定位目标元素"] --> V3["生成并执行动作"] --> V4["aiAssert/aiWaitFor"]
        V4 -.->|"观察-再规划"| V1
    end

范式选择的核心判据

• 追求<mark>稳定性与可审计性</mark> → 确定性脚本或结构化引用
• 追求<mark>抗 DOM 变化与低维护成本</mark> → 视觉意图
• 追求<mark>低 token 消耗与工程可控</mark> → 结构化引用

3 工具深度分析

3.1 agent-browser（Vercel Labs）

项目概况

• 仓库：vercel-labs/agent-browser
• 技术栈：TypeScript 58.7% + Rust 36.1%，基于 Playwright/Chromium
• 最新版本：v0.15.1（2026-02）
• GitHub Stars：16,800+

3.1.1 架构：Rust CLI + Node.js Daemon

agent-browser 采用混合客户端-守护进程架构：

• Rust CLI：负责命令解析，亚毫秒级开销。
• Node.js Daemon：后台常驻进程，通过 Playwright 控制浏览器实例。浏览器在多次命令调用间保持活跃，无需反复启动。
• 如果 Rust 二进制不可用，自动回退到纯 Node.js 模式。

flowchart LR
    CLI["Rust CLI\n命令解析"] -->|"IPC"| Daemon["Node.js Daemon\n浏览器控制"]
    Daemon --> Browser["Chromium\n浏览器实例"]
    CLI2["CLI 命令 2"] -->|"复用连接"| Daemon
    CLI3["CLI 命令 3"] -->|"复用连接"| Daemon

Daemon 的关键意义

命令间共享浏览器状态是因为后台 daemon 常驻，因此 && 链式调用安全且高效——这不是 Playwright API 常识，而是 agent-browser 的运行时语义。不了解这一点会导致写出不可靠的调用方式。

3.1.2 核心机制：Snapshot → Refs → 操作

这是 agent-browser 最核心的交互模型：

1. open 打开页面。
2. snapshot -i 生成可交互元素列表，为每个元素分配临时引用（@e1、@e2……）。
3. 用引用执行动作：click @e3、fill @e1 "..."、select @e2 "..."。
4. 页面一旦变化（导航、弹窗、重渲染），<mark>refs 立即失效</mark>，必须重新 snapshot -i 获取新引用。

Token 优化效果：传统方式（完整 DOM/HTML）约 3,000–5,000 tokens，refs 快照压缩至 200–400 tokens，<mark>降幅约 93%</mark>。

Ref 生命周期是硬约束

导航、表单提交、动态加载后必须 re-snapshot。这是说明书中反复强调的强规约——模型"可能知道"，但不一定每步都遵守；skill 把它变成默认行为模式。

3.1.3 等待与稳定性

agent-browser 将"页面加载完成"变成可控步骤：

3.1.4 验证与对比（Diff）

• diff snapshot：对比两次快照的可访问性树变化（文本级 diff），确认交互是否产生预期变化。
• diff screenshot：对比截图像素差异，适合 UI 回归验收。
• screenshot --annotate：在截图上给交互元素编号，建立编号到 @eN 的映射；对图标按钮、无文本按钮特别有用。

3.1.5 会话与状态管理

3.1.6 安全边界（六大控制）

这是 agent-browser 区别于"只是 Playwright API 封装"的关键特性——为 AI Agent 场景提供现成的安全护栏：

1. 域名白名单（AGENT_BROWSER_ALLOWED_DOMAINS）：限制只能访问指定域，防止跳转到不可信站点。
2. 动作策略（AGENT_BROWSER_ACTION_POLICY）：用 policy 控制允许的动作（如只允许 navigate/snapshot/click/get）。
3. 输出边界标记：给页面输出加标记，帮助上层 AI 区分"工具输出"与"不可信页面内容"，降低 prompt injection 风险。
4. 输出长度限制：防止超大页面内容溢出上下文窗口。
5. 会话隔离：通过独立 session 防止跨任务污染。
6. 凭据加密存储：auth vault 机制避免明文暴露。

3.1.7 配置优先级

agent-browser 的配置按以下优先级合并：

~/.agent-browser/config.json < 项目 agent-browser.json < 环境变量 < CLI 参数

3.1.8 工程结构总览

将 agent-browser 的能力按模块职责拆解：

graph TD
    CommandLayer["CLI 命令层\nopen/snapshot/click/fill/wait/diff..."] --> SessionRouter["会话路由层\n--session / --session-name / session list"]
    SessionRouter --> DaemonLayer["浏览器常驻层\nNode.js Daemon + Chromium"]
    CommandLayer --> SnapshotLayer["页面表征层\nsnapshot -i → refs @eN"]
    CommandLayer --> VerifyLayer["验证与取证层\ndiff/screenshot/record/trace/profiler"]
    CommandLayer --> SecurityLayer["安全策略层\nallowlist/policy/content boundaries"]
    ConfigLayer["配置解析层\nconfig.json + env + CLI 优先级"] --> CommandLayer
    TemplateLayer["模板层\ntemplates/*.sh 场景脚本"] --> CommandLayer

3.2 Playwright MCP（Microsoft 官方）

项目概况

• 包名：@playwright/mcp
• 定位：MCP Server，将 Playwright 暴露为一组结构化工具供 LLM/Agent 调用
• 提供 22–34 个工具（browser_navigate / browser_snapshot / browser_click 等）

3.2.1 核心定位：标准化工具接口

Playwright MCP 是一个 MCP（Model Context Protocol）Server，核心产物是"有哪些工具、每个工具的参数 schema、返回什么"。它把 Playwright 的浏览器能力按标准协议暴露给任何 MCP 客户端（Cursor、Claude Code、其他 Agent 框架），强调走<mark>可访问性树 / 结构化数据</mark>路线。

与 agent-browser 的关键区别：

3.2.2 Token 消耗问题

<mark>Playwright MCP 的 token 消耗是最大痛点</mark>。根据实测数据：

单次测试场景：Playwright MCP 约消耗 114K tokens，而 Playwright CLI 方式仅约 27K tokens（4–10 倍差距）。

高 Token 消耗的根因

Playwright MCP 在每次动作后发送完整的可访问性快照（50KB–500KB）到模型上下文窗口；加上 13+ 工具的选择推理开销，导致 token 消耗急剧膨胀。这在长流程自动化中尤为致命。

3.2.3 适用场景

• IDE Agent 集成：在 Cursor / Claude Code 中配置 MCP server，Agent 直接调用 browser_* 工具完成验收——这是 Playwright MCP 最自然的使用方式。
• 短流程探索：对于简单的 3–5 步操作，token 消耗在可接受范围内。
• 生态互操作：需要同时调用浏览器、数据库、文件系统等多个 MCP server 时，统一协议层带来的可组合性是优势。

3.3 Midscene（web-infra-dev）

项目概况

• 仓库：web-infra-dev/midscene
• GitHub Stars：6,300+
• 最新版本：v1.4（2026 年）
• 支持模型：Qwen3-VL、Doubao-1.6-vision、gemini-3-pro、UI-TARS 等

3.3.1 核心定位：意图驱动的一体化框架

Midscene 包含了<mark>规划 + 执行</mark>两层能力：用户用自然语言描述目标，由视觉模型看截图去定位控件、决定怎么点/填，并通过闭环验证完成任务。相比之下，agent-browser 只提供执行层，规划来自调用方（LLM）。

flowchart LR
    subgraph midscene ["Midscene 一体化"]
        Intent["自然语言意图"] --> VLM["VLM 理解截图"]
        VLM --> Plan["规划动作序列"]
        Plan --> Execute["Playwright 执行"]
        Execute --> Observe["观察页面状态"]
        Observe -->|"再规划"| VLM
    end

    subgraph agentBrowser ["agent-browser 分层"]
        LLM["上层 LLM 规划"] --> AB_CLI["agent-browser CLI 执行"]
        AB_CLI --> AB_Verify["wait/diff 验证反馈"]
        AB_Verify --> LLM
    end

3.3.2 核心 API

3.3.3 规划与定位缓存

Midscene 引入了<mark>规划与定位缓存</mark>机制来应对模型推理的不确定性与成本问题：

• 缓存"这类页面怎么做 / 元素怎么找"的推理结果，存储在 ./midscene_run/cache 目录。
• 减少重复推理次数，提升速度与一致性。
• 对于相同页面结构的重复执行场景效果显著。

3.3.4 跨平台能力

v1.4 后 Midscene 支持：Web（Puppeteer/Playwright）、iOS（WebDriverAgent）、Android（ADB）、桌面应用（Windows/macOS/Linux），以及自定义接口——这是其它工具暂不具备的广度。

3.3.5 使用体感

# Midscene YAML 示例
- action: 点击登录按钮
- action: 在手机号输入框输入 13800138000
- wait: 出现验证码输入框
- action: 滚动到价格区域
- assert: 页面显示"订单已提交"

直觉对比

• Midscene：像在写"我要达成的目标"，<mark>具体点哪里由模型决定</mark>。
• agent-browser：像在写"可重复的操作脚本"，<mark>每一步都很明确</mark>。

3.4 BettaFish / MindSpider

项目概况

• 仓库：666ghj/BettaFish
• GitHub Stars：7,800+
• 定位：多智能体舆情分析系统（"微舆"）
• 爬虫模块：MindSpider，基于 Playwright 1.45.0

3.4.1 与意图驱动的本质区别

BettaFish 需要驱动浏览器完成采集任务，但其浏览器控制本质上是<mark>采集管道的一环</mark>，而非"意图执行平台"：

"视觉"能力的位置不同

BettaFish 的多模态/视觉能力（Media Agent 使用 Gemini 模型）主要用于<mark>抓取后的内容解析与理解</mark>（解析短视频、图片、信息卡片），而非用来"看图找按钮并点击"。浏览器交互仍是工程化流程驱动。

3.4.2 四大 Agent 架构

BettaFish 的价值在于多 Agent 协作的舆情分析链路：

flowchart TB
    User["用户提问"] --> Parallel["并行启动"]
    Parallel --> Insight["Insight Agent\n私域数据分析\nMySQL 舆情库"]
    Parallel --> Query["Query Agent\n全球资讯搜索\nTavily API"]
    Parallel --> Media["Media Agent\n多模态内容解码\nGemini 模型"]
    Insight --> Forum["论坛协作机制\n链式思维碰撞"]
    Query --> Forum
    Media --> Forum
    Forum --> Report["Report Agent\n报告生成"]

4 多维度对比矩阵

4.1 工具横向对比

4.2 Skill vs MCP：定位辨析

在 Claude Code / Cursor 生态中，Skill 和 MCP 经常被混淆。二者的关系可以类比为：

<mark>Skill ≈ 工具 + 使用说明书（可被当作 prompt 注入）</mark>
<mark>MCP ≈ 标准化工具接口定义（function calling 协议）</mark>

但 Skill 不能替代 MCP，二者作用域不同：

最佳实践

MCP 提供工具能力（硬接口/硬约束/可组合/可部署），Skill 提供使用规约（软策略/使用说明/最佳实践/让模型少走弯路）。在 IDE Agent 工作流中，最常见的组合是：<mark>MCP 提供工具能力 + Skill（或系统 prompt）提供使用规约</mark>。

4.3 agent-browser 的 Skill 增量价值

agent-browser 的 SKILL.md 不仅是"API 说明"，更是把一系列<mark>隐性工程细节变成显性、可重复的操作规约</mark>：

• Refs 压缩机制：将 3,000–5,000 tokens 压缩到 200–400 tokens，这是机制而非常识。
• Ref 生命周期强规约：页面变化后必须 re-snapshot，把"模型可能知道"变成"默认行为模式"。
• Daemon 会话语义：命令间共享浏览器是因为后台 daemon——这是工具运行时语义，不是 Playwright API 常识。
• 安全边界：不是"提示模型要小心"，而是工具层面的硬限制。
• 验证闭环：把"操作是否生效"做成可自动验收的证据链。

API 说明 vs 操作规约

API 说明解决的是"能不能调用工具"；Skill 说明书解决的是"在真实网页 + 不稳定加载 + token 限制 + 安全风险下，怎样调用才更容易成功、失败了怎么自救、怎么把结果变成证据"。

5 关键问题深度分析

5.1 为什么"让 AI 操作页面"必然不稳定？

只要是"AI 在运行时做决策"，就会面临以下不稳定源（动态 DOM 会放大它们）：

1. 可观测性不完备：模型看到的是快照（截断文本/可访问性树），不是完整 DOM 与真实时序——容易"选错对象"或"误判当前状态"。
2. 定位是启发式：动态组件（时间选择器、虚拟列表、弹层）会让节点频繁重建、同名元素多实例；模型在多候选中挑选，本质是不确定决策。
3. 时序/等待问题：UI 动画、异步请求、延迟渲染导致"此刻能点"和"下一刻能点"不同；wait 策略不对就会 race。
4. 模型本身非确定：同样上下文下也可能给出不同选择。

5.2 两种 AI 参与方式的本质区别

理解这个区别对选型至关重要：

AI-in-the-loop 执行：运行过程中 LLM 每一步都在"看快照→决定点谁→再看快照"。这是不稳定的主要来源。Playwright MCP 和 agent-browser 被 Agent 调用时通常属于此类。

AI-assisted 生成脚本：LLM 只在"写代码"阶段帮你生成 Playwright 测试（selectors、断言、等待），然后在 CI/本地直接跑确定性测试。运行时不需要 LLM 参与。Playwright 官方的 test agents（planner/generator/healer）本质上就是把流程沉淀为可审计的测试文件再执行。

核心结论

要追求稳定验收，最佳路线通常是<mark>"AI 帮你生成或修复 Playwright 测试（固定定位 + 断言 + 等待）→ 用确定性 runner 执行"</mark>，而不是让 AI 每次都现场操作页面。

6 移动端延伸

6.1 agent-device（Callstack Incubator）

agent-device 是目前在交互模型上<mark>最像 agent-browser 的移动端版</mark>，同样走 snapshot -i → refs(@eN) → press/fill → diff snapshot 的工作流：

覆盖范围：iOS 模拟器/真机 + Android 模拟器/真机。还提供 replay -u ./session.ad 的确定性回放模式。

6.2 xcodebuildmcp

偏 iOS 工程全流程：构建/运行/测试 + 模拟器管理 + 坐标级 UI 自动化 + 日志/LLDB 调试。更像"移动端工程与自动化的 MCP 工具箱"。

6.3 移动端选型建议

澄清

agent-browser 自带的 -p ios 模式是"移动端 Safari（模拟器）浏览器自动化"，<mark>不是原生 App 自动化</mark>。原生 App 需要 agent-device。

7 选型决策树

7.1 按场景推荐

flowchart TD
    Start["你的核心需求是？"] --> CI["CI 回归 / 稳定验收"]
    Start --> Crawl["数据采集 / 爬取"]
    Start --> RPA["后台操作自动化"]
    Start --> AgentExec["AI 代理执行网页任务"]

    CI --> CI_Result["优先：AI 生成 Playwright 测试 + 确定性执行\n补充：agent-browser diff 做验收"]
    Crawl --> Crawl_Q{"页面结构稳定？"}
    Crawl_Q -->|"是"| Crawl_Stable["固定脚本（Playwright/BettaFish）"]
    Crawl_Q -->|"否/经常变"| Crawl_Dynamic["Midscene 或 agent-browser + LLM"]
    RPA --> RPA_Result["agent-browser（CLI 脚本化 + 会话复用 + 安全边界）"]
    AgentExec --> Agent_Q{"需要强安全约束？"}
    Agent_Q -->|"是"| Agent_Safe["agent-browser（allowlist/policy/边界标记）"]
    Agent_Q -->|"否"| Agent_Flex["Midscene（意图驱动 + 低维护）"]

7.2 在 Claude Code / Cursor 中的推荐

• 默认选择 Playwright MCP：它就是为"LLM 在 IDE Agent 工具链里调用浏览器"设计的，更贴合 Cursor / Claude Code 的集成方式。适合短流程探索与验收。
• 长流程/高安全场景选 agent-browser：当你需要 diff 验证闭环、会话持久化、域名/动作策略等一站式"执行+约束+验证"能力时。
• 稳定化沉淀：把 Agent 探索出的关键路径沉淀为 Playwright 测试用例，在 CI 中用确定性 runner 执行。

7.3 混合方案

很多团队最终会采用混合打法：

1. 用 agent-browser 做流程骨架与等待/校验。
2. 用 Midscene 只在"定位困难的步骤/视觉断言"上补刀。
3. 把稳定后的路径沉淀为 Playwright 测试（CI 跑）。

或者分层来看：

8 技术展望

1. Token 效率之战：从 Playwright MCP 的 114K 到 agent-browser 的 200–400 tokens，压缩率仍在持续优化。OpenBrowser MCP 用单一 Python 执行工具把开销降到 283 tokens，代表了另一种极端思路。
2. 视觉与结构化的融合：纯视觉（Midscene）和纯结构化（agent-browser）正在互相借鉴——Midscene v1.0 已转向纯视觉，而 agent-browser 的 --annotate 截图也在向视觉辅助靠拢。
3. AI-assisted 生成 > AI-in-the-loop 执行：对于需要稳定性的场景，趋势是让 AI 生成可审计的确定性测试脚本，而非让 AI 每次现场决策。Playwright 官方的 planner/generator/healer agents 代表了这个方向。
4. 移动端统一：agent-device 已初步实现与 agent-browser 一致的 refs 工作流；跨平台（Web + iOS + Android）的统一自动化框架是下一个竞争焦点。
5. 安全边界标准化：随着 AI Agent 操作真实浏览器的场景增多，域名白名单、动作策略、输出边界标记等安全机制将从"可选特性"变为"行业标配"。

参考资料

• vercel-labs/agent-browser (GitHub)
• agent-browser Skill 页面 (skills.sh)
• @playwright/mcp (npm)
• Playwright Agents 文档
• Midscene.js 官方文档
• Midscene Playwright 集成
• BettaFish (GitHub)
• callstackincubator/agent-device (skills.sh)
• Playwright MCP vs CLI Token 对比
• 2026 Browser Agent 对比 (firecrawl.dev)

关联笔记

• [2026-03-03 开源舆情信息采集与决策分析系统选型调研](2026-03-03 开源舆情信息采集与决策分析系统选型调研) - 了解BettaFish在舆情分析领域的应用场景