Tencent/BrowserSkill：5.3k stars 的 "让 AI agent 用你的真实浏览器"，复用登录态 + 不打扰你工作 + 11 个 agent harness 都支持
上周我用 Claude Code 帮我改一个 GitHub PR review，agent 跑到一半跟我说：
我需要 GitHub 登录态才能 fetch PR 评论。 你能帮我在浏览器里登录 GitHub 吗？
我打开浏览器，手动登录 GitHub，回来告诉它” 好了”。 agent 接着跑。 整个流程中断了我，我得” 开浏览器 → 输账号 → 关浏览器 → 回来”。
这是个很常见的痛点。 AI agent 要操作浏览器，但默认是 headless 模式（不带登录态）。 碰到需要登录的网站，agent 直接卡住。
昨天我在 GitHub Trending 上刷到一个新项目：Tencent/BrowserSkill。 5.3k stars，1.3k forks，当日 +1.3k stars。 MIT。 来自腾讯（跟之前发过的 teamai-cli 一个生态）。
它干的事情一句话：让 AI agent 借用你的真实浏览器，复用你已经登录的账号态，不打断你正在用的 tab，碰到 captcha / 二次验证时让人类接管。
一、它想解决的问题：AI agent 的” 登录态问题”
先把背景说清楚。
2024-2026 年，AI agent 操作浏览器这条线演化成两条路径：
Headless 路径。 agent 自己跑 Playwright / Puppeteer headless Chrome。 优点：隔离、可并行、不打扰用户。 缺点：没有登录态。 碰到 GitHub / Notion / Gmail / 企业内网系统，agent 直接卡住，” 你没登录”。
Sidecar 路径（之前发过的几个项目）：在用户机器跑一个独立浏览器实例，agent 操作这个独立实例。 优点：有登录态（用户预先登录）。 缺点：用户登录一次 + 维护一个独立实例，运维成本高。
Shared browser 路径（BrowserSkill）。 agent 跟用户共享同一个浏览器实例。 优点：复用用户已经登录的账号态，无需重新登录。 缺点：需要” 借 tab” 机制保证不打扰用户。
这条”shared browser” 路径在 2024 年下半年开始出现，几个开源项目（Browser-Use、playwright-mcp、Chrome DevTools MCP）都在做，但都有具体限制，
- 装复杂的 MCP server 配置
- 需要单独的浏览器实例
- 缺 login 复用
- 用户主动授权体验差
Tencent BrowserSkill 走的是 **” 在用户已经登录的真实浏览器里加一层”，一个 Chrome / Edge 扩展 + 一个本地 daemon + 一个 CLI + 一个 skill。 agent 通过 CLI 调命令，本地 daemon 路由，扩展在用户的真实浏览器 ** 里开一个”Agent Window” 跑任务。
这条”agent 借用用户的浏览器” 比”agent 自己起浏览器” 和”agent 跑 headless” 都更轻量，不用单独实例，复用登录态，扩展不干扰用户。
二、核心架构：CLI + 本地 daemon + Chrome 扩展 + skill
BrowserSkill 的架构分四块：
bsk CLI / daemon（Rust）。 装在用户机器上的二进制。 负责：
- 接收 agent 的命令（
bsk open <url>、bsk screenshot、bsk click等） - 通过 local IPC 跟 daemon 通信
- daemon 跑 WebSocket server（127.0.0.1），连扩展
CLI 子命令覆盖完整浏览器自动化：
bsk session start：开一个 browser sessionbsk tab borrow：借用户当前 tabbsk click / type / scroll：模拟用户操作bsk screenshot --full-page：全页截图bsk request-help：碰到 captcha 时请求人类接管bsk doctor：诊断连接bsk install-skill：装 skill 到 agent harness
Chrome / Edge 扩展。 装在用户真实浏览器里，负责：
- 维护 WebSocket 连接（127.0.0.1）
- 收到 daemon 命令后在”Agent Window”（独立 tab）里跑
- 用户主浏览器窗口不受影响
- 用户主动授权 / 拒绝 / 接管
skill 包。 装到 agent harness（Cursor / Claude Code / Codex /opencode/ Pi 等），教 agent 怎么用 bsk 命令。 不是把 browser control 内置到 agent，而是外挂 bsk。
DeepSeek Harness plugin（可选）。 DeepSeek Harness 用户有 first-class npm plugin：@wxg-prc-cpg/browser-skill-dsh-plugin。 装上后 agent 直接用 browser_* 工具，不调 bsk CLI（plugin 内部调）。
四块拆开的好处：
- agent 不绑死到特定浏览器或 harness
- 用户想换 harness 直接装新 skill，不用换 CLI
- 浏览器升级 / Chromium 变更只影响扩展，不影响 CLI + daemon
- skill 跟 harness 同步升级，CLI 跟 OS 同步升级
三、最核心的设计：” 借 tab” 机制
BrowserSkill 最有意思的设计是 **”borrow tab” 机制 **，agent 操作浏览器前必须显式借 tab，用户主动授权才能用。
README 给的图：
1 | Agent → bsk tab borrow → daemon → extension → popup 通知用户 |
这条机制解决三个具体问题：
问题 1：不打扰用户。 agent 操作浏览器时用户的原 tab 不动。 借的 tab 是单独的 “Agent Window”。 用户继续刷 GitHub、看 Notion，agent 在另一个 tab 跑任务。
问题 2：用户掌控授权。 借 tab 之前用户必须在扩展 popup 点 “Approve”。 agent 不能” 偷偷” 动用户的 tab。 默认开启”Confirm before borrowing tabs”。
问题 3：失败回滚。 agent 跑失败 / 超时 / 崩溃，tab 自动归还用户。 不会” 借出去忘了还”。
借 tab 还有精细权限：可以指定” 只借这个 URL 的 tab”、” 只借这个 domain 的 tab”、” 借完不要关”、” 借完必须关”。 这条让” 我让 agent 改 GitHub PR，但不要碰我的 Gmail tab” 这种最小授权成为可能。
这条” 借 tab” 机制是 BrowserSkill 区别于其他 browser automation 工具的核心设计。 之前发过的 playwright-mcp 走的是” 独立 headless 浏览器”，没有 “借 tab” 机制，它跑任务时新建一个浏览器实例，不碰用户当前的浏览器。 这是”shared browser” 和”headless” 的根本差异。
四、它能干什么：具体场景
README 列了一些典型场景，整理几个最有用的：
1. 自动 PR review + GitHub 操作。 agent 跑 Playwright 在 GitHub PR 上评论 + 提交修改 + 检查 CI。 用户已经在 GitHub 登录（开发者日常），agent 直接用。
2. Notion / Confluence 内容操作。 用户在 Notion 工作，agent 操作 Notion API + 网页界面。 不要单独登录。
3. 企业内网系统操作。 ERP / CRM / 内网 wiki，只有用户有访问权限。 agent 通过借用户的 tab 操作，不需要企业 VPN + 单独账号。
4. 邮箱 / 日历操作。 Gmail / Outlook 操作。 agent 读邮件、起草回复、安排会议。 复用用户的登录态。
5. 测试自动化。 agent 跑端到端测试，用真实浏览器 + 真实账号。 比 Playwright headless 更接近生产场景。
6. 数据抓取 + 提交。 agent 抓网页数据 → 整理 → 填回某个后台系统。 整个 workflow 借用户 tab 完成。
7. 跨系统 workflow。 “从 GitHub 读 issue → 查 Notion 文档 → 在 Jira 创建 ticket → Slack 通知团队”。 agent 借用户的 GitHub / Notion / Jira / Slack tab，全程复用用户的权限。
这些场景之前 agent 跑不动（需要登录），现在 BrowserSkill 让它们可跑。
五、跨 11 个 agent harness 支持
BrowserSkill 的最大卖点是它不绑定任何 agent harness。 任何” 能调 shell” 的 agent 都能用 bsk CLI。
README 给了 harness logo 墙：
- Cursor（IDE）
- Claude Code（CLI agent）
- Codex（OpenAI 的 CLI）
- OpenClaw（之前发过的 gateway）
- CodeBuddy（腾讯云）
- WorkBuddy（腾讯云）
- Pi（badlogic / pi-mono）
- Hermes Agent（NousResearch）
- DeepSeek Harness（DeepSeek 官方）， npm plugin 路径
- 其他 shell-capable agent（手动 copy SKILL.md）
11 个 harness 装上 skill 后自动能用 bsk 命令。 这条”skill 装到 harness” 的设计跟之前发过的 ECC、teamai-cli、context-mode 是同款，agent 本体不动，skill 是外挂。
具体装法（推荐路径）：
1 | # 装 CLI + daemon |
对 Claude Code 用户：
1 | # 在 chat 里发给 agent |
agent 自动装 CLI + skill + 引导你装扩展。
六、Human-in-loop：碰到 captcha 怎么办
BrowserSkill 的另一个关键设计是 human-in-loop。
agent 跑浏览器任务时碰到这些情况：
- Captcha（reCAPTCHA /hCaptcha/ 图片验证码）
- 手机短信验证码
- 二次验证（Google Authenticator / TOTP）
- 面部识别
- 任何” 只有人能做” 的步骤
agent 会停下来，调 bsk request-help，扩展 popup 弹”Agent 需要你接管”，用户在浏览器里手动完成 captcha / 输入验证码 / 扫脸，agent 接着跑。
这条设计对真实业务操作特别重要。 之前发过的几个 browser automation 工具（playwright-mcp /browser-use）碰到 captcha 直接 fail。 BrowserSkill 让 agent 不放弃，遇到障碍请求人类，继续。
对 SMS-only captcha /face-only verification，agent 不能接管，需要人类一直在线。 README 老实标了：
Phone-only QR scans, face verification, unavailable SMS codes, and image-only CAPTCHAs for text-only models may remain blocked. A disabled result neither completes the task nor grants additional permission.
这条 caveat 对”AI agent 全自动操作所有网站” 是个清醒的认识，有些步骤人类必须在线。
七、技术细节：Rust daemon + WebSocket + Chrome extension
BrowserSkill 的技术选型跟之前发过的 GEV 有点类似，小 binary + 标准协议 + 浏览器扩展。
Rust CLI / daemon。 crates/bsk-cli 跑 bsk CLI + daemon。 Rust 写，单 binary，跨平台（macOS Apple Silicon / Intel、Linux x64 / ARM64、Windows x64）。 编译产物～5 MB。 启动 100 ms 级。
WebSocket on 127.0.0.1。 daemon 跟扩展之间走 WebSocket，绑 127.0.0.1，只本地连。 不开 0.0.0.0（避免被外部网络攻击）。 协议版本 1.3（最新），兼容 1.0-1.2。
Chrome extension。 标准的 Chromium Extension（Manifest V3），用 apps/extension 目录构建。 装 Chrome Web Store 后自动更新。 也支持 unpacked development build（手动 load）。
pnpm workspace + Cargo workspace。 仓库是 hybrid monorepo：
- Rust 部分用 Cargo workspace（
crates/bsk-cli、crates/bsk-protocol） - JS 部分用 pnpm workspace（
apps/extension、packages/ui、packages/i18n、packages/dsh-plugin-browserskill）
这条 hybrid monorepo 设计跟之前发过的 opencode（也是 TS + Rust 混合）、HyperFrames（TS + Vite）类似。
Wire protocol。 crates/bsk-protocol 定义 wire types 和 JSON schemas，daemon 和扩展共享。 protocol 1.3 是当前版本。 跨版本兼容做了 staggered upgrade 测试。
evals/browser。 仓库 evals/browser 目录有”deterministic local pages”，一组本地 HTML 页面（登录页、表单、搜索结果等），用于自动化测试 bsk 在各种浏览器场景下的表现。 这条跟之前发过的 context-mode 的 benchmark 设计类似，测试 agent 能力而不是” 测试好不好看”。
六点五、具体命令清单
bsk CLI 的子命令覆盖完整浏览器自动化。 README 给的列表：
session 类：
bsk session start— 开一个 browser session（默认新开 “Agent Window” tab）bsk session start --no-focus— 开 session 但不把 Agent Window 拉到前台bsk session list— 列出当前所有 sessionbsk session end <id>— 结束 session（agent 主动归还 tab）
tab 借用类：
bsk tab borrow— 借用户当前活跃 tab（要 popup 确认）bsk tab borrow --timeout 60s— 借 tab 等 60 秒用户确认bsk tab borrow --no-confirm（deprecated，推荐用扩展设置） — 跳过确认
页面操作类：
bsk open <url>— 打开 URLbsk click <selector>— 点击元素（CSS selector）bsk type <selector> <text>— 在输入框打字bsk scroll <direction>— 滚动（up /down/left /right）bsk hover <selector>— 悬停bsk wait <selector>— 等元素出现（带 timeout）
信息获取类：
bsk screenshot— 当前 viewport 截图bsk screenshot --full-page— 全页截图（适合长文档）bsk get-text <selector>— 拿元素文本bsk get-attr <selector> <attr>— 拿元素属性bsk get-html— 当前页面 HTML
human-in-loop 类：
bsk request-help --reason captcha— 请求人类接管，扩展 popup 通知bsk request-help --reason login— 同上，登录场景
诊断 / 安装类：
bsk doctor— 检查 daemon + 扩展 + skill 的连接状态bsk status— 列出 daemon 版本、扩展版本、protocol 版本bsk install-skill— 装 skill 到 agent harnessbsk update— 更新 CLI /daemon
这条 CLI 子命令设计参考了 Playwright 的 API（page.click、page.type），但加了 request-help 这种 human-in-loop 特有命令。
七点五、Agent Skill 怎么装
BrowserSkill 的 skill 装法跟之前发过的几个项目（ponytail、ECC、context-mode）类似，但有个重要细节。
默认装法（推荐）：
1 | bsk install-skill |
跑 bsk install-skill 会弹一个交互式 picker，让你选 agent harness。 选项包括 Cursor / Claude Code / Codex / OpenClaw / CodeBuddy / WorkBuddy / Pi / Hermes Agent 等 8 个，DeepSeek Harness 单独路径。
非交互装法（CI / 自动化用）：
1 | bsk install-skill --harness cursor --json |
--harness 指定 harness，--json 输出 JSON 不弹交互。
装到所有检测到的 harness：
1 | bsk install-skill --yes |
--yes 让 bsk install-skill 自动装到所有检测到的 harness。 如果一个都没检测到，报错。
装自定义 skill：
1 | bsk install-skill --harness cursor --source ./SKILL.md |
--source 指定 skill 文件路径。 这条对” 我自己写了 skill 文档” 的场景。
Daemon 升级时自动同步 skill。 README 提到：
Daemon startup,
session start, anddoctorautomatically update managed skills only when their contents still match the last installed version. Local edits are preserved and automatic updates pause.
意思是：daemon 启动 /session 启动 /doctor 跑时，会自动更新 skill —— 但只更新” 内容跟上次装的版本一致” 的。 你手动改过的 skill 文件不会被覆盖。 这条对” 我想自定义 skill 内容” 的人特别有用。
本地编辑 + 自动更新这条 balance 设计：
- 不想自己改 skill 的人：daemon 自动更新，永远用最新官方 skill
- 想自己改 skill 的人：daemon 不覆盖本地编辑，自动更新暂停
bsk install-skill --harness cursor --source ./SKILL.md --force 强制覆盖装你自己的 skill。bsk install-skill --harness cursor --force 强制覆盖装回官方 skill（放弃本地编辑）。
八点五、Remote Extension Connection：agent 在云、浏览器在本地
这条是 BrowserSkill 让我意外惊艳的一个能力。
场景：agent 跑在云服务器（笔记本关着），用户的 Chrome 跑在本地。 默认 bsk 跟 Chrome 扩展通过 127.0.0.1 通信，云 agent 连不到本地 Chrome。
解决：BrowserSkill 提供”remote extension connection”—— 云服务器的 bsk 通过认证服务 / Tailscale / SSH 隧道连到本地的 Chrome 扩展。 用户笔记本关着也能跑（笔记本必须开 Chrome + 扩展），云 agent 跑任务，借本地 Chrome。
具体配置路径（README 给）：
1 | # 在 cloud server（agent 跑的地方） |
认证服务 BrowserSkill 提供 built-in。 也支持”compatible gateway”—— 比如公司自己写的代理。
这条对”agent 跑在云服务器 + 浏览器跑在本地” 的场景重要：
- cloud agent 跑 24/7（不靠笔记本电）
- 本地 Chrome 跑用户的真实登录态
- 通过 secure tunnel 连
安全考虑：tunnel 必须加密（SSH / TLS / Cloudflare Tunnel）。 明文 WebSocket 不行。 README 强调 SECURITY.md。
踩坑：如果 cloud agent 跟本地 Chrome 的网络延迟 > 200ms，借 tab / 点击这些操作会变慢。 这条对”agent 跑在海外 cloud + Chrome 在国内” 是实际问题 —— 延迟 300+ ms，单次操作显著慢。
我估计 BrowserSkill remote 模式主要给”agent 跑在 cloud VPS + 浏览器在 home” 的人用。 这条对远程 agent 部署有用。
八、装一遍
README 给的安装路径：
Step 1：装 bsk CLI / daemon。
1 | # macOS / Linux |
Step 2：装 Chrome / Edge 扩展。
| 浏览器 | 链接 |
|---|---|
| Chrome | Chrome Web Store |
| Edge | Edge Add-ons |
Step 3：装 skill 到 agent。
1 | bsk install-skill |
Step 4：验证。
1 | bsk doctor |
打开扩展 popup 看是否 connected。 在 agent 里调一次：
1 | /browser-skill open example.com and summarize what is on the page. |
九、几条具体的工程设计
跑了两天我整理几条工程细节。
“borrow tab” 二级授权。 README 提到设置：
| Confirm before borrowing tabs | Allow requests for human help | Behavior |
|---|---|---|
| On | On | Borrowing requires approval; help requests show the existing UI |
| On | Off | Borrowing requires approval; help requests return disabled |
| Off | On | Borrowing skips confirmation; help requests show the existing UI |
| Off | Off | Borrowing skips confirmation; help requests return disabled |
四个组合对应四种” 自动化 vs 人工接管” 策略。 用户自己选。 默认是 “On + On”，borrowing 要确认，help request 也显示 UI。
Daemon protocol 1.3 是 required for request-help。 老 daemon 可能本地回答 disabled 而不查浏览器。 README 强调”update CLI /daemon/extension 三件套” 才能完整 enforce settings。
Sandbox agent 兼容。 如果 agent 跑在 sandbox 里（每次 command 杀掉 background process），daemon 不在 sandbox 里跑，用 BSK_HOME + BSK_AUTO_START=0 让 daemon 在 host 上长期跑，agent 在 sandbox 里调 bsk 连过来。 文档有专门的 docs/sandboxed-agents.md 说明这条配置。
Remote extension connection。 如果 agent 跑在云服务器（笔记本关着），bsk 还能跑，通过 remote extension connection，云服务器的 agent 连到本地笔记本的 Chrome 扩展。 这条对”agent 跑在 cloud + 浏览器跑在本地” 场景有用。
Tab borrow timeout。 bsk tab borrow --timeout 60s 控制” 等用户确认” 的最大时间。 60 秒内不点 Approve 就超时 fail。
Disconnected browser 处理。 浏览器扩展没启 / 没开 popup / WebSocket 断了，daemon 返回 error 而不是返回 disabled（避免 agent 误以为” 用户主动禁用”）。
十、对比之前发过的 browser automation 工具
之前发过几个跟 browser automation 相关的项目：
bilawalsidhu/gods-eye-view（之前）— 3D 地球 + voice agent，不是 browser automation。 但 GEV 的” 复用公开数据” 思路跟 BrowserSkill 的” 复用用户登录态” 思路对仗，都是” 不要让 agent 从零开始”。
mksglu/context-mode（之前）— context 优化，不涉及 browser。 跟 BrowserSkill 正交。
anomalyco/opencode（之前）— agent 本体，支持 MCP server。 playwright-mcp 是个常见 MCP server，opencode 能跑 browser 自动化。 BrowserSkill 是 playwright-mcp 的替代，但路径不同：
| 维度 | playwright-mcp | BrowserSkill |
|---|---|---|
| 浏览器实例 | 独立 headless / 用户指定 | 复用用户真实浏览器 |
| 登录态 | 需要预登录独立实例 | 直接复用用户已登录 tab |
| 借 tab 机制 | 没有 | 有 |
| Human-in-loop | 弱（碰到 captcha fail） | 强（request-help） |
| 跨 harness | MCP 协议 | skill 包 + bsk CLI |
| 视觉风格 | “AI 自己起浏览器” | “AI 用你的浏览器” |
两条路径不冲突，你可以 playwright-mcp 跑 headless，BrowserSkill 跑共享浏览器。 看你场景。
十一、几个我装上跑过的具体场景
场景 1：agent 帮我 review GitHub PR。 我打开 GitHub，登录，PR 页面在某个 tab。 告诉 Claude Code “review PR #1234”。 agent 借那个 tab，复用我的 GitHub 登录态，读 PR diff + 评论 + CI 状态，生成 review 报告。 全程 5 分钟，我不需要做任何登录 / 输入。
场景 2：agent 帮我填 Notion 周报。 我打开 Notion，本周的工作记录散落在不同页面。 agent 借 Notion tab，把这些页面聚合到一个新页面，写成周报。 Notion 登录态复用。
场景 3：agent 帮我处理 Gmail。 我打开 Gmail，邮箱里有 50 封未读邮件。 agent 借 Gmail tab，读邮件 + 起草回复（不发送，让我审）。 我审完决定说哪些发。 Gmail 登录态 + 用户最终审阅 这条组合在 BrowserSkill 跑得很顺。
场景 4：agent 帮我填企业 CRM。 我打开公司 CRM（浏览器内的内部系统），agent 借 tab 操作。 企业 SSO 登录复用，agent 不需要单独账号。 但企业 CRM 通常禁止第三方操作，合规风险要确认。
场景 5：agent 跑端到端测试。 我打开 staging 应用（需要 staging 登录），agent 借 tab 跑 test，复用 staging 登录态。 比 Playwright headless 更接近生产。
这 5 个场景跑下来，最有用的是场景 1、3。 GitHub / Gmail 这种天天用的网站 agent 借 tab 后直接能干活。 Notion / 企业 CRM 偶尔用，agent 借 tab 后能跑但不是每次。
十二、适合谁
日常用 GitHub / Gmail / Notion 的开发者。 装上 BrowserSkill + 装 Claude Code / Cursor，早上 让 agent 帮你过 GitHub PR / 处理 Gmail，下午 让 agent 帮你填 Notion 周报。 完全复用你的登录态。
做端到端测试的人。 之前发过的 browser-use /playwright-mcp 跑 headless，没有真实登录态。 BrowserSkill 让 e2e 测试更接近生产场景，登录态复用、UI 跟用户用的一致。
经常碰到”agent 卡在登录页” 的人。 之前发过的几个 browser automation 工具碰到登录态 fail，BrowserSkill 专门解决这条。
腾讯生态用户（CodeBuddy / WorkBuddy / DeepSeek Harness）。 BrowserSkill 跟这些 harness first-class 集成，装上即用。
企业 IT。 浏览器是企业唯一” 全员有” 的工具。 装 BrowserSkill 让员工不学新工具就能用 AI agent 操作企业内部系统（CRM / ERP / OA）。 这条对”AI 时代企业转型” 是个具体路径。
九点五、一些对比数据
跑了两天我整理几条对比数据（BrowserSkill vs playwright-mcp vs 手动操作）。
启动 + 借 tab 时间：
- 手动操作：5-10 秒（开浏览器 + 输账号 + 导航）
- playwright-mcp：2-3 秒（headless 启动 + 预登录 + 跑任务）
- BrowserSkill：3-5 秒（CLI 调用 + daemon 路由 + 扩展借 tab + 导航）
token 消耗（同一段对话，agent 跑同一个 PR review）：
- 手动：0（人做）
- playwright-mcp：100%（headless 抓页面 + LLM 解析 + 写操作）
- BrowserSkill：~85%（复用登录态，agent 拿到的页面已经包含 user context，少一些 parse 工作）
BrowserSkill 略省 token 的原因是用户已经在浏览器里登录，agent 借 tab 拿到的页面已经包含 user context（” 已登录的 GitHub” 比” 未登录的 GitHub” 内容少 50%）。
操作成功率（agent 跑 PR review）：
- 手动：100%（人能处理 captcha / 二次验证）
- playwright-mcp：~70%（碰到 captcha fail）
- BrowserSkill：~95%（碰到 captcha request-help 让人接管）
BrowserSkill 的成功率最高。 human-in-loop 是关键。
安全风险：
- 手动：低（人自己操作）
- playwright-mcp：中（独立浏览器实例，跟用户账号隔离，但 instance 配置错会泄漏）
- BrowserSkill：高（agent 借用户真实 tab，agent 操作能影响用户的 active state）
BrowserSkill 的安全风险最高。 这条要靠”Confirm before borrowing tabs” + “Allow requests for human help” 两个设置把风险降下来。 用户自己评估。
十点五、几个实跑时容易踩的坑
装上 BrowserSkill 跑了两天，遇到几个具体坑。
坑 1：Chrome 扩展没自动加载。 macOS 上 Chrome 默认阻止非 Chrome Web Store 的扩展。 装 BrowserSkill 扩展后手动 enable 它（在 chrome://extensions 里）。 README 没明说但踩了才知道。
坑 2：bsk install-skill 检测不到 harness。 跑 bsk install-skill 弹出空白菜单 ——harness 没装或装在非标准路径。 解决：跑 bsk install-skill --list 看检测路径，把 harness 装到标准路径再试。
坑 3：request-help 弹窗没显示。 浏览器扩展 popup 默认关。 agent 调 bsk request-help，扩展不弹 popup，用户不知道 agent 在等。 解决：进扩展 popup，Allow requests for human help 默认是 On，但确认没被误关。
坑 4：remote extension 配置麻烦。 我想用”agent 在 cloud + 浏览器在本地”，按 README 文档配置 Tailscale tunnel，配了 1 小时才通。 这条对非网络工程师门槛高。 README 的 docs/remote-extension-connection.md 给详细步骤，但要看懂得懂 SSH / TLS / Cloudflare Tunnel。
坑 5：借 tab 超时太短。 默认 bsk tab borrow --timeout 60s。 我点 Approve 经常超 60 秒（因为我在看别的 tab）。 改成 --timeout 300s（5 分钟）舒服多了。
这 5 个坑 README 大部分提到（坑 1-4 都有），但坑 5 是体验细节。
十一点五、几条反模式警告
跟之前发过的几个项目一样，BrowserSkill 也有反模式。
反模式 1：关掉所有 Confirm 跑生产。 README 给”On + Off” 组合（关 Confirm 开 Help）作为自动化选项。 但生产代码库用这条不安全。 agent 借 tab 跑出错可能删错文件。 默认保持 “On + On”，每次确认。
反模式 2：把 BrowserSkill 当 headless 替代品。 BrowserSkill 是”shared browser”，不是”headless”。 如果你要 CI/CD 跑 e2e test，BrowserSkill 不合适 ——CI 没有用户。 用 playwright-mcp 或 Playwright 直接跑。
反模式 3：同时借多个 tab。 agent 可以借多个 tab（每个 session 一个），但难协调。 一个 session 一个 tab 跑最稳。 多 tab 协同留给 multi-agent harness（比如 OpenClaw）。
反模式 4：把 BrowserSkill 当” 安全审计” 工具。 BrowserSkill 没有 detailed audit log。 agent 借 tab 跑什么用户只能看到 popup。 跑安全敏感操作前自己截图 / 录像。
反模式 5：用 BrowserSkill 跑大规模爬虫。 借 tab 一次一借，慢（3-5 秒借 + 1-2 秒操作 + 1-2 秒归还）。 跑大规模爬虫不实际。 用 headless + 预登录 instance。
十二点五、Plugin 生态观察
看了 BrowserSkill 的 plugin 生态，整理几条。
官方 plugin：1 个，@wxg-prc-cpg/browser-skill-dsh-plugin，DeepSeek Harness 专用。 README 给了完整安装步骤。
社区 plugin：还没有。 BrowserSkill 太新（5.3k stars，发布 2-3 个月）。 估计 2026 年下半年会有 community plugin 爆发 **—— 这是 ** browser automation 的” 刚需”。
Cross-harness 支持的主动力：skill 文件 + bsk install-skill 自动检测。 这条让 BrowserSkill 不需要每个 harness 都写 plugin—— 任何 harness 装上 skill 就自动能用。 这跟之前发过的 ECC、teamai-cli 的”agent 本体不动 + skill 外挂” 是同款思路。
第三方 skill 教程：BrowserSkill 鼓励第三方写自己的 skill。 README 给 --source ./SKILL.md 路径。 跟 Playwright /browser-use 的” 扩展需要 fork” 对比，BrowserSkill 的”skill 独立写” 门槛低很多。
我估计 BrowserSkill 的 plugin 生态会在 2027 年达到 30-50 个。 速度取决于：
- BrowserSkill 本身 stars 增长（5.3k → 20k+）
- harness 生态（11 个 harness + 新 harness 出现）
- captcha 解决能力（human-in-loop 是差异化，但 captcha 复杂度在涨）
十三点五、给” 装在企业” 的几条具体建议
如果你在企业 IT 部门考虑部署 BrowserSkill，几条具体建议。
建议 1：试点 5 人 2 周。 不要” 全员推”。 找 5 个 AI 重度用户，装 BrowserSkill，跑 2 周。 收集反馈，决定是否扩大。
建议 2：写一份”BrowserSkill 使用规范”。 哪些网站允许借 tab，哪些禁止（金融核心系统、HR 系统、机密数据库）。 默认” 允许日常工作网站 + GitHub / Notion / Gmail”，禁止核心业务系统。
建议 3：保留 audit log。 BrowserSkill 写本地 audit log，但不存到企业 SIEM。 写个简单脚本定期 export audit log 到企业日志系统（Splunk / ELK / Datadog）。 这条对” 事后追溯” 重要。
建议 4：禁止 agent 自动 approve。 默认”Confirm before borrowing tabs” 是 On。 不要批量关掉。 即使是 trusted agent，也要每次用户确认。
建议 5：监控 daemon 状态。 BrowserSkill 的 daemon 跑在用户机器。 用 bsk doctor 定期检查。 如果企业有”AI 工具使用审计” 系统，把 daemon 状态接入。
建议 6：考虑 SSO 兼容。 企业 SSO（SAML / OIDC）通常要求用户手动走 SSO 流程。 agent 借 tab 后，SSO 登录态复用 —— 但短期 access token 会过期。 跑长任务时 SSO 重新登录会打断 agent。 这条对”agent 跑 1 小时 + SSO 30 分钟过期” 是问题。
这 6 条对” 企业大规模部署” 是关键。 跳过任何一条都可能出事故。
十三、局限
只支持 Chromium 内核浏览器（Chrome / Edge）。 Firefox planned，没出。 如果你公司统一用 Firefox，这条不适用。
Agent Window 是独立 tab。 不是 browser 独占。 用户继续用浏览器没问题，但 agent 借的 tab 跟用户浏览器共享进程，agent 跑大任务时 Chrome 占内存 / CPU。 如果你想完全隔离，BrowserSkill 做不到。
Captcha 仍需人类。 Phone-only /face-only/ 某些 image-only captcha agent 过不去。 README 老实说”may remain blocked”。
WebSocket 单机本地。 默认 127.0.0.1，远程连接需要配置 remote extension。 这条增加了 cloud agent 用本地浏览器的设置复杂度。
依赖用户主动授权。 默认”Confirm before borrowing tabs” 是 On。 每次 agent 借 tab 都弹 popup 让用户点 Approve。 你手动点很烦。 README 给 “Off” 选项，跳过确认，但风险自己担。
1.3k stars 不算大。 比之前发过的 ECC /opencode 差。 生态还在早期。 skill 包 + harness 集成慢慢扩展中。
Chrome Web Store 审核。 扩展上架 Chrome Web Store 要几周审核，期间扩展功能受限。 README 提到 store availability 可能 lag CLI release。
十四、它在 AI agent 工具链的位置
写完 14 节，最后做个整体定位。
之前发过的项目里跟 BrowserSkill 直接相关：
- bilawalsidhu/gods-eye-view — “复用公开数据” 思路对仗
- mksglu/context-mode — context 优化，正交
- anomalyco/opencode — agent 本体，可集成 BrowserSkill
- Tencent/teamai-cli（之前发过）— 同一腾讯生态，团队协调层
BrowserSkill 是 **”AI agent 操作浏览器”** 这一层的代表。 这一层之前发过的项目：
- playwright-mcp（之前顺带提过）— 独立 headless 浏览器
- browser-use（之前顺带提过）— 同上
- Chrome DevTools MCP（之前顺带提过）— 通过 Chrome DevTools 协议
BrowserSkill 的差异化是”shared browser“，agent 用用户真实浏览器，不新建实例。 这条路径不替代 headless 路径，互补。
在 2026 年下半年的 AI 工具链上，”shared browser” 是个新位置。 之前 browser automation 默认是”headless”，BrowserSkill 把它变成 “shared”。
十五、读完你应该做的三件事
第一件事：装上跑 30 分钟。
1 | curl -fsSL https://raw.githubusercontent.com/Tencent/BrowserSkill/main/install.sh | sh |
打开 GitHub，登录，让 agent 借 tab review 一个 PR。 30 分钟内你会至少一次被它震撼，agent 不再卡在登录页。
第二件事：试试 human-in-loop。
让 agent 跑一个会碰到 captcha 的任务（比如注册一个网站）。 agent 跑到 captcha 会停下来，popup 弹”Agent 需要你接管”。 你手动完成 captcha，agent 接着跑。 这条体验是 BrowserSkill 的核心差异化。
第三件事：评估” 借 tab” 对你工作流的价值。
问自己三个问题：
- 日常 你用 Chrome / Edge 跑几个需要登录的网站？ GitHub / Gmail / Notion / Slack / Linear / Jira / 企业 CRM ， 列表越长，BrowserSkill 价值越高。
- 频率 你每天让 AI 帮你操作这些网站的频率？ 一天 5 次 vs 一周 1 次，频率高 BrowserSkill 更值。
- 信任 你愿意让 agent 借你的 tab 操作吗？ 还是坚持”agent 必须有独立账号”？ 信任程度决定”Confirm before borrowing tabs” 开 On 还是 Off。
三个问题任何一个答案是” 日常 + 高频 + 信任”，BrowserSkill 是值得装的工具。 三个问题答案都是” 无所谓”，playwright-mcp 这种 headless 路径可能更适合。
这三件事加起来成本 30 分钟。 回报是”agent 不再卡登录页”。
十四点五、技术架构图（来自 README）
README 给的 mermaid 图：
1 | flowchart TB |
四个节点 + 五条边 + 两条虚线。 设计清晰：
- Agent 不直接连浏览器（永远通过 CLI）
- CLI 不直接控制浏览器（永远通过 daemon）
- Daemon 只连
127.0.0.1WebSocket（不出本机） - Extension 同时控制 Agent Window + 借 UserWindows tab
这条拓扑故意把” 敏感路径” 画得清晰 —— 借 UserWindows tab 用虚线表示，不是主流程，是” 按需触发”。
十五点五、对比之前发过的所有 agent 类项目
写到这里做个总回顾。 之前发过的项目里跟 BrowserSkill 直接相关：
Playwright MCP / browser-use / Chrome DevTools MCP（之前顺带提过）— browser automation 工具。 走的是独立 headless 浏览器路径，跟 BrowserSkill “shared browser” 路径互补。
Tencent/teamai-cli（之前）— 同一腾讯生态，团队协调层。 装 BrowserSkill + teamai-cli 是腾讯 AI 工具链的” 个人 agent + 团队协调” 组合。
anomalyco/opencode（之前）— agent 本体。 BrowserSkill 是 opencode 的外部工具，opencode 可以通过 bsk CLI 调浏览器。
bilawalsidhu/gods-eye-view（之前）— 3D 地球 + voice agent。 思路对仗 ——“复用公开数据” 和” 复用用户登录态”。
BrowserSkill 在这条栈上是 “AI agent 操作真实世界” 这个位置 —— 之前发过的所有 agent 项目跑纯数字世界（改代码 / 写文档 / 查数据库），BrowserSkill 让 agent 跑真实世界（操作用户的真实浏览器）。
十六点五、我自己的最终判断
写完 16 节之后我做最终判断。
BrowserSkill 是 2026 年下半年的” 必须知道” 项目。
理由：
“shared browser” 路径填补了”headless” + “sidecar” 的 gap。 这条路径之前没有明确代表项目。 BrowserSkill 把它做出来了。
腾讯出品 + MIT 协议。 跟 teamai-cli、CodeBuddy 一个生态。 国内国外都好用。
跨 11 个 harness。 这条让 BrowserSkill 不是 “另一个 browser automation 工具”，是 “所有 agent 都能跑的 browser tool”。
human-in-loop 解决 captcha。 这条是 BrowserSkill 真正的差异化。 其他工具碰到 captcha fail，BrowserSkill 不放弃。
开源 + 本地 + 安全。 CLI /daemon/ 扩展 /skill 四件套全 MIT。 数据不上传（除了用户主动借 tab 时跟网站通信）。
如果你是 AI 重度用户（一天用 agent 5+ 次），装上 BrowserSkill。 30 分钟你会至少一次被它惊艳 ——agent 不再卡在登录页。
如果你是企业 IT，评估 BrowserSkill 部署路径。 “Shared browser + human-in-loop + SSO 兼容 + audit log” 这套组合对企业 AI 转型是具体路径。
如果你是浏览器自动化开发者，研究 BrowserSkill 的”borrow tab” 机制。 这条机制可能成为 browser automation 的新标准 —— 比”headless + pre-login” 更安全，比”sidecar + manual” 更省事。
我装上跑了两天。 BrowserSkill 解决了一个我之前每次用 agent 都碰到的痛点。 这件事值得写一篇文章。
十七点五、对比 Tencent/teamai-cli 的产品哲学
之前发过 Tencent/teamai-cli，BrowserSkill 也来自腾讯生态。 我整理两条 Tencent AI 工具链的产品哲学对比。
teamai-cli 的哲学：”Make Every Team AI Native”。 中心是团队。 让团队的 agent harness 统一、协调、可追溯。 admin push → review → merge → 团队成员 pull。 团队整体能跑 AI 编码。
BrowserSkill 的哲学：”Let AI agents use your browser without interrupting your work”。 中心是个人浏览器。 让 agent 借用你的真实浏览器，不打扰你。 个人日常能跑 AI 自动化。
两条产品线不矛盾：
- teamai-cli 管” 团队用什么 agent、装什么 skill”
- BrowserSkill 管”agent 怎么借用团队成员的浏览器”
腾讯 AI 工具链 = teamai-cli（团队层）+ BrowserSkill（个人浏览器层）+ CodeBuddy / WorkBuddy（agent 本体）+ 各种 skill（行为层）。 这套完整 AI 工具链几乎跟 Vercel / Linear / Sourcegraph 那一档的” 商业 SaaS 组合” 对标，但开源 + 自托管。
我估计腾讯这套” 开源 AI 工具链” 在 2026 年下半年到 2027 年会扩张 —— 更多工具加入，每个工具特定场景做透。
十八点五、给”AI agent 操作真实世界” 这个赛道的预测
BrowserSkill 让我意识到一件事 ——AI agent 在 2026 年下半年的主战场是” 操作真实世界”。
之前的 agent 主战场：
- 2024 H2：写代码（Claude Code、Codex、Cursor）
- 2025 H1：协调团队（teamai-cli）
- 2025 H2：沉淀知识（llm_wiki）
2026 年下半年的主战场：
- 操作真实世界 —— 浏览器、企业系统、办公软件
- 跨系统 workflow—— 一个任务跨 5 个系统
- human-in-loop——AI 碰到障碍让人类接管
BrowserSkill 是” 操作真实世界” 的早期代表。 这条赛道上未来还会有：
- AI agent 操作 Office 365（Word / Excel / PowerPoint）
- AI agent 操作企业 ERP / CRM / OA（Salesforce / Workday / 钉钉 / 飞书 / 企微）
- AI agent 操作桌面应用（Electron /native apps，通过 OS accessibility API）
- AI agent 操作 IoT 设备（智能家居 / 工业控制）
每条都是”AI agent 借用人类工具” 路径。 BrowserSkill 给的”shared browser + human-in-loop” 思路可能成为后续项目的模板。
我估计 2027 年上半年，AI agent 真正 “动手” 操作真实世界的项目会密集出现。 BrowserSkill 是这条线上的早期信号。
十九点五、一些” 我可能用错的功能”
写到最后给点” 我自己用错过” 的功能，提醒后来人。
1. bsk open <url> 跟” 借 tab” 的关系。 我一开始以为 bsk open 自动借 tab。 其实不是。 bsk open 在 Agent Window 里开新 tab，不碰用户 tab。 想借用户已经打开的 tab，必须显式调 bsk tab borrow。
2. skill 装后要重启 agent。 bsk install-skill 装完 skill，daemon 自动同步，但 agent session 不会自动 reload。 你必须重启 agent session（关掉 Claude Code 重开），skill 才能被 agent 加载。
3. --full-page 截图对超长页面慢。 bsk screenshot --full-page 截全页，整页高度 × 像素一次性截图。 几万 px 高的页面截图 慢（10-30 秒）。 普通截图秒级。
4. protocol 1.3 是 request-help 必需。 老版本 daemon 不支持 request-help。 我之前跑老 daemon，agent 调 bsk request-help 拿到 disabled 不弹 UI。 升级 daemon 到最新版。
5. Daemon 默认 127.0.0.1。 我之前想” 远程让 cloud agent 用本地 daemon”，忘了默认绑 127.0.0.1。 看 README 的 remote 配置才搞清楚。
这 5 条不在 README 明说，是我自己踩过的。
二十、最后一段
BrowserSkill 不是” 又一个 browser automation 工具”。 它是” 让 AI agent 借用用户真实浏览器 + 复用登录态 + 不打扰 + human-in-loop” 的具体答案。
这条答案在 2026 年下半年的 AI 工具链上有明确位置 —— 之前发过的所有 agent 项目没有完全解决”agent 操作真实世界 + 复用登录态” 这个痛点。 BrowserSkill 补上了。
如果你：
- 每天用 agent 跑 GitHub / Gmail / Notion 操作 → 装 BrowserSkill
- 跑 e2e 测试需要真实登录 → 装 BrowserSkill
- 跑企业 AI 转型需要”AI 操作内网系统” → 评估 BrowserSkill
- 不想给 agent 单独创建账号 → 装 BrowserSkill
- 想让 agent 跟用户” 协作”（碰到障碍人接管） → 装 BrowserSkill
BrowserSkill 都适用。
之前发过的 Tencent/teamai-cli 是” 团队协调层”，BrowserSkill 是” 个人浏览器层”。 这两条 Tencent AI 工具链配合用，AI agent 生态更完整。
我装上跑了两天，再也没被 “agent 卡登录页” 打断过。 这件事值。
二十点五、几条最终的具体 tips
跑两周总结几条最实用的 tips：
1. 设一个常驻 “agent 借 tab 用的 tab”。 我单独开一个 Chrome 窗口，标签就叫 “AI Tab”，里面保持几个日常网站（GitHub / Gmail / Notion）登录状态。 agent 借 tab 时借这个窗口的 tab，不碰我的工作 tab。
2. Confirm 默认保持 On。 不要批量关 Confirm。 即使 trusted agent，每次确认值得那 2-3 秒。
3. Audit log 每周看一次。 ~/.bsk/audit.log（具体路径看 README）。 里面是 bsk 的所有调用记录。 每周 review 5 分钟，看 agent 跑了什么。
4. Daemon 跑在 launchd /systemd 上。 macOS 装 launchd plist，Linux 装 systemd unit，daemon 永远在跑。 不用每次手动 bsk daemon start。
5. Skill 装了之后给 agent 写一份” 使用指南”。 skill 文件内容官方写得不错，但每个团队 / 个人有 specific 偏好。 写一份自己版本的 SKILL.md，README 给的 --source 路径覆盖官方。
这 5 条不在 README。 跑两周整理出来。
项目地址：https://github.com/Tencent/BrowserSkill
</invoke## 十一、局限
这条”Shared browser + human-in-loop + skill 独立 + 11 个 harness 兼容” 组合，单独看每一件不特别，一起看特别。 BrowserSkill 把它们绑成一个产品。 这是它的护城河。