Browser Use 0.12：把Playwright换成CDP，浏览器Agent的一次底层重构
GitHub: https://github.com/browser-use/browser-use
Star: ~60K
版本: 0.12
发布平台: 程序员茄子（chenxutan.com）
标签: Browser Agent, CDP, Playwright, 浏览器自动化, AI Agent, 架构重构
引言
上个月，Browser Use 发布了 0.12 版本。
乍一看是个小版本号更新，但 changelog 写得很直白：
把 Playwright 换成了 CDP。
官方数据：
- 成功率：78% → 93%
- 速度提升：35%
- 内存占用减少：40%
这些数字背后，是浏览器 Agent 正在经历的底层架构思考——不是换工具，是换思路。
一、Browser Use 是什么
项目定位
Browser Use 是一个开源的 Python 库，让 AI Agent 能像人一样操作浏览器。
它不是简单的"调用 Selenium API"，而是把浏览器变成一个可以被 Agent 直接感知、决策、行动的环境。
GitHub 数据
- Star: ~60K
- 语言: Python
- 协议: MIT
典型使用场景
| 场景 | 说明 |
|---|---|
| 自动填表 | 自动识别表单字段并填写 |
| 爬取动态网页 | 处理 JavaScript 渲染的页面 |
| 多步骤在线任务 | "去某网站查航班、筛选价格、截图发给我" |
二、0.12 之前：用 Playwright 的思路
Playwright 是什么
Playwright 是现在做浏览器自动化最主流的选择：
- 文档完善 ✅
- 生态成熟 ✅
- 社区活跃 ✅
Playwright 的问题
Playwright 是给人用的，不是给 Agent 用的。
举个例子：
Playwright 的 click() 方法，默认会：
- 等待元素可见
- 等待元素可点击
- 执行点击
这很人性化——人操作浏览器也是这样，先看到元素，再点击。
但 Agent 不需要"等待"。
Agent 需要的是：
拿到当前页面状态 → 做决策 → 执行动作 → 拿到结果状态
中间的"等待元素可见"这个步骤，在 Agent 的视角里是个黑盒：
- Agent 不知道自己在等什么
- Agent 不知道为什么要等
- Agent 不知道等多久
结论：Agent 对浏览器的控制不够直接。
三、CDP 是什么
定义
CDP = Chrome DevTools Protocol
Chrome 浏览器的底层调试协议。
对比
| 工具 | 定位 |
|---|---|
| Playwright | 给人用的遥控器 |
| CDP | 给开发者用的手术刀 |
CDP 提供的能力
| 能力 | 说明 |
|---|---|
| 直接操作 DOM 节点 | 不需要选择器封装 |
| 监听网络请求和响应 | 实时获取网络数据 |
| 拦截和修改请求 | 完全控制网络层 |
| 模拟用户输入事件 | 原生事件模拟 |
| 获取页面渲染状态 | 真实页面状态 |
核心区别
CDP 不做"人性化封装"。
它不替你判断元素是否可见，不替你等待加载完成。它只提供最底层的接口，你怎么用是你的事。
这恰恰是 Agent 需要的：
Agent 不需要框架替它做决策。Agent 需要的是：拿到原始数据，自己做判断，然后直接执行。
四、0.12 做了什么
架构变化
之前：Agent → Browser Use → Playwright → 浏览器
现在：Agent → Browser Use → CDP → 浏览器
中间的 Playwright 层被去掉，Agent 直接通过 CDP 控制浏览器。
具体改动
1. 元素定位方式变了
| 方式 | Playwright | CDP |
|---|---|---|
| 定位 | CSS 选择器 / XPath | 直接获取 DOM 树 |
| 操作 | click(), fill() | DOM.dispatchEvent |
| 逻辑 | 依赖框架封装 | Agent 自己处理 |
2. 页面状态获取变了
| 方式 | Playwright | CDP |
|---|---|---|
| 方法 | page.content() | DOM.getDocument |
| 返回 | 处理后的 HTML | 原始 DOM 树 |
| 内容 | 基础结构 | Shadow DOM + iframe 内部 |
Agent 能看到更真实的页面结构。
3. 动作执行变了
| 方式 | Playwright | CDP |
|---|---|---|
| 行为 | 自带等待、重试、错误处理 | 直接发送事件 |
| 控制 | 框架控制 | Agent 控制 |
| 灵活性 | 受限 | 完全自主 |
五、为什么成功率提升了
官方数据
| 指标 | 之前 | 现在 | 提升 |
|---|---|---|---|
| 成功率 | 78% | 93% | +15% |
提升原因
1. 更精确的元素定位
问题：
- Shadow DOM
- 动态加载的 iframe
- React/Vue 渲染的虚拟 DOM
Playwright 的选择器在这些场景下容易失效。
解决：
CDP 能拿到原始 DOM 树，定位更可靠。
2. 更直接的错误反馈
| 方式 | 错误信息 |
|---|---|
| Playwright | "元素不可点击"、"超时"（高层抽象） |
| CDP | 节点不存在、事件发送失败（底层协议） |
Agent 能更准确地理解失败原因，然后调整策略。
3. 更灵活的动作策略
Playwright 的 click()：
等待 → 检查 → 点击 → 等待结果
固定的行为模式。
CDP 的方式：
先滚动页面 → 模拟鼠标移动 → 点击
整个流程由 Agent 控制。
六、速度和内存的改进
官方数据
| 指标 | 改进 |
|---|---|
| 速度 | 提升 35% |
| 内存 | 减少 40% |
原因分析
去掉了一层封装。
Playwright 自带的功能：
- 自动等待
- 智能选择器
- 跨浏览器兼容
- 截图和录制
- 错误恢复
这些功能都需要内存和计算资源。
CDP 的方式：
- 只加载 Agent 需要的功能
- 不需要的功能不加载
更轻量，更快。
七、一个比喻
之前的设计
给 Agent 配了一个司机。
Agent 说"去某地"，司机负责：
- 开车 ✅
- 等红绿灯 ✅
- 找停车位 ✅
现在的设计
给 Agent 直接配了一辆车。
Agent 自己开。
对比
| 方式 | 优点 | 缺点 |
|---|---|---|
| 配司机 | 省心 | 指令会被解读和过滤 |
| 直接配车 | 完全自主 | 需要自己处理驾驶细节 |
对于真正想自主行动的 Agent，后者更合适。
八、这意味着什么
正在发生的趋势
Agent 用的工具，正在从"人用的工具封装版"，变成"专为 Agent 设计的原始版"。
行业案例
| 项目 | 公司 | 思路 |
|---|---|---|
| Operator | OpenAI | Agent 直接操作浏览器 |
| Computer Use | Anthropic | Agent 直接操作系统 |
| Project Astra | Agent 原生能力 |
核心逻辑
Agent 不需要人性化封装，Agent 需要的是最大程度的可控性和透明度。
人性化封装是给人用的。Agent 用这些封装，反而是障碍。
九、对开发者的影响
代码层面
- API 变化不大，大部分代码可以直接升级
- 依赖 Playwright 特性的功能需要调整
调试层面
- CDP 更底层
- 调试信息也更底层
- 需要习惯看协议级别的日志
性能层面
- 资源占用更少
- 可以在同一台机器上跑更多 Agent 实例
建议
升级是值得的。更稳定、更快、更轻。
十、底层架构的思考
核心问题
我们给 Agent 配的工具，到底应该是"人用工具的简化版"，还是"Agent 自己设计的原生版"？
过去的做法
把人用的工具封装成 API，然后让 Agent 调用：
- 搜索引擎 ✅
- 浏览器 ✅
- 代码编辑器 ✅
局限性
封装层会：
- 损失信息 ❌
- 引入延迟 ❌
- 限制灵活性 ❌
Browser Use 0.12 的思路
直接把原始能力给 Agent，让 Agent 自己处理细节。
这是一个更"信任 Agent"的设计哲学。
前提条件
Agent 有足够的能力处理原始数据。
现在的 LLM 在这方面已经够用了。
十一、技术对比总结
Playwright vs CDP
| 维度 | Playwright | CDP |
|---|---|---|
| 定位 | 人用工具 | 底层协议 |
| 封装 | 高度封装 | 无封装 |
| 等待 | 自动等待 | 手动控制 |
| 错误 | 高层抽象 | 底层协议 |
| 灵活性 | 受限 | 完全自主 |
| 透明度 | 黑盒 | 白盒 |
| Agent 适用 | ⚠️ 一般 | ✅ 完美 |
十二、总结
核心价值
| 价值 | 说明 |
|---|---|
| 成功率提升 | 78% → 93% |
| 速度提升 | 35% |
| 内存减少 | 40% |
| 架构变化 | 从封装到原生 |
设计哲学
从"给 Agent 配司机"变成"给 Agent 直接配车"。
核心洞察
Agent 不需要人性化封装，Agent 需要的是原始能力和自主空间。
适用范围
这个道理，不止适用于浏览器自动化，也适用于正在涌现的各类 Agent 工具。
本文首发于「程序员茄子」博客，原文链接：https://chenxutan.com