每周AI工具|AI 助手总卡在登录页:腾讯开源 BrowserSkill,一行命令借用你已登录的浏览器

AI工具 AI科研专家 — 用AI做科研的效率工具

浏览器复用 · 文献库检索 · 投稿留痕 · 凭证边界

点击文末「阅读原文」直接使用

关注「AI-For-Precision-Health」 — 每天一篇AI科研实操干货

食品 · 医药 · 器械 · AI工具 · 科研Skill — 让AI真正帮你做科研。

让 AI 帮你干点网页上的活，最卡的一步从来不是它看不懂页面，而是它连门都进不去。

我自己的浏览器里常年挂着三样必须登录才能用的东西：机构订阅的文献库、投稿系统，还有一个试剂订购后台。每次想让 AI 接手其中任何一步，最后都会演成同一个画面——我坐在旁边，把它撞上的登录页和验证码一页页手动点过去。那个瞬间它连我自己的手速都比不上。

9 月 17 日，腾讯开源了一个叫 BrowserSkill 的项目，把这件事换了个方向。它不去开一个干净的无痕浏览器，而是用一条命令行加一个浏览器扩展，把 AI 接到你真实、已经登录的浏览器上：agent 在独立的 Agent Window 里干活，不抢你的鼠标；要碰你已经打开的标签页，得先显式「借用」，用完归还[1][2]。项目上线当天就在 GitHub Trending 冲到单日新增约 1,300 star，9 月中旬第三方快照已抓到 5,297 star、MIT 许可[3][4]。

但它最有价值的地方，和它最大的风险，来自同一件事：让 agent 复用你的登录态。今天我把这东西拆开——架构、安装、科研场景，以及四条必须自己扛的边界。

本文要点

① 它解决的不是「网页自动化」，而是「复用你已经登好的会话」——Playwright 开的是干净实例，BrowserSkill 借的是你真实的浏览器[6]；② 链路全在本机：agent → bsk 命令行 → 本地守护进程 → 浏览器扩展 → Agent Window，daemon 与扩展默认走 127.0.0.1:52800[2]；③ 两个默认开启的安全开关是「借标签页前确认」和「允许人工帮助」，0.3.0 起旧的无人值守参数不能覆盖它们[2]；④ 最容易踩的坑不是安装，是把「窗口隔离」当成「账号沙箱」——Agent Window 仍在你的浏览器资料里，继承你的登录态[2]。

创作来源说明：本文信息基于腾讯 BrowserSkill 开源仓库（github.com/Tencent/BrowserSkill，MIT 许可）的 README、AGENT_INSTALL.md 与 release 记录（cli-v0.3.0，2026-09-17）、GitHub 仓库元数据（2026-09-19 抓取）、Chrome 扩展 Manifest V3 权限文档、Playwright 官方鉴权文档，以及第三方技术媒体与开源雷达的公开实测整理（2026-09-18 至 09-19）。star 数与 issue 编号来自第三方快照与整理，随时变化，引用前请以仓库实时页面为准；文中 10 步流程是按官方文档逐条核对整理的，不是我的实机运行日志（原因见第三节的交底）。

先把这件事说清楚：Playwright、Puppeteer 这类工具做得很好，但它们的设计前提是干净、可复现、可批量——独立浏览器实例、固定环境、公开页面、随时可重跑[6]。而科研工作流里那些页面恰恰相反：机构 IP 段校验、SSO 跳转、OAuth 回调、一次性验证码、双标签页共享 cookie、对无头浏览器做指纹风控。你让脚本从零开始，它第一步就过不去。

我在这上面栽过不止一次。最早做文献调研时想让脚本自动导出题录，写了两天，最后卡在会话过期和机构代理认证上——脚本跑得再顺，一过夜就全废。后来换成半自动：脚本负责抓，我负责守着重新登录。这种分工说出来挺荒谬的，但做过的人都知道，这就是当时的现实。

传统只有两条路可走，而两条都不舒服。第一条是把凭据交出去：把账号密码、cookie 或 token 交给脚本，让它自己登——安全上完全说不通，机构账号一旦泄露，牵出来的是整个单位。第二条是让脚本抢你的浏览器窗口：它接管鼠标和焦点，你整段时间没法干别的，而且随时可能因为一次误点把状态搞乱。

BrowserSkill 走的是第三条路：不搬运凭据，也不抢夺窗口，而是把「借用」这个概念制度化。agent 默认只在一个专用窗口里工作；确实需要碰你已经打开的页面，就先向你申请借用，用完归还[2]。我第一次读到「borrow-and-return」这个说法的时候，觉得这才是把工程问题拆对了地方——

它承认了一件大多数工具不愿意承认的事：你的登录态本身就是一种资产，正确做法是让它留在原地被引用，而不是被复制出去。这个判断，比它现在有多少 star 更值得留意。

一条命令要过四层。agent 先调用 bsk 命令行；命令行通过本地进程间通信找到 bsk 守护进程（daemon）；守护进程默认通过 127.0.0.1:52800 的 WebSocket 找到浏览器里的扩展；最后由扩展控制专用的 Agent Window 完成动作[1][2]。整条链路跑在本机，项目文档说明默认没有遥测，也没有强制的托管服务[2]。

读什么、做什么，范围是明确的。读取侧：DOM、可访问性树、HTML、页面截图与标签信息。动作侧：导航、点击、输入、滚动、下载文件，以及生成完整页面截图[2]。这套能力集对科研场景来说刚好够用——它不承诺绕过任何网站的安全校验，也没有说能适配所有浏览器和所有站点，官方文档本身就建议从小范围开始试[2]。

「借用」是这里最值得单独讲的设计。默认情况下，agent 不控制你已经打开的普通标签页，它在自己的窗口里工作；只有当它确实需要操作你面前的某个页面时，才发起一次显式的标签页借用，任务结束后归还[2]。同一会话内的调用是串行执行的，不同会话之间可以并行——这意味着多个 agent 能同时干活，但也意味着「哪个标签页归谁」变成了你必须自己搞清楚的事[2]。

这里我要把一句话写重：Agent Window 是窗口隔离，不是账号沙箱。它仍然处在你的浏览器资料（profile）里，因此可能继承网站登录状态[2]。窗口隔离能减少误操作，但不会让账号的权限少一分。你判断风险的时候，不能只问「它会不会把我的 cookie 导出去」，还要问「它能用这个账号替我完成哪些操作」——后一个问题才是真的。

先交个底

我本机是 Windows x64，浏览器里没有机构订阅账号，这一周也没有让 agent 真正接管过任何一个登录页面。所以下面 10 步，是我按官方 README、AGENT_INSTALL.md 与第三方公开实测逐条核对整理的，不是我的实机运行日志。每条命令都能在仓库里复查，你照着跑能对上。涉及权限和账号的步骤，请务必先在低权限测试账号上走一遍。

三阶段全景——阶段一（Step 1-3）装上：命令行、扩展、技能；阶段二（Step 4-8）用起来：读页面、借标签页、整页存证、填表下载、开审计；阶段三（Step 9-10）跑实战：文献检索导出与归档。

Step 1｜装 bsk 命令行工具

📥 输入：一台联网电脑（macOS / Linux / Windows x64）；🤖 AI动作：macOS 与 Linux 用 curl -fsSL https://raw.githubusercontent.com/Tencent/BrowserSkill/main/install.sh | sh，Windows 则在 PowerShell 里执行 irm https://raw.githubusercontent.com/Tencent/BrowserSkill/main/install.ps1 | iex，默认装到 ~/.local/bin[2]；📤 输出：可执行的 bsk 命令；🔍 人审：跑 bsk --version 能打印出版本号；⚠️ 失败处理：装完先确认安装目录进了 PATH，必要时在当前 shell 补一次 export PATH="${BSK_INSTALL_DIR:-$HOME/.local/bin}:$PATH"——安装脚本若只改了当前 shell 的环境变量，已经在运行的 agent 仍然找不到这条命令，看起来像装失败，其实只是环境没传进去，这是官方文档专门提醒过的一个坑[2]。

Step 2｜装浏览器扩展并确认连接

📥 输入：Chrome 或 Edge（其它 Chromium 内核浏览器需允许加载未打包扩展）；🤖 AI动作：从 Chrome Web Store 或 Edge Add-ons 安装 BrowserSkill 扩展，装好后在扩展面板确认连接状态；📤 输出：浏览器侧就绪的连接；🔍 人审：扩展面板能看到连接状态、浏览器别名与实例信息；⚠️ 失败处理：本轮官方只支持 Chrome 与 Edge，Firefox 仍在路线图阶段；Windows 目前只支持 x64，其它架构先别折腾[1][2]。

Step 3｜把技能装进你的 agent

📥 输入：任意一个能执行 shell 的 agent（Claude Code、Codex、Cursor、OpenClaw、WorkBuddy、DeepSeek Harness 等都有现成入口）[1][4]；🤖 AI动作：执行 bsk install-skill，用空格键勾选目标 harness，回车安装；📤 输出：该 harness 的技能目录下出现 browser-skill/SKILL.md；🔍 人审：跑 bsk doctor 做整体自检——它不会覆盖你本地改过的技能，只给警告，要恢复官方版本得显式加 --force[1][2]；⚠️ 失败处理：不在官方列表里的 harness，把仓库中的 skill/SKILL.md 手动复制到它的技能目录即可；用 DeepSeek Harness 的话走专用插件包，这一步可以跳过[1][2]。

Step 4｜让它先看清页面（读取）

📥 输入：目标页面地址；🤖 AI动作：用 bsk open <url> 打开页面，agent 读取 DOM、可访问性树、HTML 与截图[2]；📤 输出：结构化的页面内容描述；🔍 人审：对着真实页面核对它描述的元素是否真在那一屏，别只看命令回显；⚠️ 失败处理：页面是异步渲染时，不要让它「再读一次」硬撞——先确认加载完成状态，命令返回成功不等于内容已经就绪。

Step 5｜借用你已经打开的那个标签页

📥 输入：你已在浏览器里登录并停在目标页的标签页；🤖 AI动作：agent 发起一次显式的标签页借用，把该页交给 Agent Window 处理[2]；📤 输出：对该标签页的读取与操作能力；🔍 人审：「借用前确认」默认开启，确认框弹出来时核对清楚借的是哪一个标签页；⚠️ 失败处理：任务结束后记得归还；更重要的是——别把借用理解成隔离。借来的页面处在你的登录态下，agent 在这个页面上的权限，跟你自己拿鼠标点是一样的[2]。

Step 6｜整页截图存证

📥 输入：需要留痕的页面（审评进度、申报回执、订单确认页）；🤖 AI动作：用 bsk screenshot --full-page 生成完整长页截图[2]；📤 输出：整页 PNG，可直接进你的留痕目录；🔍 人审：核对截图里是否包含时间字段与关键结论区域——只有可见字段才拍得下来；⚠️ 失败处理：后台窗口模式下不要凭「显示成功」就收工。仓库的已知问题里就有这一类反馈：后台窗口下点击命令返回成功、但实际没有产生输入[4][8]。要么让它在可见窗口里跑，要么事后人工复核页面状态。

Step 7｜填表、滚动与下载

📥 输入：字段清单与要下载的资源；🤖 AI动作：执行输入、点击、滚动与触发下载[2]；📤 输出：填好的表单状态，或落到本地的文件；🔍 人审：任何会改变状态的操作，第一次都在旁边看着，尤其是提交类按钮；⚠️ 失败处理：撞上登录、验证码、一次性验证码或付款确认，就让它停下来交回给你——「允许人工帮助」默认开启，这正是它跟「让脚本硬闯」的根本区别：它把人工接管当作正常流程，而不是错误状态[2]。

Step 8｜把操作审计打开（默认是关的）

📥 输入：扩展设置里的审计开关；🤖 AI动作：开启后，操作记录以 JSONL 格式写在守护进程所在主机的 BSK_HOME/audit 目录下[7]；📤 输出：可检索的动作日志；🔍 人审：先把它的边界搞清楚——只记录动作元数据，不保存页面正文、输入值、完整 DOM、截图和上传内容；已结束任务保留 30 天，单个任务上限约 16 MiB，项目自己也说明不提供防篡改或不可抵赖的保证[7]；⚠️ 失败处理：关闭审计不会自动删除旧记录，卸载扩展也不会清理守护进程侧的文件——要清理得自己动手[7]。

先说清这个案例为什么选它。做综述的前期检索，是科研里最典型、最重复、又最依赖登录态的一步：机构订阅的文献库按 IP 段加账号双重控制，题录和 PDF 都只能在这个会话里拿。它也是我最早想让脚本接手、又最早放弃的那一步。

输入侧：① 一个已经登录机构订阅的文献库标签页；② 检索式（关键词 + 年份与文献类型限定）；③ 目标导出格式（BibTeX 或 RIS）。输出侧：一份可导入 EndNote / Zotero 的题录文件、一个 PDF 归档目录，以及检索条件的存档。验收侧：题录条数与页面显示的命中数一致、抽样 DOI 可解析、PDF 能正常打开且页数合理。

这套流程真正省掉的，不是「点击」这个动作，而是「人必须一直在线」这个约束。你可以去配试剂、去开组会，回来收结果；只有它撞上人工环节时才会叫你。

Step 9｜检索、翻页与逐条导出题录

📥 输入：检索式与限定条件；🤖 AI动作：在借用的标签页里执行检索、翻页、逐条抓取题录字段，导出为 BibTeX 或 RIS；📤 输出：题录文件；🔍 人审：拿命中总数对账，再抽查 5-10 条核对期刊名、年份、DOI 是否与页面一致；⚠️ 失败处理：翻页中途会话过期，就停下来交回人工重新登录——不要为了提高速度开多个会话同时打同一个库，这既容易被风控，也会让你事后分不清哪个标签页归哪个任务[2]。

Step 10｜下载、对账与归档

📥 输入：需要留存的 PDF 或页面；🤖 AI动作：触发下载，必要时对关键页面做整页截图存证；📤 输出：本地 PDF 目录 + 存证截图；🔍 人审：用「计划下载 N 个 / 实际落地 M 个」对账，抽查几份 PDF 能否正常打开；⚠️ 失败处理：下载目录权限不足或命名冲突会静默失败，只看命令输出发现不了——所以对账这一步不能省，它是这套流程里唯一能兜住「假成功」的环节。

合规边界（四条硬线，一条都不能含糊）：① 机构账号不是你个人的——拿它跑自动化之前，先确认图书馆或单位的使用条款是否允许自动化访问，这条我不会替你判断；② 涉密数据别上云——Agent Window 里读到的页面内容会进入你所选模型的上下文，敏感课题请先走本地部署，再谈自动化；③ 审计日志不是司法证据——官方明确它不提供防篡改与不可抵赖保证，别把它当作合规凭证，它只是给你自己复盘用的[7]；④ 高权限账号最后上——主账号、财务后台、单位管理端不要作为第一批测试对象，先用一个低权限测试账号把流程走顺[2]。

好在哪，说三点。第一，它把问题拆对了地方：不搬凭据、不抢窗口，让登录态留在原地被引用——这个设计选择比任何功能列表都重要。第二，入口是通用的：因为浏览器能力被封装成一条命令行，任何能跑 shell 的 agent 都能接，不绑定单一框架，也不锁定在某家的 SDK 上[1][4]。第三，安全默认值不糊弄：借用前确认、允许人工帮助这两个开关是默认开启的，而且从 0.3.0 起，旧的无人值守参数无法再覆盖扩展里的当前设置——等于把「安全设置以扩展为准」写进了版本行为[2]。

不足与已知问题，也照实说。这个项目现在更像是「值得谨慎接入工作流」，而不是「可以托付关键操作」。第三方整理提到的几个值得盯的点：后台窗口下的点击命令可能返回成功但未实际输入；Windows 上的会话可靠性；守护进程的生命周期管理；Chrome 资料（profile）识别；视频录制能力还停留在需求阶段[4][8]。平台覆盖面也有限——官方只支持 Chrome 与 Edge，Windows 仅 x64，Firefox 还在路线图里[1][2]。扩展要申请的权限一点不轻：调试、标签页、脚本注入、导航监听、活动标签页，以及全站点访问[5]。这些权限每一项都有正当用途，但同样意味着扩展的来源、更新链路和远程连接对象都必须可信。

还有一个必须提的模式差异：项目默认是本机运行、无遥测，但它也支持把扩展配对到经过认证的远程守护进程或网关[2]。一旦走远程模式，被配对的那台服务器就成了高信任组件——它可能收到页面内容、截图、标签信息和操作结果。做团队部署的人，这一步必须单独评估。

所以什么场景该选别人？只要你的目标是公开页面的、可复现的批量抓取，Playwright 或干脆一个 HTTP 请求就够了，更便宜也更稳；需要跨 CI 跑像素级视觉回归的，那本来就是 Playwright 的活[6]。BrowserSkill 的坐标很清楚：当目标页面必须带着你本人的登录态才进得去的时候，它才成立。我用一句话概括我的判断——它不是更强的浏览器自动化，它是「浏览器自动化的前置条件」被重新定义了一遍。

「过去我们让 AI 去学怎么登录，现在换了个问法：为什么不能直接借用我已经登好的那一次登录？」

综合评分（捞仔主观打分，10分制）

问题定位精准度：9.5（「登录态复用」这个缺口真实且长期被绕开）｜ 上手门槛：8.5（一条命令加一次商店安装，门槛主要在权限理解而非操作）｜ 证据完备度：7（仓库、文档、权限说明都公开，但 issue 与热度数据依赖第三方快照，会随时间变化）｜ 即用安全性：5.5（审计默认关闭、窗口隔离易被误读成沙箱、高权限权限申请不可避免）｜ 对科研人实用度：8（文献库检索、投稿状态核对、关键页面存证三处都能落地）｜ 综合：7.7

💬 你浏览器里那个「必须登录才进得去、又每周都要点一遍」的页面是什么？是文献库、投稿系统，还是某个申报后台？评论区说说你的场景，我会挑几个写进后续的实操稿。觉得有用请点个「在看」，转给那位每周手动导出题录的同门。