Como criamos OWL, a nova arquitetura por trás do navegador Atlas baseado no ChatGPT

Por Ken Rockot, membro da equipe técnica, e Ben Goodger, chefe de engenharia do ChatGPT Atlas

Na semana passada, lançamos o ChatGPT Atlas⁠, uma nova maneira de navegar na web com o ChatGPT. Além de ser um navegador completo, o Atlas oferece um vislumbre do futuro: um mundo onde você pode levar o ChatGPT com você pela internet para fazer perguntas, dar sugestões e realizar tarefas para você. Nesta publicação, vamos abordar um dos aspectos mais complexos da engenharia do produto: a maneira como transformamos o ChatGPT em um navegador que se torna mais útil à medida que é utilizado.

Para tornar o ChatGPT um verdadeiro copiloto para a web, foi necessário repensar toda a arquitetura de um navegador. Não à toa, separamos o Atlas do ambiente de execução do Chromium. Para isso, precisamos desenvolver uma nova maneira de integrar o Chromium que nos permitisse atingir nossos objetivos para o produto: inicialização instantânea, capacidade de resposta mesmo ao abrir várias abas e criação de uma base sólida para casos de uso agênticos.

O Chromium é um componente de construção natural. Ele oferece um mecanismo de última geração para a web, com um modelo de segurança robusto, credenciais de desempenho comprovadas e compatibilidade incomparável. Além disso, o Chromium é desenvolvido por uma comunidade global dedicada a aprimorá-lo continuamente. Isso tudo faz com que ele seja a opção mais comum para navegadores da web modernos para desktop.

Nossa talentosa equipe de design tinha metas ambiciosas para a experiência do usuário, incluindo animações ricas e efeitos visuais para recursos como o modo Agente. Isso exigiu que nossa equipe de engenharia empregasse as estruturas nativas mais modernas para nossa UI (SwiftUI, AppKit e Metal), em vez de simplesmente reformular a UX de código aberto do Chromium. Como resultado, a UI do Atlas é uma reconstrução abrangente de toda a UX do aplicativo.

Nós também tínhamos outras metas para o produto, como tempos de inicialização rápidos e suporte a centenas de abas que não prejudicassem o desempenho. Esses objetivos eram difíceis de alcançar com o Chromium original, que é rígido em muitos detalhes — como a sequência de inicialização, o modelo de threading e os modelos de guias. Consideramos a possibilidade de fazer alterações substanciais aqui, mas queríamos manter nosso conjunto de patches direcionados ao Chromium para que pudéssemos rapidamente integrar novas versões. Para garantir que nossa velocidade de desenvolvimento fosse acelerada ao máximo, precisávamos encontrar uma maneira diferente de integrar e impulsionar o tempo de execução do Chromium.

Um teste decisivo para nosso investimento técnico não era apenas que ele permitisse experimentação, iteração e entrega mais rápidas de novos recursos. Ele também precisava manter uma parte essencial da cultura de engenharia da OpenAI: entregar resultados já no primeiro dia. Por isso mesmo, cada novo profissional de engenharia realiza e incorpora uma pequena alteração na parte da tarde do seu primeiro dia. Precisávamos garantir que isso fosse possível, ainda que o Chromium pudesse levar horas para fazer a verificação e a compilação.

Nossa resposta a esses desafios foi construir uma nova camada arquitetônica que chamamos de OWL: OpenAI’s Web Layer, ou Camada da Web da OpenAI. OWL é a nossa integração do Chromium, que envolve a execução do processo do navegador Chromium fora do processo principal do aplicativo Atlas.

Funciona mais ou menos assim: o Chromium revolucionou os navegadores quando moveu as abas para processos separados. Nós levamos essa ideia adiante, removendo o Chromium do processo principal do aplicativo e colocando-o em uma camada isolada de serviço. Essa mudança traz uma série de benefícios:

• Um aplicativo mais simples e moderno: o Atlas foi desenvolvido quase inteiramente em SwiftUI e AppKit. Isso significa uma linguagem, um stack tecnológico e uma base de código limpa.
• Inicialização mais rápida: o Chromium é inicializado de forma assíncrona em segundo plano. Já o Atlas não espera: os pixels aparecem na tela quase instantaneamente.
• Isolamento contra falhas e travamentos: o Chromium é um mecanismo poderoso e complexo da web. Se o seu thread principal travar, o Atlas não trava. Se ele travar, o Atlas continua funcionando.
• Menos dores de cabeça ao mesclar códigos: como não dependemos tanto da interface open source do Chromium, a diferença do nosso código em relação ao Chromium upstream fica muito menor e mais fácil de manter.
• Iteração mais rápida: a maioria dos engenheiros não precisa compilar o Chromium localmente. O OWL é enviado internamente como um binário pré-compilado, o que significa que as compilações do Atlas levam minutos, não horas.

Como a maioria dos engenheiros da nossa equipe não trabalha regularmente com o Chromium a partir do código-fonte, o desenvolvimento acaba sendo muito mais rápido. Até mesmo os novos membros conseguem integrar alterações simples logo na primeira tarde de trabalho.

Em um nível elevado, o navegador Atlas é o Cliente OWL, e o processo do navegador Chromium é o Host OWL. Eles se comunicam por meio de IPC, especificamente no Mojo⁠(abre em uma nova janela), o sistema de passagem de mensagens do próprio Chromium. Criamos ligações personalizadas em Swift (e até em TypeScript) para o Mojo, permitindo que nosso app em Swift chame diretamente as interfaces do lado do host.

A biblioteca cliente da OWL oferece uma API pública simples em Swift, que abstrai vários conceitos essenciais disponibilizados pela camada de serviços do host.

• Sessão: configurar e controlar o host globalmente
• Perfil: gerenciar o estado do navegador para um perfil de usuário específico
• WebView: controlar e incorporar conteúdos individuais da web (por exemplo, renderizar, receber entrada, navegar, ampliar etc.)
• WebContentRenderer: enviar eventos de entrada para o pipeline de renderização do Chromium e receber respostas do renderizador
• LayerHost/Client: trocar informações de composição entre a UI e o Chromium

Há também uma ampla variedade de pontos de acesso de serviço para gerenciar recursos de alto nível, como favoritos, downloads, extensões e preenchimento automático.

As WebViews, que compartilham um espaço de apresentação mutuamente exclusivo no aplicativo cliente, são trocadas dinamicamente dentro de um contêiner de composição compartilhado. Por exemplo, a janela de um navegador geralmente tem um único contêiner compartilhado visível e, ao selecionar uma guia na barra de guias, a WebView dessa guia é movida para o contêiner. No lado do Chromium, esse contêiner corresponde a um gfx::AcceleratedWidget, que é, em última instância, suportado por um CALayer. Nós tornamos visível o ID de contexto dessa layer para o cliente, onde uma NSView faz a incorporação usando a API privada CALayerHost.

Casos especiais, como menus suspensos ou seletores de cores, são renderizados em widgets pop-up separados no Chromium e utilizam a mesma abordagem. Eles não têm um content::WebContents, mas têm sim um content::RenderWidgetHostView com seu próprio gfx::AcceleratedWidget. Portanto, o mesmo modelo de renderização delegada se aplica.O OWL mantém internamente a geometria das views sincronizada com o lado do Chromium, permitindo que o compositor de GPU seja atualizado de forma adequada e produza sempre conteúdos de layer com o tamanho e escala do dispositivo corretos.Também reutilizamos essa técnica para projetar de maneira seletiva os elementos da Views UI nativa do próprio Chromium no Atlas (o que também é útil para viabilizar rapidamente recursos como prompts de permissão, sem precisar criar substitutos do zero em SwiftUI). Essa técnica se baseia amplamente na infraestrutura existente do Chromium para aplicativos da web instaláveis no macOS.Eventos de entrada: captura e encaminhamentoA UI do Chromium traduz eventos da plataforma (como NSEvents do macOS) para o modelo WebInputEvent do Blink antes de encaminhá-los aos renderizadores. Porém, como o OWL executa o Chromium em um processo oculto, fazemos essa tradução nós mesmos na biblioteca do cliente em Swift e encaminhamos ao Chromium eventos já traduzidos.A partir daí, eles seguem o mesmo ciclo de vida que os eventos de entrada reais normalmente seguiriam para conteúdos da web. Isso inclui o retorno dos eventos ao cliente sempre que uma página indicar que não processou o evento. Quando isso acontece, nós ressintetizamos um NSEvent e damos ao resto do aplicativo a chance de processar a entrada.Modo Agente: casos especiaisO recurso de navegação agêntica do Atlas apresenta alguns desafios únicos para nossas abordagens de renderização, encaminhamento de eventos de entrada e armazenamento de dados.Nosso modelo de uso do computador espera uma única imagem da tela como entrada. Contudo, alguns elementos da UI, como menus suspensos , são renderizados fora dos limites da aba em janelas separadas. No modo Agente, nós compomos esses pop-ups de volta na imagem da página principal dentro das coordenadas corretas, para que o modelo veja o contexto completo em um único frame.

Para a entrada, aplicamos o mesmo princípio: os eventos gerados pelo agente são encaminhados diretamente para o renderizador, nunca pela camada privilegiada do navegador. Isso preserva o limite da área restrita, mesmo sob controle automatizado. Nós não queremos, por exemplo, que essa classe de eventos sintetize atalhos de teclado que façam o navegador realizar ações não relacionadas ao conteúdo da web que está sendo exibido.

A navegação pelo agente também pode ser executada em um contexto efêmero "deslogado". Em vez de compartilhar o perfil anônimo existente do usuário, o que poderia vazar dados, usamos a infraestrutura StoragePartition do Chromium para criar armazenamentos isolados na memória. Cada sessão de agente começa do zero e, quando termina, todos os cookies e dados do site são descartados. Você pode executar várias sessões de agente "deslogadas", cada uma em sua própria guia do navegador e totalmente isoladas umas das outras.

Nada disso seria possível sem a comunidade global do Chromium e seu incrível trabalho na construção de uma base para a web moderna. O OWL se baseia nessa fundação de uma maneira nova: separando o mecanismo do aplicativo, combinando uma plataforma da web de primeira classe com estruturas nativas modernas e revelando uma arquitetura mais rápida e flexível.

Ao repensar a forma como um navegador incorpora o Chromium, estamos abrindo espaço para novos tipos de experiências: inicializações mais suaves, UI mais rica, integração mais sólida com o restante do sistema operacional e um ciclo de desenvolvimento que acompanha a velocidade das ideias. Se esse tipo de desafio é do seu interesse, confira nossas vagas para trabalhar no Atlas como Engenheiro de Software, Atlas⁠⁠, Engenheiro de Software, iOS⁠⁠ e muito mais⁠⁠.

Experimente o Atlas: acesse chatgpt.com/atlas⁠(abre em uma nova janela)⁠.