Kopīgu darbvietu veidošana cilvēkiem un aģentiem

Nesen ieviesām projektus, kur cilvēki un aģenti kopā strādā pie ilgstošiem uzdevumiem Perplexity Computer vidē. Katrs projekts atrodas kopīgā darbvietā ar failu sistēmu, kas uzkrāj kontekstu starp sesijām, aģentiem un lietotājiem. Vairāku dalībnieku sadarbībai, kas ilgst mēnešiem, nepieciešama noturība, vienlaicīgums un izsekojamība:

• Noturība: darbam jāsaglabājas ilgāk par jebkuru atsevišķu aģenta sesiju vai smilšu kasti, lai vēlāk to varētu turpināt tas pats lietotājs vai aģents un uz tā varētu balstīties jebkurš līdzstrādnieks.
• Vienlaicīgums: vairākiem lietotājiem vienā projektā katram var būt vairāki aģenti, kas paralēli veic labojumus, virzot uz priekšu kopīgu stāvokli, nevis pārrakstot cits cita darbu.
• Izsekojamība: gan lietotājiem, gan aģentiem jāspēj redzēt vēsturi, lai viņi varētu pārbaudīt, kas ko mainījis kopš viņu pēdējās sesijas, nepārlasot visu projektu, un vajadzības gadījumā atsaukt labojumus.

Šie izaicinājumi programmatūras inženieriem šķitīs pazīstami. Git forge platformas radās pirms gadu desmitiem tieši šo prasību apmierināšanai: tas ir mitināts pakalpojums, kas versiju kontroli papildina ar sadarbības funkcijām, lai daudzi līdzautori varētu nonākt pie vienota patiesības avota. Failu sistēma, uz kuras darbojas projekti, ir viena šāda Git forge platforma, kas veidota sadarbībai starp cilvēkiem un aģentiem, kā arī starp pašiem aģentiem.

Izvērst

Arhitektūra

Git jau nodrošina noturību, vienlaicīgumu un izsekojamību. Tas identificē katru failu pēc tā satura, tāpēc nemainīti faili tiek glabāti vienreiz un saglabātās kopijas nekad nenoveco. Katrs komits saglabā visus atjauninātos failus vienlaikus, tāpēc līdzstrādnieki nekad neredz pusgatavu stāvokli. Kad divi rakstītāji saduras, zaudētājs var atkārtoti piemērot savas izmaiņas jaunajai versijai un mēģināt vēlreiz. Komitu ķēde parāda, kas ko mainīja, un ļauj viegli atjaunot iepriekšējās versijas. Aģentiem nav vajadzīga pārējā cilvēkiem veidotas forge platformas funkcionalitāte, piemēram, pārskatīšanas ekrāni, zaru pārvaldība un paziņojumi.

Mūsu arhitektūra visu procesu izpilda mākonī un atbalsta visus zināšanu darba veidus, ne tikai programmēšanu. Katra Computer projekta pamatā ir Git repozitorijs, ko apkalpo 5 komponenti:

• CLI katrā smilšu kastē uztur lokālās darba kopijas, sinhronizē atjauninājumus un iesniedz aģenta izmaiņas.
• Vadības plakne atrod projekta repozitoriju un izsniedz īslaicīgus akreditācijas datus piekļuvei tam.
• Git pakalpojums nosūta repozitorija datus uz smilšu kastēm, saņem to iesniegumus un nosaka, kurš iesniegums kļūst par pēdējo pieņemto komitu.
• Uz AWS S3 balstīta krātuve noturīgi glabā repozitoriju datus.
• Lejupējā apstrāde izgūst tekstu un citu noderīgu informāciju no saglabātajiem dokumentiem un padara to pieejamu, kad aģenti ielādē vai atsvaidzina projektu.

Katram aģentam ir sava izolēta smilšu kaste. Tajā aģents strādā ar lokālu repozitorija kopiju, ko pārvalda neliels CLI. CLI lūdz vadības plaknei atrast repozitoriju, pēc tam ienes un iesniedz izmaiņas caur Git pakalpojumu. Aģentu starpniekserveris pārbauda smilšu kastes pieprasījumu piekļuves tiesības, pirms tie sasniedz Git pakalpojumu. Git pakalpojums lasa un raksta repozitorijus kopīgā failu sistēmā un nosaka, vai katrs iesniegums kļūst par pēdējo pieņemto komitu. Šo failu sistēmu nodrošina AWS S3Files, kas padara uz S3 balstītu krātuvi pieejamu kā parastus failus un direktorijus. Krātuve ir sadalīta izolētās šūnās, un katrā no tām ir sava failu sistēma un Git pakalpojuma replikas. Kad komits ir pieņemts, fona apstrādes procesi izgūst tekstu un citu noderīgu informāciju no mainītajiem dokumentiem, glabā rezultātus atsevišķi no repozitorija vēstures un padara tos pieejamus, kad aģenti ielādē vai atsvaidzina projektu.

Tālāk aplūkosim komponentus pa vienam.

Izvērst

CLI: darbs ar lokāliem failiem smilšu kastēs

Aģenti darbojas SPACE — mūsu iekšēji izstrādātajā smilšu kastes platformā. Katrā smilšu kastē ir neliels CLI, kas materializē repozitoriju un uztur to sinhronizētu. Par katru jēgpilnu aģenta paveiktā darba vienību CLI iesniedz izmaiņas kā komitu.

Aģenti parasti skar tikai nelielu daļu projekta failu, tāpēc nav nepieciešams uzreiz materializēt visu repozitoriju. Tādēļ CLI materializē slinki: lieli un binārie faili, kas glabāti ar Git Large File Storage (LFS), tiek saņemti kā nelieli rādītāju faili, kuros norādīts objekta patiesais lielums, lai aģents pēc nosaukuma un lieluma varētu izlemt, vai lejupielāde ir tā vērta. Tādiem dokumentiem kā PDF aģents vispirms lasa parsēto tekstu un avota failus lejupielādē tikai tad, kad tas nepieciešams.

Vēl viena dabiska iespēja būtu izmantot virtuālu failu sistēmu. Mēs testējām uz FUSE balstītu implementāciju, taču failu sistēmas intensīvās slodzēs tā bija aptuveni 400 reizes lēnāka nekā lokālie faili, jo katram pieprasījumam nepieciešams tīkla pieprasījuma un atbildes cikls. Turklāt tai parasti ir vajadzīgas priviliģētas resursdatora iespējas, tāpēc katram aģentam būtu jādarbojas priviliģētā smilšu kastē.

Izvērst

Vadības plakne: repozitoriju atrašana un piekļuves piešķiršana

Vadības plakne nosaka, kur glabājas katrs repozitorijs, un nodrošina piekļuvi tam. Kad repozitorijs tiek izveidots, vadības plakne to piešķir krātuves šūnai — izolētai krātuves vienībai ar savām Git pakalpojuma replikām. Kad aģents sāk darbu pie projekta, CLI vaicā vadības plaknei, kur repozitorijs glabājas. Vadības plakne atgriež atrašanās vietu un pagaidu akreditācijas datus piekļuvei Git pakalpojumam. Vadības plakne nekad nelasa un neraksta repozitorija datus. To, kas nonāk repozitorijā, nosaka Git pakalpojums.

Git pakalpojums: datu pārsūtīšana un atjauninājumu koordinēšana

Git pakalpojums izpilda Git operācijas un pārsūta repozitorija saturu un versiju vēsturi starp smilšu kastēm un krātuvi. Tas ir plāns apvalks ap paša Git apkalpošanas komandām. Tas atbalsta atsauču noteikšanu, lai klientam paziņotu, kur atrodas repozitorija head, upload-pack klonēšanai un ienešanai, kā arī receive-pack jaunu objektu un repozitorija head pārvietošanas pieprasījuma saņemšanai. Tas apkalpo arī Git LFS API: lieliem un binārajiem failiem tas izsniedz īslaicīgas saites, lai smilšu kastes varētu augšupielādēt un lejupielādēt šos failus tieši no S3.

Mēs sākām ar gatavu forge serveri, lai varētu prototipēt aģenta un lietotāja saskarnes paralēli tam, kā veidojām paši savu vieglo forge risinājumu, kas vērsts tikai uz mums nepieciešamajām Git operācijām.

Pakalpojumu veido replikas, un katra no tām ir viena un tā paša servera darbojoša instance. Šūna apvieno kopīgu krātuvi ar replikām un to atbalsta pakalpojumiem. Tādējādi šūnas replikas var piekļūt vienai un tai pašai kopīgajai failu sistēmai, nevis uzturēt neatkarīgas katra repozitorija kopijas.

Šī kopīgā krātuve ļauj replikām palikt bez stāvokļa. Jebkura šūnas replika var apkalpot jebkuru no šūnas repozitorijiem, tāpēc, aizstājot vai pievienojot replikas, nav jāpārvieto repozitoriju dati starp serveriem. Pieprasījumi konkrētam repozitorijam parasti tiek novirzīti uz to pašu repliku, lai tās kešatmiņa būtu noderīga, taču repozitorijs nav atkarīgs no tā, vai šī konkrētā instance paliek pieejama.

Pieņemšanas solis pārbauda repozitorija invariantus, lai nodrošinātu, ka pieņemts komits ir derīgs repozitorija stāvoklis. Katram repozitorijam mēs definējam skaidru līgumu, lai mehāniskas pārbaudes neļautu tam pārmērīgi izaugt. Lieli un binārie faili, piemēram, PDF faili un attēli, tiek glabāti, izmantojot Git LFS, nevis kā neapstrādāti Git blobi. Kompaktēšana saglabā neseno vēsturi pieejamu, vienlaikus ierobežojot repozitorija lielumu. Pēc veiksmīgas iesniegšanas CLI vaicā Git pakalpojumam, vai repozitorijam nepieciešama kompaktēšana. Ja saglabāto komitu skaits pārsniedz slieksni, Git pakalpojums patur tikai mazāku jaunāko komitu kopu. Vecāko vēsturi aizstāj viens sākuma momentuzņēmums, un nesenie komiti tiek atkārtoti piemēroti, lai atjauninātu komitu identifikatorus.

Izvērst

Vienkāršs sinhronizācijas solis kontrolē vienlaicīgus rakstītājus. Tas seko līdzi pēdējam pieņemtajam komitam jeb head. Saņemot iesniegumu, tas to pieņem tikai tad, ja iesniegums ir veidots uz šī head pamata. Ja nav, tas nosūta strukturētu novecojušas bāzes atbildi; zaudētājam tad jāpiemēro savas izmaiņas atkārtoti virs jaunā head un jāiesniedz vēlreiz. Šis dizains nodrošina, ka vienlaicīgi strādājoši aģenti klusi nepārraksta cits cita darbu, turklāt bez būtiska palēninājuma. Mūsu produkcijas vides darbplūsmās mazāk nekā 2 % iesniegumu tiek noraidīti kā novecojuši. Kopumā iesniegšanas latentuma mediāna ir mazāka par 1,7 sekundēm, bet p99 latentums — mazāks par 8 sekundēm.

Izvērst

Git pakalpojums arī reģistrē katru pieņemto izmaiņu. Par katru pieņemto ierakstīšanu tas pievieno ierakstu izsūtnē — žurnālā, kurā norādīts repozitorijs, jaunais komits, lietotājs, kas veica izmaiņu, un mainītie ceļi. Lejupējie pakalpojumi, piemēram, parsētājs, lasa šo žurnālu, lai atrastu jaunu darbu.

Kopā šīs daļas veido repozitoriju pārvaldības slāni bez tām daļām, kas aģentiem nav vajadzīgas. Nav vajadzīgi pull request, jo neviens cilvēks nepārskata katru izmaiņu. Tā vietā Git pakalpojums iesniegšanas brīdī pārbauda līgumu, aģents, kas zaudē sacensībā, atkārtoti piemēro savas izmaiņas, un komitu vēsture fiksē, kas ko mainīja. Deterministiskas pārbaudes notur katru repozitoriju tā līguma robežās, nevis paļaujas uz cilvēku operatoru, kas pārvaldītu izaugsmi.

Krātuve: darba noturības nodrošināšana

Krātuves slānis noturīgi saglabā repozitoriju datus neatkarīgi no smilšu kastēm un Git pakalpojuma replikām. Repozitoriji atrodas AWS S3Files, kas nodrošina uz S3 balstītu krātuvi ar failu sistēmas saskarni, ko standarta Git var izmantot bez modifikācijām. Katrs no tiem ir bare Git repozitorijs kopīgajā failu sistēmā, kurā ir repozitorija objekti un atsauces, nevis darba kopija.

Krātuves un skaitļošanas nodalīšana ļauj smilšu kastēm palikt īslaicīgām. Katrs aģents saņem savu smilšu kasti, un daudzi aģenti var strādāt pie viena projekta, nedalot vienu mašīnu. Ja smilšu kaste avarē, apdraudēts ir tikai neiesniegtais darbs.

Tā vietā mēs varētu katram projektam piešķirt ilgdzīvojošu smilšu kasti, ko koplieto visi tā aģenti, lai projekta faili atrastos šīs mašīnas diskā. Tomēr tas piesaistītu aģentu skaitļošanas resursus vietai, kur darbojas mašīna, un prasītu to dimensionēt noslogotākajiem periodiem. Turklāt tai būtu jāpaliek darbspējīgai mēnešiem ilgi, un rezerves kopēšana un atkopšana būtu jāpārvalda kā daļa no projekta krātuves sistēmas.

Izvērst

Lejupējā apstrāde: kā padarīt dokumentus aģentiem lasāmus

Galvenais lejupējais komponents ir parsētāja konveijers, kas izgūst tekstu un metadatus no jaunpievienotiem vai atjauninātiem dokumentiem, lai aģenti varētu viegli lasīt projekta failus. Parsētāja apstrādes process patērē atjauninājumus no izmaiņu plūsmas rindas, nosaka mainītos failus pēc komita metadatiem un ienes neapstrādātos baitus, izmantojot satura jaucējvērtību. Pēc tam tas parsē dokumentu, iegūstot izgūto tekstu un dokumenta metadatus.

Parsētie rezultāti atrodas ārpus repozitorija — krātuvē, kuras atslēga ir avota dokumenta jaucējvērtība. Šie artefakti nekad netiek komitēti atpakaļ repozitorijā, jo tas lieki piesārņotu vēsturi un palielinātu vienlaicīgo ierakstīšanu skaitu. Tā vietā parsētie rezultāti nonāk smilšu kastē darba kopijas izveides un sinhronizācijas laikā. Katrā darba kopijā ir rezervēts direktorijs, ko CLI izmanto artefaktu materializēšanai. Parsēšana notiek asinhroni, tāpēc fona parsētāja apstrādes process nebloķē darba kopiju izveidi.

Kā aģenti izmanto darbvietu

Aģenti pēta smilšu kastē ielādēto repozitorija versiju, izmantojot standarta failu sistēmas rīkus. Tā vietā, lai sekotu fiksētam meklēšanas un lasīšanas konveijeram, tie pārlūko mapes, meklē failu saturā ar grep, lasa attiecīgos fragmentus un, balstoties uz atrasto, izlemj, kur meklēt tālāk.

Līdzīgi kā Computer, arī Search izmanto šo pašu pieeju ar saviem standarta failu rīkiem. Atsevišķs izpētes aģents pārmeklē projektu ierobežotākā budžetā un atgriež attiecīgos failu ceļus un pamatojošus fragmentus. Pēc tam atbildes modelis izlasa atlasītos failus un ģenerē atbildi. Esošas projekta smilšu kastes atkārtota izmantošana samazina sagatavošanas laiku: pievienošanās jau sagatavotai darba kopijai aizņem aptuveni 2,9 sekundes, salīdzinot ar aptuveni 8 sekundēm aukstās palaišanas gadījumā.

Izvērst

Parsētais teksts ļauj ar tiem pašiem rīkiem meklēt arī lielākos dokumentos, piemēram, PDF un Office failos. Aģents vispirms pārbauda manifestu — sarakstu, kas parāda, kuriem dokumentiem ir pieejams izgūtais teksts, — un pēc tam meklē un lasa šo tekstu kā parastus failus. Oriģinālo dokumentu tas lejupielādē tikai tad, ja ar tekstu nepietiek, piemēram, lai aplūkotu attēlus, izkārtojumu vai iegultus datus.

Mēs salīdzinājām šo pieeju ar semantisko meklēšanu indeksā, izmantojot 150 finanšu jautājumus par atsevišķiem dokumentiem tajā pašā korpusā. Izpētes aģents ieguva 0,867 punktus pareizā dokumenta izgūšanā un 0,627 punktus pareizu atbilžu sniegšanā, savukārt semantiskā meklēšana — attiecīgi aptuveni 0,39 un 0,37. Tas ir aptuveni 1,7 reizes labāks rezultāts atbildēs un 2 reizes labāks izgūšanā, turklāt ar aptuveni par 25 % mazāku latentumu. Izpētes aģents galvenokārt strādā ar izgūto tekstu un reti lejupielādē oriģinālos PDF failus.

Izvērst

Viena kopīga infrastruktūra

Computer pastāvīgā atmiņa izmanto to pašu failu sistēmas infrastruktūru. Perplexity Brain, Computer zināšanu wiki, glabā atmiņu zināšanu repozitorijos ar savu vēsturi un politikām. Tā kā zināšanas tiek glabātas atsevišķi no projekta failiem, fona atmiņas atjauninājumi nekonkurē ar šo failu labojumiem. Sesija, kurai nepieciešami abi, ielādē abus repozitorijus.

Fona aģenti lasa esošās zināšanas, iekļauj jaunu informāciju un saglabā atjauninātās lapas kā komitus. Citi aģenti lasa šīs lapas ar parastiem failu rīkiem, un cilvēki tās var arī labot. Rakstītāji kopīgo savu darbu caur repozitoriju, nevis koordinējas tieši ar katru lasītāju. Komitu vēsture fiksē, kas ko mainīja, bet izsūtne ziņo par pieņemtajiem atjauninājumiem lejupējiem pakalpojumiem. Cilvēki un aģenti var balstīties cits uz cita darbu, un saglabājas ieraksts par to, kā zināšanas attīstījušās.

Secinājumi

Kad cilvēki un aģenti kopīgi strādā pie projekta, darbvieta nav tikai failu glabātuve. Tā nodrošina kopīgu vietu, kur apvienot ieguldījumus un sekot līdzi izmaiņām. Lielu daļu šī pamata jau nodrošina Git. Mēs pievienojam koordināciju un automatizētas pārbaudes, lai aģenti varētu iesniegt darbu, cilvēkam neapstiprinot katru atjauninājumu. Rezultāts ir līdz pamatiem vienkāršota forge platforma, jo sadarbība starp aģentiem un programmatūras izstrāde ar daudziem līdzautoriem būtībā ir viena un tā pati problēma.

Aģenti strādā neatkarīgās, īslaicīgās smilšu kastēs, vienlaikus papildinot noturīgus repozitorijus. Repozitoriju ierobežojumi palīdz kontrolēt izaugsmi, skaidri norādītas lejupielādes ļauj aģentiem izvēlēties, ko ienest, bet parasti faili ļauj tiem pētīt saturu ar pazīstamiem rīkiem. Fona atjauninājumi, interaktīvi labojumi un ieplānoti uzdevumi var balstīties cits uz cita darbu bez tiešas koordinācijas.

Tā kā projektos autonomi strādā arvien vairāk aģentu, to kopīgajai darbvietai jāpaliek uzticamai un cilvēkiem saprotamai. Mērķis ir vienkāršs: katrai izmaiņai jābūt noturīgākai par aģentu, kas to radījis, jākļūst pieejamai nākamajam līdzstrādniekam un jāatstāj skaidrs ieraksts par to, kas mainījās.

Atsauce

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