Közös munkaterületek építése emberek és ügynökök számára

Nemrég elindítottuk a projektek funkciót, amelyben emberek és ügynökök dolgoznak együtt hosszan futó feladatokon a Perplexity Computerben. Minden projekt egy közös munkaterületre épül, amelynek fájlrendszere munkameneteken, ügynökökön és felhasználókon átívelően gyűjti a kontextust. A hónapokon át tartó, többszereplős együttműködéshez tartósság, egyidejűség és nyomon követhetőség szükséges:

• Tartósság: A munkának túl kell élnie az egyes ügynökmunkameneteket és sandboxokat, hogy később ugyanaz a felhasználó vagy ügynök folytathassa, és bármelyik közreműködő tovább építhessen rá.
• Egyidejűség: Ugyanabban a projektben több felhasználó is dolgozhat, mindegyikük több ügynökkel, amelyek párhuzamos szerkesztésekkel egy közös állapotot visznek előre ahelyett, hogy felülírnák egymást.
• Nyomon követhetőség: A felhasználóknak és az ügynököknek egyaránt látniuk kell az előzményeket, hogy a teljes projekt újraolvasása nélkül ellenőrizhessék, ki mit módosított a legutóbbi munkamenetük óta, és szükség esetén visszavonhassák a szerkesztéseket.

Ezek a kihívások ismerősek lehetnek a szoftvermérnököknek. A Git-forge-ok évtizedekkel ezelőtt éppen ezeknek a követelményeknek a kielégítésére jöttek létre: olyan hosztolt szolgáltatások, amelyek együttműködési funkciókkal egészítik ki a verziókezelést, hogy sok közreműködő egyetlen hiteles forrás köré gyűlhessen. A projekteket működtető fájlrendszer is egy ilyen Git-forge, amelyet ember–ügynök és ügynök–ügynök együttműködésre terveztek.

Nagyítás

Architektúra

A Git eleve kezeli a tartósságot, az egyidejűséget és a nyomon követhetőséget. Minden fájlt a tartalma alapján azonosít, így a változatlan fájlokat csak egyszer tárolja, a mentett másolatok pedig soha nem avulnak el. Minden commit egyszerre menti az összes frissített fájlt, így a közreműködők soha nem látnak félkész állapotot. Ha két író ütközik, az alulmaradó fél az új verzióra újra alkalmazhatja a változtatásait, és újra próbálkozhat. A commitok láncolata megmutatja, ki mit módosított, és megkönnyíti a korábbi verziók visszaállítását. Ami az ügynököknek nem kell, az egy emberek számára épített forge többi része, például az áttekintő felületek, az ágkezelés és az értesítések.

Architektúránk a teljes folyamatot a felhőben futtatja, és a programozáson túl a tudásalapú munka minden formáját támogatja. Minden Computer-projekt mögött egy Git-tároló áll, amelyet 5 komponens szolgál ki:

• A CLI minden sandboxban kezeli a helyi checkoutokat, szinkronizálja a frissítéseket, és beküldi az ügynök változtatásait.
• A vezérlősík megkeresi a projekttárolót, és rövid élettartamú hitelesítő adatokat ad ki az eléréséhez.
• A Git-szolgáltatás tárolóadatokat küld a sandboxoknak, fogadja a beküldéseiket, és eldönti, melyik beküldés váljon a legutóbbi elfogadott committá.
• Az AWS S3-alapú tárhely tartósan tárolja a tárolóadatokat.
• A további feldolgozás kinyeri a szöveget és más hasznos információkat a mentett dokumentumokból, és elérhetővé teszi őket, amikor az ügynökök betöltik vagy frissítik a projektet.

Minden ügynöknek saját, elkülönített sandboxa van. A sandboxon belül a tároló egy helyi másolatával dolgozik, amelyet egy kis CLI kezel. A CLI a vezérlősíktól kérdezi meg a tároló helyét, majd a Git-szolgáltatáson keresztül lekéri és beküldi a változtatásokat. Egy ügynökproxy ellenőrzi a sandboxkérések hozzáférési jogosultságát, mielőtt azok elérnék a Git-szolgáltatást. A Git-szolgáltatás egy közös fájlrendszeren olvassa és írja a tárolókat, és eldönti, hogy az egyes beküldések a legutóbbi elfogadott committá válnak-e. Ezt a fájlrendszert az AWS S3Files biztosítja, amely hagyományos fájlokként és könyvtárakként teszi elérhetővé az S3-alapú tárhelyet. A tárhely elkülönített cellákra oszlik, mindegyik saját fájlrendszerrel és Git-szolgáltatás-replikákkal. Egy commit elfogadása után háttérfolyamatok kinyerik a szöveget és más hasznos információkat a módosult dokumentumokból, az eredményeket a tároló előzményeitől elkülönítve tárolják, és elérhetővé teszik, amikor az ügynökök betöltik vagy frissítik a projektet.

Az alábbiakban egyenként bemutatjuk a komponenseket.

Nagyítás

CLI: munka helyi fájlokkal a sandboxokban

Az ügynökök a SPACE nevű, saját fejlesztésű sandboxplatformunkon futnak. Minden sandboxban egy kis CLI működik, amely helyben létrehozza a tárolót, és szinkronban tartja. Az ügynök által elvégzett minden érdemi munkaegység után a CLI commitként küldi be a változtatásokat.

Az ügynökök jellemzően a projektfájloknak csak kis töredékéhez nyúlnak hozzá, ezért nem szükséges előre helyben létrehozni a teljes tárolót. A CLI ezért lustán, igény szerint hozza létre a fájlokat: a Git Large File Storage (LFS) segítségével tárolt nagy és bináris fájlok kis mutatófájlokként érkeznek, amelyek az objektum valódi méretét tartalmazzák, így az ügynök a név és a méret alapján eldöntheti, megéri-e a letöltés. Az olyan dokumentumoknál, mint a PDF-ek, az ügynök először a feldolgozott szöveget olvassa be, és csak szükség esetén tölti le a forrásfájlokat.

Kézenfekvő alternatíva lett volna egy virtuális fájlrendszer használata is. Kipróbáltunk egy FUSE-alapú megvalósítást, de a fájlrendszer-igényes munkaterheléseknél nagyjából 400-szor lassabbnak bizonyult a helyi fájloknál, mivel minden kérés hálózati oda-vissza utat igényel. Emellett jellemzően privilegizált jogosultságokat követel a gazdagéptől, így minden ügynöknek privilegizált sandboxban kellene futnia.

Nagyítás

Vezérlősík: a tárolók megkeresése és a hozzáférés biztosítása

A vezérlősík megkeresi az egyes tárolók helyét, és hozzáférést biztosít hozzájuk. Egy tároló létrehozásakor a vezérlősík hozzárendeli azt egy tárhelycellához, vagyis a tárhely egy elkülönített egységéhez, amely saját Git-szolgáltatás-replikákkal rendelkezik. Amikor egy ügynök munkába kezd egy projekten, a CLI megkérdezi a vezérlősíkot, hol található a tároló. A vezérlősík visszaadja a helyet és a Git-szolgáltatáshoz szükséges ideiglenes hitelesítő adatokat. A vezérlősík soha nem olvas és nem ír tárolóadatokat. Azt, hogy mi kerül be egy tárolóba, a Git-szolgáltatás dönti el.

Git-szolgáltatás: az adatok mozgatása és a frissítések koordinálása

A Git-szolgáltatás hajtja végre a Git-műveleteket, és mozgatja a tárolók tartalmát és verzióelőzményeit a sandboxok és a tárhely között. Ez egy vékony burkoló a Git saját kiszolgálóparancsai körül. Támogatja a ref-felderítést, amellyel közli a klienssel, hol van a tároló headje, az upload-pack parancsot a klónozáshoz és a lekéréshez, valamint a receive-pack parancsot az új objektumok és a tároló headjének továbbléptetésére irányuló kérés fogadásához. Emellett a Git LFS API-t is kiszolgálja: a nagy és bináris fájlokhoz rövid élettartamú hivatkozásokat ad ki, így a sandboxok közvetlenül az S3-ba tölthetik fel, illetve onnan tölthetik le ezeket a fájlokat.

Egy kész forge-szerverrel kezdtünk, így az ügynöki és a felhasználói felületek prototípusát a saját, könnyűsúlyú forge-unk fejlesztésével párhuzamosan készíthettük el. Ez utóbbi kizárólag a számunkra szükséges Git-műveletekre összpontosít.

A szolgáltatás replikák flottájából áll, amelyek mindegyike ugyanannak a szervernek egy futó példánya. Egy cella a közös tárhelyet replikák egy csoportjával és az azokat támogató szolgáltatásokkal fogja össze. Így egy cellán belül a replikák ugyanahhoz a közös fájlrendszerhez férhetnek hozzá, ahelyett hogy minden tárolóról saját, független másolatot tartanának fenn.

Ennek a közös tárhelynek köszönhetően a replikák állapotmentesek maradhatnak. A cellán belül bármelyik replika kiszolgálhatja a cella bármelyik tárolóját, így a replikák cseréje vagy újak hozzáadása nem igényli a tárolóadatok szerverek közötti mozgatását. Az egy adott tárolóra irányuló kérések általában ugyanahhoz a replikához futnak be, hogy annak gyorsítótárai hasznosak maradjanak, a tároló azonban nem függ attól, hogy az adott példány elérhető marad-e.

Az elfogadási lépés a tárolóra vonatkozó invariánsokat ellenőrzi, hogy minden elfogadott commit érvényes tárolóállapotot jelentsen. Minden tárolóhoz explicit szerződést határozunk meg, így gépies ellenőrzésekkel megakadályozható, hogy túlságosan megnőjön. A nagy és bináris fájlokat, például a PDF-eket és a képeket, a Git LFS segítségével tároljuk, nem nyers Git-blobokként. A tömörítés (compaction) elérhetően tartja a közelmúltbeli előzményeket, miközben korlátozza a tároló méretét. Sikeres beküldés után a CLI megkérdezi a Git-szolgáltatást, hogy szükség van-e a tároló tömörítésére. Ha a megőrzött commitok száma meghalad egy küszöbértéket, a Git-szolgáltatás csak a legutóbbi commitok egy kisebb halmazát tartja meg. A régebbi előzményeket egyetlen kiinduló pillanatkép váltja fel, a legutóbbi commitokat pedig a szolgáltatás újrajátssza, hogy frissüljenek a commitazonosítók.

Nagyítás

Egy egyszerű szinkronizálási lépés kezeli az egyidejű írókat. Nyilvántartja a legutóbbi elfogadott commitot, vagyis a headet. Amikor beküldést kap, csak akkor fogadja el, ha az erre a headre épült. Ha nem, strukturált „elavult alap” (stale-base) választ küld; ekkor az alulmaradó félnek újra kell játszania a változtatását az új headre építve, majd újra be kell küldenie. Ez a kialakítás biztosítja, hogy az egyidejűleg dolgozó ügynökök ne írják felül csendben egymás munkáját, mégpedig jelentős lassulás nélkül. Éles munkafolyamatainkban a beküldések kevesebb mint 2%-át utasítjuk el elavultként. Összességében a beküldés medián késleltetése 1,7 másodperc alatt, a p99-es késleltetés pedig 8 másodperc alatt marad.

Nagyítás

A Git-szolgáltatás minden elfogadott változtatást rögzít is. Minden elfogadott írásnál bejegyzést ad hozzá egy outboxhoz, vagyis egy naplóhoz, amely tartalmazza a tárolót, az új commitot, a változtatást végző felhasználót és a módosult elérési utakat. A további feldolgozást végző szolgáltatások, például az elemző, ebből a naplóból tudják meg, milyen új munka vár rájuk.

Ezek az elemek együtt egy tárolókezelési réteget alkotnak, azon részek nélkül, amelyekre az ügynököknek nincs szükségük. Pull requestekre nincs szükség, mert egyetlen változtatást sem néz át ember. Ehelyett a Git-szolgáltatás a beküldéskor ellenőrzi a szerződést, a versenyhelyzetben alulmaradó ügynök újra alkalmazza a saját változtatását, a commitelőzmények pedig rögzítik, ki mit módosított. Determinisztikus ellenőrzések tartják az egyes tárolókat a szerződésük keretein belül, így a növekedés kezelését nem kell egy emberi operátorra bízni.

Tárhely: a munka tartós megőrzése

A tárhelyréteg a sandboxoktól és a Git-szolgáltatás replikáitól függetlenül, tartósan menti a tárolóadatokat. A tárolók az AWS S3Files szolgáltatásban találhatók, amely fájlrendszer-felületen keresztül teszi elérhetővé az S3-alapú tárhelyet, így a szabványos Git módosítás nélkül használhatja. Mindegyik tároló egy csupasz (bare) Git-tároló a közös fájlrendszeren, amely a tároló objektumait és hivatkozásait tartalmazza, nem pedig egy munkapéldányt.

A tárhely és a számítási kapacitás szétválasztása lehetővé teszi, hogy a sandboxok rövid életűek maradjanak. Minden ügynök saját sandboxot kap, és sok ügynök dolgozhat ugyanazon a projekten anélkül, hogy egy gépen kellene osztozniuk. Ha egy sandbox összeomlik, csak a még be nem küldött munka kerül veszélybe.

Ehelyett adhatnánk minden projektnek egy hosszú életű sandboxot, amelyen az összes ügynöke osztozik, így a projekt fájljai az adott gép lemezén lennének. Ez azonban az ügynökök számítási erőforrásait ahhoz kötné, ahol a gép fut, és a gépet a legforgalmasabb időszakokra kellene méretezni. Emellett hónapokig működőképesnek kellene maradnia, a biztonsági mentéseket és a helyreállítást pedig a projekt tárhelyrendszerének részeként kellene kezelni.

Nagyítás

További feldolgozás: a dokumentumok olvashatóvá tétele az ügynökök számára

A további feldolgozás legfontosabb komponense egy elemzési folyamatlánc, amely kinyeri a szöveget és a metaadatokat az újonnan hozzáadott vagy frissített dokumentumokból, hogy a projektfájlok könnyen olvashatók legyenek az ügynökök számára. Egy elemzőfolyamat a változásfolyam-sorból fogadja a frissítéseket, a commit metaadataiból meghatározza a módosult fájlokat, és a tartalmi hash alapján lekéri a nyers bájtokat. Ezután elemzi a dokumentumot, és előállítja a kinyert szöveget és a dokumentum metaadatait.

A feldolgozott kimenetek a tárolón kívül, egy a forrásdokumentum hash-e szerint kulcsolt tárban találhatók. Ezeket a műtermékeket soha nem commitoljuk vissza a tárolóba, mivel ez szükségtelenül szennyezné az előzményeket, és növelné az egyidejű írások számát. Ehelyett a feldolgozott kimenetek a checkout és a szinkronizálás során jutnak el a sandboxba. Minden checkout tartalmaz egy fenntartott könyvtárat, amelyet a CLI a műtermékek helyi létrehozására használ. Az elemzés aszinkron módon történik, így a háttérben futó elemzőfolyamat nem blokkolja a checkoutokat.

Hogyan használják az ügynökök a munkaterületet

Az ügynökök szabványos fájlrendszer-eszközökkel fedezik fel a sandboxba betöltött tárolóverziót. Ahelyett, hogy egy rögzített „keresés, majd olvasás” folyamatot követnének, mappákat listáznak, a grep segítségével keresnek a fájlok tartalmában, elolvassák a releváns részeket, és a talált információk alapján döntik el, hol keressenek tovább.

A Computerhez hasonlóan a Keresés is ugyanezt a megközelítést alkalmazza a szabványos fájleszközein keresztül. Egy különálló felfedező ügynök szűkebb erőforráskeretből kutatja át a projektet, és visszaadja a releváns fájlútvonalakat és az alátámasztó részleteket. Ezután a válaszadó modell elolvassa a kiválasztott fájlokat, és elkészíti a választ. Egy meglévő projekt-sandbox újrafelhasználása csökkenti az előkészítési időt: egy már meleg checkouthoz való csatlakozás körülbelül 2,9 másodpercig tart, szemben a hidegindítás nagyjából 8 másodpercével.

Nagyítás

A feldolgozott szövegnek köszönhetően a nagyobb dokumentumok, például a PDF- és Office-fájlok is kereshetők ugyanazokkal az eszközökkel. Az ügynök először egy jegyzéket ellenőriz – egy listát arról, hogy mely dokumentumokhoz érhető el kinyert szöveg –, majd ezt a szöveget hagyományos fájlokként keresi és olvassa. Az eredeti dokumentumot csak akkor tölti le, ha a szöveg nem elegendő, például ábrák, az elrendezés vagy beágyazott adatok vizsgálatához.

Ezt a megközelítést egy indexen végzett szemantikus kereséssel vetettük össze 150, egyetlen dokumentumra vonatkozó pénzügyi kérdésen, ugyanazon a korpuszon. A felfedező ügynök 0,867-es eredményt ért el a helyes dokumentum visszakeresésében és 0,627-est a helyes válaszadásban, szemben a szemantikus keresés nagyjából 0,39-es és 0,37-es eredményével. Ez körülbelül 1,7-szer jobb válaszokat és kétszer jobb visszakeresést jelent, mintegy 25%-kal alacsonyabb késleltetés mellett. A felfedező ügynök többnyire a kinyert szöveggel dolgozik, és ritkán tölti le az eredeti PDF-eket.

Nagyítás

Egyetlen közös infrastruktúra

A Computer tartós memóriája ugyanazt a fájlrendszer-infrastruktúrát használja. A Perplexity Brain, a Computer tudásbázis-wikije, saját előzményekkel és szabályzatokkal rendelkező tudástárolókban tárolja a memóriát. Mivel a tudás elkülönül a projektfájloktól, a háttérben futó memóriafrissítések nem versengenek ezeknek a fájloknak a szerkesztéseivel. Az a munkamenet, amelynek mindkettőre szüksége van, mindkét tárolót betölti.

A háttérben futó ügynökök beolvassák a meglévő tudást, beépítik az új információkat, és a frissített oldalakat commitokként mentik. Más ügynökök hagyományos fájleszközökkel olvassák ezeket az oldalakat, és az emberek is szerkeszthetik őket. Az írók a tárolón keresztül osztják meg a munkájukat, ahelyett hogy közvetlenül egyeztetnének az egyes olvasókkal. A commitelőzmények rögzítik, ki mit módosított, az outbox pedig jelenti az elfogadott frissítéseket a további feldolgozást végző szolgáltatásoknak. Az emberek és az ügynökök építhetnek egymás munkájára, és az is nyomon követhető marad, hogyan alakult a tudás.

Összegzés

Amikor emberek és ügynökök osztoznak egy projekten, a munkaterület többet tesz a fájlok tárolásánál. Közös helyet biztosít a hozzájárulások egyesítésére és a változások nyomon követésére. Ennek az alapnak a nagy részét a Git már biztosítja. Mi koordinációval és automatizált ellenőrzésekkel egészítjük ki, hogy az ügynökök anélkül küldhessék be a munkájukat, hogy minden frissítést egy embernek kellene jóváhagynia. Az eredmény egy a lényegre lecsupaszított forge, hiszen az ügynökök közötti együttműködés és a több közreműködős szoftverfejlesztés alapjában véve ugyanaz a probléma.

Az ügynökök független, ideiglenes sandboxokban dolgoznak, miközben tartós tárolókhoz járulnak hozzá. A tárolókorlátok kezelhetővé teszik a növekedést, az explicit letöltéseknek köszönhetően az ügynökök maguk dönthetik el, mit töltenek le, a hagyományos fájlok pedig lehetővé teszik, hogy jól ismert eszközökkel fedezzék fel a tartalmat. A háttérben futó frissítések, az interaktív szerkesztések és az ütemezett feladatok közvetlen egyeztetés nélkül is építhetnek egymás munkájára.

Ahogy egyre több ügynök dolgozik önállóan a projektekben, a közös munkaterületüknek megbízhatónak és az emberek számára érthetőnek kell maradnia. A cél egyszerű: minden változtatás élje túl az azt létrehozó ügynököt, váljon elérhetővé a következő közreműködő számára, és hagyjon egyértelmű nyomot arról, mi változott.

Hivatkozás

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