Slik bygde vi OWL, den nye arkitekturen bak den ChatGPT‑baserte nettleseren Atlas

Av Ken Rockot, medlem av den tekniske staben, og Ben Goodger, teknisk leder, ChatGPT Atlas

I forrige uke lanserte vi ChatGPT Atlas⁠, en ny måte å surfe på nettet med ChatGPT ved din side. I tillegg til å være en fullt fungerende nettleser, gir Atlas et glimt inn i fremtiden: en verden hvor du kan ta ChatGPT med deg over hele internett for å stille spørsmål, gi forslag og gjøre oppgaver for deg. I dette innlegget forklarer vi et av de mest komplekse tekniske aspektene ved produktet: hvordan vi gjorde ChatGPT om til en nettleser som blir mer nyttig etter hvert som du bruker den.

Å gjøre ChatGPT til en ekte kopilot på nettet betydde å tenke nytt rundt hele arkitekturen til en nettleser: å skille Atlas fra Chromium-kjøremiljøet. Dette innebar en ny måte å integrere Chromium på som lar oss levere på produktmålene våre: umiddelbar oppstart, rask selv med flere åpne faner, og å skape et sterkt grunnlag for agent-bruksområder.

Chromium var en naturlig byggestein Den tilbyr en toppmoderne nettmotor med en robust sikkerhetsmodell, etablerte ytelseskrav og enestående nettkompatibilitet. I tillegg er den utviklet av et globalt felleskap som kontinuerlig forbedrer den. Det er en vanlig måte å bruke moderne nettlesere på.

Vårt dyktige designteam hadde ambisiøse mål for brukeropplevelsen, inkludert dynamiske animasjoner og visuelle effekter for funksjoner som agentmodus. Dette krevde at det tekniske teamet vårt utnyttet de mest moderne innebygde rammeverkene for brukergrensesnittet vårt (SwiftUI, AppKit og Metal), i stedet for å bare endre utseendet på den åpne kildekoden til Chromium UX. Derfor er Atlas’ brukergrensesnitt en omfattende gjenoppbygging av hele applikasjonens UX.

Vi hadde også andre produktmål, som rask oppstartstid og støtte for hundrevis av faner uten at det går utover ytelsen. Disse målene var utfordrende med kun Chromium, som har begrensninger rundt mange detaljer rundt oppstartssekvensen, trådmodellen og fanemodellene. Vi vurderte å gjøre betydelige endringer her, men vi ville holde oppdateringene mot Chromium målrettede så vi raskt kunne integrere nye versjoner. For å sikre at utviklingshastigheten ble maksimert, måtte vi finne en annen måte å integrere og drive Chromium-kjøremiljøet på.

En lakmustest for den tekniske investeringen vår var ikke bare at den ville muliggjøre raskere eksperimentering, iterasjon og levering av nye funksjoner – den ville også gjøre det mulig for oss å beholde en sentral del av OpenAIs tekniske kultur: levere på deg én. Alle nye ingeniører lager og implementerer en liten endring på slutten av deres første dag. Vi måtte sørge for at det var mulig, selv om Chromium kan ta timer å utforske og bygge.

Svaret på disse utfordringene var å bygge et nytt arkitektonisk lag vi kaller OWL: OpenAIs Web Layer. OWL er vår integrasjon av Chromium, som innebærer å kjøre Chromiums nettleserprosess utenfor hovedprosessen i Atlas-appen.

Tenk på det slik: Chromium revolusjonerte nettlesere ved å flytte faner til separate prosesser. Vi tar ideen videre ved å flytte Chromium ut av hovedapplikasjonsprosessen og til et isolert tjenestelag. Endringen skaper en rekke fordeler:

• En enklere, moderne app: Atlas er nesten utelukkende bygget i SwiftUI og AppKit. Ett språk, én teknologisk struktur, én ren kodebase.
• Raskere oppstart: Chromium starter asynkront i bakgrunnen. Atlas venter ikke – pikslene kommer på skjermen omtrent umiddelbart.
• Skjerming fra hakking og krasjing: Chromium er en kraftig og kompleks nettmotor. Dersom hovedtråden henger, gjør ikke Atlas det. Dersom den krasjer, holder Atlas det gående.
• Færre problemer med sammenslåing: Siden vi ikke bygger like mye på Chromiums åpen kildekode-grensesnitt, er forskjellen til oppstrøms Chromium mye mindre og enklere å opprettholde.
• Raskere iterasjon: De fleste ingeniører trenger aldri å bygge Chromium lokalt. OWL leveres internt som en forhåndsbygd binærfil, så å bygge med Atlas tar minutter, ikke timer.

Siden de fleste ingeniørene våre ikke bygger Chromium fra kildekoden jevnlig, kan utviklingen gå mye raskere – selv nye teammedlemmer kan lage enkle endringer den første dagen.

På overordnet nivå er Atlas-nettleseren OWL-klienten, og Chromium-nettleserprosessen er OWL-verten. De kommuniserer over IPC, nærmere bestemt Mojo⁠(åpnes i et nytt vindu), Chromiums eget system for meldingsoverføring. Vi skrev tilpassede Swift-bindinger (og til og med TypeScript) for Mojo, så Swift-appen kan kalle vertsgrensesnitt direkte.

Klientbiblioteket i OWL eksponerer et enkelt offentlig Swift-API, som abstraherer flere nøkkelkonsepter eksponert av vertens tjenestelag:

• Økt: konfigurere og kontrollere verten globalt
• Profil: administrere nettleserstatus for en bestemt brukerprofil
• WebView: kontrollere og bygge inn individuelt nettinnhold (f.eks. gjengivelse, inndata, naviger, zoom o.l.)
• WebContentRenderer: videresende inndatahendelser til Chromiums gjengivelsesprosess og få tilbakemelding fra gjengiveren
• LayerHost/Client: utveksle oppbygningssinformasjon mellom brukergrensesnittet og Chromium

Det er også et bredt utvalgt av tjenesteendepunkter for å håndtere funksjoner på høyt nivå, som bokmerker, nedlastinger, utvidelser og autofyll.

WebViews, som deler et presentasjonsområde som utelukker andre i klientappen, byttes inn og ut av en delt komposisjonsbeholder. For eksempel har et nettleservindu ofte én synlig delt beholder, og når du velger en fane på fanelinjen bytter fanens WebView til beholderen. På Chromium-siden tilsvarer beholderen en gfx::AcceleratedWidget som er støttet av en CALayer. Vi eksponerer lagets kontekst-ID for klienten, hvor en NSView bygger den inn ved å bruke det private CALayerHost-API-et.

Spesialtilfeller som -rullegardinmenyer eller fargevelgere, som Chromium gjengir i separate popup-widgeter, brukes samme tilnærming. De har ikke en content::WebContents, men de har en content::RenderWidgetHostView med sin egen gfx::AcceleratedWidget, så den samme delegerte gjengivelsesmodellen gjelder.

OWL holder visningsgeometrien synkronisert med Chromium-siden internt slik at GPU-komposisjonen kan oppdateres deretter og alltid kan produsere laginnhold i rett størrelse og enhetsskala.

Vi bruker denne teknikken på nytt for å selektivt projisere elementer av Chromiums egen innebygde Views UI til Atlas (det er også nyttig for å starte funksjoner som tillatelsesmeldinger raskt uten å bygge erstatninger fra bunn av i SwiftUI). Teknikken låner mye fra Chromiums eksisterende infrastruktur for installerbare nettapper på macOS.

Chromium UI oversetter plattformhendelser (som macOS NSEvents) til Blinks WebInputEvent-modell før den videresendes til gjengivere. Men siden OWL kjører Chromium i en skjult prosess, gjør vi oversettelsen selv i klientbiblioteket i Swift og videresender allerede oversatte hendelser nedover i Chromium.

Derfra følger de samme livssyklus som ekte inndatahendelser normalt ville fulgt for nettinnhold. Dette inkluderer å få hendelser returnert tilbake til klienten når en side indikerer at den ikke kunne håndtere hendelsen. Når dette skjer, syntetiserer vi en NSEvent og resten av appen mulighet til å håndtere inndataen.

Atlas’ agentdrevne nettleserfunksjon byr på noen unike utfordringer for våre tilnærminger til gjengivelse, videresending av inndatahendelser og datalagring.

Bruksdatamodellen vår forventer et enkelt bilde av skjermen som inndata. Men noen grensesnitt-elementer, som -rullegardinmenyer, gjengis utenfor fanens grenser i separate vinduer. I agentmodus setter vi popup-vinduene tilbake til hovedsidebildet med riktige koordinater slik at modellen ser hele konteksten i ett bilde.

For inndata bruker vi samme prinsipp: agentgenererte hendelser rutes direkte til gjengiveren, aldri gjennom det priviligerte nettleserlaget. Det bevarer sandkassegrensen selv under automatisert kontroll. For eksempel ønsker vi ikke at denne hendelsesklassen skal syntetisere hurtigtaster som får nettleseren til å gjøre ting som ikke angår nettinnholdet som vises.

Agentnettlesing kan også kjøre i en kortvarig «utlogget»-kontekst. I stedet for å dele brukerens eksisterende inkognitoprofil, som kan lekke tilstand, bruker vi Chromiums StoragePartition-infrastruktur til å lage isolerte minnelagre. Hver agentøkt starter på nytt, og når den avsluttes blir alle informasjonskapsler og nettstedsdata forkastet. Du kan kjøre flere «utlogget»-agentøkter, hver i sin egen nettleserfane, og hver fullstendig isolert fra hverandre.

Dette ville ikke vært mulig uten det globale Chromium-fellesskapet og deres fantastiske arbeid for å bygge et grunnlag for det moderne nettet. OWL bygger på det grunnlaget på en ny måte: kobler motoren fra appen, blander en nettplattform i verdensklasse med moderne innebygde rammeverk og låser opp en raskere, mer fleksibel arkitektur.

Ved å tenke nytt rundt hvordan en nettleser bruker Chromium skaper vi rom for nye opplevelser: raskere oppstart, rikere brukergrensesnitt, tettere integrasjon med resten av operativsystemet og en utvikling som beveger seg i takt med ideer. Om dette høres ut som din type utfordring, kan du sjekke ut våre ledige stillinger for å jobbe med Atlas som en Programvareingeniør, Atlas⁠, Programvareingeniør, iOS⁠ og flere⁠.

Prøv Atlas på chatgpt.com/atlas⁠⁠(åpnes i et nytt vindu).