14 pontos por GN⁺ 2025-12-25 | 1 comentários | Compartilhar no WhatsApp
  • Projeto open source de automação de navegador recriado com agentes de IA em mente por Jason Huggins, que desenvolveu o Selenium há 21 anos
  • O Vibium é uma infraestrutura de automação de navegador para agentes de IA, que gerencia o ciclo de vida do navegador e o protocolo WebDriver BiDi em um binário único, além de expor um servidor MCP
  • O binário único em Go de 10 MB, Clicker, detecta e inicia o Chrome automaticamente, permitindo que modelos de IA ou clientes JS controlem o navegador por meio de um proxy BiDi e de um servidor MCP
  • O cliente JS/TS oferece suporte a APIs síncronas e assíncronas, podendo ser usado imediatamente após a instalação com npm install vibium
  • Agentes LLM como o Claude Code podem adicionar recursos de controle de navegador com uma única linha de comando: claude mcp add vibium
  • É adequado tanto para automação com IA quanto para automação de testes, oferecendo um ambiente de controle de navegador sem configuração

Visão geral do Vibium

  • O Vibium é uma infraestrutura de automação de navegador para agentes de IA e usuários humanos
    • Integra gerenciamento de navegador, proxy WebDriver BiDi e servidor MCP em um único binário Go
    • Compatível com diversos modelos LLM, como Claude Code, Codex e Gemini
  • A estrutura funciona imediatamente sem processo de instalação, podendo ser usada em ambientes de agentes de IA ou de automação de testes

Componentes

  • Clicker: binário Go de cerca de 10 MB que executa as seguintes funções
    • Detecção automática do Chrome e execução em modo BiDi
    • Encaminhamento de comandos por um servidor proxy BiDi baseado em WebSocket
    • Comunicação com agentes LLM por meio de um servidor MCP
    • Recurso de Auto-Wait para aguardar elementos antes de interagir
    • Recurso de captura de tela
  • Cliente JS/TS: fornecido como pacote npm, com suporte a APIs síncronas (browserSync) e assíncronas (browser)
    • Controle do navegador com comandos simples como vibe.go(), vibe.find(), vibe.click() e vibe.quit()
    • Inclui funções básicas de automação, como salvar capturas de tela, localizar elementos e clicar

Integração com agentes de IA

  • Comando para adicionar controle de navegador ao Claude Code:
    claude mcp add vibium -- npx -y vibium  
    
    • O Chrome é baixado automaticamente, sem necessidade de configuração adicional
  • Lista de comandos disponíveis
    • browser_launch: iniciar o navegador
    • browser_navigate: navegar para uma URL
    • browser_find: localizar elemento por seletor CSS
    • browser_click: clicar em um elemento
    • browser_type: inserir texto
    • browser_screenshot: capturar a viewport
    • browser_quit: encerrar o navegador

Instalação para usuários humanos

  • Instalação automática com o comando npm install vibium
    • Baixa para o cache o binário Clicker, o Chrome for Testing e o chromedriver de acordo com a plataforma
    • Linux: ~/.cache/vibium/, macOS: ~/Library/Caches/vibium/, Windows: %LOCALAPPDATA%\vibium\
  • É possível pular o download do navegador com a variável de ambiente VIBIUM_SKIP_BROWSER_DOWNLOAD=1

Suporte a plataformas

  • Compatível com Linux x64, macOS (Intel/Apple Silicon) e Windows x64

Início rápido

  • Exemplo de uso da biblioteca
    import { browser } from "vibium";  
    const vibe = await browser.launch();  
    await vibe.go("https://example.com");  
    const el = await vibe.find("a");  
    await el.click();  
    await vibe.quit();  
    
  • Exemplo de integração com Claude Code
    • Após a instalação, é possível controlar o navegador com comandos como “Go to example.com and click the first link”

Roteiro

  • V1: foco no controle do navegador via MCP e cliente JS
  • Planos para V2
    • Clientes para Python e Java
    • Cortex (camada de memória e navegação)
    • Retina (recurso de extensão para gravação)
    • Gravação de vídeo e localização de elementos com IA

1 comentários

 
GN⁺ 2025-12-25
Comentários do Hacker News
  • O Selenium causou uma grande mudança na minha carreira. Sou sinceramente grato por isso
    Hoje em dia uso Playwright, mas estou curioso sobre a nova abordagem do Vibium

    • O Playwright avançou bastante com o controle rápido do navegador baseado em WebSockets+JSON. O Vibium usa o padrão W3C WebDriver BiDi como resposta a isso. O objetivo é oferecer uma experiência de desenvolvimento elegante, do tipo “alguns cliques e pronto”, como no Playwright
    • Se você já usa Playwright, recomendo experimentar o Stagehand. A API é parecida, mas foi projetada para automação, não para testes
  • Fiquei curioso se o Vibium oferece suporte a injeção de JS, modificação do DOM e monitoramento/alteração de requisições de rede. Quase sempre uso esses recursos quando trabalho com Playwright

    • Ainda não há suporte, mas isso está no roadmap. O objetivo é absorver as vantagens do Playwright e ir além delas
    • Pessoalmente, só o monitoramento de requisições de rede já seria suficiente. Aplicativos em Flutter + Amazon AppSync são muito difíceis de depurar
  • Interessante. Recentemente venho usando dev-browser e obtendo economia de contexto e ganho de velocidade. Com certeza vou testar o Vibium também

    • O plano é que o Vibium também ofereça esse tipo de extensibilidade baseada em skills
  • Como alguém que ganha a vida com automação de UI há mais de 10 anos, sou grato ao Selenium. Hoje o Playwright é o padrão de fato, mas o Selenium foi o driver de navegador original. Fiquei curioso sobre como o Vibium se diferencia do Playwright

    • O Playwright está à frente em termos de “velocidade”, mas o Selenium ainda tem um ecossistema profundamente enraizado no mundo todo. O plano do Vibium é construir uma ponte para que usuários de Selenium façam uma transição natural para a codificação com agentes voltada para o futuro
  • Sou uma das pessoas que ajudaram a expandir os testes da Atlassian com Selenium no passado. Lembro de termos conversado há uns 13~15 anos. É bom ver que você ainda está ativo nessa área

  • Fiquei curioso se, ao migrar scripts antigos de Selenium para o Vibium, seria possível aproveitar o recurso de auto-recuperação (self-heal) em caso de falha nos testes

    • Fazendo uma analogia, agora estou construindo um resort em uma ilha. A ponte (o caminho de migração) vai ser construída depois. Se o resort for atraente primeiro, haverá motivo para construir a ponte. No momento estou focado em construir o resort, mas também quero muito fazer a ponte
  • Fiquei curioso sobre como ele encontra seletores CSS quando o agente tira uma captura de tela com browser_screenshot e depois tenta clicar. Só com a imagem é difícil saber o tipo dos elementos

    • No momento, o servidor MCP ainda não tem exploração autônoma completa. No meu fork, adicionei a ferramenta browser_evaluate para obter a árvore de acessibilidade via JS e permitir navegação com base nela. Para mais detalhes, veja o roadmap V2
  • Para permitir que ferramentas como Claude usem automação de navegador com liberdade, seria necessário um recurso de bloqueio do navegador que permita apenas URLs específicas. Fiquei curioso se isso está no roadmap

    • Se você usa Claude Code, dá para controlar isso facilmente com o hook browser_navigate. Um script de whitelist pode ser configurado em 5 minutos. Políticas mais complexas podem ser implementadas com cupcake e Rego. Referência: documentação de Hooks do Claude Code
    • Tenho plena noção do risco de “blast radius” do Claude. Eu também desenvolvo o Vibium dentro de uma VM UTM. Estou considerando adicionar regras de rede. Já publiquei o roadmap V2 e talvez precise preparar um rascunho do V3 também
    • O método mais confiável é rodar isso dentro de um contêiner com firewall, permitindo apenas uma whitelist curta
  • Eu estava pensando em criar algo parecido com o Skyvern, então fiquei curioso sobre por que você fez um novo Vibium em vez de uma extensão do Selenium

    • Expliquei parte disso no anúncio do Vibium v1. Selenium e Playwright não foram projetados com foco em IA. O Vibium foi desenhado desde o início com uma estrutura otimizada para “vibe coding” baseado em IA
  • Fiquei curioso sobre como vocês lidam com o problema de sobrecarga de contexto (context bloat) entre o navegador e o LLM. Também perguntaram se há planos de expor arquivos de tracing como no Playwright ou permitir execução de JS

    • A exposição do navegador será ampliada gradualmente. Ainda não existe uma solução perfeita para a sobrecarga de contexto. No longo prazo, a resposta pode até ser “seguir sem usar MCP”. Atualmente o Vibium oferece duas opções: servidor MCP e API JS/TS. Na API JS/TS, é possível executar JS arbitrário. Fazer o agente escrever e executar scripts do Vibium também pode ser um atalho para reduzir a sobrecarga de contexto