让 AI 通过命令行操作浏览器

让 AI 操作网页，难点不只在于点到按钮，还在于知道页面上有什么、操作是否成功，以及下一步还能不能沿用刚才的定位。vercel-labs/agent-browser 给出的方案是：用 Rust 编写的命令行工具，把浏览器操作拆成一次次简短的 shell 调用。

它的关键设计是把页面读成带元素引用的可访问性树，让 Agent 按「读取、操作、检查」循环工作。对想让 AI 自己验证网页功能的前端和全栈开发者，这套接口值得了解；但原文没有提供成功率或性能对照，不能直接推导出它比其他方案更可靠。

AI 怎么知道该点哪个元素

agent-browser 的 snapshot 会把页面转换成紧凑文本，并给元素分配 @e1 这样的引用。可访问性树可以理解为浏览器提供的一份语义目录，包含链接、按钮及其名称等信息。

下面这段命令展示了从打开页面到检查结果的基本循环：

agent-browser open example.com
agent-browser snapshot -i       # 只列出交互元素，每个元素都有引用
agent-browser click @e1         # 操作这次快照中的元素引用
agent-browser get url           # 检查操作结果
agent-browser close

要盯住第二行：-i 会筛出交互元素，后面的点击依赖这次快照产生的引用。原文中 example.com 的快照只有一个名为「Learn more」、引用为 e1 的链接。

元素引用只对生成快照时的页面状态负责。

导航或 DOM 变化之后，应重新获取快照，再使用新的引用。否则，Agent 可能拿着旧页面的定位继续操作。工具也支持 CSS selectors、文本、XPath 和语义定位，例如 agent-browser find role button click --name "Submit"，并不要求所有动作都经过引用。

另一个实用设计是明确报告点击失败：目标隐藏、禁用、位于视口外，或者被同意弹窗等元素覆盖时，工具不会直接报成功。原文建议先处理遮挡，再获取快照并重试。这能给 Agent 一个可处理的错误，但如何决定重试、何时放弃，仍需要上层流程安排。

每次都是 shell 调用，浏览器为什么不会重开

CLI 背后有一个后台守护进程，首次执行命令时启动，通过 Chrome DevTools Protocol（CDP）控制浏览器。后续命令连接同一个进程，因此页面可以持续打开，登录和交互流程也能跨命令延续。

每个 --session 都有独立的守护进程和浏览器。默认情况下，无头浏览器连续一小时没有收到命令，守护进程就会关闭浏览器并退出；配置会话持久化后，退出前会先保存状态。这里不能理解为所有会话默认都会永久保存。

安装可以先走 npm：

npm install -g agent-browser
agent-browser install           # 首次使用时下载 Chrome for Testing

第二行安装的是浏览器，不能只装 CLI 就认为准备完成。Homebrew 对应 brew install agent-browser，之后同样需要执行浏览器安装；Linux 可用 agent-browser install --with-deps 补齐系统库，也可以通过 npx agent-browser open example.com 启动。

默认浏览器是 Chrome for Testing，也能用 --cdp 或 --auto-connect 接入运行中的 Chrome，通过 --engine 选择 Lightpanda 或 Obscura，还支持 iOS Simulator 中的 Mobile Safari，以及 Browserbase、Browserless、Browser Use、Kernel、AgentCore 等云浏览器提供商。原文没有展开这些后端的能力差异。

它提供 macOS ARM64、x64，Linux ARM64、x64 的 glibc 和 musl，以及 Windows x64 原生二进制，npm 会选择对应版本。从源码构建则需要 Node.js 24 或更高版本、pnpm 11 或更高版本，以及 Rust。

使用说明怎样跟着 CLI 一起更新

原文另一个有用的设计，是让 CLI 自带与版本匹配的 skills。Agent 首次使用前执行 agent-browser skills get core，就能加载核心循环、引用、等待和常见工作流的说明；--ref commands 获取命令参考，--full 补充完整参考与模板，agent-browser skills list 则列出 electron、slack、dogfood 等专项 skills。

通过 npx skills add vercel-labs/agent-browser 安装的发现 skill 只是一层轻量入口，会引导 Agent 向本机 CLI 获取说明。它想解决的是工具升级后，Agent 还在照着旧文档执行的问题。也可以把首次加载 core skill 的要求写进 AGENTS.md。

对于 MCP 客户端，agent-browser mcp 可以通过 stdio 启动服务。配置入口包括命令行参数、环境变量和 agent-browser.json。原文还列出了 auth vault、域名允许列表、动作策略和内容边界等安全主题，但没有给出具体配置，不能据此判断默认限制有多严格。

我的判断

我认为最值得借鉴的是它把观察和验证放进了操作循环。点击只是中间动作，读取 URL 或重新获取页面信息，才是在确认任务有没有推进。对于 AI 编程后的网页验收，这比只要求 Agent「打开页面看看」更具体。

不过，可访问性树能否清晰表达页面，依赖页面自身的语义实现。大量自绘内容或名称含糊的控件，可能仍需要其他观察方式。这是接口选择带来的前提，原文没有给出相关覆盖率测试。

它也没有提供与 Playwright 脚本、其他 MCP 浏览器工具的对照数据。因此，紧凑文本是否更省上下文、任务成功率能提高多少，都还不能下结论。固定且需要反复回归的流程，继续保留可审查的测试脚本有其价值；agent-browser 更适合作为 Agent 执行探索和交互时的一个候选接口。

能拿来做什么

• 在日常 AI 编程验收中，把任务写成「打开页面、获取快照、执行操作、检查结果」，并明确 DOM 更新后重新读取引用，让 Agent 有具体步骤可遵循。
• 排查表单或弹窗问题时，保留点击失败信息，先检查隐藏、禁用和遮挡状态，再决定下一步，避免无条件重复点击。
• 团队接入前，先用熟悉的页面试跑一条完整流程，再比较它与现有脚本的定位稳定性、失败反馈和维护成本。
• 把加载 agent-browser skills get core 的要求写入 AGENTS.md；已有 MCP 客户端的团队，也可以评估通过 agent-browser mcp 接入。