我最近在用 [[OpenClaw]] 处理一些需要浏览器自动化的任务时，发现平台提供了两种截然不同的方案：一个是官方内置的 browser 插件，另一个是 [[Vercel]] Labs 开源的 agent-browser 外部 Skill。刚开始我以为两者差不多，无非是换了个名字、换了个入口，但用了一段时间之后才意识到，这两套方案的设计哲学完全不同——一个面向”人机协作”，另一个专为”AI 批量执行”而生。搞清楚这个区别之后，我的 Agent 任务效率和 API 成本都有了明显改善。
浏览器自动化在 AI Agent 工作流中的位置
浏览器自动化在 AI Agent 工作流中越来越常见，无论是抓取数据、填写表单，还是处理需要登录才能访问的网页，都需要一个可靠的浏览器控制方案。问题在于，传统的浏览器自动化工具（比如 [[Playwright]] MCP）虽然功能强大，但它们并不是专门为 AI Agent 设计的——每次操作都需要把大量的 DOM 结构塞进上下文窗口，Token 消耗惊人，很容易在复杂任务中撑爆上下文，导致任务中断或推理质量下降。
[[OpenClaw]] 为了解决这个问题，提供了两套并行的方案，分别针对不同的使用场景。内置 browser 插件是开箱即用的，能直接接管你正在运行的 Chrome；agent-browser 则是一个来自 Vercel Labs 的外部 Skill，需要单独安装，但在 Token 效率和执行速度上都更激进。了解两者之间的本质区别，能帮你在不同任务中做出更合理的选择，同时也能节省大量的 API 费用。
两种插件的核心定位
在深入技术细节之前，先从整体上理解两者的定位差异。内置 browser 插件由 OpenClaw 官方开发，核心设计目标是支持接管已打开的 Chrome，通过 Chrome DevTools Protocol（CDP）直接 Attach 到你正在运行的浏览器会话，天然保留登录状态和 Cookie。它更像是把你桌面上的 Chrome 浏览器权限开放给了 Agent，操作直观、可见，适合那些登录态敏感、需要可视化调试的场景。
agent-browser 则走了完全不同的路，它由 Vercel Labs 开发并开源，专门为 AI Agent 优化，默认以无头模式（Headless）运行，用 Rust 写的 CLI 和 Daemon 追求极致的执行效率。两者的功能侧重差异用一张表可以看得很直观：
| 维度 | 内置 browser 插件 | agent-browser |
|---|---|---|
| 开发方 | OpenClaw 官方 | Vercel Labs |
| 接入方式 | CDP Attach，支持有头模式 | 无头模式（Headless）为主 |
| Token 消耗 | 使用 DOM/HTML，上下文占用较高 | 比 Playwright MCP 减少 93% |
| 启动速度 | 每次启动新浏览器进程 | Rust daemon 热命令 <10ms |
| 已登录会话 | 原生支持，直接接管 | 需配置 Auth Vault 或 CDP 模式 |
技术架构的根本差异
agent-browser 的三层架构是理解它高效率的关键。最外层是 Rust 写的 CLI，负责解析命令并与 Daemon 通信，冷启动在 50ms 以内；中间层是持久运行的 Daemon，维持浏览器会话，热命令执行在 10ms 以内，彻底消除了传统方案每次都要重新启动浏览器的冷启动开销；底层由 [[Playwright]] 负责实际的浏览器操作，支持 Chromium、Firefox 和 WebKit，同时提供视频录制、网络拦截等高级功能。
内置 browser 插件则基于 Chrome DevTools Protocol，支持多种接入模式：可以通过 OpenClaw 的 Chrome 扩展 Attach 到你已有的标签页（Extension Relay Mode），也可以让 OpenClaw 启动独立的 Chromium 实例（OpenClaw-Managed Mode），还可以通过官方的 Chrome DevTools MCP Server 连接（需要 Chrome 144 以上版本）。不同模式对应不同的隔离程度和登录态保留能力，最常用的场景是直接接管你当前打开的 Chrome，这样 Agent 就能访问你已经登录的所有网站。
Token 消耗为什么差了 93%
这是两者最关键的差异，理解这个问题需要知道两者在”描述页面”这件事上的不同做法。内置 browser 插件（以及传统的 Playwright MCP）描述页面的方式是提取 DOM 结构或 HTML，一个普通网页的 DOM 往往包含大量嵌套的 div 容器、样式标签、脚本代码，塞进上下文动辄需要 1万 到 5万 Token，十步操作的任务流程累计下来轻松突破 10万 Token。
agent-browser 的核心创新在于用无障碍树（Accessibility Tree）代替 DOM 来描述页面。无障碍树是浏览器为屏幕阅读器等辅助工具构建的一套平行结构，它只保留有语义的交互元素：按钮、链接、输入框、标题，把所有纯布局的容器和装饰性标记都过滤掉。agent-browser 从这棵树里提取有用的节点，给每个元素分配一个极短的引用标识（如 @e1、@e2、@e3），整张页面的快照只需要大约 200 到 300 Token。实际测试数据显示，一个十步操作的工作流，Playwright MCP 需要约 11.4万 Token，agent-browser 只需要约 7000 Token。
元素引用的稳定性是另一个重要优点。传统方式依赖 CSS 选择器或 XPath 定位，一旦页面样式或结构微调，定位就可能失效；而无障碍树里的元素语义（”登录按钮”就是登录按钮）基本不随页面改版而变化，Agent 操作的稳定性也更高。
登录态的处理方式
这是两者使用体验差异最明显的地方。内置 browser 插件的 CDP Attach 模式天生就能复用你的 Chrome 登录状态，打开对应的标签页，Agent 接管即可访问，对于需要扫码的中国互联网平台、或者配置了双因素认证的账号，这几乎是唯一合理的方案，完全不需要把密码交给 Agent 处理。
agent-browser 应对登录的方式是 Auth Vault（认证保险库）。你预先用加密方式把账号密码存储在本地（AES-256-GCM 加密，密钥存在 ~/.agent-browser/.encryption-key），Agent 执行时调用 agent-browser auth login 命令完成登录流程，整个过程密码不会出现在 LLM 的上下文里，安全性有保障。对于不那么复杂的登录场景（用户名密码），这个方案完全够用。此外 agent-browser 也支持 CDP 模式，可以连接到已运行的 Chrome，在需要时同样能复用登录状态：
# 启动 Chrome 并开启远程调试
google-chrome --remote-debugging-port=9222
# agent-browser 连接到已运行的 Chrome
agent-browser --cdp 9222 open https://example.com
agent-browser --cdp 9222 snapshot -i
agent-browser --cdp 9222 click @e1
实际使用中该怎么选
在真实任务里，我的选择逻辑大致如下：如果任务涉及已登录账号的操作，比如在社交平台发帖、操作公司内部后台、处理需要二维码登录的产品，就用内置 browser 插件直接 Attach 到 Chrome。这种方式几乎是零配置，打开对应标签页，让 Agent 接管即可；调试也很方便，因为整个过程是有头的，你能看到浏览器实时在做什么，出问题了直接盯着屏幕找原因。
如果任务是批量的、重复性的——大量数据采集、自动化填写表单、跨多个页面的流程操作——选 agent-browser 更合适。93% 的 Token 减少意味着同一个上下文窗口里可以完成更长、更复杂的任务，也意味着 API 账单会显著降低。Rust daemon 的持久化设计也意味着连续操作之间几乎没有启动延迟，在需要频繁与页面交互的场景里手感明显更流畅。
两者并不互斥，完全可以在同一个 OpenClaw 实例里同时启用，无头批处理任务用 agent-browser，需要登录态的操作用内置 browser 插件，根据任务性质灵活切换。
最后
回顾整个对比，内置 browser 插件和 agent-browser 的区别，本质上是”人机协作”和”AI 批处理”两种思路的碰撞。内置 browser 插件把你桌面上的 Chrome 权限开放给 Agent，操作直接、可见，登录态天然保留；agent-browser 则把浏览器操作彻底抽象成 AI 友好的指令集，用无障碍树代替 DOM，用 Rust daemon 消除冷启动，在 Token 效率和执行速度上都做到了极致。
如果你刚开始接触 [[OpenClaw]] 的浏览器自动化，建议先从内置 browser 插件入手，几乎不需要额外配置，能让你快速验证 Agent 的浏览器操作能力；等到任务量上来了，或者发现 Token 费用开始令人心疼，再引入 agent-browser，会是一个非常值得的迁移。两个工具都用好了，才是把 [[OpenClaw]] 浏览器自动化能力发挥到极致的正确姿势。