Vytváření sdílených pracovních prostorů pro lidi a agenty

Nedávno jsme spustili projekty, ve kterých lidé a agenti společně pracují na dlouhodobých úlohách v Perplexity Computer. Každý projekt stojí na sdíleném pracovním prostoru se souborovým systémem, který shromažďuje kontext napříč relacemi, agenty a uživateli. Spolupráce více lidí trvající měsíce vyžaduje perzistenci, souběžnost a sledovatelnost:

• Perzistence: Práce by měla přetrvat déle než jednotlivé relace agentů nebo sandboxy, aby v ní mohl stejný uživatel nebo agent později pokračovat a kterýkoli spolupracovník na ní mohl stavět.
• Souběžnost: Více uživatelů ve stejném projektu může mít každý několik agentů, kteří paralelně provádějí úpravy posouvající sdílený stav kupředu, místo aby se navzájem přepisovali.
• Sledovatelnost: Uživatelé i agenti by měli mít přístup k historii, aby mohli zjistit, kdo co od jejich poslední relace změnil, aniž by museli znovu číst celý projekt, a v případě potřeby mohli úpravy vrátit zpět.

Tyto výzvy jsou softwarovým inženýrům povědomé. Právě kvůli těmto požadavkům vznikly před desítkami let Git forge: hostované služby, které doplňují správu verzí o funkce pro spolupráci, aby se mnoho přispěvatelů mohlo sbíhat k jedinému zdroji pravdy. Souborový systém, na kterém stojí projekty, je jednou takovou Git forge, vytvořenou pro spolupráci lidí s agenty i agentů mezi sebou.

Zvětšit

Architektura

Git už perzistenci, souběžnost i sledovatelnost řeší. Každý soubor identifikuje podle jeho obsahu, takže nezměněné soubory se ukládají jen jednou a uložené kopie nikdy nezastarají. Každý commit uloží všechny aktualizované soubory najednou, takže spolupracovníci nikdy neuvidí napůl dokončený stav. Když se dva zapisovatelé střetnou, ten, kdo prohrál, může své změny znovu aplikovat na novou verzi a zkusit to znovu. Řetězec commitů ukazuje, kdo co změnil, a usnadňuje obnovení dřívějších verzí. Agenti ale nepotřebují zbytek forge vytvořené pro lidi, například obrazovky pro revize, správu větví a oznámení.

Naše architektura provozuje celý proces v cloudu a podporuje všechny formy znalostní práce nad rámec programování. Každý projekt v Computeru je založen na repozitáři Git, který obsluhuje 5 komponent:

• CLI v každém sandboxu spravuje lokální checkouty, synchronizuje aktualizace a odesílá změny agenta.
• Řídicí rovina vyhledává repozitář projektu a vydává krátkodobé přihlašovací údaje pro přístup k němu.
• Služba Git posílá data repozitářů do sandboxů, přijímá z nich odeslané změny a rozhoduje, které odeslání se stane nejnovějším přijatým commitem.
• Úložiště založené na AWS S3 trvale uchovává data repozitářů.
• Navazující zpracování extrahuje z uložených dokumentů text a další užitečné informace a zpřístupňuje je, když agenti projekt načítají nebo obnovují.

Každý agent má vlastní izolovaný sandbox. V něm pracuje s lokální kopií repozitáře, kterou spravuje malé CLI. CLI požádá řídicí rovinu o vyhledání repozitáře a poté načítá a odesílá změny přes službu Git. Proxy pro agenty ověřuje přístup u požadavků ze sandboxu dříve, než se dostanou ke službě Git. Služba Git čte a zapisuje repozitáře na sdíleném souborovém systému a rozhoduje, zda se dané odeslání stane nejnovějším přijatým commitem. Tento souborový systém poskytuje služba AWS S3Files, která zpřístupňuje úložiště založené na S3 jako běžné soubory a adresáře. Úložiště je rozděleno do izolovaných buněk, z nichž každá má vlastní souborový systém a repliky služby Git. Po přijetí commitu extrahují workery na pozadí ze změněných dokumentů text a další užitečné informace, ukládají výsledky odděleně od historie repozitáře a zpřístupňují je, když agenti projekt načítají nebo obnovují.

Dále si jednotlivé komponenty projdeme jednu po druhé.

Zvětšit

CLI: práce s lokálními soubory v sandboxech

Agenti běží v SPACE, naší interní platformě pro sandboxy. Každý sandbox obsahuje malé CLI, které materializuje repozitář a udržuje ho synchronizovaný. Za každou jednotku smysluplné práce, kterou agent odvede, CLI odešle změny jako commit.

Agenti obvykle pracují jen s malou částí souborů projektu, takže není nutné materializovat celý repozitář předem. CLI proto materializuje líně: velké a binární soubory uložené přes Git Large File Storage (LFS) přicházejí jako malé soubory s ukazateli, které uchovávají skutečnou velikost objektu, takže se agent podle názvu a velikosti může rozhodnout, zda se stažení vyplatí. U dokumentů, jako jsou PDF, agent nejprve čte parsovaný text a zdrojové soubory stahuje jen v případě potřeby.

Další přirozenou možností by bylo použít virtuální souborový systém. Otestovali jsme implementaci založenou na FUSE, ale při úlohách intenzivně využívajících souborový systém byla zhruba 400krát pomalejší než lokální soubory, protože každý požadavek vyžaduje síťovou komunikaci tam a zpět. Navíc obvykle vyžaduje privilegovaná oprávnění od hostitele, takže by každý agent musel běžet v privilegovaném sandboxu.

Zvětšit

Řídicí rovina: vyhledávání repozitářů a vydávání přístupu

Řídicí rovina zjišťuje, kde je každý repozitář uložen, a vydává k němu přístup. Při vytvoření repozitáře ho řídicí rovina přiřadí k úložné buňce – izolované jednotce úložiště s vlastními replikami služby Git. Když agent začne pracovat na projektu, CLI se řídicí roviny zeptá, kde je repozitář uložen. Řídicí rovina vrátí umístění a dočasné přihlašovací údaje pro službu Git. Řídicí rovina nikdy data repozitáře nečte ani nezapisuje. O tom, co se do repozitáře dostane, rozhoduje služba Git.

Služba Git: přesun dat a koordinace aktualizací

Služba Git provádí operace Gitu a přenáší obsah repozitářů a historii verzí mezi sandboxy a úložištěm. Jde o tenkou vrstvu nad vlastními obslužnými příkazy Gitu. Podporuje zjišťování referencí, které klientovi sděluje, kde se nachází head repozitáře, upload-pack pro klonování a načítání a receive-pack pro příjem nových objektů a požadavku na posunutí headu repozitáře. Obsluhuje také API Git LFS: pro velké a binární soubory vydává krátkodobé odkazy, aby sandboxy mohly tyto soubory nahrávat a stahovat přímo ze S3.

Začali jsme s hotovým serverem typu forge, abychom mohli prototypovat rozhraní pro agenty a uživatele souběžně s vývojem vlastní odlehčené forge zaměřené jen na operace Gitu, které potřebujeme.

Služba se skládá z flotily replik, z nichž každá je běžící instancí stejného serveru. Buňka seskupuje sdílené úložiště se sadou replik a jejich podpůrnými službami. Repliky v rámci buňky pak mohou přistupovat ke stejnému sdílenému souborovému systému, místo aby udržovaly nezávislé kopie všech repozitářů.

Díky tomuto sdílenému úložišti mohou repliky zůstat bezstavové. Kterákoli replika v buňce může obsluhovat kterýkoli z jejích repozitářů, takže výměna nebo přidání replik nevyžaduje přesouvání dat repozitářů mezi servery. Požadavky na daný repozitář obvykle směřují na stejnou repliku, aby její mezipaměti zůstaly užitečné, repozitář však nezávisí na tom, že tato konkrétní instance zůstane dostupná.

Krok přijetí kontroluje invarianty repozitáře, aby bylo zajištěno, že přijatý commit představuje platný stav repozitáře. Pro každý repozitář definujeme explicitní kontrakt, takže mechanické kontroly mohou zabránit jeho přílišnému růstu. Velké a binární soubory, například PDF a obrázky, se ukládají přes Git LFS, nikoli jako surové Git bloby. Kompaktace udržuje nedávnou historii dostupnou a zároveň omezuje velikost repozitáře. Po úspěšném odeslání se CLI zeptá služby Git, zda repozitář potřebuje kompaktaci. Pokud počet uchovaných commitů překročí prahovou hodnotu, služba Git ponechá jen menší sadu nejnovějších commitů. Starší historie se nahradí jediným výchozím snímkem a nedávné commity se znovu přehrají, čímž se aktualizují jejich identifikátory.

Zvětšit

Souběžné zápisy ošetřuje jednoduchý synchronizační krok. Sleduje nejnovější přijatý commit, tzv. head. Když obdrží odeslání, přijme ho jen tehdy, pokud bylo vytvořeno na tomto headu. Pokud ne, pošle strukturovanou odpověď o zastaralé bázi; agent, který prohrál, pak musí svou změnu znovu přehrát nad novým headem a odeslat ji znovu. Tento návrh zajišťuje, že se souběžní agenti potichu nepřepisují navzájem, a to bez výrazného zpomalení. V našich produkčních pracovních postupech je jako zastaralé odmítnuto méně než 2 % odeslání. Celkově je medián latence odeslání pod 1,7 sekundy a latence p99 pod 8 sekund.

Zvětšit

Služba Git také zaznamenává každou přijatou změnu. Ke každému přijatému zápisu přidá záznam do outboxu – protokolu, který uvádí repozitář, nový commit, uživatele, který změnu provedl, a změněné cesty. Navazující služby, například parser, z tohoto protokolu zjišťují novou práci.

Společně tyto části tvoří vrstvu pro správu repozitářů – bez těch součástí, které agenti nepotřebují. Pull requesty nejsou nutné, protože jednotlivé změny nekontroluje žádný člověk. Místo toho služba Git při odeslání ověří kontrakt, agent, který prohraje souběh, znovu aplikuje svou změnu a historie commitů zaznamenává, kdo co změnil. Deterministické kontroly udržují každý repozitář v mezích jeho kontraktu, místo aby růst musel hlídat lidský operátor.

Úložiště: trvalé uchování práce

Vrstva úložiště trvale ukládá data repozitářů nezávisle na sandboxech a replikách služby Git. Repozitáře jsou uloženy ve službě AWS S3Files, která zpřístupňuje úložiště založené na S3 prostřednictvím rozhraní souborového systému, jež může standardní Git používat bez úprav. Každý z nich je holý (bare) repozitář Git na sdíleném souborovém systému, který obsahuje objekty a reference repozitáře, nikoli pracovní checkout.

Oddělení úložiště od výpočetního výkonu umožňuje, aby sandboxy zůstaly dočasné. Každý agent dostane vlastní sandbox a mnoho agentů může pracovat na stejném projektu, aniž by sdíleli stroj. Pokud sandbox spadne, ohrožena je jen práce, která ještě nebyla odeslána.

Místo toho bychom mohli každému projektu přidělit dlouhodobě běžící sandbox sdílený všemi jeho agenty, takže by soubory projektu byly uloženy na disku tohoto stroje. Tím bychom ale výpočetní výkon agentů svázali s místem, kde stroj běží, a museli bychom ho dimenzovat na nejvytíženější období. Navíc by musel zůstat v dobrém stavu po celé měsíce, se zálohami a obnovou spravovanými v rámci úložného systému projektu.

Zvětšit

Navazující zpracování: zpřístupnění dokumentů agentům ke čtení

Hlavní navazující komponentou je parsovací pipeline, která z nově přidaných nebo aktualizovaných dokumentů extrahuje text a metadata, aby byly soubory projektu pro agenty snadno čitelné. Parsovací worker odebírá aktualizace z fronty proudu změn, z metadat commitu odvodí změněné soubory a pomocí hashe obsahu načte nezpracované bajty. Poté dokument zparsuje a vytvoří extrahovaný text a metadata dokumentu.

Parsované výstupy jsou uloženy mimo repozitář, v úložišti indexovaném podle hashe zdrojového dokumentu. Tyto artefakty se nikdy necommitují zpět do repozitáře, protože by to zbytečně zaneřádilo historii a zvýšilo počet souběžných zápisů. Místo toho se parsované výstupy dostávají do sandboxu prostřednictvím checkoutu a synchronizace. Každý checkout obsahuje vyhrazený adresář, který CLI používá k materializaci artefaktů. Parsování probíhá asynchronně, takže parsovací worker na pozadí neblokuje checkouty.

Jak agenti pracovní prostor využívají

Agenti prozkoumávají verzi repozitáře načtenou do sandboxu pomocí standardních nástrojů souborového systému. Místo pevně daného postupu „nejdřív vyhledat, pak číst“ vypisují složky, prohledávají obsah souborů pomocí grep, čtou relevantní pasáže a podle toho, co najdou, se rozhodují, kam se podívat dál.

Podobně jako Computer využívá stejný přístup i Search prostřednictvím svých standardních souborových nástrojů. Samostatný průzkumný agent prohledává projekt s omezenějším rozpočtem a vrací relevantní cesty k souborům a podpůrné úryvky. Model generující odpověď pak vybrané soubory přečte a vytvoří odpověď. Opětovné použití existujícího sandboxu projektu zkracuje dobu přípravy: připojení k zahřátému checkoutu trvá asi 2,9 sekundy, zatímco studený start zhruba 8 sekund.

Zvětšit

Díky parsovanému textu lze stejnými nástroji prohledávat i větší dokumenty, jako jsou PDF a soubory Office. Agent nejprve zkontroluje manifest – seznam dokumentů, pro které je k dispozici extrahovaný text – a poté tento text prohledává a čte jako běžné soubory. Původní dokument stahuje jen tehdy, když text nestačí, například kvůli kontrole obrázků, rozvržení nebo vložených dat.

Tento přístup jsme porovnali se sémantickým vyhledáváním nad indexem na 150 finančních otázkách týkajících se jednoho dokumentu ze stejného korpusu. Průzkumný agent dosáhl skóre 0,867 při vyhledání správného dokumentu a 0,627 při správném zodpovězení, oproti zhruba 0,39 a 0,37 u sémantického vyhledávání – tedy přibližně 1,7× lepší výsledky u odpovědí a 2× lepší u vyhledávání, a to při zhruba o 25 % nižší latenci. Průzkumný agent pracuje převážně s extrahovaným textem a původní PDF stahuje jen zřídka.

Zvětšit

Jedna sdílená infrastruktura

Trvalá paměť Computeru využívá stejnou infrastrukturu souborového systému. Perplexity Brain, znalostní wiki Computeru, ukládá paměť do znalostních repozitářů s vlastní historií a pravidly. Díky oddělení znalostí od souborů projektu nekonkurují aktualizace paměti na pozadí úpravám těchto souborů. Relace, která potřebuje obojí, načte oba repozitáře.

Agenti na pozadí čtou existující znalosti, začleňují nové informace a ukládají aktualizované stránky jako commity. Ostatní agenti tyto stránky čtou běžnými souborovými nástroji a upravovat je mohou i lidé. Zapisovatelé sdílejí svou práci prostřednictvím repozitáře, místo aby se přímo koordinovali s každým čtenářem. Historie commitů zaznamenává, kdo co změnil, zatímco outbox hlásí přijaté aktualizace navazujícím službám. Lidé i agenti mohou stavět na práci ostatních a mají přitom záznam o tom, jak se znalosti vyvíjely.

Závěr

Když lidé a agenti sdílejí projekt, pracovní prostor neslouží jen k ukládání souborů. Poskytuje společné místo, kde se spojují příspěvky a sleduje se, co se změnilo. Velkou část tohoto základu už poskytuje Git. My přidáváme koordinaci a automatizované kontroly, aby agenti mohli odesílat práci, aniž by každou aktualizaci musel schvalovat člověk. Výsledkem je forge zredukovaná na to podstatné, protože spolupráce mezi agenty a vývoj softwaru s více přispěvateli jsou v jádru tentýž problém.

Agenti pracují v nezávislých dočasných sandboxech a přitom přispívají do trvalých repozitářů. Limity repozitářů udržují růst pod kontrolou, explicitní stahování umožňuje agentům vybrat si, co načtou, a běžné soubory jim dovolují zkoumat obsah známými nástroji. Aktualizace na pozadí, interaktivní úpravy a plánované úlohy mohou navazovat na práci ostatních bez přímé koordinace.

S tím, jak v projektech autonomně pracuje stále více agentů, musí jejich sdílený pracovní prostor zůstat spolehlivý a pro lidi srozumitelný. Cíl je jednoduchý: každá změna by měla přetrvat déle než agent, který ji vytvořil, být k dispozici dalšímu spolupracovníkovi a zanechat jasný záznam o tom, co se změnilo.

Citace

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