Budovanie zdieľaných pracovných priestorov pre ľudí a agentov

Nedávno sme spustili Projekty, v ktorých ľudia a agenti spolupracujú na dlhodobých úlohách v Perplexity Computer. Každý projekt je postavený na zdieľanom pracovnom priestore so súborovým systémom, ktorý zhromažďuje kontext naprieč reláciami, agentmi a používateľmi. Spolupráca viacerých účastníkov, ktorá trvá mesiace, si vyžaduje perzistenciu, súbežnosť a sledovateľnosť:

• Perzistencia: Práca by mala pretrvať aj po skončení ktorejkoľvek jednotlivej relácie agenta či sandboxu, aby v nej neskôr mohol pokračovať ten istý používateľ alebo agent a nadväzovať na ňu mohli akíkoľvek spolupracovníci.
• Súbežnosť: Viacerí používatelia v tom istom projekte môžu mať každý viacerých agentov, ktorí paralelne vykonávajú úpravy posúvajúce spoločný stav dopredu, namiesto toho, aby sa navzájom prepisovali.
• Sledovateľnosť: Používatelia aj agenti by mali vidieť históriu, aby si mohli overiť, kto čo zmenil od ich poslednej relácie, bez opätovného čítania celého projektu, a v prípade potreby vrátiť úpravy späť.

Tieto výzvy sú softvérovým inžinierom dobre známe. Platformy typu Git forge vznikli pred desaťročiami práve na splnenie týchto požiadaviek: ide o hostovanú službu, ktorá obaľuje správu verzií funkciami na spoluprácu, aby sa príspevky mnohých prispievateľov mohli zbiehať v jedinom zdroji pravdy. Súborový systém, na ktorom sú postavené Projekty, je práve takouto Git forge platformou vytvorenou na spoluprácu medzi ľuďmi a agentmi aj medzi agentmi navzájom.

Zväčšiť

Architektúra

Git už zvláda perzistenciu, súbežnosť aj sledovateľnosť. Každý súbor identifikuje podľa jeho obsahu, takže nezmenené súbory sa ukladajú iba raz a uložené kópie nikdy nezastarajú. Každý commit uloží všetky aktualizované súbory naraz, takže spolupracovníci nikdy neuvidia rozpracovaný stav. Keď sa zápisy dvoch zapisovateľov dostanú do konfliktu, ten, ktorý neuspel, môže svoje zmeny znova aplikovať na novú verziu a skúsiť to znova. Reťazec commitov ukazuje, kto čo zmenil, a uľahčuje obnovenie starších verzií. Agenti však nepotrebujú zvyšok forge platformy vytvorenej pre ľudí, napríklad obrazovky na kontrolu zmien, správu vetiev a upozornenia.

Naša architektúra spúšťa celý proces v cloude a podporuje všetky formy znalostnej práce nad rámec programovania. Každý projekt v nástroji Computer je založený na repozitári Git, ktorý obsluhuje 5 súčastí:

• CLI v každom sandboxe spravuje lokálne checkouty, synchronizuje aktualizácie a odosiela zmeny agenta.
• Riadiaca rovina lokalizuje repozitár projektu a vydáva krátkodobé prihlasovacie údaje na prístup k nemu.
• Služba Git posiela údaje repozitára do sandboxov, prijíma od nich odoslané zmeny a rozhoduje, ktoré odoslanie sa stane najnovším prijatým commitom.
• Úložisko založené na AWS S3 trvalo uchováva údaje repozitárov.
• Nadväzujúce spracovanie extrahuje text a ďalšie užitočné informácie z uložených dokumentov a sprístupňuje ich, keď agenti načítajú alebo obnovia projekt.

Každý agent má vlastný izolovaný sandbox. V ňom pracuje s lokálnou kópiou repozitára, ktorú spravuje malé CLI. CLI požiada riadiacu rovinu o lokalizáciu repozitára a potom načítava a odosiela zmeny cez službu Git. Proxy agenta overuje prístup pri požiadavkách zo sandboxu predtým, než sa dostanú k službe Git. Služba Git číta a zapisuje repozitáre v zdieľanom súborovom systéme a rozhoduje, či sa jednotlivé odoslanie stane najnovším prijatým commitom. Tento súborový systém poskytuje AWS S3Files, vďaka ktorému je úložisko založené na S3 dostupné ako bežné súbory a adresáre. Úložisko je rozdelené na izolované bunky, z ktorých každá má vlastný súborový systém a repliky služby Git. Po prijatí commitu pracovné procesy na pozadí extrahujú text a ďalšie užitočné informácie zo zmenených dokumentov, výsledky ukladajú oddelene od histórie repozitára a sprístupňujú ich, keď agenti načítajú alebo obnovia projekt.

Ďalej si jednotlivé súčasti prejdeme jednu po druhej.

Zväčšiť

CLI: práca s lokálnymi súbormi v sandboxoch

Agenti bežia v SPACE, našej internej platforme pre sandboxy. Každý sandbox obsahuje malé CLI, ktoré materializuje repozitár a udržiava ho synchronizovaný. Za každú jednotku zmysluplnej práce, ktorú agent vykoná, CLI odošle zmeny ako commit.

Agenti zvyčajne pracujú len s malým zlomkom súborov projektu, takže nie je potrebné vopred materializovať celý repozitár. CLI preto materializuje súbory lenivo: veľké a binárne súbory uložené cez Git Large File Storage (LFS) prichádzajú ako malé súbory ukazovateľov so skutočnou veľkosťou objektu, takže agent sa podľa názvu a veľkosti môže rozhodnúť, či sa sťahovanie oplatí. Pri dokumentoch, ako sú PDF, agent najprv prečíta parsovaný text a zdrojové súbory stiahne len v prípade potreby.

Ďalšou prirodzenou možnosťou by bolo použiť virtuálny súborový systém. Otestovali sme implementáciu založenú na FUSE, no pri záťažiach náročných na súborový systém bola približne 400-krát pomalšia než lokálne súbory, pretože každá požiadavka si vyžaduje cestu po sieti tam a späť. Navyše zvyčajne vyžaduje od hostiteľa privilegované oprávnenia, takže každý agent by musel bežať v privilegovanom sandboxe.

Zväčšiť

Riadiaca rovina: lokalizácia repozitárov a vydávanie prístupu

Riadiaca rovina zisťuje, kde je každý repozitár uložený, a vydáva k nemu prístup. Pri vytvorení repozitára mu riadiaca rovina pridelí úložnú bunku – izolovanú jednotku úložiska s vlastnými replikami služby Git. Keď agent začne pracovať na projekte, CLI sa opýta riadiacej roviny, kde je repozitár uložený. Riadiaca rovina vráti umiestnenie a dočasné prihlasovacie údaje pre službu Git. Riadiaca rovina nikdy nečíta ani nezapisuje údaje repozitára. O tom, čo sa dostane do repozitára, rozhoduje služba Git.

Služba Git: presun údajov a koordinácia aktualizácií

Služba Git vykonáva operácie Git a prenáša obsah repozitárov a históriu verzií medzi sandboxmi a úložiskom. Ide o tenký obal okolo vlastných obslužných príkazov Gitu. Podporuje zisťovanie referencií (ref discovery), ktoré klientovi oznamuje, kde sa nachádza head repozitára, upload-pack na klonovanie a načítavanie zmien a receive-pack na prijímanie nových objektov a požiadavky na posunutie headu repozitára. Obsluhuje aj Git LFS API: pre veľké a binárne súbory vydáva krátkodobé odkazy, aby sandboxy mohli tieto súbory priamo nahrávať do S3 a sťahovať z neho.

Začali sme s hotovým forge serverom, aby sme mohli prototypovať rozhrania pre agentov a používateľov súbežne s budovaním vlastnej odľahčenej forge platformy zameranej len na operácie Git, ktoré potrebujeme.

Služba pozostáva z flotily replík, pričom každá je bežiacou inštanciou toho istého servera. Bunka zoskupuje zdieľané úložisko so sadou replík a ich podporných služieb. Repliky v rámci bunky tak môžu pristupovať k rovnakému zdieľanému súborovému systému namiesto toho, aby udržiavali nezávislé kópie každého repozitára.

Vďaka tomuto zdieľanému úložisku môžu repliky zostať bezstavové. Ktorákoľvek replika v bunke môže obsluhovať ktorýkoľvek z jej repozitárov, takže nahradenie alebo pridanie replík nevyžaduje presun údajov repozitárov medzi servermi. Požiadavky na repozitár zvyčajne smerujú na tú istú repliku, aby jej vyrovnávacie pamäte zostali užitočné, no repozitár nezávisí od toho, či táto konkrétna inštancia zostane dostupná.

Krok prijatia kontroluje invarianty repozitára, aby sa zaistilo, že prijatý commit predstavuje platný stav repozitára. Pre každý repozitár definujeme explicitný kontrakt, takže mechanické kontroly mu môžu zabrániť v nadmernom raste. Veľké a binárne súbory, ako sú PDF a obrázky, sa ukladajú cez Git LFS, a nie ako surové Git bloby. Kompakcia zachováva dostupnú nedávnu históriu a zároveň obmedzuje veľkosť repozitára. Po úspešnom odoslaní sa CLI opýta služby Git, či repozitár potrebuje kompakciu. Ak počet uchovaných commitov prekročí prahovú hodnotu, služba Git ponechá iba menšiu množinu najnovších commitov. Staršia história sa nahradí jednou počiatočnou snímkou a nedávne commity sa znova aplikujú, čím sa aktualizujú identifikátory commitov.

Zväčšiť

Súbežných zapisovateľov kontroluje jednoduchý synchronizačný krok. Sleduje najnovší prijatý commit, teda head. Keď prijme odoslanie, akceptuje ho len vtedy, ak bolo postavené na tomto heade. Ak nie, pošle štruktúrovanú odpoveď o zastaranom základe (stale-base); neúspešný agent potom musí svoju zmenu znova aplikovať nad novým headom a odoslať ju znova. Tento návrh zaisťuje, že sa súbežní agenti navzájom potichu neprepisujú, a to bez výrazného spomalenia. V našich produkčných pracovných postupoch sa ako zastarané zamieta menej ako 2 % odoslaní. Celkovo je medián latencie odoslania pod 1,7 sekundy a latencia p99 pod 8 sekúnd.

Zväčšiť

Služba Git tiež zaznamenáva každú prijatú zmenu. Pri každom prijatom zápise pridá záznam do outboxu – logu, ktorý uvádza repozitár, nový commit, používateľa, ktorý zmenu vykonal, a zmenené cesty. Nadväzujúce služby, napríklad parser, čítajú tento log, aby našli novú prácu.

Spolu tieto časti tvoria vrstvu správy repozitárov bez súčastí, ktoré agenti nepotrebujú. Pull requesty sú zbytočné, pretože jednotlivé zmeny nekontroluje žiadny človek. Namiesto toho služba Git pri odoslaní overí kontrakt, agent, ktorý v súbehu neuspeje, znova aplikuje svoju zmenu a história commitov zaznamenáva, kto čo zmenil. Deterministické kontroly udržiavajú každý repozitár v medziach jeho kontraktu, takže pri riadení rastu sa netreba spoliehať na ľudského operátora.

Úložisko: trvalé uchovanie práce

Úložná vrstva trvalo ukladá údaje repozitárov nezávisle od sandboxov a replík služby Git. Repozitáre sú uložené v AWS S3Files, ktoré sprístupňuje úložisko založené na S3 cez rozhranie súborového systému, s ktorým štandardný Git funguje bez úprav. Každý z nich je holý (bare) repozitár Git v zdieľanom súborovom systéme, ktorý obsahuje objekty a referencie repozitára, a nie pracovný checkout.

Oddelenie úložiska od výpočtových prostriedkov umožňuje, aby sandboxy zostali efemérne. Každý agent dostane vlastný sandbox a mnoho agentov môže pracovať na tom istom projekte bez zdieľania stroja. Ak sandbox zlyhá, ohrozená je len práca, ktorá ešte nebola odoslaná.

Namiesto toho by sme mohli každému projektu poskytnúť dlhodobý sandbox, ktorý by zdieľali všetci jeho agenti, takže súbory projektu by sa nachádzali na disku tohto stroja. To by však viazalo výpočtové prostriedky agentov na miesto, kde stroj beží, a vyžadovalo by dimenzovať ho na najvyťaženejšie obdobia. Navyše by musel zostať v dobrom stave celé mesiace, pričom zálohovanie a obnova by sa museli spravovať ako súčasť úložného systému projektu.

Zväčšiť

Nadväzujúce spracovanie: sprístupnenie dokumentov na čítanie agentom

Hlavnou nadväzujúcou súčasťou je pipeline parsera, ktorá z novo pridaných alebo aktualizovaných dokumentov extrahuje text a metadáta, aby agenti mohli súbory projektu ľahko čítať. Pracovný proces parsera odoberá aktualizácie z fronty prúdu zmien, z metadát commitu odvodí zmenené súbory a pomocou hashu obsahu načíta surové bajty. Potom dokument parsuje a vytvorí extrahovaný text a metadáta dokumentu.

Parsované výstupy sa nachádzajú mimo repozitára, v úložisku indexovanom podľa hashu zdrojového dokumentu. Tieto artefakty sa nikdy necommitujú späť do repozitára, pretože by to zbytočne znečisťovalo históriu a zvyšovalo počet súbežných zápisov. Namiesto toho sa parsované výstupy dostávajú do sandboxu prostredníctvom checkoutu a synchronizácie. Každý checkout obsahuje vyhradený adresár, ktorý CLI používa na materializáciu artefaktov. Parsovanie prebieha asynchrónne, takže pracovný proces parsera na pozadí neblokuje checkouty.

Ako agenti používajú pracovný priestor

Agenti skúmajú verziu repozitára načítanú do sandboxu pomocou štandardných nástrojov súborového systému. Namiesto pevného postupu „najprv vyhľadať, potom čítať“ vypisujú obsah priečinkov, vyhľadávajú v obsahu súborov pomocou grep, čítajú relevantné pasáže a na základe zistení sa rozhodujú, kam sa pozrieť ďalej.

Podobne ako Computer, aj Search využíva rovnaký prístup prostredníctvom svojich štandardných nástrojov na prácu so súbormi. Samostatný prieskumný agent prehľadáva projekt s obmedzenejším rozpočtom a vracia relevantné cesty k súborom a podporné úryvky. Model generujúci odpoveď potom prečíta vybrané súbory a vytvorí odpoveď. Opätovné použitie existujúceho sandboxu projektu skracuje čas prípravy: pripojenie k už pripravenému checkoutu trvá približne 2,9 sekundy v porovnaní s približne 8 sekundami pri studenom štarte.

Zväčšiť

Parsovaný text umožňuje prehľadávať väčšie dokumenty, ako sú PDF a súbory Office, rovnakými nástrojmi. Agent najprv skontroluje manifest, teda zoznam dokumentov, pre ktoré je k dispozícii extrahovaný text, a potom tento text prehľadáva a číta ako bežné súbory. Pôvodný dokument stiahne len vtedy, keď text nestačí, napríklad na preskúmanie obrázkov, rozloženia alebo vložených údajov.

Tento prístup sme porovnali so sémantickým vyhľadávaním v indexe na súbore 150 finančných otázok týkajúcich sa jedného dokumentu v rámci toho istého korpusu. Prieskumný agent dosiahol skóre 0,867 pri vyhľadaní správneho dokumentu a 0,627 pri správnych odpovediach, oproti približne 0,39 a 0,37 pri sémantickom vyhľadávaní, teda približne 1,7-krát lepšie výsledky pri odpovediach a 2-krát lepšie pri vyhľadávaní, a to s približne o 25 % nižšou latenciou. Prieskumný agent pracuje prevažne s extrahovaným textom a pôvodné PDF sťahuje len zriedka.

Zväčšiť

Jedna zdieľaná infraštruktúra

Perzistentná pamäť nástroja Computer využíva tú istú infraštruktúru súborového systému. Perplexity Brain, znalostná wiki nástroja Computer, ukladá pamäť do znalostných repozitárov s vlastnou históriou a pravidlami. Oddelenie znalostí od súborov projektu znamená, že aktualizácie pamäte na pozadí nesúperia s úpravami týchto súborov. Relácia, ktorá potrebuje oboje, načíta oba repozitáre.

Agenti na pozadí čítajú existujúce znalosti, začleňujú nové informácie a aktualizované stránky ukladajú ako commity. Ostatní agenti tieto stránky čítajú bežnými nástrojmi na prácu so súbormi a upravovať ich môžu aj ľudia. Zapisovatelia zdieľajú svoju prácu prostredníctvom repozitára namiesto priamej koordinácie s každým čitateľom. História commitov zaznamenáva, kto čo zmenil, zatiaľ čo outbox hlási prijaté aktualizácie nadväzujúcim službám. Ľudia aj agenti môžu nadväzovať na prácu ostatných a zároveň majú záznam o tom, ako sa znalosti vyvíjali.

Záver

Keď ľudia a agenti zdieľajú projekt, pracovný priestor neslúži len na ukladanie súborov. Poskytuje spoločné miesto na spájanie príspevkov a sledovanie zmien. Git už veľkú časť týchto základov poskytuje. Pridávame koordináciu a automatizované kontroly, aby agenti mohli odosielať prácu bez toho, aby každú aktualizáciu schvaľoval človek. Výsledkom je forge platforma zredukovaná na to podstatné, pretože spolupráca medzi agentmi a vývoj softvéru s viacerými prispievateľmi sú v podstate ten istý problém.

Agenti pracujú v nezávislých dočasných sandboxoch a zároveň prispievajú do trvalých repozitárov. Limity repozitárov udržiavajú rast zvládnuteľný, explicitné sťahovanie umožňuje agentom vybrať si, čo načítať, a bežné súbory im umožňujú skúmať obsah pomocou známych nástrojov. Aktualizácie na pozadí, interaktívne úpravy a naplánované úlohy môžu nadväzovať na prácu ostatných bez priamej koordinácie.

Keďže v rámci Projektov pracuje autonómne čoraz viac agentov, ich spoločný pracovný priestor musí zostať spoľahlivý a pre ľudí zrozumiteľný. Cieľ je jednoduchý: každá zmena by mala byť trvácnejšia ako agent, ktorý ju vytvoril, mala by byť dostupná ďalšiemu spolupracovníkovi a zanechať jasný záznam o tom, čo sa zmenilo.

Citácia

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