腾讯开源 BSK 实测：让 AI 接管你已登录的浏览器

腾讯最新开源的 BSK（Browser Skill Kit）把「AI 操控浏览器」这件事往前推了一步。它不再是启动一个空白的无头浏览器去模拟操作，而是直接接管你已经登录、装满插件的真实 Chrome 会话。这意味着 AI 可以借用你现成的登录态和浏览器指纹去干活，绕开许多反爬机制。这篇文章基于一位 B 站 UP 主的完整实操演示，梳理 BSK 的架构原理、安装方式，以及实测中踩到的三个坑。

BSK 是什么：computer skill 与 browser skill 的分野

要理解 BSK 的价值，得先分清两类 AI 操作方式。Computer skill 靠截取屏幕像素、判断鼠标位置来决定点哪里，本质是「看图操作」；browser skill 则相对简单直接——它在浏览器里读取网页源码（source），从 DOM 结构层面定位元素。从像素定位的角度看，读源码的方式要比纯视觉方案稳定得多。

BSK 全称大致对应 Browser Skill Kit，是腾讯出品的一套工具。它由两部分组成：一是装在操作系统上的服务端（BSK CLI），二是装在浏览器里的插件。UP 主特别强调，浏览器插件这一环反而是最关键、也最容易翻车的地方——他自己就因为装的是旧版本插件，导致协议版本不支持、缺失远程功能而在开头卡了壳。

WebSocket 双向通讯的架构

BSK 的核心机制是 WebSocket。CLI 端起一个 WebSocket 服务（演示中用的是 wss:// 安全连接，走 8443 端口），配对时需要填入一串类似 API key 的 hash 完成握手。浏览器插件配置好后，就与服务端建立起双向通讯。之后无论哪个 AI Agent 调用 CLI，指令都会通过这条 socket 通道传达到浏览器执行。

值得一提的是它的兼容性：BSK 几乎支持市面上所有主流 Agent。安装也极简，UP 主直接把项目 URL 丢给 AI（演示中用的是 OpenClaude），一句「帮我装一下」就在树莓派上部署完成，老用户则做个 update 即可。

WebSocket 是一种在单条 TCP 连接上提供全双工通信的协议（RFC 6455），与传统 HTTP 的「请求-响应」模式不同，它允许服务端主动向客户端推送数据，无需客户端轮询。在 BSK 的场景里，这意味着 AI Agent 发出的指令可以实时「推」到浏览器插件，浏览器执行的结果也能立刻「推」回服务端，延迟极低。wss:// 是 WebSocket 的加密变体（类比 HTTPS 之于 HTTP），通过 TLS 加密传输，适合跨网络的远程控制场景。8443 是常见的 HTTPS 备用端口，选用它而非标准 443 端口通常是为了避免与系统已有的 Web 服务冲突。握手时用到的 hash 字符串相当于一次性共享密钥，确保只有持有该 key 的客户端才能建立连接，防止未授权的设备接入控制通道。

远程指挥：人在外面也能操控家里的浏览器

这套方案最亮眼的场景，是远程指挥。UP 主全程通过手机上的企业微信，接入运行在树莓派上的 OpenClaude 会话，再由 BSK 控制家里那台电脑的 Chrome。人在外面吃完饭遛弯，就能让 AI 抓取一篇 Bloomberg 文章——AI 不仅拿到了比浏览器直接打开时更完整的正文，还顺手做了摘要总结。

配置时有个细节要注意：连接方式要选「远程」，同时把「控制提示 / 确认开关」关掉。否则每一步操作都要你手动确认，远程场景下根本没法用。关掉后 AI 就能全自动执行，无需任何人工干预。

为什么用有头浏览器，而不是无头

一个反直觉的选择是：BSK 采用有头（带界面）浏览器而非无头。原因在于反爬。现代网站的反爬能力极强，会检测 IP 地址、浏览器指纹等各种特征。只有用真实的、已登录的有头浏览器会话，才能带着完整的登录态和指纹去访问，从而突破那些拦截无头爬虫的防线。这正是 BSK 相比传统 CDP 方案或谷歌/Mozilla 出品的无头浏览器工具的关键差异。

CDP（Chrome DevTools Protocol）是谷歌官方提供的浏览器自动化协议，Puppeteer、Playwright 等主流自动化框架底层都依赖它。CDP 通常与无头模式（headless）搭配使用——浏览器在后台运行，没有可见的图形界面，资源占用低，适合 CI/CD 流水线等场景。然而正因为无头浏览器的行为特征过于一致，各大网站（尤其是内容平台和金融类网站）早已针对性地建立了检测规则：User-Agent 中的 HeadlessChrome 标识、缺失的 GPU 渲染信息、异常的 Canvas/WebGL 指纹、缺乏真实鼠标移动轨迹等，都是被识别的依据。Cloudflare、Akamai 等 Bot 管理服务能以极高准确率区分真人浏览器与自动化工具。BSK 选择接管有头浏览器，本质上是「借壳」——用户日常积累的 Cookie、登录态、浏览历史和真实指纹构成了最难伪造的信任凭证，远比任何模拟方案都更接近真人。

实测三个坑与验证码的「人机接管」

实操中暴露了几个真实问题，值得使用者提前知晓。

坑一：插件版本。 旧版插件缺失远程功能，且报的是「协议版本不支持」，实际是功能缺失。务必从 Chrome 商店安装最新版插件。

坑二：新标签 vs 新窗口。 AI 提供两种操作方式，走「新标签」不需要任何交互确认。演示中 AI 打开的是一个 new window，但它保持了用户的浏览器 profile——右上角能看到已登录的头像和全部插件，证明这不是独立的干净环境，而是复用当前登录会话。

坑三：模型的合规红线。 这是最有意思的一点。当 UP 主让 AI 去 Anna's Archive（安娜的档案）抓取电子书信息时，遇到了 Cloudflare 的验证码（captcha）。他直接问 AI 能否「截图识别验证码并按要求点击」，AI 明确回答：技术上可以做到，但我不做——因为它判定这属于协助获取盗版内容。同样，AI 也始终拒绝提供实际的下载链接，反复强调「不会触发下载那一环」。

验证码由人来接管

面对验证码，实际流程变成了人机协作：验证码由 UP 主自己手动完成（他甚至吐槽验证码大小写敏感、字符看不清），AI 则负责验证通过后的数据抓取与整理工作。

验证通过后，AI 展现了它真正的价值：把两页共 61 本书的信息全部采集出来，翻页、抓取、去重一气呵成，最后做数据清洗——识别出真正与 AI 相关的约 10 本、字面匹配的若干本、PDF 格式的 25 本，并整理成 CSV 格式输出。整个过程虽然耗时较长（抓取花了两分多钟），但把原本需要人工逐条查看的活儿彻底自动化了。

Cloudflare 的验证码（现多以 Turnstile 或 hCaptcha 形式出现）是目前 Bot 防御体系中最后一道明文屏障。它的设计目标不只是让机器「看不懂图」，更重要的是通过鼠标移动轨迹、点击时序、浏览器环境熵值等隐式信号来判断是否为真人。即便 AI 在技术上能截图并识别字符，整个交互过程产生的行为特征仍然可能触发二次拦截。这也解释了为什么 AI 选择拒绝而非「勉强一试」——成功率存疑，且可能导致 IP 被标记。人机协作模式（人类处理验证、AI 负责结构化抓取）在实际 RPA（机器人流程自动化）工程中是成熟的解决方案，被称为「Human-in-the-loop」，专门用于处理自动化流程中必须由人介入的异常节点。

使用建议与局限

BSK 把 AI 从「隔离的沙盒」拉进了「你真实的浏览器」，这是它的核心竞争力，也是最需要警惕之处。让 AI 复用你的登录态意味着它能以你的身份操作各种已登录服务，权限边界值得认真评估。关闭确认提示虽然方便远程自动化，但也移除了最后一道人工审核关卡。

从实测看，BSK 的定位很清晰：日常需要 AI 处理真实网页任务、又常受反爬困扰的场景。它不是万能的——遇到验证码这类需要人类介入的环节，仍需人机接管；模型自身的合规约束也会拒绝某些请求。但作为一款刚开源、支持几乎所有主流 Agent 的工具，BSK 的实用性已经得到验证。