Browser Use 0.12 弃用 Playwright，token 用量减半

📝

90.4k stars 的开源浏览器 Agent，最近悄悄把 Playwright 从核心里踢出去了

原文链接：https://mp.weixin.qq.com/s/v-rV7sKOotQpyzYInWdfcA

90.4k stars 的开源浏览器 Agent，最近悄悄把 Playwright 从核心里踢出去了

90.4k stars 的开源浏览器 Agent，最近悄悄把 Playwright 从核心里踢出去了。

90.4k stars 的浏览器 Agent，最简上手只要四行 Python

先看 Browser Use 官方 README 里的最小示例：

1	`from browser_use import Agent, Browser, ChatBrowserUse agent = Agent( task="去 GitHub 搜 browser-use 并截图首页", llm=ChatBrowserUse(), browser=Browser(), ) agent.run()`

四行 Python，一个能自己点网页、自己读页面、自己截图的 Agent 就跑起来了。

这是 YC W25 的项目，MIT 协议开源。GitHub 上 90.4k stars、10.3k forks。在 WebVoyager 这个跑 586 个真实网页任务的基准上，他们的 SOTA 报告里写的是 89.1% 成功率——目前开源浏览器 Agent 公开成绩里最高的那个。

WebVoyager 不是”打开网页找标题”那种玩具基准。它包含 Amazon 下单流程、GitHub 搜索 PR、Google Flights 查机票这种带状态、带多步骤、带表单的真实任务。89.1% 意味着 100 个真实任务里能跑通 89 个，这个数字在一年前还在 60% 上下徘徊。

Agent 类里默认隐藏了三件事：把页面渲染成可读结构（accessibility tree + 视觉 grounding）、把 LLM 输出映射成具体的浏览器动作、维护跨步骤的 short-term memory。这三块是任何浏览器 Agent 框架都绕不开的地基，区别只在实现路径。

内置的 LLM 客户端有 ChatBrowserUse、ChatGoogle、ChatAnthropic 几种。你可以接 gemini-3-flash-preview，可以接 claude-sonnet-4-6，也可以接它们自己训的 bu-30b-a3b-preview——这是一个 30B 的 MoE 模型，专门针对浏览器任务做了 RL，作为内置的默认选项。换 LLM 就是换一行参数，不用重写 prompt。

中文教程没跟上：0.12.3 的 CLI 2.0 把 Playwright 踢出了核心

中文社区到现在大多还在把 Browser Use 介绍成”Playwright + LLM 的封装”。

这个说法在 0.12.3 之后已经过时。

2026-03-23 发布的 0.12.3 引入了 Browser Use CLI 2.0。官方 release notes 直接写明：基于 CDP 持久后台 daemon，不再走 Playwright。命令延迟约 50ms，比 Playwright 路径快 2 倍，token 用量减少 50%。

这不是小修小补，是路线变更的强信号。

Playwright 的设计假设是”你有一段脚本，要跑一遍”。每次调用要起 context、关闭再重启，对一个常驻 Agent 来说额外开销很重。CDP（Chrome DevTools Protocol）是浏览器原生的远程控制协议——Chrome DevTools 自己就是通过 CDP 和浏览器通信的。Browser Use 现在直接对 Chrome 发指令，省掉了 Playwright 这层抽象。

token 用量减少 50% 这个数字值得拆开看。Playwright 路径下，每一步 Agent 都要把当前页面 DOM、actions API 文档、错误回执塞给 LLM。daemon 模式下，浏览器状态由 CDP 直接维护，LLM 只需要看到页面摘要和动作结果——上下文可以做更激进的裁剪。对长任务来说，省下来的就是钱。

实际意义是什么？

如果你之前是把 Browser Use 当”Playwright 调用工具”在用——塞一段 JS、做一次 click——升到 0.12.3 之后会发现，CLI 模式下根本没有 Playwright 这个东西。你需要的能力会通过新的 CDP 接口暴露。

它正在从”Playwright 上面的 LLM 封装”变成”直接坐在 CDP 上的浏览器自动化基础设施”。这个变化对工具链上下游的影响，比 LLM 适配本身大得多。CLI 2.0 同时支持把自己挂成 Claude Code 或 Codex 的 skill，等于把浏览器变成了 coding agent 的一只手——你的 Claude Code 会话里直接多出”打开网页、读页面、点按钮”这几个原生能力。

Gemini 3 适配的真正重点：用视觉直接找字段，不再死磕 CSS selector

2025-12-19 Google Developers Blog 发布 Gemini 3 的 Real-World Agent Examples，点名了 6 个生态框架：ADK、Agno、Browser Use、Eigent、Letta、mem0。Browser Use 是其中唯一专门做”浏览器”的开源代表。

外界讨论 Gemini 3 Computer Use 大多停在”Google 也有 computer use 了”。但 Browser Use 这次适配的真正重点在另一处。

官方 demo 是一个表单填写 Agent。

它放弃了 CSS selector 这条路。改用 Gemini 3 的多模态视觉能力，直接在截图上识别”这是用户名输入框””这是上传按钮”。然后把结构化 JSON 数据映射到复杂输入控件，自主处理文件上传，并能稳定跨多步表单和 cross-origin iframe。

CSS selector 在 SaaS 表单里向来是黑洞。React 组件 className 每次构建都换一次，跨域 iframe 又不能直接 querySelector，传统脚本最容易在这里崩。视觉识别绕开了这层脆弱性——只要肉眼能看见，模型就能定位。Stripe 的支付表单、Auth0 的登录组件、Salesforce 的嵌入式 widget，过去都需要单独维护 selector 兜底逻辑，视觉路径下这部分代码可以直接删掉。

代价是延迟和 token 成本。每一步都要截图、上传、推理。一次完整的表单填写从 5 秒变到 15-20 秒是常态。这就是为什么 0.12.6 里专门修了一个 heavy page DOM capture 的 O(n²) 性能 bug——大型页面是这套方案的真实瓶颈，复杂的 enterprise SaaS 后台动辄上千个 DOM 节点，一旦序列化算法跟不上，每步都多花两三秒，跑 20 步任务就是分钟级延迟。

适合上视觉路径的场景：

政府/医疗/金融的老旧表单系统
跨域嵌套很深的 B 端工具
CSS 结构经常变的 SaaS

不适合：

用 Playwright 一行就能搞定的常规任务，视觉路径在那里就是过度工程

0.12.5 是一次紧急安全发版：litellm 供应链投毒后的硬切

0.12.5 是 2026-03-25 发布的，距离 0.12.3 只有两天。它不是常规迭代，是一次紧急安全 patch。

背景是 litellm 在 2026-03-24 出现供应链攻击。litellm v1.82.7 和 v1.82.8 两个版本被植入后门。litellm 是大量 LLM 项目的统一 API 封装层，用得非常广——它把 OpenAI、Anthropic、Google、Azure、本地模型这些 API 全部封装成同一个调用接口，是无数 AI 项目的”瑞士军刀”。

Browser Use 的处理动作很硬：直接把 litellm 从核心依赖里移除。

如果你之前装的是 0.12.4 及更早版本，依赖链里就有 litellm。从 0.12.5 开始，需要 litellm 功能的人要自己单独装。这是一次明确的边界切割——核心库不再为一个外部依赖的安全状况背书。

这件事在英文社区有零星讨论，中文社区基本没人提。但它的意义不止于 Browser Use 自己。所有把 litellm 当核心依赖的 AI 项目都该立刻做三件事：

检查 lockfile 里的 litellm 版本是不是 v1.82.7 或 v1.82.8
如果是，立刻回滚到安全版本
审查这两个版本运行期间产生的 API key 流向，必要的话直接 rotate

供应链攻击不是抽象概念。在 AI 项目依赖链动辄上百个包的今天，这是真实的攻击面——一个被劫持的 npm/pypi 维护者账号就能污染整条链。Browser Use 选择把这层依赖整个剥离，是个偏激进但合理的决定：与其依赖第三方做版本审计，不如让用户自己显式选择。

适合什么人，不适合什么人

适合的场景，三类。

**第一类：**任务里有大量”读页面 → 决策 → 操作”的循环，传统 RPA 写规则覆盖不过来。比如调研类任务（自动跑十几个网站抓数据并汇总）、客服自动化的网页操作部分、批量从 Web UI 导出后台没暴露 API 的数据。

**第二类：**目标网站 DOM 结构经常变，CSS selector 维护成本高。视觉路径在这里有结构性优势。一套 Agent 配置能扛住前端重构，是 selector 路径换不来的稳定性。

**第三类：**想要一个能直接挂进 Claude Code 或 Codex skill 的 CLI 工具。0.12.3 的 CLI 2.0 就是为这个设计的。你的 coding agent 在写代码时可以顺手验证一个 staging 环境的页面，不用再切窗口手动点。

不适合的场景，也三类。

**第一类：**稳定网站上的固定路径自动化。Playwright 几行脚本就够，套个 LLM 反而慢、贵、还不稳定。每月跑同一个流程 1000 次的话，规则脚本永远是最优解。

**第二类：**对成本极度敏感的高频任务。每步截图 + 视觉推理对 token 是真实压力，跑量大就肉疼。简单估一下：一次表单填写 15 步、每步一张截图，按 Gemini 3 视觉 token 算下来单次成本是 Playwright 路径的几十倍。

**第三类：**需要严格审计每一步操作的合规场景。LLM 决策本质上是概率的，关键操作前还是要人工 confirm。涉及付款、删除数据、发邮件这类不可逆动作，建议在 Agent 配置里强制加 human-in-the-loop。

上手路径建议：
先 pip 装 0.12.6，按官方 Quickstart 跑通最小 demo，再决定要不要切到 CLI 2.0。直接从 CLI 2.0 入门会跳过很多关于浏览器自动化基本盘的理解，反而绕路。如果你只是想试试视觉路径效果，配一个 Gemini 3 API key 跑官方的表单 demo，半小时之内就能形成判断。

这里是向量猫，帮你从 100 个工具里挑出 3 个真正值得用的。

参考来源：

browser-use/browser-use GitHub 仓库：https://github.com/browser-use/browser-use
Releases · browser-use/browser-use：https://github.com/browser-use/browser-use/releases
Browser Use 官方文档（Open Source 介绍）：https://docs.browser-use.com/open-source/introduction
Browser Use SOTA 技术报告（WebVoyager 89.1%）：https://browser-use.com/posts/sota-technical-report
Real-World Agent Examples with Gemini 3（Google Developers Blog）：https://developers.googleblog.com/real-world-agent-examples-with-gemini-3/

💬 本文评论区已开启，但暂无读者留言。

本文转载自微信公众号，如有侵权请联系删除。