ARTICLE · 1031184
BrowserSkill:让 AI 编程助手直接用你的浏览器,还不用你让出控制权
“’
AI 能写代码、能读文件，但就是没法直接操作浏览器。BrowserSkill 用最小的侵入性把这个问题解决了——不劫持你的浏览器，不影响日常使用，只在 AI 需要时才介入。
📌 本文看点
01
借标签页不借浏览器
02
通用接口不锁 Agent
03
三个月 4100 星
DESIGN
核心思路：借标签页，而不是开新浏览器
每天用 Cursor 或 Claude Code 写代码的时候，你有没有遇到过这样的场景：AI 助手说“’我需要登录 GitHub 看一下 issue”，然后你不得不切到浏览器，手动登录，再把页面内容复制给它？或者你想让 AI 帮你跑一个需要登录的网页自动化任务，但各种浏览器自动化工具都要你新建一个无头浏览器实例，完全无法复用你已经在浏览器里登录好的状态？
— BrowserSkill 项目概览
Tencent 开源的 BrowserSkill 正好解决这个痛点——它让 AI 编程助手直接操作你已经登录好的浏览器，而且完全不会打断你正在做的事情。项目上线不到三个月，GitHub Stars 已经突破 4,100，今天单日增长超过 1,300 星，冲上 GitHub Trending 第四名。
大多数 AI 浏览器自动化方案走的都是“’开一个全新的浏览器实例”这条路——无论是 Playwright、Puppeteer 还是各种 browser-use 框架，它们都会启动一个独立的 Chromium 进程，这意味着所有登录态、Cookie、书签都要重新配置。
BrowserSkill 的思路完全不同。它由两部分组成：一个本地的 bsk CLI/守护进程（Rust 编写），和一个浏览器扩展（基于 WXT + Manifest V3，用 React 写的弹窗界面）。AI 助手通过 shell 调用 bsk 命令，守护进程通过 WebSocket 把指令转发给浏览器扩展，扩展在一个独立的“’Agent Window”里执行操作。
「整个链路是：Agent Harness → bsk CLI → bsk 守护进程 → 浏览器扩展 → Agent Window。Agent 从来不直接跟浏览器对话。」
最关键的设计是“’借标签页”机制——当 AI 需要操作你已经在浏览器中打开的某个页面时，它必须显式地“’借用”那个标签页，用完之后归还，你的其他浏览器窗口完全不受影响。你可以在自己的窗口里继续浏览网页，AI 在另一个窗口里干活，互不干扰。
ARCHITECTURE
技术架构：Rust 守护进程 + MV3 扩展 + 21 个工具
BrowserSkill 的仓库是一个 Cargo + pnpm 的 monorepo，结构很清晰。
CLI/守护进程（Rust）：bsk 命令同时充当客户端和服务器。默认情况下它通过 Unix Domain Socket（~/.bsk/run/daemon.sock）暴露 JSON Lines 协议，AI 助手发一条命令，它处理完返回结果就退出。守护进程则监听本地回环地址的 WebSocket（默认端口 52800），接收来自浏览器扩展的连接。
浏览器扩展（TypeScript + React）：基于 WXT 框架构建的 Manifest V3 扩展，包含后台 Service Worker 和 React 弹窗。扩展通过 CDP（Chrome DevTools Protocol）直接操作浏览器——点击、滚动、截图、填表，样样都行。扩展内置了 21 个工具处理器（ToolDispatcher），覆盖了浏览器自动化的绝大多数场景。
协议层（bsk-protocol）：Rust 写的共享类型定义和 JSON Schema，TypeScript 端通过测试保持同步，确保两端的数据结构永远不会对不上。
Agent Window 隔离：每个 Session 对应一个独立的 Agent Window 和 session-scoped 的 ref-store。多个 Session 可以同时存在多个 Agent Window，完全隔离。同 Session 内的操作是串行化的——守护进程对每个 Session 维护一个 RPC 队列，避免多个并发工具调用互相冲突。不同 Session 之间则可以并行执行。
COMPARISON
和同类方案比，BrowserSkill 赢在哪里
目前 AI 浏览器自动化的方案大致分三类，BrowserSkill 跟每一类都有明显的差异：
— BrowserSkill 在 Chrome Web Store 的展示页面
这是最传统的浏览器自动化方式，需要写代码、管理浏览器实例、处理登录态。AI 助手用它的时候需要生成完整的脚本代码，调试成本高。BrowserSkill 的优势在于 AI 只需要发自然语言指令，底层工具链已经封装好了。
这些框架通常也是启动独立的浏览器实例，无法复用已有的登录态。BrowserSkill 直接操作你已经在用的浏览器，Cookie 和登录态天然继承。
Claude Code 最近加了浏览器能力，Cursor 也有相关功能，但这些都是绑定在特定 Agent 里的。BrowserSkill 的 通用接口设计让它在 Agent 框架之争中站到了一个很好的位置——不管最后谁是主流 Agent 平台，只要它能调 shell，就能用 BrowserSkill。
💡 还有一个极其实用的设计：内置 human-in-loop 机制。当自动化任务遇到验证码、登录确认弹窗、或者任何需要人类介入的步骤时，Agent 可以请求你接管，你处理完之后 Agent 继续执行。
USE CASES
典型使用场景
BrowserSkill 最直接的使用场景就是给 AI 编程助手加浏览器能力。你在 Cursor 里写代码，需要查一个需要登录才能访问的内部文档？一句 /browser-skill open 内部wiki地址 就行，AI 直接用你浏览器里已有的登录态打开页面、读取内容。
做网页数据抓取也是高频场景。很多目标网站有反爬机制，但你在浏览器里已经登录了，BrowserSkill 让 AI 以你的身份去抓取，绕过了大部分反爬问题。配合全页截图功能（bsk screenshot --full-page），还能做网页视觉回归测试。
测试工程师用它做 E2E 测试——让 AI 按照测试用例操作网页、截图对比结果。由于支持多 Session 并行，可以同时跑多个测试用例。
对普通开发者来说，它还能帮你自动化那些“’打开网页→登录→点几个按钮→下载文件”的重复性操作。你只需要用自然语言描述要做什么，AI 通过 BrowserSkill 一步步执行。
THE END
开发者生态与未来
BrowserSkill 从 6 月 22 日首次提交到现在，已经经历了 500 多次 commit，发布了 25 个 tag，最新版本 0.3.0 在 9 月 17 日刚发布。Rust 写的 CLI 保证了性能，WXT + MV3 的扩展架构保证了兼容性——目前支持 Chrome 和 Edge，其他 Chromium 内核浏览器理论上也能用，Firefox 支持在计划中。
协议版本已经到了 1.3，向后兼容 1.0-1.2。远程模式支持通过认证的 WSS 连接，让部署在服务器上的 AI Agent 也能操作你本地的浏览器。操作审计功能可以把所有浏览器操作记录下来，方便事后审查。
从社区反响来看，这个项目切中了 AI 编程助手“’最后一公里”的需求——AI 能写代码、能读文件、能跑命令，但就是没法直接操作浏览器。BrowserSkill 用最小的侵入性（一个 CLI + 一个扩展）把这个问题解决了，而且设计得很克制：不劫持你的浏览器，不影响你的日常使用，只在 AI 需要时才介入。
随着 AI 编程助手的普及，“’Agent 能操作浏览器”正在从“’加分项”变成“’标配”。
如果你觉得今天这篇有收获，欢迎点赞、在看、转发三连，我们下篇见。