从 Playwright 到 agent-browser：基于 Accessibility Tree 的浏览器自动化与 AI Agent 实践

这篇文章整理了一次从『传统浏览器自动化测试』一路深入到『AI Agent 驱动浏览器操作』的完整思考路径，核心关键词包括 Playwright、Rust、playwright-rs、agent-browser、Accessibility Tree、LLM。如果你正在思考如何让浏览器自动化更稳、更智能，或者如何把 LLM 接进真实网页操作，这篇总结可以作为一份系统性参考。

一、浏览器自动化的三条路线

在讨论具体工具前，先明确三种常见路线：

1. 官方 Playwright（Node.js / Python / Java / .NET）
   工程能力最强，生态最成熟，适合严肃的 E2E 测试。

2. Rust + Playwright
   通过 Rust bindings 调用 Playwright（如 playwright-rs），在 Rust 工程内完成浏览器自动化。

3. Rust WebDriver / Selenium 生态
   标准化强，但对现代浏览器能力（自动等待、可访问性、trace）支持有限。

本文重点集中在 路线 2 以及由此延伸出的 agent-browser + LLM 思路。

二、playwright-rs：在 Rust 中写浏览器自动化测试

playwright-rs 是目前最有前途的 Rust Playwright 绑定：

• 基于 官方 Playwright Server（Node.js）
• Rust 侧通过 JSON-RPC 调用
• 支持 Chromium / Firefox / WebKit
• 支持 Linux / macOS / Windows
• 已在 GitHub Actions 跨平台跑通

一个最小的 Rust 测试用例

1
2
3
4
5
6
7
8
9
10
11
12
13
14

#[tokio::test]
async fn smoke_test() -> Result<(), Box<dyn std::error::Error>> {
    let pw = Playwright::launch().await?;
    let browser = pw.chromium().launch().await?;
    let page = browser.new_page().await?;

    page.goto("https://example.com", None).await?;

    let heading = page.locator("role=heading").await;
    assert!(heading.is_visible().await?);

    browser.close().await?;
    Ok(())
}

关键点在于：推荐使用 role / name 等基于可访问性语义的 locator，而不是 CSS selector。

三、Accessibility Tree 是什么？为什么它更稳

1. 它不是 DOM

   Accessibility Tree 是浏览器内部为屏幕阅读器和辅助技术维护的一棵语义树：

   • 节点是 button / textbox / heading / link
   • 而不是 div / span
   • 包含 role、accessible name、state（disabled/checked/expanded）

   它由浏览器从 DOM + CSS + ARIA 自动计算生成。

2. 为什么适合自动化与 AI

   • 更贴近『人类理解的页面结构』
   • 对 class、布局、嵌套不敏感
   • 天然支持『这个按钮叫什么』『这个输入框是干嘛的』

Playwright 原生支持基于 accessibility 的定位，这也是它明显强于 Selenium 的地方。

四、Selenium 为什么很难支持 Accessibility Tree

结论先行：
Selenium 短期内几乎不可能完整支持 accessibility tree。

原因包括：

• WebDriver 标准主要围绕 DOM
• Accessibility Tree 属于浏览器内部语义模型
• AOM（Accessibility Object Model）仍处于实验/讨论阶段
• 不同浏览器、不同操作系统的无障碍实现差异巨大

因此，Selenium 通常只能：

• 结合 axe-core 等工具做无障碍检测
• 而不是『读取并操作 accessibility tree』

五、agent-browser：为 AI Agent 设计的浏览器控制层

1. agent-browser 是什么
   • Vercel Labs 出品
   • 一个 Rust CLI + Playwright 后端 的工具
   • 不是测试框架，而是『浏览器操作协议的 CLI 实现』

它的核心创新是：

snapshot + ref-id 的交互模型

2. snapshot 的工作原理
   1. 从 Playwright 读取页面的 accessibility tree
   2. 语义裁剪（去掉无关节点）
   3. 为每个节点分配稳定的引用 ID（如 @e2）
   4. 输出一份『当前页面可操作状态』

示例：

1
2
3

@e1  heading "Log in to Miro"
@e2  textbox "Email"
@e3  button "Continue"

3. 用 ref-id 操作页面

1
2

agent-browser fill @e2 "test@example.com"
agent-browser click @e3

完全不需要 CSS selector。

六、用 agent-browser 操作 Miro 登录页（示例）

1
2
3
4
5

agent-browser open https://miro.com/login/
agent-browser snapshot
agent-browser fill @e2 "test@example.com"
agent-browser click @e3
agent-browser snapshot

核心原则只有一句话：
页面一变，就重新 snapshot。
ref-id 是『当前页面状态下的逻辑锚点』，不是全局 ID。

七、agent-browser vs playwright-mcp

一句话区分：

• agent-browser：浏览器能力 = 一组命令
• playwright-mcp：浏览器能力 = MCP 工具集

八、如何把 LLM 和 agent-browser 结合

典型的 ReAct / Tool Loop：

1. open 页面
2. snapshot 获取页面状态
3. 把 snapshot + 目标发给 LLM
4. LLM 输出下一条命令（受限 DSL）
5. 执行命令
6. 重复直到完成或失败

关键工程要点：

• 命令白名单
• 域名限制
• 步数 / 时间上限
• 失败自动截图

本质分工是：
LLM 负责决策，agent-browser 负责执行。

九、整体对照总结

• playwright-rs：适合『Rust 工程内的自动化测试』
• Accessibility Tree：是稳定自动化与 AI 操作的语义基础
• agent-browser：把可访问性语义变成可执行协议
• LLM + agent-browser：让浏览器自动化从『写 selector』升级为『做决策』

十、一句话收尾

DOM 是给浏览器画页面用的，
Accessibility Tree 是给『人』理解页面用的，
而 agent-browser，是给 AI 操作页面用的。

这正是现代浏览器自动化正在发生的范式转移。