需求场景
目前 bsk 要求 Agent 和浏览器在同一台机器上。实际使用中经常希望两者分离:
- Agent 在云服务器 / 远程开发机上(headless 环境),浏览器在本地 Mac/PC 上,带着全部已登录的内部系统、文档站登录态;
- Agent 在 WSL / 容器 / CI 里,想复用宿主机或另一台机器上真实浏览器的登录态,而不是另外维护测试账号;
- 团队内一台"浏览器执行机"统一对外提供已登录的浏览器操作能力。
期望
- Agent 侧依然只用 bsk CLI,就能操作另一台机器上的浏览器,使用 session start / snapshot / click 等全部现有能力;
- bsk CLI 支持连接远程的 daemon;
- 浏览器插件也支持配置要连接的 daemon 地址,不局限于本机;
- 远程连接需有鉴权,默认关闭、显式开启——毕竟操作的是已登录的真实浏览器。
Use Cases
Today bsk requires the agent and the browser to run on the same machine. In practice, we often want them separated:
- The agent runs on a cloud server / remote dev box (headless), while the browser runs on a local Mac/PC with logged-in sessions for internal systems and doc sites;
- The agent runs in WSL / a container / CI and should reuse the real, logged-in browser on the host or another machine, instead of maintaining separate test accounts;
- A single "browser runner" machine provides logged-in browser automation for the whole team.
What We'd Like
- From the agent side, keep using only the
bsk CLI to drive a browser on another machine, with all existing capabilities (session start / snapshot / click / ...);
- The
bsk CLI can connect to a remote daemon;
- The browser extension can also be configured with the daemon address to connect to, not limited to the local machine;
- Remote connections must be authenticated, off by default, and explicitly opt-in — after all, what's being driven is a real, logged-in browser.
需求场景
目前 bsk 要求 Agent 和浏览器在同一台机器上。实际使用中经常希望两者分离:
期望
Use Cases
Today bsk requires the agent and the browser to run on the same machine. In practice, we often want them separated:
What We'd Like
bskCLI to drive a browser on another machine, with all existing capabilities (session start/snapshot/click/ ...);bskCLI can connect to a remote daemon;