BrowserSkill 浏览器自动化工具 Rust 工作区完整指南：一次看懂 bsk-cli 与 bsk-protocol 双 crate 分工-平芜编程栈

BrowserSkill 浏览器自动化工具 Rust 工作区完整指南：一次看懂 bsk-cli 与 bsk-protocol 双 crate 分工

【免费下载链接】BrowserSkillLet AI agents use your real, logged-in browser without interrupting your work. CLI + extension for browser automation across any shell-capable AI agent.项目地址: https://gitcode.com/GitHub_Trending/br/BrowserSkill

BrowserSkill 是一个让 AI Agent 直接驱动「已登录真实浏览器」的开源浏览器自动化工具，Rust 侧代码集中在 crates/ 下的一个 Cargo 工作区，成员只有 bsk-cli 与 bsk-protocol 两个。从一条截图请求入手，双 crate 的分工就能看清楚。

它到底解决什么问题

AI Agent 自己打开的浏览器是一个全新的 profile：常用网站没有登录态，也没有已保存的凭证，任务执行到一半就得重新处理账号密码。BrowserSkill 的路数不同，它接入用户机器上已经装好、已经登录的真实浏览器，Agent 只负责下达指令，点击、输入、跳转这些实际操作发生在用户日常使用的那份浏览环境里。对涉及账号与登录态的自动化场景来说，这是它与无头方案的本质区别。

一次截图请求的完整链路：跟一条命令走完全程

以 bsk screenshot 为例。命令先进入 src/cli/ 的子命令处理逻辑，CLI 前端通过 src/ipc_client.rs 把消息发给后台常驻的守护进程；daemon 将请求按会话队列排队，再经本地 WebSocket 转发到 TypeScript 侧的浏览器扩展，扩展完成截图后按协议帧结构把结果原路回传。整条路径四跳，每一跳的输入输出都有明确定义。

bsk screenshot (cli/screenshot.rs) → IPC 本地通道 (ipc_client.rs → daemon/ipc.rs) → daemon 会话队列 (daemon/queue.rs) → WebSocket :52800 (daemon/ws.rs) → 浏览器扩展（TypeScript 侧，按协议帧回传结果）

工作区配置本身很轻：根目录 Cargo.toml 只声明两个 member，版本号 0.3.0、Rust 版本 1.85 与许可证统一放在 [workspace.package]，各 crate 以 version.workspace = true 继承；tokio、serde、clap、thiserror 等第三方依赖全部集中在 [workspace.dependencies]，crate 内部只写 workspace = true，升级依赖只改这一处即可。

双 crate 分工速读：两个 crate 各守一摊

bsk-cli：命令前端 + 常驻守护进程

编译出什么：bsk 可执行命令，定位就写在 crate 描述里——browser-skill CLI — control your browser from AI agents。
具体管哪几件事：crates/bsk-cli/ 内，src/cli/ 用 clap 定义三十余个子命令（screenshot、navigate、click、fill、tab、record 等），每个命令对应独立文件；src/daemon/ 是长驻后台进程，对外提供 IPC 与 WebSocket 服务，默认 WebSocket 端口常量 DEFAULT_WS_PORT 为 52800，子模块按 ipc、ws、sessions、queue、remote 等职能拆分；src/skill_install/ 负责把 skill/SKILL.md 安装进各类 AI 编程助手。
哪几个文件最值得先看：src/cli/mod.rs 看子命令全貌，src/daemon/mod.rs 看守护进程生命周期，src/ipc_client.rs 看前端如何接入 IPC。另外 tests/ 下有三十余个集成测试，覆盖锁文件、IPC 冒烟、远程服务端、记录恢复等关键场景，阅读源码时可以对照着看。

bsk-protocol：双方签字的协议契约

如果把整个系统看作两家单位之间的协作，bsk-protocol 就是那份双方签字的合同——它不做任何具体操作，但规定了每条消息必须长什么样。

编译出什么：一个纯库 crate，无独立可执行文件，产出的是 CLI ↔ daemon ↔ 浏览器扩展之间每条消息的类型定义。
具体管哪几件事：四个文件的分工很清晰——src/frame.rs 定义 RequestFrame / ResponseFrame / EventFrame 三种 JSON-RPC 帧；src/method.rs 把所有 RPC 方法名收敛为一个枚举；src/tools/ 存放每个 tool.* 方法的入参与出参类型，按 interaction、navigation、observation、record、tabs 等功能分文件；src/system.rs 负责握手、状态查询与版本兼容检查（compare_protocol、evaluate_handshake_compat）。
哪几个文件最值得先看：frame.rs 理解消息骨架，method.rs 看「动词表」全量清单，tools/ 看具体操作的参数约定。
schema/ 目录的价值：crates/bsk-protocol/schema/ 下存放着由这些类型自动生成的九十余份 JSON Schema，例如 tool_click_params.json、tool_navigate_result.json、trace_v3.json。这意味着协议契约不再依赖 Rust 环境，任何语言与工具都能直接校验消息格式；协议演进（如 trace v2 → v3 的变化）在 schema 文件里一目了然。运行 dump-schema 二进制即可整体重新生成。bsk-protocol 正是以 workspace 依赖的形式被 bsk-cli 引用，拆成独立 crate 的理由一句话：协议稳定，实现可换。