Vibium：Selenium 创始人给 AI Agent 做的浏览器验证层

2026 年，Selenium 和 Appium 的联合创始人 Jason Huggins 推出了 Vibium——一个把浏览器管理、协议代理和 MCP 服务统一打包进单个约 10MB 二进制的工具。它的定位不是”又一个 Playwright”，而是给编码 Agent 用的浏览器验证层：Agent 写完代码后，需要自己打开浏览器跑一遍、截图验证、检查断言，Vibium 就是干这个的。本文基于其官方 README 分析其设计。

一、背景：为什么 Selenium 创始人要做新工具

浏览器自动化领域已有 Selenium、Playwright、Puppeteer 等成熟方案，但它们的设计目标是人类写测试脚本——API 冗长、需要选择器、等待逻辑复杂。AI Agent 的需求完全不同：

• Agent 需要的是简短命令：“打开这个页面、点这个按钮、截图给我看”；
• Agent 需要语义化定位：不需要写 CSS 选择器，用”找文字为 Sign In 的按钮”就行；
• Agent 需要自检能力：做完操作后能独立验证”购物车里确实有一个电池包”；
• Agent 需要零配置：装上就能用，不要让 Agent 去下载 ChromeDriver、处理版本匹配。

Vibium 就是为这些需求设计的。它不是替代 Playwright 做端到端测试，而是让 AI Agent 能用最短的路径操作浏览器来验证自己的工作。

二、技术架构：一个二进制包打天下

根据 README，Vibium 的架构可以概括为：

┌──────────────────────────────────────┐
│           LLM / Agent                │
│   (Claude Code, Codex, Gemini)      │
└──────────────┬───────────────────────┘
               │ CLI (Bash) 或 MCP (stdio)
┌──────────────▼───────────────────────┐
│          Vibium ~10MB binary         │
│  ┌──────────────┐  ┌──────────────┐  │
│  │ CLI Commands │  │  MCP Server  │  │
│  └──────┬───────┘  └──────┬───────┘  │
│         └───────┬─────────┘          │
│           ┌─────▼─────┐              │
│           │ BiDi Proxy │              │
│           └─────┬─────┘              │
└──────────────────┼───────────────────┘
                   │ WebSocket BiDi :9515
          ┌────────▼─────────┐
          │  Web Browser     │
          │  (Chrome/Firefox)│
          └──────────────────┘

关键设计决策：

• 基于 WebDriver BiDi：不是自研协议，用 W3C 标准的双向协议，避免了 Selenium 时代的协议碎片化问题；
• 单二进制：Go 编写，编译后约 10MB，无运行时依赖；
• 浏览器自动下载：vibium setup 会在检测到缺失时自动安装 Chrome；
• 三种接入方式：CLI（给 Agent 通过 Bash 调用）、MCP Server（给 Claude Code / Gemini 等）、客户端库（JS/TS/Python/Java）。

三、API 设计：同步与异步双套

Vibium 同时提供同步和异步 API，README 里 Python 示例：

# 异步
import asyncio
from vibium.async_api import browser

async def main():
    bro = await browser.start()
    vibe = await bro.page()
    await vibe.go("https://example.com")
    png = await vibe.screenshot()
    bro.stop()

asyncio.run(main())

# 同步（默认）
from vibium import browser
bro = browser.start()
vibe = bro.page()
vibe.go("https://example.com")
vibe.screenshot()
bro.stop()

CLI 层面，核心工作流是”Map & Interact”：

vibium go https://var.parts      # 导航
vibium map                       # 映射可交互元素为 @e1, @e2...
vibium click @e1                 # 用引用编号点击
vibium find text "Sign In"       # 语义化查找
vibium check "购物车有一个电池包"  # 断言验证

这种设计让 Agent 不需要写复杂的选择器链——map 命令会把页面上的可交互元素编号，后续操作直接引用编号。

四、与现有方案的对比

五、口径与局限

README 中有几个需要注意的点：

1. “Run and Check 需要开发版和 AI 配置”：内置的 vibium run "自然语言任务" 和 vibium check "断言" 功能依赖 AI 模型配置（写在 ~/.config/vibium/ai.env），不是开箱即用的；
2. Windows 仅支持 x64：没有 ARM64 Windows 版本；
3. Firefox 支持有限：默认是 Chrome，Firefox 154+ 才能录制视频；
4. 不是完整浏览器 Agent：README 明确说它是”verification layer”——提供工具让 Agent 检查自己的工作，而不是替 Agent 做决策。做什么、点哪里，仍然是上层 LLM 的决定；
5. Java 客户端版本号 26.8.21：版本号跟随日期，不是语义化版本。

六、Check：Agent 的独立验证能力

Vibium 最有特色的设计是 check 命令——它不是”截图给你看”，而是让 Agent 用自然语言提出断言，由 Vibium 结合浏览器当前状态和可选的录制回放来判断断言是否成立：

vibium check "购物车中恰好有一个电池包"
vibium check "页面标题包含 'VAR Parts'" -o check-result.zip

这个设计把”操作浏览器”和”验证结果”拆成了两个独立的 skill：browser 负责执行操作，check 负责独立判断。README 强调 check 是”独立”的——它不假设前一步操作成功，而是自己去页面上重新确认。这种分离对 Agent 工作流很重要：Agent 经常需要在多轮操作后回头验证一个状态，而不是每步都假设成功。

vibium record 可以把整个会话录制成带截图的 zip 包，供后续回放或作为 bug report 附件。

七、客观分析

优势：

1. 作者信誉：Jason Huggins 是浏览器自动化领域的奠基人之一，对这个领域的痛点理解极深；
2. WebDriver BiDi 标准：避免了私有协议锁定；
3. 单二进制 + 零配置：Agent 安装成本极低；
4. CLI/MCP/SDK 三模式统一：从命令行到编程库到 Agent 工具调用，一套后端；
5. Apache 2.0 开源：可自由商用。

局限：

1. 年轻项目：生态和文档不如 Playwright/Selenium 成熟；
2. AI 依赖的 Check/Run 功能需额外配置模型；
3. 不是测试框架：没有内置测试 runner、断言库、报告生成，定位是工具不是框架；
4. Windows ARM 不支持；
5. Chrome 为主：Firefox 是二等公民。

八、适合谁

• 构建 AI 编码 Agent 的团队：需要 Agent 能自己打开浏览器验证 UI 改动；
• Claude Code / Codex 用户：通过 MCP 一键接入；
• 不想写 Playwright 脚本的简单自动化场景：CLI 命令比 Playwright API 简短。

它不适合：需要复杂 E2E 测试套件、跨浏览器矩阵测试、或移动端自动化的团队——这些仍然是 Playwright/Selenium/Appium 的领地。

参考来源

• Vibium GitHub 仓库
• Vibium npm 包
• Vibium 官方文档（Getting Started）
• Koala 项目库条目