做浏览器 Agent，迟早会碰到登录这关

本文同步自 X：原帖

做浏览器 Agent，迟早会碰到一个很现实的问题：它能操作网页，却未必进得了你已经登录的系统。

扫码、验证码、二次验证，甚至只是一个需要保持登录状态的后台，都可能让自动化流程中断。

最近看到两个挺有意思的开源项目，恰好代表了两种不同的思路。

browser-use 算是这条赛道的老面孔了，GitHub 已经接近 12 万 Star，MIT 协议。基于 Python，让 Agent 自己打开浏览器、识别页面、执行操作。适合陌生网站探索，以及需要深度定制的自动化任务。

上手也简单：

uv add browser-use

另一个是腾讯开源的 BrowserSkill，目前接近一万 Star，同样是 MIT。

它的思路有点不同：不急着给 Agent 准备一台新浏览器，而是让它直接使用你已经登录的 Chrome 或 Edge。

原来的浏览器会话、账号状态都可以沿用，Agent 在独立窗口里执行任务，不耽误你正常浏览。遇到验证码或二次验证，再交还给人处理。

安装入口：

curl -fsSL https://raw.githubusercontent.com/Tencent/BrowserSkill/main/install.sh | sh

还需要安装浏览器扩展，通过 bsk install-skill 接入 Agent。

我自己平时就在用持久登录的浏览器跑一些日常自动化，所以对 BrowserSkill 这条路线更有感触。

很多时候，Agent 不是不会操作，而是拿不到操作所需的身份。

从这个角度看，两者并非简单的替代关系。

browser-use 更适合从零开始探索和控制网页；BrowserSkill 则试图打通人和 Agent 之间已有的浏览器环境。

前者解决“怎么操作”，后者进一步解决“以谁的身份操作”。

当然，共享登录状态也意味着共享相应权限。涉及后台数据、支付或敏感账号，最好从低权限、只读任务开始，关键操作保留人工确认。

我觉得这比单纯比较哪个 Agent 点击成功率更值得讨论。

浏览器自动化往下走，真正重要的可能不只是让 Agent 更会用浏览器，而是让它能够安全、连续地接手人的工作。

项目地址：

你更倾向于给 Agent 一套独立的浏览器环境，还是让它接入自己已经登录的浏览器？