Bendrų darbo erdvių kūrimas žmonėms ir agentams

Kaip Perplexity projektai užtikrina ilgai trunkančio darbo išliekamumą, lygiagretumą ir atsekamumą.

AutoriaiPerplexity Engineering

Neseniai pristatėme funkciją Projektai, kurioje žmonės ir agentai kartu dirba su ilgalaikėmis užduotimis Perplexity Computer aplinkoje. Kiekvienas projektas veikia bendroje darbo erdvėje su failų sistema, kuri kaupia kontekstą iš įvairių sesijų, agentų ir naudotojų. Mėnesius trunkančiam kelių dalyvių bendradarbiavimui reikia išliekamumo, lygiagretumo ir atsekamumo:

  • Išliekamumas: darbas turi išlikti ilgiau nei bet kuri atskira agento sesija ar sandbox aplinka, kad ateityje jį galėtų tęsti tas pats naudotojas ar agentas ir toliau plėtoti bet kurie bendradarbiai.
  • Lygiagretumas: kiekvienas iš kelių to paties projekto naudotojų gali turėti po kelis agentus, kurie lygiagrečiai atlieka pakeitimus ir plėtoja bendrą būseną, o ne perrašo vienas kito darbą.
  • Atsekamumas: tiek naudotojai, tiek agentai turėtų matyti istoriją, kad galėtų patikrinti, kas ką pakeitė nuo jų paskutinės sesijos, neperskaitydami viso projekto iš naujo, ir prireikus atšaukti pakeitimus.

Šie iššūkiai programinės įrangos inžinieriams atrodo pažįstami. Git forge platformos atsirado prieš kelis dešimtmečius būtent šiems poreikiams patenkinti: tai talpinama paslauga, kuri versijų valdymą papildo bendradarbiavimo funkcijomis, kad daugelis prisidedančiųjų galėtų dirbti su vienu bendru tiesos šaltiniu. Failų sistema, kuria grindžiami projektai, yra viena tokių Git forge platformų, sukurta žmonių ir agentų bei agentų tarpusavio bendradarbiavimui.

Vienas projektas: interaktyvūs agentai, suplanuoti agentai ir kitų naudotojų agentai – visi dirba toje pačioje saugykloje.

Architektūra

Git jau užtikrina išliekamumą, lygiagretumą ir atsekamumą. Kiekvieną failą jis identifikuoja pagal turinį, todėl nepakitę failai saugomi vieną kartą, o išsaugotos kopijos niekada nepasensta. Kiekvienas commit'as visus atnaujintus failus išsaugo vienu metu, todėl bendradarbiai niekada nemato pusiau baigtos būsenos. Kai susiduria du rašantieji, pralaimėjęs gali iš naujo pritaikyti savo pakeitimus naujajai versijai ir bandyti dar kartą. Commit'ų grandinė rodo, kas ką pakeitė, ir leidžia lengvai atkurti ankstesnes versijas. Agentams nereikia likusios žmonėms sukurtos forge platformos dalies, pavyzdžiui, peržiūros ekranų, šakų valdymo ir pranešimų.

Mūsų architektūra visą procesą vykdo debesyje ir palaiko visų formų žinių darbą, ne tik programavimą. Kiekvienas Computer projektas remiasi Git saugykla, kurią aptarnauja 5 komponentai:

  • CLI kiekvienoje sandbox aplinkoje prižiūri vietines darbines kopijas, sinchronizuoja atnaujinimus ir pateikia agento pakeitimus.
  • Valdymo plokštuma nustato projekto saugyklos vietą ir išduoda trumpalaikius prisijungimo prie jos duomenis.
  • Git paslauga siunčia saugyklų duomenis į sandbox aplinkas, gauna jų pateikimus ir nusprendžia, kuris pateikimas tampa naujausiu priimtu commit'u.
  • AWS S3 pagrindu veikianti saugojimo sistema patvariai saugo saugyklų duomenis.
  • Tolesnės grandies apdorojimas iš išsaugotų dokumentų išgauna tekstą ir kitą naudingą informaciją bei pateikia ją, kai agentai įkelia ar atnaujina projektą.

Kiekvienas agentas turi savo izoliuotą sandbox aplinką. Joje jis dirba su vietine saugyklos kopija, kurią valdo nedidelis CLI įrankis. CLI paprašo valdymo plokštumos surasti saugyklą, tada per Git paslaugą parsiunčia ir pateikia pakeitimus. Agento tarpinis serveris patikrina sandbox užklausų prieigos teises, prieš joms pasiekiant Git paslaugą. Git paslauga skaito ir rašo saugyklas bendroje failų sistemoje ir nusprendžia, ar kiekvienas pateikimas tampa naujausiu priimtu commit'u. Šią failų sistemą teikia AWS S3Files paslauga, leidžianti S3 pagrindu veikiančią saugojimo sistemą pasiekti kaip įprastus failus ir katalogus. Saugojimo sistema padalyta į izoliuotas celes, kurių kiekviena turi savo failų sistemą ir Git paslaugos replikas. Priėmus commit'ą, foniniai darbo procesai iš pakeistų dokumentų išgauna tekstą ir kitą naudingą informaciją, rezultatus saugo atskirai nuo saugyklos istorijos ir pateikia juos, kai agentai įkelia ar atnaujina projektą.

Toliau aptarsime kiekvieną komponentą atskirai.

CLI kreipiasi į valdymo plokštumą, kad surastų savo saugyklą, tada per agento tarpinį serverį parsiunčia duomenis iš Git paslaugos ir pateikia jai pakeitimus. Git paslauga tikrina pateikimus ir atnaujina priimtą head'ą bei siunčiamųjų žurnalą DynamoDB duomenų bazėje. Celės vietinės replikos naudoja S3Files saugojimo sistemą, o tolesnės grandies darbo procesai išgauna tekstą darbinių kopijų kūrimui ir sinchronizavimui.

CLI: darbas su vietiniais failais sandbox aplinkose

Agentai veikia SPACE – mūsų pačių sukurtoje sandbox platformoje. Kiekvienoje sandbox aplinkoje yra nedidelis CLI įrankis, kuris materializuoja saugyklą ir palaiko jos sinchronizaciją. Už kiekvieną prasmingą agento atliktą darbo vienetą jis pateikia pakeitimus kaip commit'ą.

Agentai paprastai paliečia tik nedidelę projekto failų dalį, todėl nebūtina iš anksto materializuoti visos saugyklos. Dėl to CLI materializuoja tingiai: dideli ir dvejetainiai failai, saugomi per Git Large File Storage (LFS), atkeliauja kaip maži rodyklių failai, kuriuose nurodytas tikrasis objekto dydis, tad agentas pagal pavadinimą ir dydį gali nuspręsti, ar verta failą atsisiųsti. Tokių dokumentų kaip PDF atveju agentas pirmiausia skaito išanalizuotą tekstą, o šaltinio failus atsisiunčia tik tada, kai būtina.

Kita natūrali galimybė būtų naudoti virtualią failų sistemą. Išbandėme FUSE pagrindu veikiantį įgyvendinimą, tačiau intensyviai failų sistemą naudojančiose darbo apkrovose jis buvo maždaug 400 kartų lėtesnis nei vietiniai failai, nes kiekvienai užklausai reikia kelionės tinklu pirmyn ir atgal. Be to, jam paprastai reikia privilegijuotų pagrindinės sistemos teisių, todėl kiekvienas agentas turėtų veikti privilegijuotoje sandbox aplinkoje.

Sprendimą lemia rodyklėje nurodytas dydis ir analizės manifestas: skaityti išanalizuotą tekstą, atsisiųsti šaltinį arba praleisti.

Valdymo plokštuma: saugyklų vietos nustatymas ir prieigos suteikimas

Valdymo plokštuma nustato, kur laikoma kiekviena saugykla, ir suteikia prieigą prie jos. Sukūrus saugyklą, valdymo plokštuma priskiria ją saugojimo celei – izoliuotam saugojimo vienetui su savomis Git paslaugos replikomis. Kai agentas pradeda dirbti su projektu, CLI paklausia valdymo plokštumos, kur laikoma saugykla. Valdymo plokštuma grąžina vietą ir laikinus prisijungimo prie Git paslaugos duomenis. Valdymo plokštuma niekada neskaito ir nerašo saugyklos duomenų. Tai, kas patenka į saugyklą, sprendžia Git paslauga.

Git paslauga: duomenų perdavimas ir atnaujinimų koordinavimas

Git paslauga vykdo Git operacijas ir perduoda saugyklos turinį bei versijų istoriją tarp sandbox aplinkų ir saugojimo sistemos. Ji yra plonas apvalkalas aplink paties Git aptarnavimo komandas. Ji palaiko nuorodų (ref) aptikimą, kuris klientui praneša, kur yra saugyklos head'as, upload-pack – klonavimui ir parsiuntimui, ir receive-pack – naujiems objektams priimti kartu su užklausa paslinkti saugyklos head'ą. Ji taip pat aptarnauja Git LFS API: dideliems ir dvejetainiams failams ji išduoda trumpalaikes nuorodas, kad sandbox aplinkos galėtų tiesiogiai įkelti tuos failus į S3 ir atsisiųsti iš jo.

Pradėjome nuo standartinio forge serverio, kad galėtume kurti agentų ir naudotojų sąsajų prototipus tuo pačiu metu, kai kūrėme savo lengvą forge platformą, skirtą tik mums reikalingoms Git operacijoms.

Paslaugą sudaro replikų parkas – kiekviena replika yra veikiantis to paties serverio egzempliorius. Celė sujungia bendrą saugojimo sistemą su replikų rinkiniu ir jas palaikančiomis paslaugomis. Tada vienos celės replikos gali pasiekti tą pačią bendrą failų sistemą, užuot kiekviena laikiusi atskiras visų saugyklų kopijas.

Ši bendra saugojimo sistema leidžia replikoms išlikti be būsenos. Bet kuri celės replika gali aptarnauti bet kurią celės saugyklą, todėl keičiant ar pridedant replikas nereikia perkelti saugyklų duomenų tarp serverių. Užklausos dėl konkrečios saugyklos paprastai siunčiamos tai pačiai replikai, kad jos podėliai išliktų naudingi, tačiau saugykla nepriklauso nuo to, ar tas konkretus egzempliorius lieka pasiekiamas.

Priėmimo etapas tikrina saugyklos invariantus, kad priimtas commit'as visada atitiktų galiojančią saugyklos būseną. Kiekvienai saugyklai apibrėžiame aiškią sutartį, todėl mechaniniai patikrinimai gali neleisti saugyklai per daug išaugti. Dideli ir dvejetainiai failai, pavyzdžiui, PDF dokumentai ir vaizdai, saugomi naudojant Git LFS, o ne kaip neapdoroti Git blob objektai. Sutankinimas išsaugo naujausią istoriją ir kartu riboja saugyklos dydį. Po sėkmingo pateikimo CLI paklausia Git paslaugos, ar saugyklą reikia sutankinti. Jei išsaugotų commit'ų skaičius viršija nustatytą ribą, Git paslauga palieka tik mažesnį naujausių commit'ų rinkinį. Senesnė istorija pakeičiama viena pradine momentine kopija, o naujausi commit'ai atkuriami iš naujo, kad būtų atnaujinti jų identifikatoriai.

Sutankinimas išsaugo naujausius commit'us, senesnę istoriją sujungia į vieną momentinės kopijos šaknį ir atkuria naujausius commit'us su naujais identifikatoriais; naujajame head'e lieka tie patys failai.

Lygiagretų rašymą tvarko paprastas sinchronizavimo žingsnis. Jis seka naujausią priimtą commit'ą, vadinamąjį head'ą. Gavęs pateikimą, jis jį priima tik tuo atveju, jei pateikimas buvo sukurtas ant to head'o. Jei ne, jis siunčia struktūrizuotą pasenusios bazės atsaką; tada pralaimėjęs agentas turi atkurti savo pakeitimą ant naujojo head'o ir pateikti jį iš naujo. Toks dizainas užtikrina, kad lygiagrečiai dirbantys agentai tyliai neperrašytų vienas kito pakeitimų, ir dėl to darbas reikšmingai nesulėtėja. Mūsų gamybinėse darbo eigose mažiau nei 2 % pateikimų atmetami kaip pasenę. Apskritai pateikimo delsos mediana yra mažesnė nei 1,7 sekundės, o p99 delsa – mažesnė nei 8 sekundės.

Du agentai pateikia pakeitimus vienu metu; vieno pateikimas priimamas, o kitas gauna pasenusios bazės atsaką, atkuria pakeitimą ant naujojo head'o ir pateikia iš naujo.

Git paslauga taip pat fiksuoja kiekvieną priimtą pakeitimą. Po kiekvieno priimto rašymo veiksmo ji prideda įrašą į siunčiamųjų žurnalą (outbox), kuriame nurodoma saugykla, naujasis commit'as, pakeitimą atlikęs naudotojas ir pakeisti keliai. Tolesnės grandies paslaugos, pavyzdžiui, analizatorius, skaito šį žurnalą, kad rastų naujų užduočių.

Kartu šios dalys sudaro saugyklų valdymo sluoksnį – be tų dalių, kurių agentams nereikia. Pull request čia nereikalingi, nes nė vieno pakeitimo neperžiūri žmogus. Vietoj to Git paslauga tikrina sutartį pateikimo metu, lenktynes pralaimėjęs agentas iš naujo pritaiko savo pakeitimą, o commit'ų istorija fiksuoja, kas ką pakeitė. Deterministiniai patikrinimai užtikrina, kad kiekviena saugykla neperžengtų savo sutarties ribų, todėl nereikia pasikliauti žmogumi operatoriumi, kuris valdytų jos augimą.

Saugojimas: darbo patvarumo užtikrinimas

Saugojimo sluoksnis patvariai išsaugo saugyklų duomenis nepriklausomai nuo sandbox aplinkų ir Git paslaugos replikų. Saugyklos laikomos AWS S3Files – paslaugoje, kuri S3 pagrindu veikiančią saugojimo sistemą pateikia per failų sistemos sąsają, todėl standartinis Git ją gali naudoti be jokių pakeitimų. Kiekviena saugykla yra plika (bare) Git saugykla bendroje failų sistemoje, kurioje yra saugyklos objektai ir nuorodos, o ne darbinė kopija.

Atskyrus saugojimą nuo skaičiavimų, sandbox aplinkos gali likti trumpalaikės. Kiekvienas agentas gauna savo sandbox aplinką, ir daug agentų gali dirbti su tuo pačiu projektu, nesidalydami vienu kompiuteriu. Jei sandbox aplinka sugenda, rizikuojama tik dar nepateiktu darbu.

Vietoj to galėtume kiekvienam projektui suteikti ilgalaikę sandbox aplinką, kuria dalytųsi visi jo agentai, ir projekto failai būtų laikomi to kompiuterio diske. Tačiau tada agentų skaičiavimo ištekliai būtų susieti su vieta, kur veikia tas kompiuteris, o jo pajėgumai turėtų atitikti didžiausios apkrovos laikotarpius. Be to, jis turėtų veikti be sutrikimų ištisus mėnesius, o atsarginės kopijos ir atkūrimas būtų valdomi kaip projekto saugojimo sistemos dalis.

Viena ilgalaikė sandbox aplinka, kuria dalijasi projekto agentai, palyginti su trumpalaikėmis kiekvienam agentui skirtomis sandbox aplinkomis, kurios per be būsenos veikiančias Git paslaugos replikas pasiekia patvarią bendrą saugojimo sistemą.

Tolesnės grandies apdorojimas: dokumentų parengimas agentams skaityti

Pagrindinis tolesnės grandies komponentas – analizės konvejeris, kuris iš naujai pridėtų ar atnaujintų dokumentų išgauna tekstą ir metaduomenis, kad agentai galėtų lengvai skaityti projekto failus. Analizatoriaus darbo procesas gauna atnaujinimus iš pakeitimų srauto eilės, pagal commit'o metaduomenis nustato pakeistus failus ir pagal turinio maišos reikšmę parsiunčia neapdorotus baitus. Tada jis išanalizuoja dokumentą ir pateikia išgautą tekstą bei dokumento metaduomenis.

Analizės rezultatai laikomi už saugyklos ribų – atskiroje saugojimo sistemoje, kurioje raktas yra šaltinio dokumento maišos reikšmė. Šie artefaktai niekada neįrašomi atgal į saugyklą kaip commit'ai, nes tai be reikalo terštų istoriją ir didintų lygiagrečių įrašymų skaičių. Vietoj to analizės rezultatai pasiekia sandbox aplinką per darbinės kopijos kūrimą ir sinchronizavimą. Kiekvienoje darbinėje kopijoje yra rezervuotas katalogas, kurį CLI naudoja artefaktams materializuoti. Analizė vyksta asinchroniškai, todėl foninis analizatoriaus darbo procesas neblokuoja darbinių kopijų kūrimo.

Kaip agentai naudojasi darbo erdve

Agentai tyrinėja į sandbox aplinką įkeltą saugyklos versiją standartiniais failų sistemos įrankiais. Užuot laikęsi fiksuoto proceso „pirma ieškoti, tada skaityti“, jie peržiūri aplankų turinį, ieško failuose naudodami grep, skaito aktualias ištraukas ir pagal tai, ką randa, sprendžia, kur ieškoti toliau.

Kaip ir Computer, Paieška taiko tą patį metodą, naudodama standartinius failų įrankius. Atskiras tyrinėjimo agentas ieško projekte, laikydamasis griežtesnio biudžeto, ir grąžina aktualių failų kelius bei patvirtinančias ištraukas. Tada atsakymą formuojantis modelis perskaito pasirinktus failus ir sugeneruoja atsakymą. Pakartotinai panaudojus esamą projekto sandbox aplinką, sutrumpėja paruošimo laikas: prisijungimas prie jau paruoštos darbinės kopijos trunka apie 2,9 sekundės, o šaltasis paleidimas – maždaug 8 sekundes.

Computer sandbox aplinkos, Ask tyrinėjimo subagentas, foniniai žinių rašytojai ir analizatorių darbo procesai – visi skaito iš tos pačios saugyklos ir siunčiamųjų žurnalo bei į juos rašo.

Išanalizuotas tekstas leidžia tais pačiais įrankiais ieškoti ir didesniuose dokumentuose, pavyzdžiui, PDF ir Office failuose. Agentas pirmiausia patikrina manifestą – sąrašą, rodantį, kuriems dokumentams yra išgautas tekstas, – tada ieško ir skaito tą tekstą kaip įprastus failus. Originalų dokumentą jis atsisiunčia tik tada, kai teksto nepakanka, pavyzdžiui, norint išnagrinėti paveikslus, maketą ar įterptus duomenis.

Šį metodą palyginome su semantine paieška indekse, naudodami 150 finansinių klausimų apie atskirus to paties korpuso dokumentus. Tyrinėjimo agentas surinko 0,867 balo už tinkamo dokumento suradimą ir 0,627 už teisingą atsakymą, o semantinė paieška – atitinkamai apie 0,39 ir 0,37. Tai maždaug 1,7 karto geresni atsakymai ir 2 kartus geresnis dokumentų suradimas, o delsa – apie 25 % mažesnė. Tyrinėjimo agentas daugiausia dirba su išgautu tekstu ir retai atsisiunčia originalius PDF failus.

Tyrinėjimo ir semantinės failų paieškos palyginimas pagal vidinį etaloninį testą.

Viena bendra infrastruktūra

Nuolatinė Computer atmintis naudoja tą pačią failų sistemos infrastruktūrą. Perplexity Brain – Computer žinių wiki – saugo atmintį žinių saugyklose, turinčiose savo istoriją ir taisykles. Kadangi žinios laikomos atskirai nuo projekto failų, foniniai atminties atnaujinimai nekonkuruoja su tų failų redagavimais. Sesija, kuriai reikia abiejų, įkelia abi saugyklas.

Foniniai agentai skaito esamas žinias, įtraukia naują informaciją ir išsaugo atnaujintus puslapius kaip commit'us. Kiti agentai tuos puslapius skaito įprastais failų įrankiais, o žmonės taip pat gali juos redaguoti. Rašantieji dalijasi savo darbu per saugyklą, o ne koordinuodamiesi tiesiogiai su kiekvienu skaitytoju. Commit'ų istorija fiksuoja, kas ką pakeitė, o siunčiamųjų žurnalas (outbox) praneša apie priimtus atnaujinimus tolesnės grandies paslaugoms. Žmonės ir agentai gali remtis vienas kito darbu, o kartu išlieka įrašas apie tai, kaip žinios keitėsi.

Išvados

Kai žmonės ir agentai dalijasi projektu, darbo erdvė ne tik saugo failus. Ji suteikia bendrą vietą indėliams sujungti ir pakeitimams sekti. Didelę dalį šio pagrindo jau suteikia Git. Mes pridedame koordinavimą ir automatinius patikrinimus, kad agentai galėtų pateikti darbą, nelaukdami, kol žmogus patvirtins kiekvieną atnaujinimą. Rezultatas – iki esmės supaprastinta forge platforma, nes agentų tarpusavio bendradarbiavimas ir programinės įrangos kūrimas su daugeliu prisidedančiųjų iš esmės yra ta pati problema.

Agentai dirba nepriklausomose laikinose sandbox aplinkose ir kartu prisideda prie patvarių saugyklų. Saugyklų apribojimai padeda suvaldyti augimą, aiškūs atsisiuntimai leidžia agentams patiems rinktis, ką parsisiųsti, o dėl įprastų failų jie gali tyrinėti turinį pažįstamais įrankiais. Foniniai atnaujinimai, interaktyvūs redagavimai ir suplanuotos užduotys gali remtis vienas kito rezultatais be tiesioginio koordinavimo.

Kai vis daugiau agentų projektuose dirba savarankiškai, jų bendra darbo erdvė turi išlikti patikima ir suprantama žmonėms. Tikslas paprastas: kiekvienas pakeitimas turi išlikti ilgiau už jį sukūrusį agentą, tapti prieinamas kitam bendradarbiui ir palikti aiškų įrašą apie tai, kas pasikeitė.

Citavimas

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