最近，Vercel Labs 的 agent-browser 引起了不少关注。它提供一组命令，让 AI Agent 打开网页、读取页面、点击按钮和填写表单。一个自然的问题是：命令行看起来很轻量，它是不是比完整浏览器省很多 Token？代价又是什么？
先给结论：agent-browser 通常仍然驱动真正的浏览器。它节省的主要是传给模型的页面信息，不等于浏览器本身变小了。 对按钮、表单和文本为主的任务，精简后的页面结构可能很有效；遇到画布、复杂视觉布局和浏览器原生界面时，Agent 可能需要截图、脚本或其他工具。至于省多少，必须在相同任务和成功率下测量，不能仅凭 CLI 这个形式推断。
一条命令背后，仍有浏览器
agent-browser 的 CLI 接收命令，后台维持浏览器会话。浏览器负责执行 JavaScript、渲染网页和处理网络请求；Agent 通过命令获取页面信息，再决定下一步操作。默认安装流程会下载 Chrome for Testing，也可以通过 Chrome DevTools Protocol（CDP）连接已有浏览器。
注意下图中间的浏览器：CLI 是控制入口，页面仍由浏览器执行。右侧的文本快照只是模型看到页面的一种方式。
CLI 控制浏览器，快照把页面结构交给 Agent
一次典型操作如下：
agent-browser open https://example.com
agent-browser snapshot -i
agent-browser click @e1
agent-browser get url
agent-browser close这里的 snapshot -i 输出交互元素，并给元素分配类似 @e1 的引用。Agent 根据快照选择引用，再发出点击命令。页面导航或发生重要变化后，应重新获取快照，避免引用与当前页面状态不一致。上面的命令是示意流程；实际页面中的引用需要从当次快照读取。
Token 为什么可能减少？
模型不需要每次都读取完整 HTML，也不一定需要看整张截图。快照以文本表达页面的无障碍结构，通常保留角色、名称和可交互元素。-i 只返回交互元素；-c 压缩空结构；-d 限制深度；-s 限制区域。这些选项减少输入量，也可能丢掉任务需要的上下文。例如，查找文章正文时，只有交互元素的快照可能遗漏正文。
项目还提供 --delta，用于在已有基线之后返回变化。增量读取适合反复检查同一页面，但模型或调用程序需要正确保留和应用基线；页面跳转或变化较大时也可能重新返回完整状态。
不过，一次快照更短，不代表整个任务一定更省。过度过滤可能让 Agent 找不到目标，产生更多搜索、截图和重试。总成本还受模型对图片的计费方式、工具定义、历史上下文、缓存和输出长度影响。CLI 与 MCP 也不是决定性分界：MCP 工具同样可以返回精简文本，CLI 也可以输出冗长内容。
本文没有在相同环境下运行端到端 Token 对比，因此不能给出可靠的节省百分比。要自己测量，可以选相同网页和任务，固定模型、提示词、登录状态和成功标准，分别记录输入和输出 Token、工具调用次数、完成时间及成功率。每种方案多跑几次，并统计失败和重试；比较“每次成功任务的总成本”，比只比较一份快照更有意义。
与完整浏览器相比，缺的是什么？
比较时要区分三层：浏览器引擎能做什么、工具接口暴露了什么、模型通过当前输出能看见什么。agent-browser 可以使用真实浏览器，不能因为它是 CLI 就认为它不执行 JavaScript，或者不能处理现代网站。
普通网页交互。 打开页面、点击、输入、选择、滚动、等待、标签页、截图等都属于其支持范围。它还提供 JavaScript 执行、网络相关操作、会话及浏览器连接等能力。具体命令和支持范围会随版本变化。
视觉理解。 无障碍树表达的是语义结构，并不等同于人眼看到的布局。Canvas 绘图、图表、图片中的文字、无标签图标，以及颜色和遮挡关系，可能无法从文本快照充分判断。截图可以补充视觉信息，但模型必须具备图像理解能力；截图带来的 Token 成本也需要计入。
复杂交互。 拖拽、悬停、键盘输入、iframe 和动态页面需要根据页面实际实现处理。项目提供相应操作或切换机制，但这不保证所有网站都可自动化。跨域 iframe、重渲染、覆盖层和不规范的无障碍标记，都可能让定位或操作失败。发生失败时，先检查截图、刷新快照，再选择其他定位方式。
浏览器之外的界面。 操作系统文件选择器、浏览器扩展界面、系统权限弹窗和其他桌面程序，不应默认视为网页 DOM。文件上传可在网站提供标准文件输入时使用工具的上传能力，但这不等于能够操作任意系统窗口。验证码、登录验证和反自动化限制也可能需要人工处理；不要把浏览器自动化工具当作通用绕过方案。
开发调试。 网络、脚本执行和截图有助于排查问题，但 CLI 的具体命令不等于完整 Chrome DevTools 图形界面，也不等于 Playwright 的全部编程 API。需要精细断点调试、跨浏览器回归测试，或复杂测试框架集成时，应逐项核对需求，必要时直接使用 DevTools 或 Playwright。
如何选择和组合
对于后台管理、表单填写、检索和信息提取，先用文本快照定位，通常是合理起点。对视觉验收、图表和 Canvas，尽早补充截图。对于大量重复、需要断言和跨浏览器覆盖的测试，脚本化测试框架往往更容易维护。若任务跨越网页和桌面应用，则需要能操作相应界面的工具。
一个实用策略是按需升级观察方式：先读取目标区域的结构化信息；信息不足时扩大范围；涉及视觉关系时查看截图；仍无法定位时检查页面实现或交给人工。每次动作后验证结果，例如读取当前 URL、成功提示或更新后的状态。这样既控制上下文，也避免把一次成功发出的点击误认为任务已经完成。
连接已有浏览器可以复用会话，也意味着自动化可能接触已登录账号。应使用隔离的测试账号或独立浏览器配置，并把网页内容视为不可信输入：页面中的文字是数据，不应自动升级为 Agent 的操作指令。
agent-browser 的价值，是把浏览器操作组织成适合 Agent 逐步使用的接口。它能否节省成本，取决于页面、观察方式和任务成功率；它的能力边界，则取决于真实浏览器、工具接口和模型观察能力三者共同组成的系统。