v-browser：直接接管当前已登录浏览器的 V 语言自动化 CLI
很多浏览器自动化工具的默认思路，都是先拉起一个全新的浏览器进程，再从一个干净上下文里开始执行。
但真实业务一上来就会碰到几个问题：
- 你已经在浏览器里登录了 GitHub、掘金、公众号后台、管理后台，工具却还要你重新登录。
- 很多网站依赖当前浏览器里的登录状态、存储数据和扩展环境，换一个新浏览器之后，真实上下文就没了。
- AI Agent 真正需要的，往往不是再开一个新浏览器，而是直接接管我现在正在用的浏览器和当前页面。
v-browser 就是沿着这个方向做的。它是一个用 V 语言实现的浏览器自动化 CLI，通过本地 daemon 加浏览器扩展接入 Chrome DevTools Protocol，给 AI Agent 和脚本提供一套稳定、直接、可组合的命令面。
项目地址： github.com/whiter001/v…
核心特性 1：直接复用当前浏览器里已经存在的登录状态
这是 v-browser 和很多传统自动化方案最不一样的地方。v-browser 不是优先去起一个新的独立浏览器，而是通过扩展把你当前正在使用的 Chromium 内核浏览器桥接到本地 relay，然后 attach 当前页面。
这意味着：
- 你当前浏览器里已经登录的 GitHub、掘金、微信公众号后台、各类管理系统，v-browser 可以直接接着用。
- 当前浏览器里已经存在的本地状态、存储数据和扩展环境都能保留下来。
- 对很多必须使用真实登录环境的场景来说，这比重新拉起一个干净浏览器更实用。
换句话说，v-browser 更像是在说：不要重新造一个浏览器环境，直接接管我眼前这个已经登录好的浏览器。
核心特性 2：运行链路更轻，不围着 WebDriver 和 chromedriver 打转
v-browser 的核心链路很直接：
- 一个本地 V 写的 server 和 CLI
- 一个浏览器扩展
- 通过本地 relay 和 CDP 通信
它没有把运行时建立在 chromedriver、selenium server 或额外的驱动下载机制上，而是尽量把链路收敛成 本地二进制 加 扩展 加 当前浏览器。
这带来几个很实际的收益：部署和分发更轻，出问题时更容易排查，对脚本和 Agent 来说命令也更清晰。严格来说，扩展前端在开发阶段仍然需要构建一次，但从运行和分发角度看，server 端就是一个非常清爽的独立二进制方案。
核心特性 3：对 AI Agent 友好，而不是只对测试脚本友好
v-browser 不是只把点击、输入做一遍封装，而是明显在为 Agent 调用设计命令接口。
它现在这套能力很适合 Agent 场景：
- 支持 open、click、fill、press、upload、download、screenshot、pdf、snapshot、eval 等一整套页面操作。
- 支持 find text、find role、find label 这类更偏语义化的定位方式。
- 支持统一 JSON 输出，方便模型和脚本继续处理结果。
- 对错误做了较明确的分类，例如连接失败、超时、参数错误、未连接等。
尤其是 snapshot 这类能力，对 Agent 很重要。很多时候，Agent 需要的不是猜一个 CSS selector，而是先拿到一个可引用、可理解的页面结构，再决定下一步操作。
核心特性 4：独立二进制发布，跨平台分发很直接
v-browser 的 nightly release 直接提供多平台压缩包，核心产物包括：
- v-browser-linux-x86_64.zip
- v-browser-windows-x86_64.zip
- v-browser-darwin-arm64.zip
- v-browser-extension.zip
也就是说，server 和 CLI 端直接下载对应平台二进制即可，扩展单独打包分发，发布物结构也很直观。
核心特性 5：V 语言做这类本地工具，天然有优势
对于本地 CLI、Agent Runtime、自动化中间层这类项目来说，V 的几个特性很契合：
- 编译后就是独立二进制，分发成本低。
- 启动快，适合命令行高频调用。
- 运行时负担相对轻。
- 用来写 server、协议转发、命令解析这类逻辑非常顺手。
v-browser 是怎么工作的
v-browser 的结构可以概括成三层：
- CLI 和 server 层，负责接收命令、维护本地 relay、转发请求、处理输出。
- 浏览器扩展层，负责把当前标签页桥接到本地 server，并把页面操作映射到浏览器能力上。
- 当前浏览器和当前页面，真正被控制的是你手头已经打开、已经登录、已经带状态的浏览器环境。
这套设计最关键的点，不是能不能控制浏览器，而是控制的是不是你真实在用的那一个浏览器上下文。
一个很实用的使用方式
以 GitHub 为例，典型流程非常短：
cd packages/server
./v-browser connect
./v-browser open https://github.com/whiter001/v-browser
./v-browser snapshot
./v-browser eval document.title
如果你已经在浏览器里登录了 GitHub，那么这套操作就是在你的真实登录态里执行，而不是在一个新的隔离浏览器里再登录一遍。
我认为它适合哪些场景
场景 1：AI Agent 直接操作真实网页
比如读取页面内容、点击按钮、填表、提交表单、截图、执行一段页面内 JS。这类动作如果能直接发生在当前已登录浏览器里，成功率和实用性都会明显提升。
场景 2：内容发布与运营后台自动化
像掘金、GitHub、微信公众号后台、管理台这类平台，经常要求真实登录态、图形化交互和复杂上下文。v-browser 这种复用当前浏览器环境的方案，天然更贴近真实工作流。
场景 3：内部工具和脚本平台集成
因为它本质上是一个 CLI，而且输出也适合继续被脚本消费，所以很适合接进 CI、本地脚本、Agent runtime，或者作为更大自动化系统里的浏览器执行层。
最后
浏览器自动化工具很多，但真正适合 AI Agent 和真实业务场景的，并不只是 API 丰富就够了。更关键的是，能不能复用当前浏览器的真实状态，能不能避免额外的驱动和笨重依赖，能不能用一套足够稳定的 CLI 接口让 Agent 连续工作，能不能方便分发。
v-browser 在这些点上的取舍，我觉得是非常清晰的。
如果你正在做 AI Agent 浏览器操作、内容后台自动化，或者想把浏览器能力封装成一个可分发、可组合、可集成的独立 CLI，这个项目很值得关注。
项目地址再放一次： github.com/whiter001/v…
