Så här byggde vi OWL – den nya arkitekturen bakom vår ChatGPT‑baserade webbläsare Atlas

Av Ken Rockot, medlem av det tekniska teamet och Ben Goodger, teknisk ansvarig, ChatGPT Atlas

Förra veckan lanserade vi ChatGPT Atlas⁠, ett nytt sätt att surfa på webben med ChatGPT vid din sida. Förutom att vara en fullfjädrad webbläsare erbjuder Atlas en glimt in i framtiden: en värld där du kan ta med dig ChatGPT över internet för att ställa frågor, ge förslag och slutföra uppgifter åt dig. I det här inlägget presenterar vi upp en av produktens mest komplexa tekniska aspekter: hur vi förvandlade ChatGPT till en webbläsare som blir mer användbar med tiden.

För att göra ChatGPT till en riktig medpilot för webben fick vi omformulera webbläsarens hela arkitektur och separera Atlas från Chromium-körtiden. Detta innebar att utveckla ett nytt sätt att integrera Chromium som gör att vi kan leverera på våra produktmål: omedelbar start, responsivitet även när du öppnar flera flikar och skapande av en stark grund för agentanvändningsfall.

Chromium var en naturlig byggsten. Den tillhandahåller en toppmodern webbmotor med en robust säkerhetsmodell, etablerad prestanda och oöverträffad webbkompatibilitet. Dessutom är den utvecklad av en global community som kontinuerligt förbättrar den. Det är ett naturligt val för webbläsare för stationära datorer.

Vårt begåvade designteam hade ambitiösa mål för användarupplevelsen, inklusive rika animationer och visuella effekter för funktioner som Agentläge. Detta krävde att vårt teknikteam använde de nyaste ramverken för vårt användargränssnitt (SwiftUI, AppKit och Metal), istället för att bara omdesigna den öppna källkodsversionen av Chromiums användarupplevelse. Som ett resultat är Atlas användargränssnitt en omfattande ombyggnad av hela applikationens användarupplevelse.

Vi hade också andra produktmål som snabba starttider och stöd för hundratals flikar, utan att försämra prestandan. Dessa mål var utmanande att uppnå med Chromium direkt ur lådan, som är påstridig om många detaljer från startsekvensen, trådmodellen och flikmodellerna. Vi övervägde att göra betydande förändringar här, men vi ville hålla våra patchar mot Chromium riktade så att vi snabbt kunde integrera nya versioner. För att säkerställa att vår utvecklingstakt kunde påskyndas så mycket som möjligt behövde vi komma på ett annat sätt att integrera och driva Chromium-körtiden.

En indikator för vår tekniska investering var inte bara att den skulle möjliggöra snabbare experiment, iteration och leverans av nya funktioner – den skulle också göra det möjligt för oss att upprätthålla en central del av OpenAI:s tekniska kultur: leverans från dag ett. Varje ny utvecklare gör och sammanfogar en liten ändring på eftermiddagen sin första dag. Vi behövde se till att detta var möjligt även om Chromium kan ta timmar att kontrollera och bygga.

Vårt svar på dessa utmaningar var att bygga ett nytt arkitektoniskt lager som vi kallar OWL: OpenAI:s webblager. OWL är vår integration av Chromium, vilket innebär att Chromiums webbläsarprocess körs utanför Atlas-appens huvudprocess.

Så här kan man se det: Chromium revolutionerade webbläsare genom att flytta flikar till separata processer. Vi arbetar vidare på den idén genom att flytta ut Chromium från den huvudsakliga applikationsprocessen och in i ett isolerat servicelager. Denna förändring ger tillgång till en mängd fördelar:

• En enklare och modernare app: Atlas är nästan helt byggd i SwiftUI och AppKit. Ett språk, en teknikstack, en tydlig kodbas.
• Snabbare start: Chromium startar asynkront i bakgrunden. Atlas väntar inte – pixlar visas på skärmen nästan omedelbart.
• Isolering från dålig kvalitet och krascher: Chromium är en kraftfull och komplex webbmotor. Om dess huvudtråd hänger upp sig, gör inte Atlas det. Om den kraschar kör Atlas vidare.
• Färre problem med sammanfogningar: Eftersom vi inte använder oss av Chromiums användargränssnitt med öppen källkod för att bygga blir skillnaden, jämfört med uppströms Chromium, att den är mindre och enklare att underhålla.
• Snabbare iteration: De flesta utvecklare behöver inte bygga Chromium lokalt. OWL levereras internt som en förbyggd binärfil, så att Atlas-byggen tar några minuter, inte flera timmar.

Eftersom de flesta utvecklarna i vårt team inte bygger Chromium från källkoden kan utvecklingen gå mycket snabbare – även nya teammedlemmar kan sammanfoga enkla ändringar redan på sin första arbetsdag.

På en övergripande nivå är Atlas-webbläsaren OWL-klienten och Chromium-webbläsarprocessen är OWL-värden. De kommunicerar via IPC, närmare bestämt Mojo⁠(öppnas i ett nytt fönster), Chromiums eget meddelandeöverföringssystem. Vi skrev anpassade Swift-bindningar (och TypeScript-bindningar) för Mojo, så att vår Swift-app kan anropa gränssnitt direkt på värdsidan.

OWL-klientbiblioteket exponerar ett enkelt offentligt Swift API, som sammanfattar flera viktiga koncept som exponeras av värdens servicelager:

• Session: Konfigurerar och styr värden globalt
• Profile: Hanterar webbläsarstatus för en specifik användarprofil
• WebView: Kontrollerar och bäddar in individuellt webbinnehåll (t.ex. rendering, inmatning, navigering och zoomning)
• WebContentRenderer: Vidarebefordrar inmatningshändelser till Chromiums renderingspipeline och får feedback från renderaren
• LayerHost/Client: Utbyter kompositionsinformation mellan användargränssnittet och Chromium

Det finns också ett brett utbud av serviceslutpunkter för att hantera funktioner på hög nivå som bokmärken, nedladdningar, tillägg och automatisk ifyllning.

WebViews, som delar ett ömsesidigt exklusivt presentationsutrymme i klientappen, byts in och ut ur en delad programbehållare. Till exempel har ett webbläsarfönster ofta en enda delad programbehållare synlig och om du väljer en flik i flikfältet byts flikens WebView ut mot behållaren. På Chromium-sidan motsvarar den här programbehållaren en gfx::AcceleratedWidget som i slutändan backas upp av en CALayer. Vi exponerar lagrets kontext-ID för klienten, där en NSView bäddar in det med hjälp av det privata CALayerHost API:et.

Specialfall som -rullgardinsmenyer eller färgväljare, som Chromium renderar i separata popup-widgetar, använder samma tillvägagångssätt. De har inte en content::WebContents, men de har en content::RenderWidgetHostView med sin egen gfx::AcceleratedWidget, så samma delegerade renderingsmodell gäller.Internt håller OWL vygeometrin synkroniserad med Chromium-sidan, så GPU-kompositionen kan uppdateras därefter och alltid producera lagerinnehåll med rätt storlek och enhetsskala.Vi återanvänder även den här tekniken för att på selektiv väg projicera element från Chromiums eget inbyggda Views-gränssnitt i Atlas (detta är också användbart för att snabbt starta funktioner som behörighetsprompter utan att behöva bygga ersättningar från grunden i SwiftUI). Den här tekniken lånar i hög grad från Chromiums befintliga infrastruktur för webbappar som kan installeras på macOS.Indatahändelser: Knäckning och vidarebefordranChromiums gränssnitt översätter plattformshändelser (som macOS NSEvents) till Blinks WebInputEvent-modell innan de vidarebefordras till renderare. Men eftersom OWL kör Chromium i en dold process gör vi den översättningen själva i Swift-klientbiblioteket och vidarebefordrar redan översatta händelser ner till Chromium.Därifrån följer de samma livscykel som verkliga indatahändelser normalt skulle följa för webbinnehåll. Detta inkluderar att händelser returneras tillbaka till klienten närhelst en sida indikerar att den inte hanterade händelsen. När detta händer syntetiserar vi en NSEvent på nytt och ger resten av appen en chans att hantera indatan.Agentläge: SpecialfallAtlas agentfunktion för webbsökning innebär några unika utmaningar för våra metoder för rendering, vidarebefordran av indatahändelser och datalagring.Vår datoranvändningsmodell förväntar sig en enda bild av skärmen som indata. Men vissa UI-element, som -rullgardinsmenyer, renderas utanför flikens gränser i separata fönster. I agentläget sätter vi tillbaka dessa popup-fönster till huvudsidans bild med korrekta koordinater så att modellen ser hela kontexten i en bildruta.

För indata tillämpar vi samma princip: agentgenererade händelser dirigeras direkt till renderaren, aldrig genom det privilegierade webbläsarlagret. Det bevarar sandlådans gränser även under automatiserad kontroll. Till exempel vill vi inte att den här händelseklassen ska syntetisera kortkommandon som gör att webbläsaren gör saker som inte är relaterade till det webbinnehåll som visas.

Webbsökning med agenter kan också köras i ett tillfälligt ”utloggat” kontext. Istället för att dela användarens befintliga inkognitoprofil, som kan läcka status, använder vi Chromiums StoragePartition-infrastruktur för att skapa isolerade minneslager. Varje agentsession börjar på nytt, och när den slutar kasseras alla cookies och webbplatsdata. Du kan köra flera utloggade agentsessioner, var och en i en egen webbläsarflik och helt isolerad från de andra.

Inget av detta skulle vara möjligt utan den globala Chromium-communityn och deras enastående arbete med att bygga grunden för den moderna webben. OWL bygger vidare på den grunden på ett nytt sätt: genom att frikoppla motorn från appen, kombinera en webbplattform i världsklass med moderna, rena ramverk och ge tillgång till en snabbare och mer flexibel arkitektur.

Genom att ompröva hur en webbläsare hanterar Chromium skapar vi utrymme för nya typer av upplevelser: en smidigare start, ett rikare användargränssnitt, en tätare integration med resten av operativsystemet och en utvecklingsloop som rör sig i idéernas hastighet. Om det låter som en utmaning i din stil, kolla in våra lediga jobb på Atlas som Programvaruingenjör, Atlas⁠, Programvaruingenjör, iOS,⁠ med flera⁠.

Prova Atlas på chatgpt.com/atlas⁠⁠(öppnas i ett nytt fönster).