OpenChrome - servidor MCP de automação paralela para o navegador Chrome
(github.com/shaun0927)O Playwright é uma ferramenta útil de automação web que controla ações no navegador, como cliques, quando você quer fazer crawling de algum jeito
ou executar testes E2E em ambiente de produção.
Foi lançado em 2020,
mas ainda é uma ferramenta usada pela maioria dos desenvolvedores.
No entanto, abrir apenas uma sessão já consome mais de 2 GB de RAM, além de ser pesado, lento e quebrar com frequência.
Na era da IA, essa ferramenta precisa de inovação,
e especialmente de uma ferramenta de automação de navegador que funcione com estabilidade mesmo em tarefas paralelas.
Não queremos mais fazer QA manualmente nem ficar vagando por sites.
O OpenChrome é um projeto que nasceu da vontade de resolver esse problema.
É um servidor MCP para alcançar automação paralela de navegador com rapidez e inteligência.
Também é a ferramenta que mais tenho usado recentemente no meu trabalho pessoal.
Ele usa o login do navegador Chrome,
e, se você usar várias contas, basta indicar durante a tarefa qual nome de conta deve ser usado.
Por padrão, ele funciona com base no navegador Chrome que já está logado.
É possível executar tarefas em paralelo em mais de 20 navegadores, e o uso de RAM foi reduzido para cerca de 300 MB. Ele trabalha com o Chrome já autenticado e, na prática, neutraliza completamente a detecção de bots. Também pode ser integrado ao Openclaw.
Um exemplo de uso é o seguinte.
"Faça crawling com o oc dos posts mais recentes de 20 personalidades famosas do Twitter."
(benchmark com base no claude code: 3 minutos e 30 segundos — a maior parte é tempo de inferência do LLM)
Na verdade, o problema crônico do Playwright é a "perambulação do LLM", quando ele fica dando tiros no escuro.
Mesmo quando você pede algo como fazer login, ele passa um bom tempo fuçando o site e tentando várias coisas,
e no fim costuma mandar um aviso dizendo que falhou depois de mais de 30 minutos.
O OpenChrome resolve isso com uma abordagem guiada, em vez de baseada em suposição.
Ele faz login diretamente no Chrome e, se você fornecer um link, acessa esse link imediatamente.
Tira o mínimo possível de screenshots e identifica rapidamente a posição de botões e outros elementos.
Se surgir algum problema durante a tarefa, ele relembra o que fez para não repetir o mesmo erro.
Por ser um servidor MCP, ele pode ser usado imediatamente em qualquer ambiente no lugar do Playwright.
Funciona tanto em desenvolvimento no MAC-claude code quanto em outros sistemas operacionais, como Windows e Linux,
além de rodar também em codex cli, cursor e outros.
Instalação:
npx openchrome-mcp setup
A estabilidade em produção de grande escala, muito complexa e com alto consumo de recursos, ainda precisa de validação adicional.
Se você tiver feedback ou sugestões, publique no GitHub Issues que vou refletir isso imediatamente.
Obrigado.
13 comentários
Então, em vez de usar uma solução E2E existente, a própria IA vai gerenciar e executar diretamente o código de teste?
Se o Playwright tradicional consumia muitos tokens ao acessar sites com uma metodologia mais engessada,
o OpenChrome pode ser entendido como um conceito que aborda isso de forma mais amigável para LLMs, permitindo que o próprio LLM interfira rapidamente e controle diretamente o comportamento no site. É possível executar soluções de e2e diretamente.
Por exemplo, em um ambiente de produção que exige login do Google, é possível realizar tarefas de QA já com a conta de administrador autenticada. Dá para fazer rolagem, deixar que ele clique sozinho em casos de borda e praticamente executar a maioria das tarefas que você imaginar. Isso acontece porque, em vez de deixar o Playwright agir de forma autônoma fazendo tarefas bobas, o LLM intervém em tempo real para controlar o comportamento.
Se considerar apenas o uso de tokens, um método mais estruturado não acabaria sendo ainda menor, já que executa os casos de teste E2E sem intervenção do LLM?
Na metodologia de testes, além dos TCs, também está incluído o teste autônomo feito pelo QA.
Se julgarem que essa parte tem boa eficiência, seria uma boa avaliação?
Para responder de forma mais técnica à sua pergunta específica,
O MCP tradicional do Playwright funciona com a abstração em 3 etapas abaixo:
LLM → servidor MCP → servidor Playwright Node.js → CDP/Juggler → navegador
Já o OpenChrome funciona com a abstração em 1 etapa abaixo:
LLM → servidor MCP → CDP → navegador
Quanto menos camadas de abstração, mais rápido e mais preciso é o controle, e, enquanto o Playwright é uma ferramenta de uso geral, o OpenChrome usa ferramentas especializadas.
Em termos de matemática, seria como comprimir uma solução de 20 linhas em 4 linhas.
O Playwright recebe feedback por meio de uma abordagem textual baseada em árvore de acessibilidade
(em teoria isso é excelente, mas é justamente por isso que quebra na maioria dos sites)
e, por isso, a compreensão de contexto também fica bastante limitada.
Assim, em sites com acessibilidade bem implementada (como o Google e outros domínios conhecidos), o Playwright continua sendo útil, mas,
na maioria dos sites ou em produção, o OpenChrome é de longe superior.
Além disso, como a "densidade do design das ferramentas" e a "redução das oportunidades de erro do LLM" acabam determinando o desempenho prático,
acho correto medir isso por tarefas do mundo real, e não por desempenho teórico.
Obrigado. Eu não tinha lido o texto principal com atenção suficiente.
Acabei ignorando a parte de que era voltado para ambiente de produção.
Eu também vou experimentar com certeza.
Obrigado por responder tão bem a uma pergunta equivocada~
Não, e obrigado pela ótima pergunta. Ao explicar, eu também consegui organizar melhor minhas próprias ideias.
Com certeza é rápido e bom.
Mas, se aparecer um alerta, ele trava.
Vou melhorar isso rapidamente.
Também fiquei curioso sobre a comparação com o Chrome DevTools MCP!
Pelo que me lembro de quando usei, o Playwright acabou sendo melhor do que o chrome devtools mcp; depois vou ver se adiciono um benchmark.
No
chrome devtools mcpnão aparecia o aviso de large context, mas eu sentia que o desempenho era mais ou menos parecido, então eu estava usando este aqui! Fiquei curioso pelos resultados do benchmark :DNossa, isso também reduz o uso de tokens? Obrigado!!
Você pode considerar que, na medida em que reduz esses erros em falso, o consumo de tokens também diminui.