Izgradnja zajedničkih radnih prostora za ljude i agente

Nedavno smo predstavili Projekte, u kojima ljudi i agenti zajedno rade na dugotrajnim zadacima u okviru platforme Perplexity Computer. Svaki projekat počiva na zajedničkom radnom prostoru sa sistemom datoteka koji akumulira kontekst kroz sesije, agente i korisnike. Saradnja više učesnika koja traje mesecima zahteva trajnost, konkurentnost i sledljivost:

• Trajnost: Rad treba da ostane sačuvan i nakon završetka bilo koje pojedinačne sesije agenta ili sandbox okruženja, kako bi isti korisnik ili agent mogao da ga nastavi, a bilo koji saradnik da se nadoveže na njega.
• Konkurentnost: Više korisnika u istom projektu može da ima po više agenata koji paralelno unose izmene i grade zajedničko stanje, umesto da jedni drugima prepisuju rad.
• Sledljivost: I korisnici i agenti treba da mogu da vide istoriju kako bi proverili ko je šta izmenio od njihove poslednje sesije, bez ponovnog čitanja celog projekta, kao i da po potrebi ponište izmene.

Ovi izazovi deluju poznato softverskim inženjerima. Git forge platforme nastale su pre nekoliko decenija upravo da bi ispunile ove zahteve: to su hostovani servisi koji kontrolu verzija dopunjuju funkcijama za saradnju, tako da mnogi saradnici mogu da usaglase rad oko jedinstvenog izvora istine. Sistem datoteka na kome se zasnivaju Projekti jedna je takva Git forge platforma, napravljena za saradnju ljudi i agenata, kao i agenata međusobno.

Uvećaj

Arhitektura

Git već rešava trajnost, konkurentnost i sledljivost. Svaku datoteku identifikuje po sadržaju, pa se nepromenjene datoteke čuvaju samo jednom, a sačuvane kopije nikada ne zastarevaju. Svaki komit čuva sve ažurirane datoteke odjednom, pa saradnici nikada ne vide napola završeno stanje. Kada dva učesnika istovremeno pokušaju upis, onaj koji izgubi može ponovo da primeni svoje izmene na novu verziju i pokuša ponovo. Lanac komitova pokazuje ko je šta izmenio i olakšava vraćanje ranijih verzija. Ono što agentima nije potrebno jeste ostatak forge platforme napravljene za ljude, poput ekrana za pregled, upravljanja granama i obaveštenja.

Naša arhitektura izvršava ceo proces u oblaku i podržava sve oblike rada zasnovanog na znanju, a ne samo programiranje. Svaki Computer projekat zasnovan je na Git repozitorijumu koji opslužuje 5 komponenti:

• CLI održava lokalne radne kopije, sinhronizuje ažuriranja i predaje agentove izmene u svakom sandbox okruženju.
• Kontrolna ravan locira repozitorijum projekta i izdaje kratkotrajne akreditive za pristup njemu.
• Git servis šalje podatke repozitorijuma u sandbox okruženja, prima njihove predaje i odlučuje koja predaja postaje poslednji prihvaćeni komit.
• Skladište zasnovano na AWS S3 trajno čuva podatke repozitorijuma.
• Nizvodna obrada izdvaja tekst i druge korisne informacije iz sačuvanih dokumenata i čini ih dostupnim kada agenti učitaju ili osveže projekat.

Svaki agent ima sopstveno izolovano sandbox okruženje. U njemu radi sa lokalnom kopijom repozitorijuma kojom upravlja mali CLI. CLI traži od kontrolne ravni da locira repozitorijum, a zatim preuzima i predaje izmene preko Git servisa. Proksi za agente proverava pristup za zahteve iz sandbox okruženja pre nego što stignu do Git servisa. Git servis čita i upisuje repozitorijume na zajedničkom sistemu datoteka i odlučuje da li svaka predaja postaje poslednji prihvaćeni komit. Taj sistem datoteka obezbeđuje AWS S3Files, koji skladište zasnovano na S3 čini dostupnim kao obične datoteke i direktorijume. Skladište je podeljeno na izolovane ćelije, od kojih svaka ima sopstveni sistem datoteka i replike Git servisa. Nakon što se komit prihvati, radni procesi u pozadini izdvajaju tekst i druge korisne informacije iz izmenjenih dokumenata, čuvaju rezultate odvojeno od istorije repozitorijuma i čine ih dostupnim kada agenti učitaju ili osveže projekat.

U nastavku opisujemo komponente jednu po jednu.

Uvećaj

CLI: rad sa lokalnim datotekama u sandbox okruženjima

Agenti se izvršavaju u okviru SPACE, naše interne platforme za sandbox okruženja. Svako sandbox okruženje ima mali CLI koji materijalizuje repozitorijum i održava ga sinhronizovanim. Za svaku jedinicu smislenog rada koji agent obavi, CLI predaje izmene kao komit.

Agenti obično koriste samo mali deo datoteka projekta, pa nije neophodno unapred materijalizovati ceo repozitorijum. Zato CLI materijalizuje sadržaj lenjo, po potrebi: velike i binarne datoteke sačuvane putem Git Large File Storage (LFS) stižu kao male datoteke-pokazivači koje beleže stvarnu veličinu objekta, pa agent na osnovu imena i veličine može da odluči da li se preuzimanje isplati. Kod dokumenata kao što su PDF-ovi, agent najpre čita parsirani tekst, a izvorne datoteke preuzima samo kada je to neophodno.

Još jedna prirodna opcija bila bi upotreba virtuelnog sistema datoteka. Testirali smo implementaciju zasnovanu na FUSE-u, ali je pri radnim opterećenjima sa intenzivnim korišćenjem sistema datoteka bila otprilike 400 puta sporija od lokalnih datoteka, jer svaki zahtev podrazumeva mrežni povratni put. Pored toga, takvom rešenju su obično potrebne privilegovane mogućnosti hosta, pa bi svaki agent morao da radi u privilegovanom sandbox okruženju.

Uvećaj

Kontrolna ravan: lociranje repozitorijuma i izdavanje pristupa

Kontrolna ravan utvrđuje gde je svaki repozitorijum smešten i izdaje pristup njemu. Kada se repozitorijum kreira, kontrolna ravan ga dodeljuje ćeliji za skladištenje, izolovanoj jedinici skladišta sa sopstvenim replikama Git servisa. Kada agent započne rad na projektu, CLI pita kontrolnu ravan gde je repozitorijum smešten. Kontrolna ravan vraća lokaciju i privremene akreditive za Git servis. Kontrolna ravan nikada ne čita niti upisuje podatke repozitorijuma. Git servis odlučuje šta ulazi u repozitorijum.

Git servis: prenos podataka i koordinacija ažuriranja

Git servis izvršava Git operacije i prenosi sadržaj repozitorijuma i istoriju verzija između sandbox okruženja i skladišta. To je tanak omotač oko komandi za opsluživanje koje pruža sam Git. Podržava otkrivanje referenci, kojim klijentu saopštava gde se nalazi head repozitorijuma, upload-pack za kloniranje i preuzimanje, kao i receive-pack za prijem novih objekata i zahteva za pomeranje head pokazivača repozitorijuma. Takođe opslužuje Git LFS API: za velike i binarne datoteke izdaje kratkotrajne linkove kako bi sandbox okruženja mogla da otpremaju i preuzimaju te datoteke direktno sa S3.

Počeli smo sa gotovim forge serverom, kako bismo mogli da pravimo prototipove interfejsa za agente i korisnike paralelno sa izgradnjom sopstvene lagane forge platforme, usmerene isključivo na Git operacije koje su nam potrebne.

Servis se sastoji od flote replika, od kojih je svaka pokrenuta instanca istog servera. Ćelija objedinjuje zajedničko skladište sa skupom replika i njihovim pratećim servisima. Replike unutar ćelije tada mogu da pristupaju istom zajedničkom sistemu datoteka, umesto da održavaju nezavisne kopije svakog repozitorijuma.

Ovo zajedničko skladište omogućava replikama da ostanu bez stanja. Bilo koja replika u ćeliji može da opslužuje bilo koji od repozitorijuma te ćelije, pa zamena ili dodavanje replika ne zahteva premeštanje podataka repozitorijuma između servera. Zahtevi za određeni repozitorijum obično idu ka istoj replici kako bi njene keš memorije ostale korisne, ali repozitorijum ne zavisi od toga da li će ta konkretna instanca ostati dostupna.

Korak prihvatanja proverava invarijante repozitorijuma kako bi se osiguralo da prihvaćeni komit predstavlja validno stanje repozitorijuma. Za svaki repozitorijum definišemo eksplicitan ugovor, tako da mehaničke provere mogu da spreče njegov preteran rast. Velike i binarne datoteke, poput PDF-ova i slika, čuvaju se putem Git LFS-a, a ne kao sirovi Git blobovi. Kompakcija čuva dostupnost novije istorije, a istovremeno ograničava veličinu repozitorijuma. Nakon uspešne predaje, CLI pita Git servis da li je repozitorijumu potrebna kompakcija. Ako broj zadržanih komitova pređe određeni prag, Git servis zadržava samo manji skup najnovijih komitova. Starija istorija zamenjuje se jednim početnim snimkom, a noviji komitovi se ponovo primenjuju kako bi se ažurirali identifikatori komitova.

Uvećaj

Jednostavan korak sinhronizacije upravlja istovremenim upisima. On prati poslednji prihvaćeni komit, odnosno head. Kada primi predaju, prihvata je samo ako je izgrađena na tom head komitu. Ako nije, šalje strukturisani odgovor o zastareloj osnovi; agent koji je izgubio tada mora ponovo da primeni svoju izmenu na novi head i ponovo je preda. Ovaj dizajn obezbeđuje da agenti koji rade istovremeno ne prepisuju tiho izmene jedni drugih, a da pritom ne dolazi do značajnog usporavanja. U našim produkcionim radnim tokovima, manje od 2% predaja odbija se zbog zastarele osnove. Ukupno gledano, medijana latencije predaje je ispod 1,7 sekundi, a p99 latencija ispod 8 sekundi.

Uvećaj

Git servis takođe beleži svaku prihvaćenu izmenu. Za svaki prihvaćeni upis dodaje unos u outbox, dnevnik u kome su navedeni repozitorijum, novi komit, korisnik koji je napravio izmenu i putanje koje su izmenjene. Nizvodni servisi, poput parsera, čitaju ovaj dnevnik kako bi pronašli novi posao.

Zajedno, ovi delovi čine sloj za upravljanje repozitorijumima, bez delova koji agentima nisu potrebni. Pull requestovi nisu potrebni, jer nijedan čovek ne pregleda svaku izmenu. Umesto toga, Git servis proverava ugovor u trenutku predaje, agent koji izgubi trku ponovo primenjuje sopstvenu izmenu, a istorija komitova beleži ko je šta izmenio. Determinističke provere drže svaki repozitorijum u okvirima njegovog ugovora, umesto da se upravljanje rastom prepušta ljudskom operateru.

Skladištenje: trajno čuvanje rada

Sloj skladišta trajno čuva podatke repozitorijuma nezavisno od sandbox okruženja i replika Git servisa. Repozitorijumi se nalaze na AWS S3Files, koji omogućava pristup skladištu zasnovanom na S3 putem interfejsa sistema datoteka koji standardni Git može da koristi bez izmena. Svaki repozitorijum je bare Git repozitorijum na zajedničkom sistemu datoteka, koji sadrži objekte i reference repozitorijuma, a ne radnu kopiju.

Razdvajanje skladištenja i računarskih resursa omogućava da sandbox okruženja ostanu efemerna. Svaki agent dobija sopstveno sandbox okruženje, a mnogi agenti mogu da rade na istom projektu bez deljenja mašine. Ako sandbox okruženje otkaže, ugrožen je samo rad koji još nije predat.

Umesto toga, mogli bismo svakom projektu da dodelimo dugotrajno sandbox okruženje koje dele svi njegovi agenti, tako da bi datoteke projekta bile na disku te mašine. Međutim, to bi vezalo računarske resurse agenata za mesto na kome mašina radi i zahtevalo bi da njeni kapaciteti budu dimenzionisani za periode najvećeg opterećenja. Mašina bi takođe morala da ostane ispravna mesecima, a rezervnim kopijama i oporavkom bi se moralo upravljati kao delom sistema za skladištenje projekta.

Uvećaj

Nizvodna obrada: kako dokumente učiniti čitljivim za agente

Primarna nizvodna komponenta je cevovod za parsiranje koji izdvaja tekst i metapodatke iz novododatih ili ažuriranih dokumenata kako bi agenti lako mogli da čitaju datoteke projekta. Radni proces parsera preuzima ažuriranja iz reda toka izmena, na osnovu metapodataka komita utvrđuje izmenjene datoteke i preuzima sirove bajtove pomoću heša sadržaja. Zatim parsira dokument i dobija izdvojeni tekst i metapodatke dokumenta.

Parsirani rezultati nalaze se izvan repozitorijuma, u skladištu u kome je ključ heš izvornog dokumenta. Ovi artefakti se nikada ne komituju nazad u repozitorijum, jer bi to bespotrebno zagadilo istoriju i povećalo broj istovremenih upisa. Umesto toga, parsirani rezultati stižu u sandbox okruženje putem checkout-a i sinhronizacije. Svaka radna kopija sadrži rezervisani direktorijum koji CLI koristi za materijalizaciju artefakata. Parsiranje se odvija asinhrono, tako da radni proces parsera u pozadini ne blokira checkout operacije.

Kako agenti koriste radni prostor

Agenti istražuju verziju repozitorijuma učitanu u sandbox okruženje pomoću standardnih alata za sistem datoteka. Umesto da prate fiksni tok „pretraži pa pročitaj“, oni listaju fascikle, pretražuju sadržaj datoteka pomoću alata grep, čitaju relevantne odlomke i na osnovu onoga što pronađu odlučuju gde da traže dalje.

Slično kao Computer, Search koristi isti pristup putem svojih standardnih alata za rad sa datotekama. Zaseban istraživački agent pretražuje projekat u okviru ograničenijeg budžeta i vraća putanje relevantnih datoteka i potkrepljujuće odlomke. Model koji daje odgovor zatim čita izabrane datoteke i generiše odgovor. Ponovna upotreba postojećeg sandbox okruženja projekta skraćuje vreme pripreme: povezivanje sa već pripremljenom radnom kopijom traje oko 2,9 sekundi, u poređenju sa otprilike 8 sekundi pri hladnom pokretanju.

Uvećaj

Parsirani tekst omogućava da se veći dokumenti, kao što su PDF-ovi i Office datoteke, pretražuju istim alatima. Agent najpre proverava manifest, listu koja pokazuje za koje dokumente je dostupan izdvojeni tekst, a zatim pretražuje i čita taj tekst kao obične datoteke. Originalni dokument preuzima samo kada tekst nije dovoljan, na primer, da bi pregledao ilustracije, raspored ili ugrađene podatke.

Uporedili smo ovaj pristup sa semantičkom pretragom nad indeksom na 150 finansijskih pitanja vezanih za pojedinačne dokumente iz istog korpusa. Istraživački agent postigao je rezultat 0,867 u pronalaženju tačnog dokumenta i 0,627 u tačnom odgovaranju, naspram otprilike 0,39 i 0,37 kod semantičke pretrage, što je oko 1,7 puta bolje kod odgovora i 2 puta bolje kod pronalaženja, uz oko 25% nižu latenciju. Istraživački agent uglavnom radi sa izdvojenim tekstom i retko preuzima originalne PDF-ove.

Uvećaj

Jedna zajednička infrastruktura

Trajna memorija koju koristi Computer zasniva se na istoj infrastrukturi sistema datoteka. Perplexity Brain, wiki baza znanja za Computer, čuva memoriju u repozitorijumima znanja sa sopstvenom istorijom i pravilima. Pošto je znanje odvojeno od datoteka projekta, ažuriranja memorije u pozadini ne konkurišu izmenama tih datoteka. Sesija kojoj je potrebno i jedno i drugo učitava oba repozitorijuma.

Agenti u pozadini čitaju postojeće znanje, uključuju nove informacije i čuvaju ažurirane stranice kao komitove. Drugi agenti čitaju te stranice običnim alatima za rad sa datotekama, a ljudi takođe mogu da ih uređuju. Oni koji upisuju sadržaj dele svoj rad putem repozitorijuma, umesto da se direktno koordinišu sa svakim čitaocem. Istorija komitova beleži ko je šta izmenio, dok outbox prijavljuje prihvaćena ažuriranja nizvodnim servisima. Ljudi i agenti mogu da se nadovezuju na rad jedni drugih, uz zapis o tome kako se znanje razvijalo.

Zaključak

Kada ljudi i agenti dele projekat, radni prostor ne služi samo za čuvanje datoteka. On pruža zajedničko mesto za objedinjavanje doprinosa i praćenje izmena. Git već obezbeđuje veliki deo te osnove. Mi dodajemo koordinaciju i automatske provere kako bi agenti mogli da predaju rad, a da čovek ne mora da odobrava svako ažuriranje. Rezultat je forge platforma svedena na suštinu, jer su saradnja među agentima i razvoj softvera sa više saradnika u osnovi isti problem.

Agenti rade u nezavisnim, privremenim sandbox okruženjima, a doprinose trajnim repozitorijumima. Ograničenja repozitorijuma drže rast pod kontrolom, eksplicitna preuzimanja omogućavaju agentima da biraju šta će preuzeti, a obične datoteke im omogućavaju da istražuju poznatim alatima. Ažuriranja u pozadini, interaktivne izmene i zakazani zadaci mogu da se nadovezuju na međusobne rezultate bez direktne koordinacije.

Kako sve više agenata radi autonomno u okviru Projekata, njihov zajednički radni prostor mora da ostane pouzdan i razumljiv ljudima. Cilj je jednostavan: svaka izmena treba da nadživi agenta koji ju je napravio, da postane dostupna sledećem saradniku i da ostavi jasan zapis o tome šta je izmenjeno.

Citiranje

@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}
}