agent-browser:让 AI agent 用一条条命令行驱动浏览器

Published · AI Daily — AI-assisted deep research, methodology & disclosure

agent-browser 是 vercel-labs 开源的 Rust 命令行工具,为 AI agent 提供浏览器自动化能力。它把网页渲染成带 ref 编号的可访问性树文本,agent 用普通 shell 命令即可打开页面、读取结构、点击元素并核对结果,浏览器在命令之间保持打开。点击被遮挡时会明确报错,不再假装成功。后端覆盖 Chrome for Testing、已运行的 Chrome、Lightpanda、Obscura、iOS 模拟器与多家云浏览器,这让它成为 agent 稳定上网办事的实用基础件。

让 AI agent 真正操作网页,长期以来都是一件麻烦事。早期的做法,要么把整页 HTML 一股脑塞给模型,既占上下文又满是噪声,要么靠截图加坐标点击,容易点歪,也很难确认结果。vercel-labs 推出的 agent-browser 选了另一条路。它是一个用 Rust 写成的原生命令行工具,把浏览器包装成 agent 可以一条命令一条命令驱动的对象。它的定位很清楚:不是又一个面向测试工程师的框架,而是给 agent 准备的、能在 shell 里直接调用的浏览器接口。项目在 GitHub 上已有四万八千多个 star,说明这个思路确实击中了不少开发者的痛点。放到整个生态里看,它处在 agent 工具链靠近执行层的位置:上游是各类大模型与 agent 框架,下游是 Chrome 和多家云浏览器供应商。只要 agent 能运行 shell 命令,就能借它上网办事,不必再接入复杂的 SDK,这种低门槛正是它最大的吸引力。核心能力可以用一个循环来概括:读取、行动、再读取。

snapshot 命令会把页面渲染成紧凑的可访问性树文本,并给每个元素分配一个形如 @e1 的 ref。以 example.com 为例,输出只有一行链接及其 ref。agent 拿到 ref 后,用 click @e1 之类的命令操作元素,再取一次快照核对结果。这样模型看到的是语义化的结构,而不是庞杂的 DOM,也不必猜坐标。需要注意,ref 只描述快照那一刻的页面,导航或 DOM 变化之后必须重新取快照。除 ref 外,它还支持 CSS 选择器、文本、XPath 和语义定位,比如按角色和名称找按钮。另一个值得称道的设计是点击失败时不会假装成功:目标被隐藏、被禁用、在视口之外,或被同意弹窗之类的元素遮住时,命令会直接报错,agent 因此知道该先关掉遮挡物再重试。架构上,CLI 把每条命令发给后台守护进程,守护进程通过 Chrome DevTools Protocol 控制浏览器,浏览器在命令之间保持打开,每一步只是一次很短的 shell 调用。每个 session 拥有独立的守护进程和浏览器,默认空闲一小时后自动关闭无头浏览器并退出,配置了会话持久化时会先保存状态。

上手路径非常短。可以用 npm install -g agent-browser 安装,也可以用 Homebrew,随后运行 agent-browser install 下载 Chrome for Testing,首次使用才需要这一步。在 Linux 上加 --with-deps 会顺带安装浏览器依赖的系统库。如果只想试一下,npx agent-browser open example.com 就能直接跑起来。典型流程是 open 打开页面,snapshot -i 列出可交互元素,click 操作某个 ref,get url 检查结果,最后 close。浏览器后端相当灵活:默认是 Chrome for Testing,也可以用 --cdp 或 --auto-connect 接入已在运行的 Chrome,用 --engine 选择 Lightpanda 或 Obscura 引擎,驱动 iOS 模拟器里的 Mobile Safari,或者接入 Browserbase、Browserless、Browser Use、Kernel、AgentCore 等云浏览器。对 agent 开发者来说,一个贴心之处是 CLI 自带与版本匹配的 skills,通过 agent-browser skills get core 就能读到核心循环、ref 用法、等待策略和常见工作流,还可以加参数查看完整命令列表。文档站覆盖安装、快速上手、选择器、会话、CDP 模式等主题,结构清晰。另有 upgrade 和 doctor 命令,方便升级和排查环境问题。

从行业角度看,agent-browser 的意义在于把浏览器自动化的接口压缩到了最朴素的形态:命令行加文本。这与许多 agent 本来就擅长调用 shell 的习惯完全契合,让不同模型、不同 agent 框架都能共用同一套浏览器能力,而不被某个 SDK 绑定。对工程团队而言,每个 session 相互隔离、可持久化状态、可在本地与云端浏览器之间切换,也便于把原型平滑推向更正式的部署。当然也有值得留意的地方。可访问性树依赖页面本身的语义质量,结构混乱的网站可能给不出清晰的元素描述。ref 会随页面变化而失效,agent 必须养成频繁重新快照的习惯,否则容易操作到过期的目标。让 agent 驱动真实浏览器,本身也带来权限与安全边界的问题,比如登录态、表单提交等操作需要使用者自行把关,这些在现有资料中没有展开,实际采用前应当自己评估。未来值得关注的方向包括:更多浏览器引擎的支持程度、云浏览器供应商的集成深度,以及随版本分发的 skills 能否成为 agent 工具的通行做法。以目前的关注度和 Vercel 实验室的背书,它很可能继续成为 agent 浏览网页的常见选择。

Sources

FAQ

agent-browser 是什么?

agent-browser 是 vercel-labs 开源的 Rust 命令行工具,让 AI agent 用普通 shell 命令操作浏览器。它把网页渲染成带 ref 编号的可访问性树文本,agent 据此点击并核对结果。

为什么 agent-browser 对 AI agent 的网页操作很重要?

agent-browser 避开了整页 HTML 噪声大、截图坐标不稳的问题。元素被遮挡或禁用时,点击命令会明确报错而不假装成功,agent 因此知道要先关掉遮挡物再重试。只要能跑 shell 命令,不同模型和框架都能共用它。

采用 agent-browser 前需要注意什么?

ref 只对应快照那一刻的页面,导航或 DOM 变化后必须重新取快照。可访问性树依赖网站自身语义质量。登录态、表单提交等权限与安全边界,文章没有展开,采用前需自行评估。也要关注更多浏览器引擎与云浏览器的支持程度。