腾讯开源 BrowserSkill：AI 直接借用你已登录的浏览器

AI 想替你操作网页，最先卡住的往往不是任务本身，而是登录这一关——它得先拿到你的账号密码登进去。腾讯开源的 BrowserSkill 换了个思路：不要你的密码，直接让 AI 借用你已经登录好的浏览器会话。这个项目在 GitHub 上已经拿下 7000 多颗 star，最近 30 天涨了将近 6000，采用宽松的 MIT 协议。

它解决了什么问题

传统的 AI 浏览器自动化方案，绕不开身份认证这道坎。要么让 AI 重新走一遍登录流程，要么把凭证交给它，二者都伴随明显的安全顾虑和体验割裂。

BrowserSkill 的做法是让 AI 直接连上你当前已经登录的浏览器,复用现成的登录状态。这意味着那些「登录后才看得到的页面」「内部系统里的表单」——过去自动化工具最难啃的场景——现在 AI 可以直接上手。

它给 AI 配了两样东西：一个命令行工具和一个浏览器扩展。AI 只要会敲命令，就能连上浏览器执行操作。整套机制对模型的要求不高，本质上是把「操作浏览器」翻译成了命令行能理解的指令。

不抢你的标签页，中间隔一层守护进程

一个容易被忽略但很实用的设计：AI 是另开一个窗口干活的，不占用你正在浏览的标签页。你刷你的，它做它的，互不干扰。这对需要一边工作一边让 AI 跑任务的人来说，体验差别很大。

更关键的是安全边界。AI 并不直接触碰你的浏览器，中间隔着一层本地守护进程（daemon）。所有操作都要经过这一层，它做了什么都会留下记录，可追溯、可审计。这种设计在把浏览器控制权交给 AI 这件事上，提供了必要的信任基础。

遇到验证码这类 AI 搞不定的环节，它不会硬闯，而是停下来喊你过去帮一把。人机协作的边界划得清楚——机器负责能自动化的部分，人负责机器过不去的关卡。

守护进程（daemon）是一种在后台持续运行的系统级进程，不直接与用户交互，专门负责处理特定服务或转发请求。在 BrowserSkill 的架构中，这一层本地守护进程充当了 AI 代理与浏览器之间的「中间人」：AI 发出的所有指令先到达守护进程，由它校验、记录后再转发给浏览器扩展执行。这种「代理层」设计的好处是双重的——一方面，AI 无法绕过守护进程直接控制浏览器，降低了失控风险；另一方面，所有操作都有完整的日志留存，出了问题可以逐条回溯。类似的架构也常见于企业级安全产品，本质上是在自动化能力与可控性之间找到平衡点。

能干哪些活

从素材披露的能力看，BrowserSkill 覆盖了几类实际场景：

• 登录后才能访问的页面抓取
• 内部系统里的表单填写与操作
• 整页长截图
• 线上出问题时的请求排查

这些恰恰是纯 API 或无头浏览器方案难以覆盖的「有状态、需身份」的任务，也是它相比传统爬虫和自动化框架的差异化价值所在。

「无头浏览器」（Headless Browser）是指没有图形界面的浏览器实例，常用于自动化测试和爬虫场景，代表工具有 Puppeteer、Playwright 等。这类方案的根本局限在于它启动的是一个全新的、未登录的浏览器环境，无法继承用户的 Cookie、Session 及本地存储中的登录状态，遇到需要身份验证的页面就会卡住。BrowserSkill 的差异化恰恰在于它操作的是用户「真实跑着的浏览器」，所有已经存在的登录态、会话 Token、甚至企业内网的单点登录（SSO）状态都可以直接复用，这对内部系统自动化尤为关键——很多企业系统根本不提供 API，只能通过浏览器界面操作。

兼容性与接入方式

浏览器方面，Chrome 和 Edge 都支持；操作系统覆盖 Windows、macOS、Linux 三大平台。

接入侧，只要是「会敲命令」的代理都能直接用，比如 Cursor、Claude Code 这类编码代理。这也决定了它的主要受众——开发者和会使用命令行代理的进阶用户，而非纯小白。

短板与局限

工具并非没有边界，几个明确的限制值得知晓：

• 只支持 Chromium 系浏览器，Firefox、Safari 等暂不在覆盖范围内；
• 扩展需要手动安装一次，不是开箱即用；
• 一个扩展只能服务一个代理，多代理并发场景会受限。

值得关注的信号

把这些放到一起看，BrowserSkill 代表了 AI Agent 落地的一个务实方向：与其追求让 AI 从零构建一切，不如让它复用人类已经建立好的数字身份和会话状态。密码不交出去、操作留痕、人机分工明确——这些工程细节，往往比模型能力本身更决定一个工具能不能真正被用起来。

30 天涨 6000 星的增速，也说明「让 AI 安全地用我的浏览器」是一个真实存在且尚未被很好满足的需求。对于已经在用 Cursor、Claude Code 的开发者来说，这是一个值得一试的开源选项。