当 AI Agent 想用你的浏览器，它得先借你的标签页
想象这个画面：你正在浏览器里审查一个 PR，已经登录了 GitHub、Jira、Slack。你的 AI Agent（Claude Code、Cursor、或者 Codex）说："我可以帮你合并这个 PR，但需要访问你的浏览器。"
当 AI Agent 想用你的浏览器，它得先"借"你的标签页
场景：你正在登录 GitHub 审查 PR，Agent 说"我来帮你点那个按钮"
想象这个画面：你正在浏览器里审查一个 PR，已经登录了 GitHub、Jira、Slack。你的 AI Agent（Claude Code、Cursor、或者 Codex）说："我可以帮你合并这个 PR，但需要访问你的浏览器。"
传统做法是什么？要么给 Agent 一个 headless 浏览器——但它没有你的登录态，什么也干不了；要么给它 API key——但不是所有服务都有 API；要么让它用 Playwright 开一个新浏览器实例——但它得重新登录一遍，两因素认证、CAPTCHA、设备验证全来一遍。
Tencent 的 BrowserSkill 给了第四种答案：让 Agent "借"你已经打开的标签页。用完之后还给你，期间你的其他标签页不受影响。
1350 颗星一天涨上来，不是没有道理。
"借标签页"模型：从"模拟人类"到"协作人类"
Browser automation 领域过去十年的主旋律是"模拟人类"。Selenium 模拟点击，Playwright 模拟用户行为，Puppeteer 模拟键盘输入。所有这些工具的隐含假设是：浏览器是工具，Agent 是操作者，人类是旁观者。
BrowserSkill 翻转了这个假设：浏览器是人类的工作空间，Agent 是借用的访客。
具体机制是这样的：
1. Agent Window：BrowserSkill 在你的浏览器里开一个独立的 Agent 窗口，和你正在用的窗口分开。你在自己的窗口里继续工作，Agent 在它的窗口里干活。
2. 显式借用：Agent 需要访问你某个已登录的标签页时，必须通过 bsk CLI 显式声明"我要借用这个 tab"。不是静默抓取，不是后台监控，是显式请求。
3. 用完归还：任务完成后，标签页归还。Agent 不能保留访问权限。
4. Human-in-loop：碰到 CAPTCHA、登录确认、二次验证，Agent 会暂停并请你出手。你点完之后它继续。
这四个机制合起来，本质上是一个权限模型：Agent 的浏览器访问权限不是"全有或全无"，而是"按需借用、用完归还、关键节点人类介入"。
为什么"借标签页"比"开新浏览器"难
技术上，"借标签页"比"开新浏览器"难得多。开新浏览器只需要启动一个 Chromium 实例；借标签页需要：
- 浏览器扩展：BrowserSkill 有一个 Chrome/Edge 扩展，负责和你的浏览器通信。扩展知道你有哪些标签页，知道哪个标签页登录了什么服务。
- 本地 daemon：
bskCLI 背后跑一个本地守护进程，Agent 通过 CLI 和守护进程通信，守护进程再通过扩展和浏览器通信。这条链路确保 Agent 不直接接触你的浏览器 cookie 或 session。 - 会话隔离：Agent 借用标签页期间，它的操作在一个独立的会话上下文里执行。你的其他标签页看不到 Agent 的操作，Agent 也看不到你的其他标签页。
"任何 shell-capable agent 都能用"：CLI 作为通用接口
BrowserSkill 的一个关键设计决策是：不绑定特定 Agent 框架。它通过 bsk CLI 暴露所有功能，任何能调 shell 的 Agent 都能用。
这意味着 Cursor、Claude Code、Codex、OpenClaw、CodeBuddy、WorkBuddy、Pi、Hermes Agent、DeepSeek Harness——这些 Agent 只需要在它们的工具箱里加一条"调用 bsk 命令"的能力，就能立刻获得浏览器操作能力。
这个设计让我想起 Unix 哲学：工具应该通过文本流通信，而不是通过共享内存。BrowserSkill 把"浏览器操作"变成了一组 shell 命令，任何 Agent 都能调用。对比 Playwright 的 Python/Node.js SDK 绑定，或者 browser-use 的 Python-first 设计，BrowserSkill 的 CLI-first 策略在 Agent 生态碎片化的当下是一个聪明的选择。
"Agent Window"：从"共享屏幕"到"并行桌面"
BrowserSkill 的 Agent Window 概念值得单独说。传统 browser automation 工具（Selenium、Playwright、browser-use）要么在 headless 模式下运行（你看不到发生了什么），要么在全屏接管你的浏览器（你什么都干不了）。
Agent Window 是第三条路：你的浏览器窗口和 Agent 的浏览器窗口并行存在，互不干扰。你能看到 Agent 在做什么（可见性），但不需要让出你的浏览器（不中断）。
这个设计背后有一个隐含的判断：Agent 的浏览器操作大多数时候不需要人类盯着看，但偶尔需要人类介入。所以默认并行运行，只在需要时才暂停请求人类介入。这比"全自动"或"全手动"都更符合实际工作流。
和其他 browser automation 方案的对比
| 维度 | Playwright/Puppeteer | browser-use | BrowserSkill |
|---|---|---|---|
| 登录态 | 无（新实例） | 无（新实例） | 有（借用真实标签页） |
| Agent 框架绑定 | SDK 绑定 | Python-first | CLI-first，任何 shell Agent |
| 人类介入 | 无 | 截图+点击 | 显式 human-in-loop |
| 用户浏览器中断 | 不中断（独立实例） | 不中断（独立实例） | 不中断（Agent Window） |
| 安装复杂度 | pip install | pip install | CLI + 浏览器扩展 |
适用场景与局限
BrowserSkill 最适合的场景：
- 需要登录态的操作：审查 GitHub PR、在 Jira 里更新 ticket、在内网系统里填表。这些场景下 API key 往往不可用或权限不足。
- Agent + 人类协作：Agent 处理大部分步骤，人类处理 CAPTCHA 和确认对话框。
- 多 Agent 并行：不同 Agent 借用不同标签页，各自独立工作。
- 需要浏览器扩展：不支持 Firefox（计划中），不支持 Safari。
- 本地运行：Agent 和浏览器必须在同一台机器上。不支持远程 Agent 操作远程浏览器。
- 单用户设计：不支持多用户共享一个浏览器实例。
深层洞察：从"Agent 模拟人类"到"Agent 协作人类"
BrowserSkill 的"借标签页"模型背后，是一个更大的范式转变：Agent 不再试图完全替代人类操作浏览器，而是和人类共享浏览器。
这个转变的意义在于：它承认了 Agent 在某些操作上（CAPTCHA 识别、二次验证、复杂决策）仍然需要人类，而不是假装这些不存在。同时，它让 Agent 能利用人类已经建立的登录态，而不是从头开始模拟人类登录。
从 Agent 安全的角度看，这个模型也更可控：Agent 的浏览器访问权限是"借用"的、临时的、可撤销的，而不是"拥有"的、永久的、不可审计的。每次 Agent 借用标签页，都是一个显式事件，可以被记录和审计。
BrowserSkill 的 GitHub 仓库在 https://github.com/Tencent/BrowserSkill ，1350 颗星一天涨上来，说明这个痛点是真实的。如果你在用 Claude Code、Cursor 或 Codex，且经常需要 Agent 帮你操作浏览器里的已登录服务，BrowserSkill 值得一试。
"借标签页"这个概念，可能会成为 Agent 和浏览器交互的标准模式。就像"借车"比"租车"更方便——只要你信任借车的人。