Sådan byggede vi OWL, den nye arkitektur bag vores ChatGPT‑baserede browser, Atlas

Af Ken Rockot, teknisk medarbejder og Ben Goodger, Head of Engineering, ChatGPT Atlas

Sidste uge lancerede vi ChatGPT Atlas⁠, en ny måde at søge på internettet på med ChatGPT ved din side. Udover at være en webbrowser med alle tilhørende funktioner giver Atlas et glimt af fremtiden: en verden, hvor du kan tage ChatGPT med dig på internettet til at stille spørgsmål, lave forslag og fuldføre opgaver for dig. I dette opslag pakker vi et af produktets mest komplicerede tekniske aspekter op: hvordan vi lavede ChatGPT om til en browser, der bliver mere nyttig hen ad vejen.

At gøre ChatGPT til en ægte co-pilot for internettet betød en gentænkning af hele arkitekturen bag en browser: adskillelsen af Atlas fra Chromium-runtime-modulet. Det indebar at udvikle en ny måde til integration af Chromium, der gør det muligt for os at nå vores produktmål: omgående start, hurtig reaktion selv ved flere åbne faner og skabelse af et stærkt fundament for agentiske use cases.

Chromium var den naturlige hjørnesten. Den indeholder en avanceret webmotor med en robust sikkerhedsmodel, etablerede præstationskrav og uovertruffen webkompatibilitet. Desuden er den udviklet af et globalt fællesskab, der kontinuerligt forbedrer den. Den er et naturligt valg for webbrowsere på moderne computere.

Vores talentfulde designteam havde sat sig ambitiøse mål for brugeroplevelsen, der introducerede bedre animationer og visuelle effekter for funktioner som f.eks. Agenttilstand. Det krævede, at vores tekniske team udnyttede de mest moderne integrerede frameworks til vores UI (SwiftUI, AppKit og Metal) i stedet for blot at bygge på open source Chromium UX. Derfor er Atlas' UI en omfattende ombygning af hele programmets UX.

Vi havde desuden andre mål for produktet som f.eks. hurtig start og understøttelse af hundredvis af faner, uden at det gik ud over ydeevnen. De mål var en udfordring at opnå med Chromium som standard, som har sine egne måder at håndtere mange detaljer på, fra boot-rækkefølgen over trådmodellen og til fanemodeller. Vi overvejede at foretage omfattende ændringer her, men vi ville holde vores rettelser af Chromium målrettede, så vi hurtigt kunne integrere nye versioner. For at sikre, at udviklingens fremdrift var maksimal, blev vi nødt til at finde på en anden måde at integrere og køre Chromium-runtime.

Lakmusprøven for vores tekniske investering var ikke kun, at det ville muliggøre hurtigere eksperimentering, justering og leverance af nye funktioner, men også at det ville gøre os i stand til at bibeholde en væsentlig del af OpenAI's udviklingskultur: levering på dag ét. Alle nye udviklere laver og fusionerer en mindre ændring om eftermiddagen på deres første dag. Vi var nødt til at sikre os, at det var muligt, selv om Chromium kan tage timer at gennemgå og bygge.

Vores svar på udfordringerne blev at bygge et nyt arkitekturlag, som vi kalder OWL: OpenAI’s Web Layer. OWL er vores integration med Chromium, som medfører at køre Chromiums browserproces uden for den primære proces for Atlas-appen.

Tænk på det som følgende: Chromium revolutionerede browsere ved at flytte faner til separate processer. Vi tager idéen et skridt længere ved at flytte selve Chromium ud af den primære programproces og ind i et isoleret tjenestelag. Den flytning låser op for mange fordele:

• En enklere, moderne app: Atlas er bygget næsten udelukkende i SwiftUI og AppKit. Ét sprog, én teknisk stack, én ren kodebase.
• Hurtigere start: Chromiun booter asynkront i baggrunden. Atlas venter ikke – pixels rammer skærmen næsten omgående.
• Isoleret fra problemer og nedbrud: Chromium er en kraftfuld og kompleks webmotor. Hvis dens primære tråd hænger, fortsætter Atlas. Hvis den går ned, forbliver Atlas aktiv.
• Færre fusionsproblemer: Fordi vi ikke bygger på så meget af Chromiums open source-UI, er vores forskel i forhold til efterfølgende Chromium-versioner meget mindre og nemmere at vedligeholde.
• Hurtigere løbende justering: De fleste udviklere har aldrig behov for at bygge Chromium lokalt. OWL leveres integreret som en forhåndsbygget primærfil, så Atlas-versioner tager minutter og ikke timer.

Da de fleste udviklere i vores team ikke regelmæssigt bygger Chromium baseret på kilden, kan udviklingen ske meget hurtigere – selv nye medlemmer af teamet kan fusionere enkle ændringer på deres første dag.

På et højt niveau er Atlas-browseren OWL-klienten, og Chromium-browserprocessen er OWL-værten. De kommunikerer over IPC, specielt via Mojo⁠(åbner i et nyt vindue), Chromiums eget system til overførsel af meddelelser. Vi skrev tilpassede Swift-bindinger (og endda TypeScript) til Mojo, så vores Swift-app kan kalde grænseflader på værtssiden direkte.

OWL-klientens bibliotek eksponerer en enkelt offentligt Swift-API, som abstraherer adskillige nøglebegreber, der er eksponeret af værtens servicelag:

• Session: Konfigurer og kontrollér værten globalt
• Profil: Administrer browsertilstand for en specifik brugerprofil
• WebView: Kontrollér og indlejr individuelt webindhold (f.eks. gengivelse, input, navigering, zoom osv.)
• WebContentRenderer: Før input-begivenheder ind i Chromiums gengivelses-pipeline, og få feedback fra gengivelsen.
• LayerHost/Client: Udveksl kompositionsoplysninger mellem brugergrænsefladen og Chromium

Der findes også en lang række tjenesteendepunkter til administration af overordnede funktioner som f.eks. bogmærker, downloads, udvidelser og automatisk udfyldning.

WebViews, som deler en gensidigt eksklusiv præsentationsplads i klient-appen, skiftes ind og ud af en delt kompositions-container. F.eks har et browservindue ofte en enkelt delt container synlig, og valget af en fane på fanelinjen flytter den fanes WebView ind i containeren. På Chromium-siden svarer containeren til en gfx::AcceleratedWidget, som i sidste ende understøttes af et CALayer. Vi eksponerer lagets kontekst-id for klienten, hvor en NSview indlejrer det ved hjælp af den private CALayerHost-API.

Specialtilfælde som f.eks. -rullemenuer eller farvevælgere, som Chromium gengiver i separate pop op-widgets, bruger samme tilgang. De har ikke en content::WebContents, men de har en content::RenderWidgetHostView med deres egen gfx::AcceleratedWidget, så der anvendes samme distribuerede gengivelsesmodel.Internt holder OWL visningsgeometrien synkroniseret med Chromium-siden, så GPU-kompositionen kan opdateres derefter og altid kan producere indhold på laget i korrekt størrelse og skala for enheden.Vi genbruger desuden den teknik til at projicere udvalgte projektelementer i Chromiums eget indbyggede Views UI ind i Atlas (det er også nyttigt til hurtig bootstrapping af funktioner som tilladelsesforespørgsler uden at bygge erstatninger forfra i SwiftUI). Den teknik låner heftigt fra Chromiums eksisterende infrastruktur til installation af web-apps på macOS.Input-begivenheder: Nedbrydning og videresendelseChromiums UI oversætter platformsbegivenheder (som f.eks. macOS NSEvents) til Blinks WebInputEvent-model, før de videresendes til gengivelse. Men da OWL kører Chromium i en skjult proces, oversætter vi selv i Swift-klientbiblioteket og videresender de allerede oversatte begivenheder til Chromium.Derfra følger de samme livscyklus, som reelle input-begivenheder normalt ville følge for webindhold. Det omfatter begivenheder, der returneres tilbage til klienten, når en side indikerer, at den ikke håndterede begivenheden. Når det sker, syntetiserer vi en NSEvent igen og giver resten af appen en chance for at håndtere det pågældende input.Agenttilstand: SpecialtilfældeAtlas' agentiske browsingfunktion indeholder nogle unikke udfordringer for vores tilgang til at gengive, videresende input-begivenheder og opbevaring af data.Vores computermodel forventer et enkelt billede af skærmen som input. Men visse UI-elementer som f.eks. -rullemenuer, gengives uden for fanens grænser i separate vinduer. I Agenttilstand sammensætter vi disse pop op-vinduer tilbage i det primære sidebillede ved de korrekte koordinater, så modellen ser den fulde kontekst i én ramme.

Vi bruger samme princip for input: agent-genererede begivenheder føres direkte til gengivelsen og aldrig gennem det privilegerede browserlag. Det bevarer sandkassegrænsen selv under automatiseret styring. Vi ønsker f.eks. ikke, at den klasse af begivenheder syntetiserer tastaturgenveje, der får browseren til at gøre ting uden relation til det viste webindhold.

Agent-browsing kan også køre i en midlertidig "logget ud"-kontekst. I stedet for at dele brugerens eksisterende inkognito-profil, som kunne lække oplysninger om tilstand, bruger vi Chromiums StoragePartition-infrastruktur til at starte isolerede lagringssteder i hukommelsen. Hver agentsession begynder forfra, og når den slutter, slettes alle cookies og webstedsdata. Du kan køre flere "logget ud"-agentsessioner i hver sin browserfane, og alle er helt isoleret fra hinanden.

Intet af ovenstående ville være muligt uden det globale Chromium-fællesskab og deres arbejde med at bygge et fundament for det moderne internet. OWL bygger på det fundament på en ny måde: afkobling af motoren fra appen, fusionering af en webplatform i verdensklasse med moderne integrerede frameworks og brug af en hurtigere og mere fleksibel arkitektur.

Ved at gentænke, hvordan en browser opbevarer Chromium skaber vi et nyt rum for nye typer oplevelser: hurtigere start, mere avanceret UI, tættere integration med resten af OS'et og en udviklingsløkke, der bevæger sig med samme hastighed som idéer. Hvis det lyder som udfordringer for dig, så tag et kig på vores ledige stillinger hos Atlas som softwareudvikler, Atlas⁠, softwareudvikler, iOS⁠ med flere⁠.

Prøv Atlas på chatgpt.com/atlas⁠⁠(åbner i et nyt vindue).