涌现观点｜浏览器自动化的两条路：Skill 与 CLI 该怎么选

行业报告显示 85% 的企业已在用自动化测试；据 Stack Overflow 2025 开发者调查^[1]，52% 的开发者压根不用 AI 代理。另一边，Skyvern 对会话持久化的技术分析^[2]指出：会话持久化能把自动化运行时间砍掉 70%，而 Cookie 管理不当会直接导致 85% 的认证失败。数字摆在一起，问题就变了。问题不是「要不要做浏览器自动化」，而是你选的是哪条路。选错路，同样的目标会多绕一大圈。

在 skills.sh^[3] 上，你能同时看到两类东西：一类是「即装即用」的 Agent Skill，比如 Vercel 的 agent-browser^[4]，在 Cursor^[5] 或 Claude Code^[6] 对话里说一句就能让 Agent 帮你打开网页、点按钮、截个图；另一类是「可进流水线」的开源 CLI，比如 browser-use^[7]，靠一串命令和持久会话在脚本、CI、Python 里跑多步操作。前两天有人问我：既想对话里随口点一下，又想把步骤写进 CI 复现，该装哪个？很多建设者都卡在这：只想在对话里点一下的人，不想碰脚本；想把浏览器操作写进 CI 或爬虫的人，又需要稳定、可复现、能进管道。两条路都在，但没人给你一张「什么时候走哪条」的地图。

这两条路本质不一样。Skill 解决的是「单次对话内的任务」：你说话，Agent 在当轮对话里帮你做完。CLI 解决的是「跨命令的持久会话与脚本组合」：浏览器在多次命令之间保持打开，你可以 open → 操作 → 再操作 → close，也可以多 session 并行。同一件事，比如「帮我登录 Gmail 并导出某标签的邮件」，用 Skill 可能是一轮对话搞定，用 CLI 则是几句命令加一段可复用的脚本。选对了，事半功倍；选错了，事倍功半。先讲 CLI 这条路上的 browser-use，再回头说清楚何时选 Skill、何时选 CLI。

两条路怎么选，可以看这张决策关系：

browser-use：用「state → 再点」把浏览器变成可编程接口

browser-use 的心智很直接：先拿到当前页面上「能点哪儿」的清单，再按清单上的编号去点、去填。命令是 browser-use state，输出一列可点击元素的索引；然后你用 browser-use click 5、browser-use input 3 "text" 按索引操作。浏览器在命令之间不会关，所以你可以连续发很多条命令，形成多步流程。一段最简的可复制流程长这样：

用索引绑的是「当前 DOM 里的可交互元素」，不是坐标也不是截图。页面一动，坐标和截图就对不上，测试就 flaky。先跑一遍 state 再按索引操作，等于每次动手前都对齐一遍当前状态。官方文档里写得很死：

Always run browser-use state first.

这不是建议，是机制。先 state 再 click，不是啰嗦，是机制。

典型用法就是：open → state（看索引）→ click / input / type / scroll → 再 state 或 screenshot 验证 → 循环或 close。需要多开几个互不干扰的浏览器时，用 --session work 和 --session personal 之类给会话起名，就能并行多路。核心循环可以概括成下面这张图：

每次交互前用同一套语义（indices）对齐当前 DOM，等于把「黑箱里的页面」变成一台可编程状态机：当前状态可见，转移可控。我按官方文档跑完一遍后的体会是：一旦习惯「先 state 再看索引」，脚本的稳定性会明显好过「盲点坐标」或「等 AI 猜按钮在哪」。

三种浏览器模式：chromium / real / remote 该怎么选？

browser-use 支持三种浏览器模式，对应三种场景。一句话记：做 E2E 用 chromium，要登录态用 real，云端流水线用 remote。

chromium：默认无头、隔离、不带本机登录态。适合 CI、爬虫、一切不依赖 cookie 的自动化。要肉眼看着跑可以加 --headed，方便调试。

real：用你本机的 Chrome，带 cookies、扩展和已登录会话。适合「必须登录才能干完」的流程，比如用你已登录的 Gmail 导数据。用 real 之前必须先搞清楚用哪个 Chrome profile，否则会进错账号。命令 browser-use profile list-local 可以列出本机 profile；文档里写得很清楚：在打开 real 浏览器之前，agent 必须先问用户：用哪个 profile，还是不用 profile。选错 profile，等于进了别人的账号。

remote：云浏览器，可配 Cloud Profile，需要 API Key。适合没有本地环境、或要代理/多地域的场景。Cookie 往云端同步时，推荐「按域名同步」而不是全量同步，避免把整台浏览器的敏感数据都扔上去。我自己的用法是：本地要登 Gmail 导数据时用 real，其它能跑脚本的一律 chromium，省心。

你可能会问：real 用本机 Chrome，会不会不安全？用 real 前必须明确「用哪个 profile 或 no profile」，文档要求所有 agent 在打开 real 前先问用户。按这份清单做，误用他人会话的风险是可控的。

持久会话的代价：别忘了 close，也要会排错

持久会话的好处前面说了：浏览器不关，命令之间复用，多步流程好写。但「浏览器常开」是有代价的。不 browser-use close，进程和端口会一直占着；多开了几个 session 又不收尾，会叠在一起。文档里专门有一句：

Always close the browser when done.

多 session 时先用 browser-use sessions 看清当前有哪些，收尾用 browser-use close --all。你可能会觉得「关不关不是小事吗」，但在自动化脚本里，忘关一次就会留下孤儿进程和占用的端口，下次跑就冲突。我有一次忘了 close，第二天同一台机再跑直接端口占满，查了半天才想到是昨天的 session 没收尾。close 不是顺手关窗，是流程里必须写进去的一步。

real 模式还有一个坑：选错 profile 会进错账号。文档再次强调：Before opening a real browser, always ask which profile or no profile。用 profile list-local 给用户选，别默认。

和「要不要 API Key」的边界也要分清。browser-use run "任务描述"（用 LLM 做自然语言任务）、extract、以及 --browser remote 都需要 API Key（或配置好的 LLM 环境变量）。但如果你只是用 chromium + state/click/input 做本地脚本，可以零 Key 跑。很多建设者不知道这条线，以为一定要申请 key 才能用，其实纯脚本流完全可以不碰 run。

行业里还有一组反差：据 Stack Overflow 2025 调查^[8]，46% 的开发者主动不信任 AI 工具的准确性；据报道，RPA 初始准确率约 60%、部署周期约 12～18 个月（见行业与学术案例）。不信任「黑箱点一下」和缺「可复现脚本」其实是同一件事的两面——信不过一次性的 AI 操作，才更需要「先 state 再 click」这种白盒、可回放流程。持久会话和 state 优先能解决一大部分会话和 flaky 问题，但细节决定成败——close、profile、API Key 边界，这三件小事漏掉哪一件，都会在某个时刻反咬一口。

开源 CLI 与 Skill 生态：何时选 browser-use，何时选 agent-browser

browser-use 来自社区（browser-use/browser-use^[9]），在 skills.sh 上的 browser-use 技能页^[10] Hot 榜第二，周安装 17.3K+。agent-browser 来自 Vercel Labs^[11]，在 Cursor、Claude Code 里一键安装，偏「对话内即用」。两者代表两条路，不是同一款产品的两个版本。

有人会问：browser-use 和 agent-browser 会不会很快一方取代另一方？不会。两条路解决的需求不一样。可以这样记：

选 CLI（browser-use）时，你通常已经想好了：要多 session 并行、要精确控制「先 state 再 click」的节奏、不想绑死某一家 IDE 或 Agent。选 Skill（agent-browser）时，你更在意的是：在对话里说完就干、团队已经统一用 Cursor 或 Claude Code。若两种需求都很少，可以先不选，等有明确场景再对号入座。浏览器自动化不是「要么脚本要么 Agent」二选一，而是两条并行的路；一条通向对话里的即装即用，一条通向流水线里的持久会话。走错岔口，同样的目的地会多绕一大圈。

选对路，事半功倍；选错路，事倍功半。 85% 已自动化、52% 不用代理——真问题不是「要不要做」，而是「你选哪条路」。

实操清单：5 个建设者必知要点

要点 1：安装与首跑

不长期装的话，可以直接用：uvx "browser-use[cli]" open https://example.com。长期用就：uv pip install "browser-use[cli]"，然后执行 browser-use install 装 Chromium 依赖。别名 bu、browser、browseruse 和 browser-use 等价。第一次跑如果报缺 Chromium，执行一次 browser-use install 即可。

要点 2：核心循环

open → 跑一遍 state 看索引 → 用 click / input / type / keys 操作 → 需要时再 state 或 screenshot 验证；元素在下面就先 scroll down 再 state。页面若大量 iframe 或强动态渲染，可先 wait 再 state，避免索引对不上。文档里的 Tips 第一条就是：Always run browser-use state first。养成「动页面前先 state」的习惯，能少踩很多 flaky 的坑。

要点 3：登录态

用 real 时先 profile list-local 选好 profile，再 --browser real --profile "Profile 1" 这样开。云端用 remote + Cloud Profile 时，优先按域名同步 cookie，别默认全量同步；文档里对「全量同步」有明确警告，敏感数据会一起上去。

要点 4：收尾与排错

任务结束必须执行 browser-use close。卡住时先 browser-use server stop 清掉可能卡住的进程，再用 --headed 开一次看界面。元素找不到就：再跑一遍 state、scroll、再 state，往往元素在首屏下面。Session 乱了就用 browser-use sessions 看、browser-use close --all 清空再开。

要点 5：与 Agent 结合

要用自然语言让 LLM 帮你完成浏览器任务时，用 browser-use run "任务描述"，这会用到 API Key。一言以蔽之：不跑 run，chromium + state/click/input 就能零 Key 玩转 browser-use。 这条边界搞清楚，能省不少「我到底要不要申请 key」的纠结。

两条路会长期并存还是最终收敛成一条？我倾向于并存：对话里要的是省心，流水线要的是可控。你平时更常踩的是哪条路的坑——是忘 close、选错 profile，还是「该用 CLI 却一直在对话里点」？欢迎在评论区聊聊。

核心情报来源：browser-use^[12]（Browser Automation with browser-use CLI），browser-use/browser-use，skills.sh；2026 年 1 月首见。85% 企业自动化测试见行业报告；52%/46% 见 Stack Overflow 2025 开发者调查；70%/85% 会话与认证数据见 Skyvern 会话持久化技术博客；RPA 约 60%/12–18 月见行业与学术案例。