Jagatud tööruumide loomine inimestele ja agentidele

Kuidas Perplexity Projektid hoiavad pikaajalise töö püsivana, samaaegsena ja jälgitavana.

AutoridPerplexity Engineering

Hiljuti tõime turule Projektid, kus inimesed ja agendid teevad Perplexity Computeris koos pikaajalisi ülesandeid. Iga projekt toetub jagatud tööruumile, mille failisüsteem kogub konteksti seansside, agentide ja kasutajate lõikes. Kuude pikkune mitme osalejaga koostöö nõuab püsivust, samaaegsust ja jälgitavust:

  • Püsivus: töö peaks säilima kauem kui ükski üksik agendi seanss või liivakast, et sama kasutaja või agent saaks tulevikus tööd jätkata ja iga kaastöötaja saaks sellele tugineda.
  • Samaaegsus: sama projekti mitmel kasutajal võib igaühel olla mitu agenti, kes teevad paralleelselt muudatusi, mis viivad jagatud olekut edasi, selle asemel et üksteist üle kirjutada.
  • Jälgitavus: nii kasutajad kui ka agendid peaksid nägema ajalugu, et kontrollida, kes mida pärast nende viimast seanssi muutis, ilma kogu projekti uuesti läbi lugemata, ning vajaduse korral muudatusi tagasi võtta.

Need väljakutsed on tarkvarainseneridele tuttavad. Git-platvormid (ingl forge) tekkisid aastakümneid tagasi just nende nõuete täitmiseks: need on majutatud teenused, mis ühendavad versioonihalduse koostööfunktsioonidega, et paljud kaastöötajad saaksid koonduda ühe tõeallika ümber. Projektide aluseks olev failisüsteem on üks selline Git-platvorm, mis on loodud inimeste ja agentide ning agentidevahelise koostöö jaoks.

Üks projekt: interaktiivsed agendid, ajastatud agendid ja teiste kasutajate agendid koonduvad kõik samasse hoidlasse.

Arhitektuur

Git tegeleb juba püsivuse, samaaegsuse ja jälgitavusega. See tuvastab iga faili selle sisu järgi, nii et muutmata failid salvestatakse ühe korra ja salvestatud koopiad ei aegu kunagi. Iga kommit salvestab kõik uuendatud failid korraga, nii et kaastöötajad ei näe kunagi poolikut olekut. Kui kaks kirjutajat põrkuvad, saab kaotaja oma muudatused uuele versioonile uuesti rakendada ja proovida veel kord. Kommitite ahel näitab, kes mida muutis, ja muudab varasemate versioonide taastamise lihtsaks. Agendid ei vaja aga ülejäänud osa inimestele loodud Git-platvormist, näiteks ülevaatuskuvasid, harude haldust ja märguandeid.

Meie arhitektuur käitab kogu protsessi pilves ja toetab lisaks programmeerimisele kõiki teadmustöö vorme. Iga Computeri projekti aluseks on Giti hoidla, mida teenindab 5 komponenti:

  • CLI haldab igas liivakastis kohalikke väljavõtteid, sünkroonib uuendusi ja esitab agendi muudatused.
  • Juhttasand leiab projekti hoidla ja väljastab sellele juurdepääsuks lühiajalised mandaadid.
  • Giti teenus saadab hoidla andmed liivakastidesse, võtab vastu nende esitused ja otsustab, milline esitus saab viimaseks aktsepteeritud kommitiks.
  • AWS S3-põhine salvestus talletab hoidla andmeid püsivalt.
  • Järeltöötlus eraldab salvestatud dokumentidest teksti ja muud kasulikku teavet ning teeb selle kättesaadavaks, kui agendid projekti laadivad või värskendavad.

Igal agendil on oma isoleeritud liivakast. Selles liivakastis töötab agent hoidla kohaliku koopiaga, mida haldab väike CLI. CLI palub juhttasandil hoidla leida ning seejärel tõmbab ja esitab muudatusi Giti teenuse kaudu. Agendipuhverserver kontrollib liivakasti päringute juurdepääsuõigusi enne, kui need jõuavad Giti teenuseni. Giti teenus loeb ja kirjutab hoidlaid jagatud failisüsteemis ning otsustab, kas iga esitus saab viimaseks aktsepteeritud kommitiks. Selle failisüsteemi pakub AWS S3Files, mis teeb S3-põhise salvestuse kättesaadavaks tavaliste failide ja kaustadena. Salvestus on jagatud isoleeritud rakkudeks, millest igaühel on oma failisüsteem ja Giti teenuse replikad. Pärast kommiti aktsepteerimist eraldavad taustatöötlejad muutunud dokumentidest teksti ja muud kasulikku teavet, talletavad tulemused hoidla ajaloost eraldi ning teevad need kättesaadavaks, kui agendid projekti laadivad või värskendavad.

Järgmisena vaatame komponendid ükshaaval läbi.

CLI pöördub oma hoidla leidmiseks juhttasandi poole ning tõmbab ja esitab seejärel muudatusi agendipuhverserveri kaudu Giti teenusesse. Giti teenus kontrollib esitusi ning uuendab DynamoDB-s aktsepteeritud head-kommitit ja väljundpostkasti. Rakusisesed replikad kasutavad salvestust S3Files, samal ajal kui järeltöötluse töötlejad eraldavad teksti väljavõtteks ja sünkroonimiseks.

CLI: liivakastides kohalike failidega töötamine

Agendid töötavad meie ettevõttesiseses liivakastiplatvormis SPACE. Igas liivakastis on väike CLI, mis materialiseerib hoidla ja hoiab selle sünkroonis. Iga agendi tehtud sisuka tööüksuse kohta esitab see muudatused kommitina.

Agendid puudutavad tavaliselt vaid väikest osa projekti failidest, seega pole vaja kogu hoidlat kohe alguses materialiseerida. Seetõttu materialiseerib CLI faile laisalt: Git Large File Storage'i (LFS) kaudu salvestatud suured ja binaarfailid saabuvad väikeste viidafailidena, mis talletavad objekti tegeliku suuruse, nii et agent saab nime ja suuruse põhjal otsustada, kas allalaadimine tasub end ära. Selliste dokumentide puhul nagu PDF-id loeb agent esmalt parsitud teksti ja laadib lähtefailid alla ainult siis, kui see on vajalik.

Teine loomulik võimalus oleks kasutada virtuaalset failisüsteemi. Testisime FUSE-põhist lahendust, kuid failisüsteemimahukate töökoormuste puhul oli see kohalike failidega võrreldes umbes 400 korda aeglasem, sest iga päring nõuab võrgu kaudu edasi-tagasi pöördumist. Lisaks nõuab see tavaliselt hostilt privilegeeritud õigusi, mistõttu peaks iga agent töötama privilegeeritud liivakastis.

Viida suurus ja parsimismanifest otsustavad: loe parsitud teksti, laadi lähtefail alla või jäta vahele.

Juhttasand: hoidlate leidmine ja juurdepääsu andmine

Juhttasand leiab, kus iga hoidla asub, ja annab sellele juurdepääsu. Hoidla loomisel määrab juhttasand selle salvestusrakule – isoleeritud salvestusüksusele, millel on oma Giti teenuse replikad. Kui agent alustab projektiga tööd, küsib CLI juhttasandilt, kus hoidla asub. Juhttasand tagastab asukoha ja ajutised mandaadid Giti teenusele juurdepääsuks. Juhttasand ei loe ega kirjuta kunagi hoidla andmeid. Mis hoidlasse jõuab, otsustab Giti teenus.

Giti teenus: andmete liigutamine ja uuenduste koordineerimine

Giti teenus täidab Giti toiminguid ning edastab hoidla sisu ja versiooniajalugu liivakastide ja salvestuse vahel. See on õhuke ümbris Giti enda serveerimiskäskude ümber. See toetab viidete avastamist (ref discovery), mis ütleb kliendile, kus asub hoidla head-kommit, käsku upload-pack kloonimiseks ja tõmbamiseks ning käsku receive-pack uute objektide ja hoidla head-kommiti edasiviimise päringu vastuvõtmiseks. Samuti teenindab see Git LFS API-t: suurte ja binaarfailide jaoks väljastab see lühiajalised lingid, et liivakastid saaksid neid faile otse S3-sse üles laadida ja sealt alla laadida.

Alustasime valmis Git-platvormi serveriga, et saaksime agendi- ja kasutajaliideste prototüüpe luua paralleelselt oma kerge Git-platvormi ehitamisega, mis keskendub ainult meile vajalikele Giti toimingutele.

Teenus koosneb replikate kogumist, millest igaüks on sama serveri töötav eksemplar. Rakk koondab jagatud salvestuse, replikate komplekti ja nende tugiteenused. Raku replikad pääsevad seega ligi samale jagatud failisüsteemile, selle asemel et hoida igast hoidlast eraldi koopiaid.

See jagatud salvestus võimaldab replikadel jääda olekuta. Raku mis tahes replika saab teenindada ükskõik millist selle raku hoidlat, nii et replikate asendamine või lisamine ei nõua hoidla andmete teisaldamist serverite vahel. Ühe hoidla päringud suunatakse tavaliselt samale replikale, et selle vahemälud oleksid kasulikud, kuid hoidla ei sõltu selle konkreetse eksemplari kättesaadavaks jäämisest.

Aktsepteerimisetapp kontrollib hoidla invariante, et tagada, et aktsepteeritud kommit vastab hoidla kehtivale olekule. Määratleme iga hoidla jaoks selgesõnalise lepingu, et mehaanilised kontrollid hoiaksid hoidlat liiga suureks kasvamast. Suured ja binaarfailid, nagu PDF-id ja pildid, salvestatakse Git LFS-i kaudu, mitte toorete Giti blobidena. Tihendamine hoiab hiljutise ajaloo kättesaadavana, piirates samal ajal hoidla mahtu. Pärast edukat esitamist küsib CLI Giti teenuselt, kas hoidla vajab tihendamist. Kui säilitatud kommitite arv ületab läviväärtuse, jätab Giti teenus alles ainult väiksema hulga kõige uuemaid kommiteid. Vanem ajalugu asendatakse ühe algse hetktõmmisega ja hiljutised kommitid rakendatakse uuesti, et uuendada kommitite identifikaatoreid.

Tihendamine säilitab kõige uuemad kommitid, koondab vanema ajaloo ühte hetktõmmise juurkommitisse ja rakendab hiljutised kommitid uute identifikaatoritega uuesti; uues head-kommitis on samad failid.

Lihtne sünkroonimisetapp ohjab samaaegseid kirjutajaid. See jälgib viimast aktsepteeritud kommitit ehk head-kommitit. Esituse saamisel aktsepteerib see selle ainult siis, kui esitus põhineb sellel head-kommitil. Vastasel juhul saadab see struktureeritud aegunud baasi vastuse; kaotaja peab seejärel oma muudatuse uue head-kommiti peal uuesti rakendama ja uuesti esitama. See lahendus tagab, et samaaegsed agendid ei kirjuta üksteise tööd vaikselt üle, põhjustamata seejuures märkimisväärset aeglustumist. Meie tootmistöövoogudes lükatakse aegununa tagasi alla 2% esitustest. Kokkuvõttes on esituse latentsuse mediaan alla 1,7 sekundi ja p99-latentsus alla 8 sekundi.

Kaks agenti esitavad muudatusi samaaegselt; üks esitus aktsepteeritakse, teine agent saab aegunud baasi vastuse, rakendab muudatuse uue head-kommiti peal uuesti ja esitab selle uuesti.

Giti teenus talletab ka iga aktsepteeritud muudatuse. Iga aktsepteeritud kirjutuse kohta lisab see kirje väljundpostkasti – logisse, kus on kirjas hoidla, uus kommit, muudatuse teinud kasutaja ja muutunud failiteed. Järgnevad teenused, näiteks parsija, loevad seda logi, et leida uut tööd.

Koos moodustavad need komponendid hoidlahalduse kihi, milles pole agentidele mittevajalikke osi. Pull request'id pole vajalikud, sest ükski inimene ei vaata iga muudatust üle. Selle asemel kontrollib Giti teenus lepingut esitamise hetkel, võidujooksu kaotanud agent rakendab oma muudatuse uuesti ja kommitite ajalugu talletab, kes mida muutis. Deterministlikud kontrollid hoiavad iga hoidla lepingu piires, selle asemel et toetuda kasvu haldamisel inimoperaatorile.

Salvestus: töö püsivana hoidmine

Salvestuskiht salvestab hoidla andmed püsivalt, liivakastidest ja Giti teenuse replikatest sõltumatult. Hoidlad asuvad teenuses AWS S3Files, mis pakub S3-põhist salvestust failisüsteemi liidese kaudu, mida standardne Git saab muutmata kujul kasutada. Iga hoidla on jagatud failisüsteemis asuv paljas (bare) Giti hoidla, mis sisaldab hoidla objekte ja viiteid, mitte töökoopiat.

Salvestuse ja arvutuse lahtisidumine võimaldab liivakastidel jääda lühiajalisteks. Iga agent saab oma liivakasti ja paljud agendid saavad töötada samas projektis ilma masinat jagamata. Kui liivakast jookseb kokku, on ohus ainult töö, mida pole veel esitatud.

Selle asemel võiksime anda igale projektile pikaajalise liivakasti, mida kõik selle agendid jagavad, nii et projekti failid asuksid selle masina kettal. See aga seoks agentide arvutusressursid masina asukohaga ja nõuaks, et masin oleks dimensioneeritud kõige koormatumate perioodide jaoks. Samuti peaks masin püsima töökorras kuude kaupa ning varundamist ja taastamist tuleks hallata projekti salvestussüsteemi osana.

Üks pikaajaline liivakast, mida jagavad projekti agendid, võrrelduna lühiajaliste agendipõhiste liivakastidega, mis jõuavad püsiva jagatud salvestuseni olekuta Giti teenuse replikate kaudu.

Järeltöötlus: dokumentide agentidele loetavaks muutmine

Peamine järeltöötluse komponent on parsimiskonveier, mis eraldab äsja lisatud või uuendatud dokumentidest teksti ja metaandmed, et projekti failid oleksid agentidele hõlpsasti loetavad. Parsimistöötleja tarbib uuendusi muudatuste voo järjekorrast, tuletab kommiti metaandmetest muutunud failid ja hangib sisuräsi abil toorbaidid. Seejärel parsib see dokumendi, et saada eraldatud tekst ja dokumendi metaandmed.

Parsitud väljundid asuvad hoidlast väljas, eraldi salvestises, mille võtmeks on lähtedokumendi räsi. Neid artefakte ei kommitita kunagi hoidlasse tagasi, sest see risustaks asjatult ajalugu ja suurendaks samaaegsete kirjutuste arvu. Selle asemel jõuavad parsitud väljundid liivakasti väljavõtte ja sünkroonimise kaudu. Igas väljavõttes on reserveeritud kaust, mida CLI kasutab artefaktide materialiseerimiseks. Parsimine toimub asünkroonselt, nii et taustal töötav parsimistöötleja ei blokeeri väljavõtteid.

Kuidas agendid tööruumi kasutavad

Agendid uurivad liivakasti laaditud hoidla versiooni tavaliste failisüsteemi tööriistadega. Selle asemel et järgida fikseeritud konveierit, kus esmalt otsitakse ja seejärel loetakse, loetlevad nad kaustu, otsivad failide sisust käsuga grep, loevad asjakohaseid lõike ja kasutavad leitut, et otsustada, kust edasi otsida.

Sarnaselt Computeriga kasutab ka Search sama lähenemist oma standardsete failitööriistade kaudu. Eraldi uurimisagent otsib projektist piiratuma eelarve raames ja tagastab asjakohased failiteed ning toetavad katkendid. Seejärel loeb vastamismudel valitud faile ja koostab vastuse. Olemasoleva projekti liivakasti taaskasutamine lühendab seadistusaega: sooja väljavõttega ühendumine võtab umbes 2,9 sekundit, külmkäivitus aga ligikaudu 8 sekundit.

Computeri liivakastid, rakenduse Ask uurimisalamagent, taustal töötavad teadmuse kirjutajad ja parsimistöötlejad loevad kõik samast hoidlast ja väljundpostkastist ning kirjutavad neisse.

Parsitud tekst muudab suuremad dokumendid, nagu PDF- ja Office'i failid, samade tööriistadega otsitavaks. Agent kontrollib esmalt manifesti – loendit, mis näitab, millistel dokumentidel on eraldatud tekst saadaval –, seejärel otsib ja loeb seda teksti tavaliste failidena. Algse dokumendi laadib ta alla ainult siis, kui tekstist ei piisa, näiteks jooniste, paigutuse või manustatud andmete uurimiseks.

Võrdlesime seda lähenemist indeksipõhise semantilise otsinguga, kasutades sama korpuse põhjal 150 ühe dokumendi kohta käivat finantsküsimust. Uurimisagent saavutas õige dokumendi leidmisel tulemuse 0,867 ja õige vastuse andmisel 0,627, samas kui semantilise otsingu tulemused olid ligikaudu 0,39 ja 0,37 – vastustes umbes 1,7 korda ja leidmisel 2 korda parem tulemus ning umbes 25% väiksem latentsus. Uurimisagent töötab peamiselt eraldatud tekstiga ja laadib algseid PDF-e alla harva.

Uurimispõhise ja semantilise failiotsingu võrdlus sisemises võrdlustestis.

Üks jagatud taristu

Computeri püsimälu kasutab sama failisüsteemi taristut. Perplexity Brain, Computeri teadmusviki, salvestab mälu teadmushoidlatesse, millel on oma ajalugu ja reeglid. Kui teadmusi hoitakse projektifailidest eraldi, ei konkureeri mälu taustauuendused nende failide muudatustega. Seanss, mis vajab mõlemat, laadib mõlemad hoidlad.

Taustaagendid loevad olemasolevaid teadmusi, lisavad uut teavet ja salvestavad uuendatud lehed kommititena. Teised agendid loevad neid lehti tavaliste failitööriistadega ning inimesed saavad neid samuti muuta. Kirjutajad jagavad oma tööd hoidla kaudu, mitte ei koordineeri otse iga lugejaga. Kommitite ajalugu talletab, kes mida muutis, samal ajal kui väljundpostkast teavitab järgnevaid teenuseid aktsepteeritud uuendustest. Inimesed ja agendid saavad üksteise tööle tugineda ning alles jääb ülevaade sellest, kuidas teadmus arenes.

Kokkuvõte

Kui inimesed ja agendid jagavad projekti, ei piirdu tööruum failide salvestamisega. See pakub ühist kohta panuste ühendamiseks ja muudatuste jälgimiseks. Git pakub juba suure osa sellest alusest. Meie lisame koordineerimise ja automaatsed kontrollid, et agendid saaksid tööd esitada ilma, et inimene peaks iga uuenduse heaks kiitma. Tulemuseks on olemusliku miinimumini lihtsustatud Git-platvorm, sest agentidevaheline koostöö ja mitme kaastöötajaga tarkvaraarendus on sisuliselt sama probleem.

Agendid töötavad sõltumatutes ajutistes liivakastides, panustades samal ajal püsivatesse hoidlatesse. Hoidlate piirangud hoiavad kasvu hallatavana, selgesõnalised allalaadimised lasevad agentidel valida, mida tõmmata, ja tavalised failid võimaldavad neil tuttavate tööriistadega ringi uurida. Taustauuendused, interaktiivsed muudatused ja ajastatud ülesanded saavad üksteise tööle tugineda ilma otsese koordineerimiseta.

Kuna üha rohkem agente töötab Projektides iseseisvalt, peab nende jagatud tööruum jääma inimeste jaoks usaldusväärseks ja arusaadavaks. Eesmärk on lihtne: iga muudatus peaks olema püsivam kui selle loonud agent, muutuma kättesaadavaks järgmisele kaastöötajale ja jätma selge jälje sellest, mis muutus.

Viitamine

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