腾讯开源的 BrowserSkill 让 AI Agent 复用你已登录的真实浏览器，GitHub 上 5,718 star（9 月 20 日查的），适配 Cursor、Claude Code、Codex、OpenClaw、CodeBuddy、WorkBuddy、Hermes Agent、DeepSeek Harness 等一批主流 harness。这篇在我自己机器上从安装到审计跑了一遍：CLI 装得很顺，装完却什么都干不了。翻完源码和隐私政策之后，我觉得真正需要知道的不是它能干什么，是它把浏览器的钥匙交给了谁。
引子：装完第一个命令就撞墙
按官方的 Windows 装法，一条命令：
irmhttps://raw.githubusercontent.com/Tencent/BrowserSkill/main/install.ps1|iex过程干净：拉version.json拿到0.3.0，下载bsk-v0.3.0-x86_64-pc-windows-msvc.zip，校验 checksum 通过，解出bsk.exe（14,010,368 字节）落到~/.local/bin，顺手把它加到用户 PATH。
然后我想开个会话试试：
{"code":"no_browser_connected","message":"no browser is currently connected","hint":"open the browser-skill extension in your browser and wait for the popup to show \"connected\"","exit_code":1}一个浏览器都没连上。CLI 装好了，daemon 也起来了，就是没有浏览器。
这怪不得它，是我漏了第二步：浏览器扩展要从 Chrome 应用商店手动装。而这一步，恰好是整件事里最该看清的一步。
一、先搞清楚它在你机器上放了什么
链路是四段：Agent 通过 shell 调bsk→bsk走本地 IPC 找 daemon → daemon 用 WebSocket 连浏览器扩展 → 扩展在独立的 Agent Window 里干活。
我机器上的实测状态：
{"daemon_version":"0.3.0","protocol_version":"1.3","pid":3584,"uptime_secs":158,"ws_port":52800,"sock_path":"\\\\.\\pipe\\bsk-daemon-b6cbe6266bd753e0","browsers":[],"sessions":[]}bsk --help一共 38 个子命令，从navigate、click、fill到screenshot、record、request-help，该有的都有。
顺带说一个我踩到的小坑：第一次跑bsk doctor时，它报auto-spawned daemon failed to become ready within 3s，7 项检查里 4 项 fail。我去翻bsk logs，发现 daemon 其实已经 ready 了——只是 3 秒的探测窗口没赶上冷启动。第二次bsk status就正常了。日志比 doctor 的输出可信，后面几个结论都是从日志里挖出来的。
二、本地桥没消除攻击面，它换了个地方
隐私政策里有一句话，我建议每个打算用它的人都读一遍原文：
本地模式信任能够绑定所配置回环端口的进程。
翻成白话：任何能在你机器上绑到 52800 这个端口的进程，都能操控你的已登录浏览器。
52800 是默认端口（0.3.0 起可在扩展弹窗里改），我确认过它确实只绑回环：
TCP 127.0.0.1:52800 0.0.0.0:0 LISTENING 3584只听127.0.0.1是对的，外网连不进来。但这句话换个角度就不好看了：防线从"谁能访问你的网络"变成了"谁能在你本机跑起来"。
在 AI 编码 Agent 普及之后，后者的门槛低得吓人。一个 npm 包的postinstall、一个被投毒的依赖、一个跑在你机器上的脚本，甚至另一个你装过的 Agent skill，都算"能在你本机跑起来的进程"。它们不需要提权，不需要绕过防火墙。
两条路。一条是抢端口：等 daemon空闲 600 秒自动退出（实测日志）之后接手 52800，让真扩展连到自己身上。另一条更省事，直接连上正在跑的 daemon——我翻了ws.rs的握手源码，它只校验 Origin 头的形状（chrome-extension://加 32 位 a–p 字符），不校验具体扩展 ID，本地进程随手伪造一个头就过。源码注释自己承认这一点，原话：a side-loaded extension on the same machine currently passes the gate。连上之后发一帧system.handshake，它就把自己注册成 daemon 眼里的一个"浏览器"。
我的判断很具体：如果你的机器上会跑来源不明的 npm 包、脚本或其他 Agent 的 skill，BrowserSkill 带来的风险比它解决的问题更值得关注。反过来，如果你的机器是干净的、只跑你自己审过的东西，那这个信任模型完全够用。这是合理的工程取舍。
三、代价写在扩展的 manifest 里
端口后面那把钥匙有多大？看扩展的 manifest（apps/extension/wxt.config.ts，源码原文）：
permissions:["alarms","activeTab","debugger","downloads","idle","notifications","scripting","tabs","storage","webNavigation","windows",],host_permissions:["<all_urls>"],debugger加上<all_urls>，是 Chrome 扩展能给自己的最高档权限之一。debugger意味着完整的 Chrome DevTools Protocol：读 DOM、执行 JS、改请求、拿 cookie，都在射程内。隐私政策也直说了，用它把 CDP 挂到你选中的标签页上。
公平地讲，这权限是必需的——要在你已登录的页面上点按钮、填表单，不带 CDP 玩不转。而且这份隐私政策是我读过的同类项目里写得最细的，12 项权限（11 项扩展权限 +<all_urls>主机权限）逐一解释用途，还明确写了不枚举浏览历史、书签、保存的密码，不自己调 AI API，不含分析统计和指纹。
结论不变：装 BrowserSkill 等于把 CDP 级权限交给一个扩展，这个扩展再把它交给本地 52800 端口上的任何进程。两条信任链串在一起，任何一条出问题都是全套交出去。
四、还有一层：skill 会被自动加载
bsk install-skill会把一份SKILL.md（我拉下来是 16,027 字节）写进各 Agent 的 skills 目录。我本机install-skill --list --json扫出来的结果：
| harness | 写入路径 | 本机检出 |
|---|---|---|
| codex | C:\Users\lenovo\.agents\skills | ✅~/.codex,codexon PATH |
| claude-code | C:\Users\lenovo\.claude\skills | ✅~/.claude,claudeon PATH |
| codebuddy | C:\Users\lenovo\.codebuddy\skills | ✅~/.codebuddy |
| cursor / openclaw / workbuddy 等 | 各自~/.<harness>/skills | 未检出 |
三个 harness 都被认出来了。一次安装，三处落盘，而且都是会被 Agent自动读取的目录。
这和我在 SkillSpector 那篇里扫的注入面是同一件事：skill 文件进了这些目录，就会被模型当成指令读。BrowserSkill 这份写得相当克制，开头就写了Never extract credentials, cookies, tokens, or other secrets，全流程要求session stop归还借用的标签页。内容我没发现越界的东西。
需要留意的是机制本身：CLI 版本升级时，daemon 启动、session start、doctor都会尝试同步更新这些文件（本地改过的会保留并暂停更新，doctor给 WARN）。装完它，你的 Agent 指令目录就多了一个会自动更新的外部来源。
五、审计：干净的部分要认，不干净的部分也要认
干净的部分（都是我实跑或读源码确认的）：
- 依赖干净。
Cargo.toml里 tokio、tokio-tungstenite、reqwest（rustls）、clap、sha2、zip 这些主流 crate，没有混淆或来路不明的包。Rust edition 2024，rust-version 1.85，MIT - 没有遥测域名。我把源码里的外部域名扫了一遍：
github.com（44 次，发布与更新）、raw.githubusercontent.com（10 次，安装脚本）、Chrome 商店与 Edge 商店链接，剩下的全是example.com/*.test这类测试域。没有分析统计、没有自托管埋点 - 更新检查有校验，安装流程有 checksum 校验
- 端口只绑回环（已确认）
- 发布记录透明：CHANGELOG 按 Keep a Changelog 维护，6 月 22 日首个 tag、9 月 16 日 0.3.0，逐版本列 Added / Changed / Fixed，可追溯
不干净的部分：
- daemon 会自己联网。日志里明明白白：
periodic update check failed: download https://github.com/Tencent/BrowserSkill/releases/latest/download/version.json。它不是纯离线组件；抓包/进程连接监控确认，外联目标只有github.com - 操作审计默认关闭。开了才写
~/.bsk/audit，保留 30 天，脱敏（不存输入值、页面正文、截图、脚本、文件内容）。已实测开启后*.jsonl落盘，fill/click/evaluate 的输入与选择器均 redacted - 0.3.0 新增了远程模式。可以配对到远程服务器，让服务器上的 Agent 操作你本机浏览器。功能有用，攻击面也跟着从本机扩到了"你选的那台服务器"。本地
daemon devices / revoke已实测；daemon pair需 daemon 运行在 server 模式，未完整跑通 server 侧 - 那个内网域名
iwiki.woa.com出现在源码里 8 次，看着可疑，查下来只是record-steps.test.ts里的录制测试样例，不是外联
六、补做：装上扩展后，把能跑的项都跑了一遍
前面说"装完不能用"，卡在第二步没装商店扩展。装好后no_browser_connected消失，bsk status的browsers里出现chrome实例，扩展弹窗显示"已连接 / READY"。之前交代的未测项基本都补上了，只剩两项受环境限制。
| 命令 / 功能 | 实测结果 |
|---|---|
bsk session start | 成功开出 Agent Window，返回session_id |
bsk navigate https://www.example.com | reached: load，页面打开成功 |
bsk snapshot / observe / get-html | 读 DOM、可见控件、原始 HTML 均正常 |
bsk install-skill --all | 真写入 codex / claude-code / codebuddy 的skills/browser-skill/SKILL.md |
bsk update --check+ 进程外联监控 | daemon 外联目标只有github.com；更新检查直连，不走路由系统代理 |
fill→click→evaluate→ canvas 点击 | 本地测试页上填"测试员"、点按钮、读回显、canvas 命中后读像素[255,0,0,255]，全通 |
bsk tab borrow / return | 把用户窗口里的百度百科页借进 Agent Window，操作完归还，scope user→agent→user |
| 操作审计 | 扩展弹窗开启后，~/.bsk/audit/*.jsonl实时落盘；fill/click/evaluate 的输入与选择器标记input_redacted: true，URL 只保留到域名 |
bsk record start / stop | 生命周期跑通，trace/trace.json+states/成功生成；但录制内容来自真人在浏览器里的操作，自动化命令触发会被会话锁挡住 |
bsk daemon devices / revoke | 本地配对管理可列、可删；daemon pair需要bsk daemon start --mode server，未启动 server 模式故未完整测 |
两个真实约束我留给读者自己追（附操作思路，照着跑就能复现）：
① 全页截图screenshot --full-page——必须让目标标签页保持可见
后台标签页会因page_hidden直接失败（我已实踩）。正确姿势：把被借用的 Agent Window 留在屏幕最前、不最小化、不被遮挡，再跑：
# 在 agent 会话里让标签页可见，然后bsk screenshot--full-page--path"$env:USERPROFILE\Desktop\full.png"截图会平铺整页（含视口外内容），文件通常比普通截图（我那张 22KB）大几倍。重点验证：窗口被遮住时复现page_hidden，移回最前后成功——这本身就是个值得写进评论区的对比。
② 远程模式完整链路——需要 daemon 跑在 server 模式daemon devices / revoke的本机配对管理我已测通；要让远端 Agent 真控制你浏览器，得让 daemon 监听在一台可被对方连到的机器上：
# 本机（被控端）：以 server 模式起 daemon，记下它给的配对码/URLbsk daemonstart--mode server bsk daemon pair# 输出配对码，交给远端# 远端（控制端）：用配对码连进来后，bsk navigate / click 即操作你的浏览器注意攻击面会跟着从本机扩到「你选的那台 server」——配对码别裸发在公网。这一步需要临时打断你当前已连着的扩展连接，所以我没在实测里跑，留给想验证远程场景的读者。
小结
- 信任边界是"谁能碰到 52800"：绑上它或连上它都行，网络反而在防线外。本机进程门槛越低，这条边界越危险
- 代价是
debugger+<all_urls>：权限是必需的，但要知道它串起了两条信任链（扩展 ← 本地端口 ← Agent） - skill 会写进三个会被自动读取的目录且会自动更新：装之前想清楚 Agent 指令目录要不要接纳外部来源
继续用之前，先做三件事
- 用完即关：任务一结束就
bsk daemon stop。daemon 空闲 600 秒才自退，这段窗口就是留给本地攻击者的；少开一秒，少一分暴露 - 隔离运行环境：别在同时跑着来源不明 npm 包或多个第三方 Agent skill 的机器上开浏览器控制。做不到就用独立用户 profile 或干脆换台干净机器——这个信任模型的前提本来就是"本机进程可信"
- 远程能力守两样：只配对你自己审过的那台 server；配对码走私密信道，用完立刻
bsk daemon revoke。顺手把操作审计打开，出了事至少有留痕
项目地址：github.com/Tencent/BrowserSkill（MIT，CLI 0.3.0 / 协议 1.3）。本文所有输出均来自本机 Windows 11 + bsk 0.3.0 实测，源码为 main 分支。
相关阅读
- 我扫过 61 个 skills 的注入面，结论是 0 条真注入、全是误报——静态扫描只能当线索：SkillSpector 注入扫描实测
- 把这套东西变成可执行清单的版本：Agent 供应链审计方法论（待发布）
- MCP 侧的同题：自建 MCP 网关时工具名撞车怎么办（系列（六））
你机器上装了几个能操作浏览器的 Agent 工具？有没有想过它们各自的信任边界在哪？评论区聊聊。这篇装完扩展我又补跑了一遍端到端（见第六节），全页截图和远程 server 模式两项受环境限制，操作思路我已经写在第六节末尾，留给想复现的读者自己跑——谁跑通了欢迎回评论区贴结果。
参考：
- BrowserSkill 仓库
- BrowserSkill 隐私政策（中文）
- 远程浏览器连接文档
