加载失败
Vibium 是由 Selenium 与 Appium 的创建者发起的浏览器自动化项目，宣称同时为人类开发者与 LLM agent 提供能力。当前发布的 v1（称为 clicker）主要实现执行层能力，项目路线图在 v2 引入 retina（将交互转为持久感知信号）和 cortex（基于信号构建工作流的规划层），以实现机器人学的 sense–think–act 循环。实现上 Vibium 采用 W3C WebDriver BiDi（新双向 WebDriver 协议）并同时提供 MCP-compatible server（供 Claude Code 等 agent 使用）与传统 JS/TS API。讨论集中在与 Playwright 的差异、v1 的功能缺口（如 JS eval、网络拦截）、安全治理（容器/白名单）和如何为庞大的 Selenium 遗留用户提供迁移路径。
多位评论首先对 Selenium 表示感谢并回忆其对职业生涯和行业的深远影响，认为 Selenium 在很多领域仍然深入扎根。评论指出 Vibium 因为由 Selenium/ Appium 的创建者发起，自带可信背书，很多现有 Selenium 用户希望通过 Vibium 找到“升级桥梁”，而不是直接抛弃既有资产。也有声音提到 Selenium 在学术和遗留系统中占优势，但在初创公司与新一代开发者中 Playwright 更受欢迎，这既是技术差异也是品牌印象问题。若要推广 Vibium，除了技术外还要处理“修补 Selenium”与“创建新品牌”带来的市场与心理负担。
很多人要求把 Vibium 与 Playwright 直接比较：Playwright 的优点被反复提到，包括快速的 websockets+JSON 驱动、auto-waiting、内置录像和良好 DX。作者解释 Vibium 底层使用 W3C WebDriver BiDi，并把产品路线分层：v1 为执行层（clicker），v2 将加入 retina（把交互转为持久感知信号）和 cortex（基于信号构建可导航的工作流模型），目标是实现机器人学的 sense→think→act 循环而不是仅支持单次动作。因此 Vibium 的主张不是单纯复制 Playwright 的 DX，而是把感知与规划作为第一阶公民，为长期的 agent 驱动工作流做基础。社区关注点集中在 Vibium 能否把这种“sense/think”愿景变成比现有 Playwright+mcp 更有用的产品。
评论里列出了用户目前最在意的缺失：注入任意 JS、修改 DOM、拦截/修改网络请求等功能在 v1 中尚未完备，而这些正是许多 Playwright 用户的日常需求。开发者回应这些功能在路线图上，且指出除了 MCP server，还有一个普通的 JS/TS API 能运行任意脚本，社区中已有 fork 添加了 browser_evaluate 来读取 accessibility tree。实务细节也被提及：npm install vibium 会在安装时下载所需浏览器，Python 客户端计划上 PyPI，本地模型（如通过 llama.cpp）支持也在规划中。作者明确当前 v1 更聚焦于测试自动化场景，复杂的登录/会话处理与爬虫/RPA 场景仍被视为更艰难的用例，需要后续迭代和社区贡献。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8]
多条评论警惕把浏览器完全开放给 LLM 的“blast radius”风险，询问是否能通过白名单将浏览器限制为仅访问特定 URL（如 localhost）。社区给出实践建议：在 VM/容器内运行并用防火墙或 --host-resolver-rules 强制域名白名单，或在 Claude Code 的 MCP hook 层做拦截；也可使用 Rego 策略（如 cupcake）实现更细粒度治理。有人指出治理复杂性不仅在浏览器实例本身，还要把 Claude 等模型端点纳入考量，web-search 等功能会进一步增加攻击面。总体共识是短期用容器/VM+网络白名单可减轻风险，但长期需要更系统的策略与集成方案。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6]
社区在探讨用 LLM 做自愈测试与自动修复时，反复遇到现实世界的障碍：验证码、下拉菜单交互失败、SSO 问题和不可见的网络请求都会让 agent 失灵。技术细节上，截图驱动的操作难以直接映射到可靠的 CSS selector，MCP 当前对 DOM/可访问性树的暴露有限，已有开发者在 fork 中加入 browser_evaluate 来获取可访问性树以定位元素。讨论还区分了“只需点击”的高频简单用例（Vibium 的 clicker 针对该场景）与需要完整感知/规划的复杂工作流，并指出有时可以把 agent 生成的脚本转为静态测试避免每次都调用 LLM。总体上，代理的价值受限于可观测性与反机器人机制，社区期待 Vibium 的感知与规划层来提高稳健性。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8]
评论显示出对生态与长期路线的关注：很多人通过查看 commits 学习 AI 辅助开发，项目已建立 Discord 并鼓励贡献与用例分享。创始人希望为庞大的 Selenium 安装基提供“升级路径”，并考虑托管服务（如 vibium.cloud）的可能性，同时强调依赖标准（W3C WebDriver BiDi）與业界合作以扩大采纳。社区反复请求多语言客户端（Python、Go）和本地模型支持，作者表示会逐步发布 Python 客户端并支持更多后端选项。总体氛围是既有信任与兴趣，也有对能否达到 Playwright 级别 DX 与生态覆盖的现实审视与等待。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6]
MCP: MCP（Model Control Protocol）——在 Claude Code 等 LLM agent 生态中常见的工具通信协议，用于模型向外部工具发送浏览器命令（如 browser_click、browser_screenshot）并接收结果与事件。
WebDriver BiDi: WebDriver BiDi（W3C 双向 WebDriver 协议）——一种基于 JSON over WebSocket 的双向浏览器控制标准，受 Chrome DevTools Protocol 启发，用于远程控制浏览器并接收事件回传。
sense–think–act 循环: 机器人学里的 sense→think→act 循环：先感知环境、再推理/规划，最后执行动作。Vibium 用这个概念把 v1 的执行层（clicker）和后续计划的 retina（感知）与 cortex（规划）联系起来。
vibe coding: vibe coding——Vibium 提出的协作式开发/自动化方式，强调 AI agent 与人类通过长期累积的感知信号和规划模型共同驱动浏览器自动化流程，而不是每次从原始 HTML 重新推理。