Izgradnja zajedničkih radnih prostora za ljude i agente

Nedavno smo predstavili projekte, u kojima ljudi i agenti zajedno rade na dugotrajnim zadacima u usluzi Perplexity Computer. Svaki projekt počiva na zajedničkom radnom prostoru s datotečnim sustavom koji akumulira kontekst kroz sesije, agente i korisnike. Višekorisnička suradnja koja traje mjesecima zahtijeva trajnost, istodobnost i sljedivost:

• Trajnost: rad bi trebao trajati dulje od bilo koje pojedinačne sesije agenta ili sandboxa kako bi ga isti korisnik ili agent mogao nastaviti u budućnosti, a bilo koji suradnik nadograditi.
• Istodobnost: više korisnika u istom projektu može imati više agenata koji paralelno unose izmjene i tako nadograđuju zajedničko stanje umjesto da jedni drugima prepisuju rad.
• Sljedivost: i korisnici i agenti trebali bi moći vidjeti povijest kako bi provjerili tko je što promijenio od njihove posljednje sesije bez ponovnog čitanja cijelog projekta te po potrebi poništili izmjene.

Ti izazovi softverskim inženjerima zvuče poznato. Git forge platforme nastale su prije više desetljeća upravo kako bi ispunile te zahtjeve: riječ je o hostiranom servisu koji sustav za kontrolu verzija nadopunjuje značajkama za suradnju kako bi se mnogi suradnici mogli usuglasiti oko jedinstvenog izvora istine. Datotečni sustav na kojem počivaju projekti jedna je takva Git forge platforma, izgrađena za suradnju ljudi i agenata, kao i agenata međusobno.

Povećaj

Arhitektura

Git već rješava trajnost, istodobnost i sljedivost. Svaku datoteku identificira po njezinu sadržaju, pa se nepromijenjene datoteke pohranjuju samo jednom, a spremljene kopije nikada ne zastarijevaju. Svaki commit odjednom sprema sve ažurirane datoteke, pa suradnici nikada ne vide napola dovršeno stanje. Kada se dva istodobna zapisivanja sudare, ono koje je izgubilo može ponovno primijeniti svoje izmjene na novu verziju i pokušati ponovno. Lanac commitova pokazuje tko je što promijenio i olakšava vraćanje ranijih verzija. Ono što agentima ne treba jest ostatak forge platforme izgrađene za ljude, poput zaslona za pregled, upravljanja granama i obavijesti.

Naša arhitektura cijeli proces izvodi u oblaku i podržava sve oblike intelektualnog rada, ne samo programiranje. Iza svakog projekta za Computer stoji Git repozitorij koji poslužuje 5 komponenti:

• CLI u svakom sandboxu održava lokalne radne kopije, sinkronizira ažuriranja i šalje agentove izmjene.
• Upravljačka ravnina pronalazi repozitorij projekta i izdaje kratkotrajne vjerodajnice za pristup njemu.
• Git servis šalje podatke repozitorija sandboxovima, prima njihova slanja i odlučuje koje slanje postaje najnoviji prihvaćeni commit.
• Pohrana temeljena na AWS S3 trajno čuva podatke repozitorija.
• Nizvodna obrada izdvaja tekst i druge korisne informacije iz spremljenih dokumenata i čini ih dostupnima kada agenti učitavaju ili osvježavaju projekt.

Svaki agent ima vlastiti izolirani sandbox. Unutar tog sandboxa radi s lokalnom kopijom repozitorija kojom upravlja mali CLI. CLI traži od upravljačke ravnine da pronađe repozitorij, a zatim dohvaća i šalje izmjene putem Git servisa. Proxy za agente provjerava pristup za zahtjeve iz sandboxa prije nego što stignu do Git servisa. Git servis čita i zapisuje repozitorije na zajedničkom datotečnom sustavu te odlučuje hoće li pojedino slanje postati najnoviji prihvaćeni commit. Taj datotečni sustav osigurava AWS S3Files, koji pohranu temeljenu na S3 čini dostupnom kao obične datoteke i direktorije. Pohrana je podijeljena u izolirane ćelije, od kojih svaka ima vlastiti datotečni sustav i replike Git servisa. Nakon što se commit prihvati, pozadinski radni procesi izdvajaju tekst i druge korisne informacije iz promijenjenih dokumenata, pohranjuju rezultate odvojeno od povijesti repozitorija i čine ih dostupnima kada agenti učitavaju ili osvježavaju projekt.

U nastavku redom prolazimo kroz svaku komponentu.

Povećaj

CLI: rad s lokalnim datotekama u sandboxovima

Agenti rade u okruženju SPACE, našoj internoj platformi za sandboxove. Svaki sandbox ima mali CLI koji materijalizira repozitorij i održava ga sinkroniziranim. Za svaku jedinicu smislenog rada koji agent obavi CLI šalje izmjene kao commit.

Agenti obično dotiču samo mali dio datoteka projekta, pa nije potrebno unaprijed materijalizirati cijeli repozitorij. Zato CLI materijalizira lijeno: velike i binarne datoteke pohranjene putem sustava Git Large File Storage (LFS) stižu kao male datoteke pokazivača koje sadrže stvarnu veličinu objekta, pa agent na temelju naziva i veličine može odlučiti isplati li se preuzimanje. Kod dokumenata kao što su PDF-ovi agent najprije čita parsirani tekst, a izvorne datoteke preuzima samo kada je to potrebno.

Još jedna prirodna mogućnost bila bi korištenje virtualnog datotečnog sustava. Testirali smo implementaciju temeljenu na sustavu FUSE, ali kod opterećenja s intenzivnim radom s datotečnim sustavom bila je otprilike 400 puta sporija od lokalnih datoteka jer svaki zahtjev zahtijeva povratni put kroz mrežu. Uz to obično zahtijeva privilegirane mogućnosti na glavnom računalu, pa bi svaki agent morao raditi u privilegiranom sandboxu.

Povećaj

Upravljačka ravnina: pronalaženje repozitorija i izdavanje pristupa

Upravljačka ravnina pronalazi gdje je pohranjen svaki repozitorij i izdaje pristup njemu. Kada se repozitorij stvori, upravljačka ravnina dodjeljuje ga ćeliji za pohranu, izoliranoj jedinici pohrane s vlastitim replikama Git servisa. Kada agent počne raditi na projektu, CLI pita upravljačku ravninu gdje je repozitorij pohranjen. Upravljačka ravnina vraća lokaciju i privremene vjerodajnice za Git servis. Upravljačka ravnina nikada ne čita niti zapisuje podatke repozitorija. O tome što ulazi u repozitorij odlučuje Git servis.

Git servis: prijenos podataka i koordinacija ažuriranja

Git servis izvršava Git operacije i prenosi sadržaj repozitorija i povijest verzija između sandboxova i pohrane. Riječ je o tankom omotaču oko Gitovih vlastitih naredbi za posluživanje. Podržava otkrivanje referenci kako bi klijentu javio gdje je vrh repozitorija, upload-pack za kloniranje i dohvaćanje te receive-pack za primanje novih objekata i zahtjeva za pomicanje vrha repozitorija. Poslužuje i Git LFS API: za velike i binarne datoteke izdaje kratkotrajne poveznice kako bi sandboxovi te datoteke mogli izravno prenositi na S3 i preuzimati s njega.

Započeli smo s gotovim forge poslužiteljem kako bismo mogli izrađivati prototipove sučelja za agente i korisnike paralelno s izgradnjom vlastite lagane forge platforme, usmjerene samo na Git operacije koje su nam potrebne.

Servis se sastoji od flote replika, od kojih je svaka pokrenuta instanca istog poslužitelja. Ćelija objedinjuje zajedničku pohranu sa skupom replika i njihovim pratećim servisima. Replike unutar ćelije tada mogu pristupati istom zajedničkom datotečnom sustavu umjesto da održavaju neovisne kopije svakog repozitorija.

Zahvaljujući toj zajedničkoj pohrani replike mogu ostati bez stanja. Bilo koja replika u ćeliji može posluživati bilo koji repozitorij te ćelije, pa zamjena ili dodavanje replika ne zahtijeva premještanje podataka repozitorija između poslužitelja. Zahtjevi za određeni repozitorij obično idu istoj replici kako bi njezine predmemorije ostale korisne, ali repozitorij ne ovisi o tome hoće li ta instanca ostati dostupna.

Korak prihvaćanja provjerava invarijante repozitorija kako bi osigurao da je prihvaćeni commit valjano stanje repozitorija. Za svaki repozitorij definiramo eksplicitan ugovor kako bi ga mehaničke provjere mogle spriječiti da postane prevelik. Velike i binarne datoteke, poput PDF-ova i slika, pohranjuju se putem Git LFS-a umjesto kao sirovi Git blobovi. Sažimanje održava nedavnu povijest dostupnom, a istodobno ograničava veličinu repozitorija. Nakon uspješnog slanja CLI pita Git servis treba li repozitorij sažeti. Ako broj zadržanih commitova premaši prag, Git servis zadržava samo manji skup najnovijih commitova. Starija povijest zamjenjuje se jednom početnom snimkom, a nedavni se commitovi ponovno primjenjuju kako bi se ažurirali identifikatori commitova.

Povećaj

Jednostavan korak sinkronizacije kontrolira istodobna zapisivanja. Prati najnoviji prihvaćeni commit, odnosno vrh (head). Kada primi slanje, prihvaća ga samo ako je izgrađeno na tom vrhu. Ako nije, šalje strukturirani odgovor o zastarjeloj osnovi; agent koji je izgubio tada mora ponovno primijeniti svoju izmjenu na novi vrh i ponovno je poslati. Ovaj dizajn osigurava da istodobni agenti ne prepisuju neprimjetno rad jedni drugih, a da pritom ne dolazi do značajnog usporavanja. U našim produkcijskim tijekovima rada manje od 2 % slanja odbija se kao zastarjelo. Ukupno gledano, medijan latencije slanja manji je od 1,7 sekunde, a latencija p99 manja je od 8 sekundi.

Povećaj

Git servis također bilježi svaku prihvaćenu izmjenu. Za svako prihvaćeno zapisivanje dodaje unos u izlazni spremnik (outbox), zapisnik koji navodi repozitorij, novi commit, korisnika koji je napravio izmjenu i putanje koje su se promijenile. Nizvodni servisi, poput parsera, čitaju taj zapisnik kako bi pronašli novi posao.

Zajedno ti dijelovi čine sloj za upravljanje repozitorijima, bez dijelova koji agentima nisu potrebni. Pull requestovi su nepotrebni jer nijedan čovjek ne pregledava svaku izmjenu. Umjesto toga, Git servis provjerava ugovor u trenutku slanja, agent koji izgubi utrku ponovno primjenjuje vlastitu izmjenu, a povijest commitova bilježi tko je što promijenio. Determinističke provjere drže svaki repozitorij unutar njegova ugovora, umjesto da se upravljanje rastom prepušta ljudskom operateru.

Pohrana: trajno čuvanje rada

Sloj za pohranu trajno sprema podatke repozitorija neovisno o sandboxovima i replikama Git servisa. Repozitoriji se nalaze na usluzi AWS S3Files, koja pohranu temeljenu na S3 izlaže putem sučelja datotečnog sustava koje standardni Git može koristiti bez izmjena. Svaki je repozitorij goli (bare) Git repozitorij na zajedničkom datotečnom sustavu i sadrži objekte i reference repozitorija, a ne radnu kopiju.

Razdvajanje pohrane i računalnih resursa omogućuje da sandboxovi ostanu privremeni. Svaki agent dobiva vlastiti sandbox, a mnogi agenti mogu raditi na istom projektu bez dijeljenja računala. Ako se sandbox sruši, ugrožen je samo rad koji još nije poslan.

Umjesto toga mogli bismo svakom projektu dati dugotrajan sandbox koji dijele svi njegovi agenti, tako da se datoteke projekta nalaze na disku tog računala. No time bi računalni resursi agenata bili vezani uz mjesto na kojem to računalo radi, a ono bi moralo biti dimenzionirano za najopterećenija razdoblja. Također bi mjesecima moralo ostati ispravno, a sigurnosnim kopijama i oporavkom trebalo bi upravljati u sklopu sustava za pohranu projekta.

Povećaj

Nizvodna obrada: omogućavanje agentima da čitaju dokumente

Glavna nizvodna komponenta je cjevovod za parsiranje koji izdvaja tekst i metapodatke iz novododanih ili ažuriranih dokumenata kako bi agenti mogli lako čitati datoteke projekta. Radni proces parsera preuzima ažuriranja iz reda toka promjena, iz metapodataka commita utvrđuje koje su se datoteke promijenile i dohvaća sirove bajtove pomoću hasha sadržaja. Zatim parsira dokument kako bi dobio izdvojeni tekst i metapodatke dokumenta.

Parsirani rezultati nalaze se izvan repozitorija, u spremištu čiji je ključ hash izvornog dokumenta. Ti se artefakti nikada ne vraćaju u repozitorij kao commit jer bi to nepotrebno zagadilo povijest i povećalo broj istodobnih zapisivanja. Umjesto toga parsirani rezultati dolaze u sandbox prilikom stvaranja radne kopije i sinkronizacije. Svaka radna kopija sadrži rezervirani direktorij koji CLI koristi za materijalizaciju artefakata. Parsiranje se odvija asinkrono, pa pozadinski radni proces parsera ne blokira stvaranje radnih kopija.

Kako agenti koriste radni prostor

Agenti istražuju verziju repozitorija učitanu u sandbox pomoću standardnih alata datotečnog sustava. Umjesto da slijede fiksni tijek „pretraži pa pročitaj“, ispisuju sadržaj mapa, pretražuju sadržaj datoteka alatom grep, čitaju relevantne odlomke i na temelju pronađenog odlučuju gdje će dalje tražiti.

Kao i Computer, Search primjenjuje isti pristup putem svojih standardnih alata za datoteke. Zasebni istraživački agent pretražuje projekt unutar ograničenijeg budžeta i vraća relevantne putanje datoteka te popratne izvatke. Model koji odgovara zatim čita odabrane datoteke i generira odgovor. Ponovno korištenje postojećeg sandboxa projekta skraćuje vrijeme postavljanja: povezivanje s već pripremljenom radnom kopijom traje oko 2,9 sekunde, u usporedbi s otprilike 8 sekundi kod hladnog pokretanja.

Povećaj

Parsirani tekst omogućuje da se veći dokumenti, poput PDF-ova i Office datoteka, pretražuju istim alatima. Agent najprije provjerava manifest, popis koji pokazuje za koje je dokumente dostupan izdvojeni tekst, a zatim pretražuje i čita taj tekst kao obične datoteke. Izvorni dokument preuzima samo kada tekst nije dovoljan, na primjer za pregled slika, rasporeda ili ugrađenih podataka.

Ovaj smo pristup usporedili sa semantičkim pretraživanjem nad indeksom na 150 financijskih pitanja vezanih uz pojedinačne dokumente iz istog korpusa. Istraživački agent postigao je 0,867 u dohvaćanju točnog dokumenta i 0,627 u točnom odgovaranju, naspram otprilike 0,39 i 0,37 kod semantičkog pretraživanja, što je oko 1,7 puta bolje kod odgovora i 2 puta bolje kod dohvaćanja, uz oko 25 % nižu latenciju. Istraživački agent uglavnom radi s izdvojenim tekstom i rijetko preuzima izvorne PDF-ove.

Povećaj

Jedna zajednička infrastruktura

Computer za trajnu memoriju koristi istu infrastrukturu datotečnog sustava. Perplexity Brain, wiki znanja koji koristi Computer, pohranjuje memoriju u repozitorijima znanja s vlastitom poviješću i pravilima. Odvajanje znanja od datoteka projekta znači da se pozadinska ažuriranja memorije ne natječu s izmjenama tih datoteka. Sesija kojoj je potrebno oboje učitava oba repozitorija.

Pozadinski agenti čitaju postojeće znanje, uključuju nove informacije i spremaju ažurirane stranice kao commitove. Drugi agenti čitaju te stranice običnim alatima za datoteke, a mogu ih uređivati i ljudi. Oni koji zapisuju dijele svoj rad putem repozitorija umjesto da se izravno koordiniraju sa svakim čitateljem. Povijest commitova bilježi tko je što promijenio, dok izlazni spremnik prijavljuje prihvaćena ažuriranja nizvodnim servisima. Ljudi i agenti mogu se nadovezivati na rad jedni drugih, uz zapis o tome kako se znanje razvijalo.

Zaključak

Kada ljudi i agenti dijele projekt, radni prostor ne služi samo za pohranu datoteka. On pruža zajedničko mjesto za objedinjavanje doprinosa i praćenje promjena. Git već osigurava velik dio tih temelja. Mi dodajemo koordinaciju i automatizirane provjere kako bi agenti mogli slati svoj rad, a da nijedna osoba ne mora odobravati svako ažuriranje. Rezultat je forge platforma svedena na ono najbitnije jer su suradnja među agentima i razvoj softvera s više suradnika u osnovi isti problem.

Agenti rade u neovisnim, privremenim sandboxovima, a pritom doprinose trajnim repozitorijima. Ograničenja repozitorija održavaju rast upravljivim, eksplicitna preuzimanja omogućuju agentima da sami biraju što će dohvatiti, a obične datoteke omogućuju im istraživanje poznatim alatima. Pozadinska ažuriranja, interaktivne izmjene i zakazani zadaci mogu se nadovezivati na međusobni rad bez izravne koordinacije.

Kako sve više agenata radi samostalno unutar projekata, njihov zajednički radni prostor mora ostati pouzdan i razumljiv ljudima. Cilj je jednostavan: svaka izmjena treba biti trajnija od agenta koji ju je napravio, postati dostupna sljedećem suradniku i ostaviti jasan zapis o tome što se promijenilo.

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