Изградња заједничких радних простора за људе и агенте

Како Perplexity Пројекти обезбјеђују да дуготрајни рад буде трајан, конкурентан и сљедив.

АуториPerplexity Engineering

Недавно смо покренули Пројекте, у којима људи и агенти заједно раде на дуготрајним задацима у оквиру платформе Perplexity Computer. Сваки пројекат почива на заједничком радном простору са системом датотека који акумулира контекст кроз сесије, агенте и кориснике. Вишекорисничка сарадња која траје мјесецима захтијева трајност, конкурентност и сљедивост:

  • Трајност: Рад треба да траје и након било које појединачне сесије агента или sandbox окружења, како би исти корисник или агент могао касније да га настави, а сви сарадници да се на њега надовежу.
  • Конкурентност: Више корисника у истом пројекту може имати по више агената који паралелно уносе измјене, при чему те измјене надограђују заједничко стање умјесто да се међусобно преписују.
  • Сљедивост: И корисници и агенти треба да могу да виде историју, како би провјерили ко је шта промијенио од њихове посљедње сесије без поновног читања цијелог пројекта и по потреби поништили измјене.

Ови изазови су добро познати софтверским инжењерима. Git forge платформе настале су прије више деценија управо да би одговориле на ове захтјеве: то су хостовани сервиси који контролу верзија обогаћују функцијама за сарадњу, тако да многи сарадници могу да се усагласе око јединственог извора истине. Систем датотека на којем почивају Пројекти је управо таква Git forge платформа, направљена за сарадњу људи и агената, као и агената међусобно.

Један пројекат: интерактивни агенти, заказани агенти и агенти других корисника стичу се у истом репозиторијуму.

Архитектура

Git већ рјешава трајност, конкурентност и сљедивост. Сваку датотеку идентификује по њеном садржају, па се непромијењене датотеке чувају само једном, а сачуване копије никада не застаријевају. Сваки комит чува све ажуриране датотеке одједном, тако да сарадници никада не виде недовршено стање. Када се сударе двије стране које уписују измјене, она која је изгубила може поново примијенити своје измјене на нову верзију и покушати опет. Ланац комита показује ко је шта промијенио и олакшава враћање ранијих верзија. Оно што агентима није потребно јесте остатак forge платформе направљене за људе, попут екрана за преглед, управљања гранама и обавјештења.

Наша архитектура извршава цијели процес у облаку и подржава све облике рада са знањем, не само програмирање. Сваки Computer пројекат почива на Git репозиторијуму који опслужује 5 компонената:

  • CLI одржава локалне checkout копије, синхронизује ажурирања и шаље измјене агента у сваком sandbox окружењу.
  • Контролна раван лоцира репозиторијум пројекта и издаје краткотрајне акредитиве за приступ њему.
  • Git сервис шаље податке репозиторијума у sandbox окружења, прима измјене које она пошаљу и одлучује које слање постаје најновији прихваћени комит.
  • Складиште засновано на AWS S3 трајно чува податке репозиторијума.
  • Низводна обрада издваја текст и друге корисне информације из сачуваних докумената и чини их доступним када агенти учитају или освјеже пројекат.

Сваки агент има сопствено изоловано sandbox окружење. Унутар њега ради са локалном копијом репозиторијума, којом управља мали CLI. CLI тражи од контролне равни да лоцира репозиторијум, а затим преузима и шаље измјене преко Git сервиса. Агентски прокси провјерава приступ за захтјеве из sandbox окружења прије него што стигну до Git сервиса. Git сервис чита и уписује репозиторијуме на заједничком систему датотека и одлучује да ли свако слање постаје најновији прихваћени комит. Тај систем датотека обезбјеђује AWS S3Files, који складиште засновано на S3 чини доступним као обичне датотеке и директоријуме. Складиште је подијељено на изоловане ћелије, од којих свака има сопствени систем датотека и реплике Git сервиса. Након што се комит прихвати, worker процеси у позадини издвајају текст и друге корисне информације из промијењених докумената, чувају резултате одвојено од историје репозиторијума и чине их доступним када агенти учитају или освјеже пројекат.

У наставку редом пролазимо кроз сваку компоненту.

CLI се обраћа контролној равни да би лоцирао свој репозиторијум, а затим преузима и шаље измјене преко Git сервиса, посредством агентског проксија. Git сервис провјерава послате измјене и ажурира прихваћени head и outbox у DynamoDB-у. Реплике локалне за ћелију користе S3Files складиште, док низводни worker процеси издвајају текст за checkout и синхронизацију.

CLI: рад са локалним датотекама у sandbox окружењима

Агенти раде на SPACE платформи, нашој интерној платформи за sandbox окружења. Свако sandbox окружење има мали CLI који материјализује репозиторијум и одржава га синхронизованим. За сваку смислену јединицу рада коју агент обави, CLI шаље измјене као комит.

Агенти обично користе само мали дио датотека пројекта, па није потребно унапријед материјализовати цијели репозиторијум. Због тога CLI материјализује репозиторијум одложено: велике и бинарне датотеке ускладиштене преко Git Large File Storage (LFS) стижу као мале датотеке-показивачи које биљеже стварну величину објекта, тако да агент на основу назива и величине може одлучити да ли се преузимање исплати. За документе као што су PDF-ови, агент прво чита парсирани текст, а изворне датотеке преузима само када је то неопходно.

Још једна природна опција била би употреба виртуелног система датотека. Тестирали смо имплементацију засновану на FUSE технологији, али је на оптерећењима која интензивно користе систем датотека била отприлике 400 пута спорија у поређењу са локалним датотекама, јер сваки захтјев мора да прође кроз мрежу и назад. Поред тога, обично захтијева привилеговане могућности на хосту, па би сваки агент морао да ради у привилегованом sandbox окружењу.

Одлуку доносе величина показивача и манифест парсирања: прочитати парсирани текст, преузети изворну датотеку или прескочити.

Контролна раван: лоцирање репозиторијума и додјела приступа

Контролна раван утврђује гдје је сваки репозиторијум смјештен и додјељује приступ њему. Када се репозиторијум креира, контролна раван га додјељује ћелији за складиштење, изолованој јединици складишта са сопственим репликама Git сервиса. Када агент започне рад на пројекту, CLI пита контролну раван гдје је репозиторијум смјештен. Контролна раван враћа локацију и привремене акредитиве за Git сервис. Контролна раван никада не чита нити уписује податке репозиторијума. Git сервис одлучује шта улази у репозиторијум.

Git сервис: премјештање података и координација ажурирања

Git сервис извршава Git операције и преноси садржај репозиторијума и историју верзија између sandbox окружења и складишта. То је танак омотач око Git-ових сопствених команди за опслуживање. Подржава откривање референци (ref discovery), којим клијенту саопштава гдје се налази head репозиторијума, upload-pack за клонирање и преузимање, као и receive-pack за пријем нових објеката и захтјева за помјерање head-а репозиторијума. Такође опслужује Git LFS API: за велике и бинарне датотеке издаје краткотрајне линкове, тако да sandbox окружења могу те датотеке директно отпремати на S3 и преузимати са њега.

Почели смо са готовим forge сервером, како бисмо могли да израђујемо прототипове интерфејса за агенте и кориснике паралелно са изградњом сопствене лагане forge платформе, усмјерене искључиво на Git операције које су нам потребне.

Сервис се састоји од флоте реплика, од којих је свака покренута инстанца истог сервера. Ћелија обједињује заједничко складиште са скупом реплика и њиховим пратећим сервисима. Реплике унутар ћелије тада могу приступати истом заједничком систему датотека, умјесто да одржавају независне копије сваког репозиторијума.

Ово заједничко складиште омогућава да реплике остану без стања. Било која реплика у ћелији може да опслужује било који од њених репозиторијума, па замјена или додавање реплика не захтијева премјештање података репозиторијума између сервера. Захтјеви за одређени репозиторијум обично иду истој реплици, како би њени кешеви остали корисни, али репозиторијум не зависи од тога да ће баш та инстанца остати доступна.

Корак прихватања провјерава инваријанте репозиторијума како би се осигурало да прихваћени комит представља исправно стање репозиторијума. За сваки репозиторијум дефинишемо експлицитан уговор, тако да механичке провјере могу спријечити да репозиторијум прекомјерно нарасте. Велике и бинарне датотеке, попут PDF-ова и слика, чувају се преко Git LFS-а, а не као сирови Git blob објекти. Сажимање омогућава да недавна историја остане доступна, а истовремено ограничава величину репозиторијума. Након успјешног слања, CLI пита Git сервис да ли репозиторијуму треба сажимање. Ако број задржаних комита пређе одређени праг, Git сервис задржава само мањи скуп најновијих комита. Старија историја замјењује се једним почетним снимком стања, а недавни комити се поново примјењују како би се ажурирали идентификатори комита.

Сажимање задржава најновије комите, спаја старију историју у један коријенски снимак стања и поново примјењује недавне комите са новим идентификаторима; нови head задржава исте датотеке.

Једноставан корак синхронизације контролише истовремене уписе. Он прати најновији прихваћени комит, односно head. Када прими послате измјене, прихвата их само ако су засноване на том head-у. Ако нису, шаље структурисани одговор о застарјелој бази (stale-base); агент који је изгубио тада мора поново да примијени своју измјену на нови head и поново је пошаље. Овакав дизајн осигурава да истовремени агенти не преписују тихо једни друге, а да притом не изазива значајна успоравања. У нашим продукционим токовима рада мање од 2% слања одбија се као застарјело. Укупно гледано, медијанско кашњење слања је испод 1,7 секунди, а p99 кашњење испод 8 секунди.

Два агента истовремено шаљу измјене; једно слање се прихвата, а други агент добија одговор о застарјелој бази, поново примјењује измјену на нови head и поново је шаље.

Git сервис такође биљежи сваку прихваћену измјену. За сваки прихваћени упис додаје ставку у outbox, дневник у којем се наводе репозиторијум, нови комит, корисник који је направио измјену и путање које су промијењене. Низводни сервиси, попут парсера, читају овај дневник да би пронашли нови посао.

Заједно, ови дијелови чине слој за управљање репозиторијумима, без дијелова који агентима нису потребни. Pull request-ови нису потребни, јер ниједна особа не прегледа сваку измјену. Умјесто тога, Git сервис провјерава уговор у тренутку слања, агент који изгуби трку поново примјењује сопствену измјену, а историја комита биљежи ко је шта промијенио. Детерминистичке провјере одржавају сваки репозиторијум у оквирима његовог уговора, умјесто да се ослањају на људског оператера који би управљао растом.

Складиштење: трајно чување рада

Слој складишта трајно чува податке репозиторијума независно од sandbox окружења и реплика Git сервиса. Репозиторијуми се налазе на AWS S3Files, који складиште засновано на S3 излаже кроз интерфејс система датотека који стандардни Git може да користи без измјена. Сваки од њих је bare Git репозиторијум на заједничком систему датотека, који садржи објекте и референце репозиторијума, а не радну копију.

Раздвајање складишта и рачунарских ресурса омогућава да sandbox окружења остану ефемерна. Сваки агент добија сопствено sandbox окружење, а многи агенти могу радити на истом пројекту без дијељења машине. Ако се sandbox окружење сруши, у опасности је само рад који још није послат.

Умјесто тога, могли смо сваком пројекту дати дуговјечно sandbox окружење које дијеле сви његови агенти, тако да би се датотеке пројекта налазиле на диску те машине. Међутим, тиме бисмо рачунарске ресурсе агената везали за мјесто гдје машина ради, а машину бисмо морали да димензионишемо према периодима највећег оптерећења. Такође би морала да остане исправна мјесецима, уз резервне копије и опоравак којима се управља као дијелом система за складиштење пројекта.

Једно дуговјечно sandbox окружење које дијеле агенти пројекта, у поређењу са краткотрајним sandbox окружењима по агенту која до трајног заједничког складишта стижу преко реплика Git сервиса без стања.

Низводна обрада: како документе учинити читљивим за агенте

Главна низводна компонента је цјевовод за парсирање који издваја текст и метаподатке из новододатих или ажурираних докумената, како би агенти лако могли да читају датотеке пројекта. Worker за парсирање преузима ажурирања из реда тока измјена, на основу метаподатака комита утврђује које су датотеке промијењене и преузима сирове бајтове помоћу хеша садржаја. Затим парсира документ да би добио издвојени текст и метаподатке документа.

Парсирани резултати налазе се ван репозиторијума, у складишту у којем је кључ хеш изворног документа. Ови артефакти се никада не комитују назад у репозиторијум, јер би то непотребно загадило историју и повећало број истовремених уписа. Умјесто тога, парсирани резултати стижу у sandbox окружење кроз checkout и синхронизацију. Сваки checkout садржи резервисани директоријум који CLI користи за материјализацију артефаката. Парсирање се одвија асинхроно, тако да worker за парсирање у позадини не блокира checkout операције.

Како агенти користе радни простор

Агенти истражују верзију репозиторијума учитану у sandbox окружење помоћу стандардних алата за рад са системом датотека. Умјесто да прате фиксни ток „прво претрага, па читање“, они прегледају садржај фасцикли, претражују садржај датотека помоћу алата grep, читају релевантне одломке и на основу онога што пронађу одлучују гдје ће сљедеће тражити.

Слично као Computer, и Search користи исти приступ путем својих стандардних алата за рад са датотекама. Засебан истраживачки агент претражује пројекат у оквиру ограниченијег буџета и враћа релевантне путање датотека и пратеће одломке. Модел који одговара затим чита одабране датотеке и генерише одговор. Поновна употреба постојећег sandbox окружења пројекта скраћује вријеме припреме: повезивање на већ загријани checkout траје око 2,9 секунди, у поређењу са отприлике 8 секунди при хладном покретању.

Computer sandbox окружења, истраживачки подагент за Ask, позадински аутори знања и worker процеси за парсирање – сви читају из истог репозиторијума и outbox-а и уписују у њих.

Парсирани текст омогућава да се већи документи, као што су PDF-ови и Office датотеке, претражују истим алатима. Агент прво провјерава манифест, листу која показује за које документе је доступан издвојени текст, а затим тај текст претражује и чита као обичне датотеке. Оригинални документ преузима само када текст није довољан, на примјер да би прегледао илустрације, распоред или уграђене податке.

Овај приступ упоредили смо са семантичком претрагом над индексом на 150 финансијских питања везаних за појединачне документе, над истим корпусом. Истраживачки агент постигао је 0,867 у проналажењу тачног документа и 0,627 у тачном одговарању, наспрам отприлике 0,39 и 0,37 за семантичку претрагу, што је око 1,7 пута боље за одговоре и 2 пута боље за проналажење, уз приближно 25% мање кашњење. Истраживачки агент углавном ради са издвојеним текстом и ријетко преузима оригиналне PDF-ове.

Истраживачки приступ наспрам семантичке претраге датотека на интерном бенчмарку.

Једна заједничка инфраструктура

Трајна меморија коју користи Computer ослања се на исту инфраструктуру система датотека. Perplexity Brain, вики знања за Computer, чува меморију у репозиторијумима знања са сопственом историјом и правилима. Пошто је знање одвојено од датотека пројекта, ажурирања меморије у позадини не конкуришу измјенама тих датотека. Сесија којој је потребно обоје учитава оба репозиторијума.

Агенти у позадини читају постојеће знање, уносе нове информације и чувају ажуриране странице као комите. Други агенти читају те странице обичним алатима за рад са датотекама, а могу их уређивати и људи. Аутори дијеле свој рад преко репозиторијума, умјесто да се директно координишу са сваким читаоцем. Историја комита биљежи ко је шта промијенио, док outbox дневник пријављује прихваћена ажурирања низводним сервисима. Људи и агенти могу да се надовезују на рад једни других, уз запис о томе како се знање развијало.

Закључак

Када људи и агенти дијеле пројекат, радни простор није само мјесто за чување датотека. Он пружа заједничко мјесто за обједињавање доприноса и праћење измјена. Git већ обезбјеђује велики дио тих темеља. Ми додајемо координацију и аутоматизоване провјере, тако да агенти могу да шаљу свој рад, а да особа не мора да одобрава свако ажурирање. Резултат је forge платформа сведена на суштину, јер су сарадња међу агентима и развој софтвера са више сарадника у основи исти проблем.

Агенти раде у независним, привременим sandbox окружењима, а доприносе трајним репозиторијумима. Ограничења репозиторијума држе раст под контролом, експлицитна преузимања омогућавају агентима да сами бирају шта ће преузети, а обичне датотеке им омогућавају да истражују помоћу познатих алата. Ажурирања у позадини, интерактивне измјене и заказани задаци могу да се надовезују на рад једни других без директне координације.

Како све више агената ради аутономно унутар Пројеката, њихов заједнички радни простор мора остати поуздан и разумљив људима. Циљ је једноставан: свака измјена треба да буде трајнија од агента који ју је направио, да постане доступна сљедећем сараднику и да остави јасан запис о томе шта је промијењено.

Цитирање

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