Sådan bygger vi fælles arbejdsområder til mennesker og agenter

Vi har for nylig lanceret funktionen projekter, hvor mennesker og agenter arbejder sammen om langvarige opgaver i Perplexity Computer. Hvert projekt ligger på et fælles arbejdsområde med et filsystem, der opsamler kontekst på tværs af sessioner, agenter og brugere. Samarbejde med mange deltagere, der strækker sig over måneder, kræver persistens, samtidighed og sporbarhed:

• Persistens: Arbejdet skal være varigt ud over den enkelte agentsession eller sandbox, så det kan videreføres af den samme bruger eller agent, og alle samarbejdspartnere kan bygge videre på det.
• Samtidighed: Flere brugere i det samme projekt kan hver især have flere agenter, der foretager redigeringer parallelt og fører en fælles tilstand fremad i stedet for at overskrive hinanden.
• Sporbarhed: Både brugere og agenter skal kunne se historikken, så de kan tjekke, hvem der har ændret hvad siden deres seneste session, uden at skulle læse hele projektet igen, og rulle redigeringer tilbage efter behov.

Disse udfordringer virker velkendte for softwareudviklere. Git-forges opstod for årtier siden for at imødekomme netop disse krav: en hostet tjeneste, der kombinerer versionsstyring med samarbejdsfunktioner, så mange bidragydere kan samles om én fælles sandhed. Filsystemet bag projekter er netop sådan en Git-forge, bygget til samarbejde mellem mennesker og agenter og mellem agenter indbyrdes.

Udvid

Arkitektur

Git håndterer allerede persistens, samtidighed og sporbarhed. Git identificerer hver fil ud fra dens indhold, så uændrede filer kun gemmes én gang, og gemte kopier aldrig bliver forældede. Hvert commit gemmer alle opdaterede filer på én gang, så samarbejdspartnere aldrig ser en halvfærdig tilstand. Når to skrivere kolliderer, kan den, der tabte, anvende sine ændringer igen på den nye version og prøve igen. Kæden af commits viser, hvem der ændrede hvad, og gør det nemt at gendanne tidligere versioner. Det, agenter ikke har brug for, er resten af en forge bygget til mennesker, såsom gennemgangsskærme, branch-administration og notifikationer.

Vores arkitektur kører hele processen i skyen og understøtter alle former for vidensarbejde ud over kodning. Hvert Computer-projekt understøttes af et Git-repository, der betjenes af 5 komponenter:

• CLI'en vedligeholder lokale checkouts, synkroniserer opdateringer og indsender agentens ændringer i hver sandbox.
• Kontrolplanet finder projektets repository og udsteder kortlivede legitimationsoplysninger til at få adgang til det.
• Git-tjenesten sender repositorydata til sandboxe, modtager deres indsendelser og afgør, hvilken indsendelse der bliver det senest accepterede commit.
• AWS S3-baseret lager gemmer repositorydata varigt.
• Downstream-behandling udtrækker tekst og andre nyttige oplysninger fra gemte dokumenter og gør dem tilgængelige, når agenter indlæser eller opdaterer projektet.

Hver agent har sin egen isolerede sandbox. Inde i sandboxen arbejder den med en lokal kopi af repositoriet, der administreres af en lille CLI. CLI'en beder kontrolplanet om at finde repositoriet og henter og indsender derefter ændringer via Git-tjenesten. En agent-proxy kontrollerer adgangen for anmodninger fra sandboxen, før de når Git-tjenesten. Git-tjenesten læser og skriver repositorier på et delt filsystem og afgør, om hver indsendelse bliver det senest accepterede commit. Filsystemet leveres af AWS S3Files, som gør S3-baseret lager tilgængeligt som almindelige filer og mapper. Lageret er opdelt i isolerede celler, der hver har sit eget filsystem og sine egne replikaer af Git-tjenesten. Når et commit er accepteret, udtrækker baggrundsworkers tekst og andre nyttige oplysninger fra ændrede dokumenter, gemmer resultaterne adskilt fra repositoriets historik og gør dem tilgængelige, når agenter indlæser eller opdaterer projektet.

Herefter gennemgår vi komponenterne én ad gangen.

Udvid

CLI: Arbejde med lokale filer i sandboxe

Agenter kører i SPACE, vores egenudviklede sandbox-platform. Hver sandbox har en lille CLI, der materialiserer repositoriet og holder det synkroniseret. For hver meningsfuld arbejdsenhed, agenten udfører, indsender CLI'en ændringerne som et commit.

Agenter rører typisk kun en lille del af projektfilerne, så det er ikke nødvendigt at materialisere hele repositoriet på forhånd. Derfor materialiserer CLI'en dovent: Store filer og binære filer, der er gemt via Git Large File Storage (LFS), ankommer som små pointerfiler med objektets reelle størrelse, så agenten kan bruge navnet og størrelsen til at afgøre, om en download er umagen værd. For dokumenter som PDF'er læser agenten først den parsede tekst og downloader kun kildefilerne, når det er nødvendigt.

En anden oplagt mulighed ville være at bruge et virtuelt filsystem. Vi testede en FUSE-baseret implementering, men den var cirka 400 gange langsommere end lokale filer ved filsystemtunge arbejdsbelastninger, da hver anmodning kræver en rundtur over netværket. Den kræver desuden typisk privilegerede rettigheder fra værten, så hver agent skulle køre i en privilegeret sandbox.

Udvid

Kontrolplanet: Lokalisering af repositorier og udstedelse af adgang

Kontrolplanet finder ud af, hvor hvert repository er gemt, og udsteder adgang til det. Når et repository oprettes, tildeler kontrolplanet det til en lagercelle – en isoleret lagerenhed med sine egne replikaer af Git-tjenesten. Når en agent begynder at arbejde på et projekt, spørger CLI'en kontrolplanet, hvor repositoriet er gemt. Kontrolplanet returnerer placeringen og midlertidige legitimationsoplysninger til Git-tjenesten. Kontrolplanet læser eller skriver aldrig repositorydata. Det er Git-tjenesten, der afgør, hvad der kommer ind i et repository.

Git-tjenesten: Flytning af data og koordinering af opdateringer

Git-tjenesten udfører Git-operationer og overfører repositoriets indhold og versionshistorik mellem sandboxe og lager. Den er en tynd wrapper omkring Gits egne serverkommandoer. Den understøtter ref-discovery, der fortæller klienten, hvor repositoriets head er, upload-pack til kloning og hentning og receive-pack til at modtage nye objekter og en anmodning om at flytte repositoriets head frem. Den betjener også Git LFS-API'et: For store filer og binære filer udsteder den kortlivede links, så sandboxe kan uploade og downloade disse filer direkte fra S3.

Vi startede med en færdig forge-server, så vi kunne udvikle prototyper af agent- og brugergrænsefladerne, samtidig med at vi byggede vores egen letvægts-forge, der kun fokuserer på de Git-operationer, vi har brug for.

Tjenesten består af en flåde af replikaer, som hver er en kørende instans af den samme server. En celle samler delt lager med et sæt replikaer og deres understøttende tjenester. Replikaer i en celle kan dermed tilgå det samme delte filsystem i stedet for at vedligeholde uafhængige kopier af hvert repository.

Dette delte lager gør det muligt for replikaerne at forblive tilstandsløse. Enhver replika i cellen kan betjene alle cellens repositorier, så udskiftning eller tilføjelse af replikaer kræver ikke, at repositorydata flyttes mellem servere. Anmodninger til et repository går normalt til den samme replika for at holde dens caches nyttige, men repositoriet er ikke afhængigt af, at netop den instans forbliver tilgængelig.

Accepteringstrinnet kontrollerer repositoriets invarianter for at sikre, at et accepteret commit er en gyldig tilstand for repositoriet. Vi definerer en eksplicit kontrakt for hvert repository, så mekaniske kontroller kan forhindre, at det vokser sig for stort. Store filer og binære filer som PDF'er og billeder gemmes via Git LFS i stedet for som rå Git-blobs. Komprimering holder den seneste historik tilgængelig og begrænser samtidig repositoriets størrelse. Efter en vellykket indsendelse spørger CLI'en Git-tjenesten, om repositoriet skal komprimeres. Hvis antallet af bevarede commits overstiger en tærskel, beholder Git-tjenesten kun et mindre sæt af de seneste commits. Ældre historik erstattes af et enkelt start-snapshot, og de seneste commits afspilles igen for at opdatere commit-id'erne.

Udvid

Et simpelt synkroniseringstrin håndterer samtidige skrivere. Det holder styr på det senest accepterede commit, også kaldet head. Når det modtager en indsendelse, accepterer det den kun, hvis indsendelsen er bygget oven på dette head. Hvis ikke, sender det et struktureret stale-base-svar; taberen skal så afspille sin ændring igen oven på det nye head og indsende den på ny. Dette design sikrer, at samtidige agenter ikke ubemærket overskriver hinanden, uden at det medfører nævneværdige forsinkelser. I vores arbejdsprocesser i produktion afvises under 2 % af indsendelserne som forældede. Samlet set er medianlatensen for indsendelser under 1,7 sekunder, og p99-latensen er under 8 sekunder.

Udvid

Git-tjenesten registrerer også hver accepteret ændring. For hver accepteret skrivning tilføjer den en post i en outbox – en log, der angiver repositoriet, det nye commit, brugeren, der foretog ændringen, og de stier, der blev ændret. Downstream-tjenester som parseren læser denne log for at finde nyt arbejde.

Tilsammen udgør disse dele et lag til administration af repositorier – uden de dele, agenter ikke har brug for. Pull requests er unødvendige, fordi intet menneske gennemgår hver ændring. I stedet kontrollerer Git-tjenesten kontrakten ved indsendelsen, den agent, der taber et kapløb, anvender sin egen ændring igen, og commit-historikken registrerer, hvem der ændrede hvad. Deterministiske kontroller holder hvert repository inden for dets kontrakt i stedet for at være afhængige af, at en menneskelig operatør styrer væksten.

Lager: Sådan forbliver arbejdet varigt

Lagerlaget gemmer repositorydata varigt og uafhængigt af sandboxene og Git-tjenestens replikaer. Repositorierne ligger på AWS S3Files, som eksponerer S3-baseret lager via en filsystemgrænseflade, som almindelig Git kan bruge uden ændringer. Hvert af dem er et bare Git-repository på det delte filsystem, der indeholder repositoriets objekter og referencer i stedet for en arbejdskopi (checkout).

Når lager og beregning adskilles, kan sandboxe forblive kortvarige. Hver agent får sin egen sandbox, og mange agenter kan arbejde på det samme projekt uden at dele en maskine. Hvis en sandbox går ned, er det kun arbejde, der ikke er indsendt, der er i fare.

Vi kunne i stedet give hvert projekt en langlivet sandbox, som alle projektets agenter deler, så projektets filer ville ligge på den maskines disk. Det ville dog binde agenternes beregningskraft til det sted, hvor maskinen kører, og kræve, at den dimensioneres til de travleste perioder. Den skulle også køre stabilt i månedsvis, med backup og gendannelse styret som en del af projektets lagersystem.

Udvid

Downstream-behandling: Sådan gøres dokumenter læsbare for agenter

Den primære downstream-komponent er en parser-pipeline, der udtrækker tekst og metadata fra nyligt tilføjede eller opdaterede dokumenter, så projektfilerne er lette for agenter at læse. En parser-worker henter opdateringer fra køen med ændringsstrømmen, udleder de ændrede filer fra commit-metadataene og henter de rå bytes ved hjælp af indholdshashen. Derefter parser den dokumentet for at frembringe den udtrukne tekst og dokumentets metadata.

Parsede output ligger uden for repositoriet i et lager, der er indekseret efter kildedokumentets hash. Disse artefakter committes aldrig tilbage til repositoriet, da det unødigt ville forurene historikken og øge antallet af samtidige skrivninger. I stedet når de parsede output frem til en sandbox via checkout og synkronisering. Hver checkout indeholder en reserveret mappe, som CLI'en bruger til at materialisere artefakter. Parsing sker asynkront, så en parser-worker i baggrunden ikke blokerer checkouts.

Sådan bruger agenter arbejdsområdet

Agenter udforsker den version af repositoriet, der er indlæst i sandboxen, med almindelige filsystemværktøjer. I stedet for at følge en fast pipeline, hvor der først søges og derefter læses, viser de mappernes indhold, søger i filindhold med grep, læser relevante passager og bruger det, de finder, til at beslutte, hvor de skal kigge næste gang.

Ligesom Computer bruger Search den samme tilgang via sine almindelige filværktøjer. En separat udforskningsagent gennemsøger projektet inden for et mere begrænset budget og returnerer relevante filstier og understøttende uddrag. Svarmodellen læser derefter de valgte filer og genererer svaret. Genbrug af en eksisterende projektsandbox reducerer opsætningstiden: Det tager cirka 2,9 sekunder at tilknytte sig en varm checkout sammenlignet med omkring 8 sekunder ved en kold start.

Udvid

Parset tekst gør større dokumenter som PDF'er og Office-filer søgbare med de samme værktøjer. Agenten tjekker først et manifest – en liste over, hvilke dokumenter der har udtrukket tekst tilgængelig – og søger og læser derefter teksten som almindelige filer. Den downloader kun det originale dokument, når teksten ikke er tilstrækkelig, for eksempel for at undersøge figurer, layout eller indlejrede data.

Vi benchmarkede denne tilgang mod semantisk søgning i et indeks med 150 finansielle spørgsmål om enkeltdokumenter i det samme korpus. Udforskningsagenten scorede 0,867 på at hente det korrekte dokument og 0,627 på at svare korrekt mod cirka 0,39 og 0,37 for semantisk søgning – omkring 1,7 gange bedre på svar og 2 gange bedre på hentning med omkring 25 % lavere latens. Udforskningsagenten arbejder primært med udtrukket tekst og downloader sjældent de originale PDF'er.

Udvid

Én fælles infrastruktur

Computers vedvarende hukommelse bruger den samme filsysteminfrastruktur. Perplexity Brain, Computers videnswiki, gemmer hukommelse i vidensrepositorier med deres egen historik og egne politikker. Når viden holdes adskilt fra projektfiler, konkurrerer hukommelsesopdateringer i baggrunden ikke med redigeringer af disse filer. En session, der har brug for begge dele, indlæser begge repositorier.

Baggrundsagenter læser eksisterende viden, indarbejder ny information og gemmer opdaterede sider som commits. Andre agenter læser disse sider med almindelige filværktøjer, og mennesker kan også redigere dem. Skrivere deler deres arbejde via repositoriet i stedet for at koordinere direkte med hver enkelt læser. Commit-historikken registrerer, hvem der ændrede hvad, mens outboxen rapporterer accepterede opdateringer til downstream-tjenester. Mennesker og agenter kan bygge videre på hinandens arbejde med en registrering af, hvordan videnen har udviklet sig.

Konklusion

Når mennesker og agenter deler et projekt, gør arbejdsområdet mere end at gemme filer. Det giver et fælles sted at samle bidrag og holde styr på, hvad der er ændret. Git leverer allerede meget af det fundament. Vi tilføjer koordinering og automatiserede kontroller, så agenter kan indsende arbejde, uden at en person skal godkende hver opdatering. Resultatet er en forge skåret ned til det essentielle, for samarbejde på tværs af agenter og softwareudvikling med mange bidragydere er i bund og grund det samme problem.

Agenter arbejder i uafhængige, midlertidige sandboxe og bidrager samtidig til varige repositorier. Begrænsninger på repositorierne holder væksten håndterbar, eksplicitte downloads lader agenterne vælge, hvad de vil hente, og almindelige filer lader dem udforske med velkendte værktøjer. Opdateringer i baggrunden, interaktive redigeringer og planlagte opgaver kan bygge videre på hinandens arbejde uden direkte koordinering.

Efterhånden som flere agenter arbejder selvstændigt i projekter, skal deres fælles arbejdsområde forblive pålideligt og forståeligt for mennesker. Målet er ligetil: Hver ændring skal være mere varig end den agent, der lavede den, blive tilgængelig for den næste samarbejdspartner og efterlade en tydelig registrering af, hvad der blev ændret.

Kildehenvisning

@online{perplexity2026BuildingSharedWorkspacesForPeopleAndAgents,
  author = {{Perplexity} and Se Won Jang and Peter Hart and Kartik Kapur and Kevin Lau and Sidhant Rajadnya and Ishbir Singh and Thomas Wang and Jarrod Bryan and Claire Beamer and Jeremy Yang},
  title = {{Building shared workspaces for people and agents}},
  date = {2026-10-12},
  url = {https://www.perplexity.ai/hub/blog/building-shared-workspaces-for-people-and-agents}
}