[JS/TS] Vercel开源Agent Browser：为AI Agent优化的浏览器自动化工具，节省93%上下文

周末逛 GitHub 时，发现 Vercel Labs 推出了一个名为 Agent Browser 的新工具。发布不到两个月，星标数就已冲到 16.8k。点进去一看，这是一个专门为 AI Agent 设计的浏览器自动化命令行工具。

说实话，第一反应是：Playwright、Puppeteer 这些老牌工具不早就实现浏览器自动化了吗？这又是重复造轮子？

但实际测试和了解后，我发现这次 Vercel 确实瞄准并解决了一个非常具体的痛点。

传统工具的瓶颈：AI 难以理解 CSS 选择器

传统的浏览器自动化工具，如 Playwright，是面向开发者的。你需要编写 CSS 选择器、XPath 来精确指定操作哪个元素，例如“点击 class 为 submit-button 的按钮”。

这对程序员来说很自然，但对 AI Agent 而言却是个灾难。

核心问题在于上下文消耗。为了让 AI 理解页面并做出决策，通常需要将整个页面的 HTML DOM 树（即网页的结构代码）发送给大模型。一个普通网页的 DOM 树轻松就有几万行代码，全部塞进上下文，Token 消耗会瞬间爆炸。

我曾尝试使用 Playwright MCP（一种让 AI 调用工具的协议）让 Claude 控制浏览器。结果仅完成一个简单的登录操作，就消耗了近 2 万 Token。更棘手的是，AI 还经常选错元素，因为 CSS 选择器非常脆弱——前端工程师稍微修改一下 class 名称，整个自动化脚本就失效了。

当时就在想：有没有一种工具，能让 AI 无需解析庞大复杂的 HTML，就能直观地操作网页？

Agent Browser 的核心创新：用“引用”替代“选择器”

Vercel 的解决方案非常巧妙。它不再让 AI 去猜测和匹配 CSS 选择器，而是为页面上每个可交互元素分配一个稳定的“引用编号”。

其工作流程分为三步：

1. 快照（Snapshot）：AI 执行 snapshot 命令。工具会获取页面的“无障碍树”（Accessibility Tree）。这棵树自动过滤掉了所有装饰性的 div，只保留按钮、输入框、链接等可交互元素。
2. 分配引用：Agent Browser 为无障碍树中的每个元素分配一个唯一的 ref 编号，例如 @e1、@e2、@e3。AI 接收到的不是一个数万行的 HTML 文件，而是一个简洁明了的清单：

   button “登录” [ref=e1]
   input “用户名” [ref=e2]
   input “密码” [ref=e3]

3. 直接操作：AI 直接使用 ref 编号来执行操作。例如 click @e1 点击登录，fill @e2 “admin” 填写用户名。无需猜测选择器，无需解析 DOM，指哪打哪。

这个设计带来的效率提升是惊人的。根据官方数据，在相同的任务下，Agent Browser 比使用 Playwright MCP 减少了 93% 的上下文消耗。一个原本需要 20，000 Token 的操作，现在可能只需要 1，400 Token。

此外，由于 ref 编号是基于稳定的无障碍树生成的，只要网页的核心交互结构不变（即使 CSS 类名改变），引用就不会失效，大大提升了自动化脚本的健壮性。

架构设计：三层“套娃”，兼顾性能与兼容性

Agent Browser 的架构设计也很有意思，采用了三层结构：

1. Rust CLI（命令层）：用 Rust 编写的主命令行解析器。保证了启动速度和低资源占用，执行 agent-browser open example.com 可实现毫秒级响应。
2. Node.js Daemon（守护进程层）：一个常驻后台的 Node.js 进程，负责管理浏览器实例。避免了每次执行命令都重新启动浏览器的开销。
3. Playwright（驱动层）：底层实际上仍然使用 Playwright 来控制 Chromium 浏览器，但在此基础上封装了一层对 AI 更友好的 API。

为什么要这样设计？Rust 保证了 CLI 的极致性能，Node.js 则保证了良好的生态兼容性。项目还很贴心地做了降级处理：如果系统环境无法运行 Rust 二进制文件，它会自动回退到纯 Node.js 模式运行。

如何用自然语言控制？

你可能会问：这听起来不还是个命令行工具吗？怎么让 AI 来用？

这正是 Agent Browser 设计理念的核心：让 AI 来当“翻译官”。

你完全不需要手动输入命令。你只需要用自然语言告诉 AI 你的目标，AI 会自动理解意图，并生成相应的 Agent Browser 命令序列。

举个例子：
你对 Claude 说：“帮我登录 GitHub 并创建一个 Issue。”
Claude 理解后，可能会在后台自动执行如下命令：

agent-browser open https://github.com/login
agent-browser snapshot -i
agent-browser fill @e1 “你的用户名”
agent-browser fill @e2 “你的密码”
agent-browser click @e3
...

你全程只需“动动嘴”，具体的命令生成和执行都由 AI 代理完成。这才是真正的“AI-First”设计。

快速上手：两行命令安装

安装过程非常简单：

npm install -g agent-browser
agent-browser install

第一条命令全局安装 CLI 工具，第二条命令下载所需的 Chromium 浏览器内核。整个过程很快，通常几十秒内即可完成。

核心命令只有几个，却能覆盖大部分场景：

# 打开网页
agent-browser open https://example.com
# 拍摄页面快照并显示交互元素列表
agent-browser snapshot -i
# 点击引用为 @e1 的元素
agent-browser click @e1
# 向引用为 @e2 的输入框填写内容
agent-browser fill @e2 “要输入的文字”
# 截图保存
agent-browser screenshot demo.png

如果你在使用 Claude Code、Cursor 等具备代码执行能力的 AI 编程工具，可以直接让 AI 调用这些命令。AI 会自动分析 snapshot 的结果，选择合适的 ref 编号来完成任务。

我曾测试让 Claude 自动登录 GitHub 并创建 Issue。使用 Playwright MCP 需要写大量提示词来解释 DOM 结构，而使用 Agent Browser，只需一句自然语言指令，Claude 就能自己搞定。省心程度完全不在一个量级。

对比 Playwright：如何选择？

Agent Browser 并非要取代 Playwright，而是针对 AI Agent 自动化场景 做了深度优化。

何时选择 Agent Browser？

• AI Agent 驱动任务：如智能爬虫、自动化测试、多步骤数据采集。
• 高频率人机交互场景：需要模拟表单填写、复杂导航流程。
• 严格管控上下文成本：大模型 API 调用费用高昂，需要极致节省 Token。

何时坚持使用 Playwright？

• 传统自动化测试：由开发人员编写和维护的精确测试脚本。
• 需要精细控制：复杂的等待逻辑、网络请求拦截、性能指标监控等。
• 已有成熟 Playwright 代码库：迁移成本过高。

一句话总结：Agent Browser 是 AI-First，优先考虑 AI 的理解与决策效率；Playwright 是 Developer-First，优先给予开发者最大化的控制精度。

实践建议与当前局限

推荐给这些用户：

• 正在探索或使用 AI Agent 进行自动化任务的开发者。
• 曾被大模型上下文 Token 成本劝退的浏览器自动化需求方。
• 产品经理或业务人员，希望快速通过自然语言原型验证自动化流程。

需要注意的方面：

• 项目处于快速迭代期（如 v0.16.1），API 可能发生变化。
• 对于结构异常复杂或无障碍支持很差的网页，ref 识别可能不准确。
• 每次执行 snapshot 后，ref 编号会重新生成。在进行多页面跳转的多步流程时，需要在每个新页面重新获取快照，这在流程设计上需要一些额外考量。

尽管如此，93% 的上下文节省这一核心优势极具吸引力。它直接将许多原本因成本问题不可行的 AI 自动化场景变成了可能。

对于需要频繁使用大模型进行浏览器自动化的场景，Agent Browser 无疑是一个值得尝试的高效工具。它的出现，标志着浏览器自动化工具开始从“为人服务”向“为 AI 服务”演进。如果你也对 AI 驱动的自动化感兴趣，不妨到 云栈社区 的相关板块看看，那里有更多开发者在分享前沿的实践和想法。