Browser Use CLI 3.0：把浏览器装进 Claude Code 和 Codex

想让 Claude Code 或 Codex 自动打开网页、登录账号、填写表单、上传文件？

Browser Use CLI 3.0 把这件事变得更直接了。

它可以作为一个 skill 接入 Claude Code、Codex，让原本只会读代码、改文件的模型，开始真正操控浏览器。

你可以这样理解：

模型负责思考，Browser Use 负责动手。

CLI 3.0 到底升级了什么？

这次升级没有堆一大串花哨功能，重点都放在浏览器 Agent 最容易卡住的地方：体积、Token、浏览器控制、自我修复和经验复用。

1. 体积缩小，运行更轻

CLI 3.0 的底层壳大幅缩小，官方表示体积约为旧框架的六分之一，核心代码也更加精简。

这带来几个直接好处：

• 安装和启动更快
• 依赖更少
• 调试路径更短
• 模型需要理解的工具描述更少
• 长任务里更省 Token

以前让 Agent 操作一个网站，工具层可能塞进几十个点击、输入、定位函数。工具一多，模型就容易迷路。

现在的思路更简单：给模型更底层、更直接的浏览器控制能力。

2. 直接使用 Chrome 的 CDP

CLI 3.0 的核心变化，是通过 CDP，也就是 Chrome DevTools Protocol 直接控制浏览器。

过去常见的方式是给模型准备一套封装工具：

click()
type()
select()
wait()
scroll()

模型先识别页面，再调用这些函数完成操作。

问题也很明显：

• 页面结构复杂时，定位容易失效
• 动态网页经常出现元素变化
• 工具函数越来越多，提示词越来越长
• 复杂任务需要把大量 DOM 结构塞进上下文
• Token 消耗蹭蹭往上涨

CLI 3.0 换了条路。

它让模型直接和 Chrome 的底层协议沟通。模型不需要把整棵网页 DOM 树都读一遍，也不需要依赖一堆高层封装函数。

这对日常使用有什么影响？

假设你让 Agent 完成下面的任务：

打开招聘网站，筛选远程岗位，把符合条件的职位保存到表格里。

传统流程可能是：

1. 获取完整网页结构
2. 找到搜索框
3. 调用输入函数
4. 找到筛选按钮
5. 点击并等待页面刷新
6. 重新读取页面结构
7. 提取职位信息

页面一复杂，DOM 内容就能把上下文撑得很大。

CDP 方式会更贴近浏览器本身。需要什么就读取什么，需要执行什么就直接执行。上下文更干净，模型也更容易保持方向感。

3. 用过的网站，会留下可复用技能

这是 CLI 3.0 很有意思的一点：它会沉淀网站经验。

Agent 在某个网站上摸索过的流程，例如：

• 登录入口在哪里
• 哪个按钮需要悬停后才出现
• 表单提交后要等待多久
• 某个选择器经常变化
• 上传文件需要经过哪几步
• 页面弹窗如何关闭
• 特定网站有哪些奇怪的交互

这些经验可以保存成 domain-skills。

下次再访问同类网站时，Agent 不用从零开始试错，直接调用之前积累的技能。

一个很实际的场景

你每天都要登录供应商后台，下载订单，再整理成 CSV。

第一次运行时，Agent 可能需要花时间找到登录页、处理验证码提示、定位下载入口。

跑过几次后，这些流程会沉淀下来。下次再执行任务时，Agent 可以直接沿用已经验证过的路径。

网站越固定，收益越明显。

这和每次都雇一个新实习生不同。你是在慢慢训练一个熟悉公司后台的浏览器助手。

4. 没有函数？现场自己写

浏览器自动化最烦人的情况是：

任务明明很简单，但工具库里偏偏没有这个操作。

例如：

• 上传本地文件
• 拖动滑块
• 处理特殊弹窗
• 读取某种自定义组件
• 调用网页里的特殊事件
• 操作一个没有标准按钮的控件

CLI 3.0 支持一种自愈方式。

当 Agent 发现现有工具不够用时，它可以现场编写需要的函数，然后继续执行任务，而不是直接报错退出。

任务示例

登录后台，创建一条商品记录，并上传本地的产品图片。

如果现成工具没有文件上传函数，Agent 可以根据当前页面和浏览器能力生成临时函数，完成上传，再继续填写其他字段。

这对长流程特别重要。

一个任务执行到 80% 时卡死，体验很差。能自己补齐缺口，才更像一个真正能干活的 Agent。

当然，自愈不等于无限可靠。涉及支付、删除数据、发送邮件这类高风险操作，依然建议加人工确认。

5. 三种浏览器接入方式

Browser Use CLI 3.0 不要求你只能使用某一种浏览器环境。

方案一：使用电脑上的真实 Chrome

这是最适合个人日常工作的方式。

你可以让 Agent 使用现有浏览器里的：

• 已打开的标签页
• Cookie
• 登录状态
• 浏览器插件
• 本地配置
• 已授权的网站账号

比如你已经登录了企业微信、Notion、GitHub 或内部管理系统，Agent 可以在当前环境里继续操作，不用重复登录。

适合这些任务：

• 整理后台数据
• 下载文件
• 填写重复表单
• 处理已经登录的 SaaS 工具
• 操作本地浏览器插件

方案二：使用 Browser Use 云浏览器

如果你不想占用自己的电脑，可以使用 Browser Use 提供的云浏览器。

这种方式更适合：

• 定时任务
• 云端 Agent
• 多人共享自动化流程
• 服务器环境运行
• 不希望依赖本地电脑的任务

需要注意账号安全。涉及企业后台、财务系统、客户数据时，别把生产账号随手接入测试环境。

方案三：连接任意 CDP 端点

只要浏览器或远程环境提供 CDP 端点，就可以接入。

你可以使用：

• 自己部署的浏览器服务器
• 公司内部自动化环境
• 远程 Chrome 实例
• 容器中的浏览器
• 其他兼容 CDP 的浏览器服务

这给工程团队留下了很大的扩展空间。浏览器跑在哪里，不再是 CLI 的硬限制。

6. 为什么会更省 Token？

浏览器 Agent 消耗 Token 的大头，常常不是模型思考，而是反复读取页面结构。

一张复杂网页可能包含：

• 导航栏
• 隐藏菜单
• 大量无关文本
• 广告组件
• 弹窗节点
• 多层嵌套 DOM
• 重复的按钮和链接

如果每一步都把整棵 DOM 树传给模型，上下文很快就会膨胀。

CLI 3.0 通过 CDP 直接读取和操作需要的内容，减少无关页面信息进入上下文。

实际结果通常是：

• 同样的任务需要更少上下文
• 多步骤流程更不容易超出窗口
• 模型调用次数下降
• 长任务成本更可控

别小看这一点。自动填一个表单也许差别不明显，跑几十分钟的研究、采集、后台操作时，Token 账单会告诉你答案。

7. 模型不受绑定

Browser Use CLI 3.0 不绑定某一个模型。

只要模型具备足够的：

• 工具调用能力
• 页面理解能力
• 任务规划能力
• 错误处理能力

就可以套上这层浏览器控制能力，成为浏览器 Agent。

你可以根据任务选择模型：

| 任务类型 | 更关注的能力 | | --- | --- | | 简单表单填写 | 速度和成本 | | 多页面信息采集 | 上下文管理 | | 复杂后台操作 | 推理和纠错 | | 需要写临时函数 | 代码生成能力 | | 高风险生产任务 | 稳定性和可控性 |

别迷信“最强模型解决一切”。简单任务用轻量模型，复杂任务再上更强模型，成本会舒服很多。

8. 一套可执行的使用思路

你可以按下面的流程搭建自己的浏览器 Agent。

第一步：选浏览器环境

个人电脑上的任务，直接连接真实 Chrome。

需要长期运行的任务，考虑云浏览器或自己的 CDP 服务。

第二步：把浏览器能力接入 Agent

将 Browser Use CLI 作为 skill 提供给 Claude Code、Codex 或其他支持工具调用的 Agent。

接入后，给它一个清晰的任务目标，不要一上来就规定几十个点击步骤。

例如：

打开已登录的客户管理系统，找到今天新增的客户，筛选出来自官网的记录，导出为 CSV。遇到删除、发送或修改数据的操作时先暂停并询问我。

这类指令包含了三件事：

• 要完成什么目标
• 可以使用什么已有状态
• 哪些操作必须人工确认

第三步：让 Agent 自己探索

第一次访问新网站时，不要急着手写所有选择器。

让 Agent 完成一次完整任务，并观察它遇到的问题：

• 登录流程是否稳定
• 页面是否有特殊弹窗
• 哪些元素定位困难
• 哪些步骤耗时较长
• 有没有需要临时补充的函数

第四步：保留 domain-skills

成功跑通后，把网站经验保存下来。

下一次执行相同任务时，优先复用已有技能。别每次都从空白状态重新探索，那是在浪费时间和 Token。

第五步：给关键动作加确认

建议对这些动作设置人工确认：

• 删除数据
• 提交订单
• 发送邮件或消息
• 修改权限
• 上传敏感文件
• 发起支付
• 发布公开内容

浏览器自动化可以替你点按钮，但责任不会自动转移给浏览器。

避坑清单

不要把“能操作浏览器”当成“可以放任它操作一切”

登录状态和 Cookie 一旦暴露，影响可能比普通 API 密钥更大。

使用真实 Chrome 前，先确认 Agent 能看到哪些标签页和账号。

不要把所有任务都塞给同一个模型

整理网页资料和修改生产数据，风险等级完全不同。

给不同任务设置不同模型和权限，成本、稳定性都会更好。

不要跳过首次运行观察

新网站第一次跑，最好盯着过程看。

尤其留意：

• 是否误点广告
• 是否把测试账号当成生产账号
• 是否误触提交按钮
• 是否遇到验证码或二次验证
• 是否把敏感信息写入日志

不要迷信自愈

Agent 能现场写函数，是补救能力，不是安全保证。

临时生成的函数需要检查。涉及文件、账号、支付和数据修改时，人工审核不能省。

适合拿来做什么？

Browser Use CLI 3.0 更适合这些场景：

• 自动整理多个网页的数据
• 操作没有 API 的后台系统
• 下载并归档报表
• 批量填写重复表单
• 处理跨网站的信息搜集
• 让 Claude Code 或 Codex 直接使用浏览器完成开发辅助任务
• 把一次性的网页操作变成可复用技能

它最有价值的地方，不是“能帮你点网页”。

真正有价值的是：Agent 可以记住网站怎么用，知道遇到问题怎么补，下一次执行时少走弯路。

结语

Browser Use CLI 3.0 的方向很清楚：

让浏览器 Agent 少依赖厚重工具层，直接使用 CDP；让网站经验沉淀成 domain-skills；遇到能力缺口时现场补齐；再通过本地 Chrome、云浏览器和任意 CDP 环境适配不同工作流。

如果你正在使用 Claude Code 或 Codex，想让它们从“会写代码”进一步变成“会操作网页的助手”，这个版本值得试一试。

建议从一个低风险、流程固定的任务开始。

比如：每天登录后台下载报表，整理后保存到指定文件夹。

跑通一次，再逐步加入技能复用、定时执行和人工确认。别一上来就让 Agent 管理整个公司的生产系统——那不是自动化，是给自己安排加班。