Com hem construït OWL, la nova arquitectura darrere d’Atlas, el nostre navegador basat en ChatGPT

Per Ken Rockot, membre de l’equip tècnic, i Ben Goodger, cap d’enginyeria de ChatGPT Atlas

La setmana passada, vam llançar ChatGPT Atlas⁠, una nova manera de navegar pel web amb ChatGPT al teu costat. A més de ser un navegador web amb totes les funcionalitats, Atlas ofereix una mirada al futur: un món on pots portar ChatGPT amb tu per internet per fer preguntes, rebre suggeriments i completar tasques per tu. En aquesta entrada, desglossem un dels aspectes d’enginyeria més complexos del producte: com vam convertir ChatGPT en un navegador que esdevé més útil a mesura que l’utilitzes.

Fer de ChatGPT un autèntic copilot del web implicava reimaginar tota l’arquitectura d’un navegador: separar Atlas del runtime de Chromium. Això va comportar desenvolupar una nova manera d’integrar Chromium que ens permet assolir els objectius del producte: inici instantani, capacitat de resposta fins i tot quan obres més pestanyes, i crear una base sòlida per a casos d’ús agentics.

Chromium era una peça bàsica natural. Proporciona un motor web d’última generació amb un model de seguretat robust, un rendiment contrastat i una compatibilitat web inigualable. A més, el desenvolupa una comunitat global que el millora contínuament. És una opció habitual per als navegadors web d’escriptori moderns.

El nostre talentós equip de disseny tenia objectius ambiciosos per a l’experiència d’usuari, incloent-hi animacions riques i efectes visuals per a funcions com el mode agent. Això va requerir que el nostre equip d’enginyeria aprofités els frameworks natius més moderns per a la nostra UI (SwiftUI, AppKit i Metal), en lloc de limitar-se a remaquillar l’experiència d’usuari de Chromium de codi obert. Com a resultat, la UI d’Atlas és una reconstrucció completa de tota l’experiència d’usuari de l’aplicació.

També teníem altres objectius de producte, com ara temps d’inici ràpids i compatibilitat amb centenars de pestanyes sense penalitzar el rendiment. Aquests objectius eren difícils d’aconseguir amb Chromium tal com ve, ja que imposa moltes decisions sobre detalls com la seqüència d’arrencada, el model de fils i els models de pestanyes. Vam considerar fer-hi canvis substancials, però volíem mantenir el nostre conjunt de pedaços sobre Chromium ben acotat per poder integrar ràpidament les noves versions. Per garantir que la nostra velocitat de desenvolupament s’accelerés al màxim, necessitàvem trobar una altra manera d’integrar i controlar el runtime de Chromium.

Una prova clau de la nostra inversió tècnica no era només que permetria experimentar, iterar i lliurar funcionalitats noves més de pressa, sinó també que ens permetria mantenir una part central de la cultura d’enginyeria d’OpenAI: publicar el primer dia. Cada nou enginyer fa i fusiona un petit canvi la tarda del seu primer dia. Havíem d’assegurar-nos que això continués sent possible tot i que Chromium pugui trigar hores a descarregar-se i compilar-se.

La nostra resposta a aquests reptes va ser construir una nova capa arquitectònica que anomenem OWL: OpenAI’s Web Layer. OWL és la nostra integració de Chromium, que implica executar el procés de navegador de Chromium fora del procés principal de l’app Atlas.

Pensa-hi així: Chromium va revolucionar els navegadors en moure les pestanyes a processos separats. Nosaltres portem aquesta idea més enllà traslladant el mateix Chromium fora del procés principal de l’aplicació i cap a una capa de servei aïllada. Aquest canvi desbloqueja una cascada d’avantatges:

• Una app més simple i moderna: Atlas està construït gairebé del tot amb SwiftUI i AppKit. Un llenguatge, una pila tecnològica, una base de codi neta.
• Inici més ràpid: Chromium arrenca de manera asíncrona en segon pla. Atlas no espera: els píxels apareixen a la pantalla gairebé a l’instant.
• Aïllament davant bloquejos i fallades: Chromium és un motor web potent i complex. Si el seu fil principal es penja, Atlas no. Si falla, Atlas es manté actiu.
• Menys maldecaps amb les fusions: Com que no construïm sobre tanta part de la UI de codi obert de Chromium, la nostra diferència respecte al Chromium upstream és molt més petita i més fàcil de mantenir.
• Iteració més ràpida: La majoria dels enginyers no necessiten compilar Chromium localment. OWL es distribueix internament com un binari precompilat, així que les compilacions d’Atlas triguen minuts i no hores.

Com que la majoria dels enginyers del nostre equip no compilen Chromium des del codi font de manera habitual, el desenvolupament pot avançar molt més ràpid; fins i tot els nous membres de l’equip poden fusionar canvis simples la seva primera tarda.

A grans trets, el navegador Atlas és el client OWL, i el procés de navegador de Chromium és l’host OWL. Es comuniquen mitjançant IPC, concretament Mojo⁠(s'obre en una finestra nova), el propi sistema de pas de missatges de Chromium. Vam escriure enllaços personalitzats de Swift (i fins i tot de TypeScript) per a Mojo, de manera que la nostra app en Swift pot cridar directament interfícies del costat host.

La biblioteca client d’OWL exposa una API pública senzilla de Swift, que abstrau diversos conceptes clau exposats per la capa de servei de l’host:

• Session: Configura i controla globalment l’host
• Profile: Gestiona l’estat del navegador per a un perfil d’usuari concret
• WebView: Controla i incrusta continguts web individuals (p. ex., renderització, entrada, navegació, zoom, etc.)
• WebContentRenderer: Reenvia esdeveniments d’entrada al pipeline de renderització de Chromium i rep retroalimentació del renderitzador
• LayerHost/Client: Intercanvia informació de composició entre la UI i Chromium

També hi ha una àmplia gamma de punts finals de servei per gestionar funcions d’alt nivell com ara marcadors, descàrregues, extensions i emplenament automàtic.

Els WebViews, que comparteixen un espai de presentació mútuament excloent a l’app client, entren i surten d’un contenidor de composició compartit. Per exemple, una finestra del navegador sovint té un únic contenidor compartit visible i, en seleccionar una pestanya a la barra de pestanyes, el WebView d’aquella pestanya s’intercanvia dins del contenidor. Al costat de Chromium, aquest contenidor correspon a un gfx::AcceleratedWidget que en última instància es recolza en un CALayer. Exposem l’ID de context d’aquesta capa al client, on un NSView l’incrusta mitjançant l’API privada CALayerHost.

Casos especials com els desplegables de <select> o els selectors de color, que Chromium renderitza en widgets emergents separats, utilitzen el mateix enfocament. No tenen un content::WebContents, però sí que tenen un content::RenderWidgetHostView amb el seu propi gfx::AcceleratedWidget, de manera que s’hi aplica el mateix model de renderització delegada.

Internament, OWL manté la geometria de la vista sincronitzada amb el costat de Chromium, perquè el compositor de GPU es pugui actualitzar en conseqüència i pugui produir sempre continguts de capa amb la mida correcta i l’escala de dispositiu adequada.

També reutilitzem aquesta tècnica per projectar selectivament elements de la pròpia UI nativa Views de Chromium dins d’Atlas (això també és útil per posar en marxa ràpidament funcions com ara sol·licituds de permisos sense haver de construir substituts des de zero en SwiftUI). Aquesta tècnica pren molt de la infraestructura existent de Chromium per a apps web instal·lables a macOS.

La UI de Chromium tradueix esdeveniments de plataforma (com els NSEvents de macOS) al model WebInputEvent de Blink abans de reenviar-los als renderitzadors. Però com que OWL executa Chromium en un procés ocult, fem nosaltres mateixos aquesta traducció dins la biblioteca client en Swift i reenviem a Chromium els esdeveniments ja traduïts.

A partir d’aquí, segueixen el mateix cicle de vida que seguirien normalment els esdeveniments d’entrada reals per al contingut web. Això inclou que els esdeveniments es retornin al client sempre que una pàgina indiqui que no els ha gestionat. Quan això passa, tornem a sintetitzar un NSEvent i donem a la resta de l’app l’oportunitat de gestionar l’entrada.

La funció de navegació agentica d’Atlas planteja alguns reptes singulars per als nostres enfocaments de renderització, reenviament d’esdeveniments d’entrada i emmagatzematge de dades.

El nostre model d’ús de l’ordinador espera una sola imatge de la pantalla com a entrada. Però alguns elements de la UI, com els desplegables de <select> , es renderitzen fora dels límits de la pestanya en finestres separades. En mode agent, recomponem aquestes finestres emergents dins de la imatge principal de la pàgina a les coordenades correctes perquè el model vegi tot el context en un sol fotograma.

Per a l’entrada, apliquem el mateix principi: els esdeveniments generats per l’agent s’encaminen directament al renderitzador, mai a través de la capa privilegiada del navegador. Això preserva el límit del sandbox fins i tot sota control automatitzat. Per exemple, no volem que aquesta classe d’esdeveniments sintetitzi dreceres de teclat que facin que el navegador faci coses no relacionades amb el contingut web que es mostra.

La navegació amb agent també pot funcionar en un context efímer «desconnectat». En lloc de compartir el perfil d’incògnit existent de l’usuari, que podria filtrar estat, utilitzem la infraestructura StoragePartition de Chromium per crear magatzems aïllats en memòria. Cada sessió d’agent comença de zero i, quan acaba, totes les cookies i dades dels llocs s’eliminen. Pots executar múltiples sessions d’agent «desconnectades», cadascuna a la seva pròpia pestanya del navegador i totes completament aïllades entre si.

Res d’això seria possible sense la comunitat global de Chromium i la seva feina increïble construint una base per al web modern. OWL construeix sobre aquesta base d’una manera nova: desacoblant el motor de l’app, combinant una plataforma web de primer nivell amb frameworks natius moderns i obrint una arquitectura més ràpida i flexible.

Repensant com un navegador allotja Chromium, estem creant espai per a nous tipus d’experiències: inicis més fluids, una UI més rica, una integració més estreta amb la resta del sistema operatiu i un cicle de desenvolupament que es mou a la velocitat de les idees. Si això et sembla el teu tipus de repte, consulta les nostres vacants per treballar a Atlas com a Enginyer/a de programari, Atlas⁠, Enginyer/a de programari, iOS⁠ i més⁠.

Prova Atlas a chatgpt.com/atlas⁠⁠(s'obre en una finestra nova).