Creació d’espais de treball compartits per a persones i agents

Fa poc vam llançar els projectes, on persones i agents treballen junts en tasques de llarga durada a Perplexity Computer. Cada projecte es basa en un espai de treball compartit amb un sistema de fitxers que acumula context entre sessions, agents i usuaris. La col·laboració multijugador que s’estén durant mesos requereix persistència, concurrència i traçabilitat:

• Persistència: la feina ha de perdurar més enllà de qualsevol sessió d’agent o entorn de proves individual perquè el mateix usuari o agent la pugui continuar en el futur i qualsevol col·laborador s’hi pugui basar.
• Concurrència: diversos usuaris del mateix projecte poden tenir cadascun diversos agents que fan edicions en paral·lel i que fan avançar un estat compartit en lloc de sobreescriure’s els uns als altres.
• Traçabilitat: tant els usuaris com els agents han de poder veure l’historial per comprovar qui ha canviat què des de la seva última sessió sense haver de tornar a llegir tot el projecte, i desfer edicions quan calgui.

Aquests reptes resulten familiars als enginyers de programari. Les forges de Git van sorgir fa dècades per satisfer aquests requisits: un servei allotjat que envolta el control de versions amb funcions col·laboratives perquè molts col·laboradors puguin convergir en una única font de veritat. El sistema de fitxers que fa funcionar els projectes és una d’aquestes forges de Git, creada per a la col·laboració entre persones i agents i entre agents.

Amplia

Arquitectura

Git ja gestiona la persistència, la concurrència i la traçabilitat. Identifica cada fitxer pel seu contingut, de manera que els fitxers sense canvis s’emmagatzemen una sola vegada i les còpies desades mai no queden obsoletes. Cada commit desa alhora tots els fitxers actualitzats, de manera que els col·laboradors mai no veuen un estat a mig fer. Quan dos escriptors entren en conflicte, el que ha perdut pot tornar a aplicar els seus canvis sobre la nova versió i tornar-ho a provar. La cadena de commits mostra qui ha canviat què i facilita restaurar versions anteriors. El que els agents no necessiten és la resta d’una forja pensada per a persones, com ara les pantalles de revisió, la gestió de branques i les notificacions.

La nostra arquitectura executa tot el procés al núvol i admet tota mena de treball de coneixement més enllà de la programació. Cada projecte de Computer es basa en un repositori Git servit per 5 components:

• La CLI manté els checkouts locals, sincronitza les actualitzacions i envia els canvis de l’agent a cada entorn de proves.
• El pla de control localitza el repositori del projecte i emet credencials de curta durada per accedir-hi.
• El servei Git envia les dades del repositori als entorns de proves, en rep els enviaments i decideix quin enviament es converteix en l’últim commit acceptat.
• L’emmagatzematge basat en AWS S3 desa les dades del repositori de manera duradora.
• El processament posterior extreu text i altra informació útil dels documents desats i la posa a disposició quan els agents carreguen o actualitzen el projecte.

Cada agent té el seu propi entorn de proves aïllat. Dins d’aquest entorn, treballa amb una còpia local del repositori, gestionada per una petita CLI. La CLI demana al pla de control que localitzi el repositori i, després, obté i envia canvis a través del servei Git. Un servidor intermediari d’agents comprova l’accés de les sol·licituds dels entorns de proves abans que arribin al servei Git. El servei Git llegeix i escriu repositoris en un sistema de fitxers compartit i decideix si cada enviament es converteix en l’últim commit acceptat. Aquest sistema de fitxers el proporciona AWS S3Files, que fa que l’emmagatzematge basat en S3 sigui accessible com a fitxers i directoris ordinaris. L’emmagatzematge es divideix en cel·les aïllades, cadascuna amb el seu propi sistema de fitxers i les seves pròpies rèpliques del servei Git. Un cop s’accepta un commit, uns processos de treball en segon pla extreuen text i altra informació útil dels documents modificats, n’emmagatzemen els resultats separats de l’historial del repositori i els posen a disposició quan els agents carreguen o actualitzen el projecte.

A continuació, repassem els components un per un.

Amplia

CLI: treballar amb fitxers locals als entorns de proves

Els agents s’executen a SPACE, la nostra plataforma interna d’entorns de proves. Cada entorn de proves té una petita CLI que materialitza el repositori i el manté sincronitzat. Per a cada unitat de feina significativa que fa l’agent, la CLI envia els canvis com a commit.

Normalment, els agents només toquen una petita fracció dels fitxers del projecte, de manera que no cal materialitzar tot el repositori per endavant. Per això, la CLI materialitza de manera diferida: els fitxers grans i binaris emmagatzemats mitjançant Git Large File Storage (LFS) arriben com a petits fitxers punter que indiquen la mida real de l’objecte, de manera que l’agent pot utilitzar el nom i la mida per decidir si val la pena baixar-lo. En el cas de documents com ara els PDF, l’agent llegeix primer el text analitzat i només baixa els fitxers d’origen quan cal.

Una altra opció natural seria utilitzar un sistema de fitxers virtual. Vam provar una implementació basada en FUSE, però era aproximadament 400 vegades més lenta que els fitxers locals en càrregues de treball intensives en el sistema de fitxers, ja que cada sol·licitud requereix un viatge d’anada i tornada per la xarxa. A més, normalment requereix capacitats privilegiades de l’amfitrió, de manera que cada agent s’hauria d’executar en un entorn de proves privilegiat.

Amplia

Pla de control: localitzar repositoris i atorgar accés

El pla de control localitza on s’emmagatzema cada repositori i n’atorga l’accés. Quan es crea un repositori, el pla de control l’assigna a una cel·la d’emmagatzematge, una unitat d’emmagatzematge aïllada amb les seves pròpies rèpliques del servei Git. Quan un agent comença a treballar en un projecte, la CLI pregunta al pla de control on s’emmagatzema el repositori. El pla de control retorna la ubicació i unes credencials temporals per al servei Git. El pla de control mai no llegeix ni escriu dades del repositori. És el servei Git qui decideix què entra en un repositori.

Servei Git: moure dades i coordinar actualitzacions

El servei Git executa operacions de Git i transfereix el contingut i l’historial de versions dels repositoris entre els entorns de proves i l’emmagatzematge. És un embolcall lleuger al voltant de les ordres de servei pròpies de Git. Admet el descobriment de referències per indicar al client on és el head del repositori, upload-pack per clonar i obtenir dades, i receive-pack per rebre objectes nous i una sol·licitud per fer avançar el head del repositori. També serveix l’API de Git LFS: per als fitxers grans i binaris, emet enllaços de curta durada perquè els entorns de proves puguin pujar i baixar aquests fitxers directament des d’S3.

Vam començar amb un servidor de forja ja existent, de manera que poguéssim crear prototips de les interfícies d’agent i d’usuari en paral·lel mentre construíem la nostra pròpia forja lleugera, centrada només en les operacions de Git que necessitem.

El servei consisteix en una flota de rèpliques, cadascuna de les quals és una instància en execució del mateix servidor. Una cel·la agrupa l’emmagatzematge compartit amb un conjunt de rèpliques i els seus serveis de suport. Així, les rèpliques d’una mateixa cel·la poden accedir al mateix sistema de fitxers compartit, en lloc de mantenir còpies independents de cada repositori.

Aquest emmagatzematge compartit permet que les rèpliques no tinguin estat. Qualsevol rèplica de la cel·la pot servir qualsevol dels seus repositoris, de manera que substituir o afegir rèpliques no requereix moure dades de repositoris entre servidors. Normalment, les sol·licituds d’un repositori van a la mateixa rèplica perquè la memòria cau continuï sent útil, però el repositori no depèn que aquesta instància concreta continuï disponible.

El pas d’acceptació comprova els invariants del repositori per garantir que un commit acceptat correspon a un estat vàlid del repositori. Definim un contracte explícit per a cada repositori, de manera que les comprovacions mecàniques eviten que creixi massa. Els fitxers grans i binaris, com ara PDF i imatges, s’emmagatzemen mitjançant Git LFS en lloc de fer-ho com a blobs de Git en brut. La compactació manté disponible l’historial recent alhora que limita la mida del repositori. Després d’un enviament correcte, la CLI pregunta al servei Git si el repositori necessita compactació. Si el nombre de commits conservats supera un llindar, el servei Git conserva només un conjunt més petit dels commits més recents. L’historial més antic se substitueix per una única instantània inicial, i els commits recents es tornen a aplicar per actualitzar-ne els identificadors.

Amplia

Un pas de sincronització senzill controla els escriptors concurrents. Fa el seguiment de l’últim commit acceptat, o head. Quan rep un enviament, només l’accepta si s’ha construït sobre aquest head. Si no és així, envia una resposta estructurada de base obsoleta; aleshores, el perdedor ha de tornar a aplicar el seu canvi sobre el nou head i tornar-lo a enviar. Aquest disseny garanteix que els agents concurrents no se sobreescriguin els uns als altres en silenci, sense provocar alentiments significatius. En els nostres fluxos de treball de producció, menys del 2 % dels enviaments es rebutgen per obsolets. En conjunt, la latència mediana d’enviament és inferior a 1,7 segons i la latència p99 és inferior a 8 segons.

Amplia

El servei Git també registra cada canvi acceptat. Per a cada escriptura acceptada, afegeix una entrada a una safata de sortida, un registre que indica el repositori, el commit nou, l’usuari que ha fet el canvi i els camins que han canviat. Els serveis posteriors, com ara l’analitzador, llegeixen aquest registre per trobar feina nova.

Junts, aquests elements formen una capa de gestió de repositoris, sense les parts que els agents no necessiten. Les pull requests són innecessàries, perquè cap persona no revisa cada canvi. En canvi, el servei Git comprova el contracte en el moment de l’enviament, l’agent que perd una cursa torna a aplicar el seu propi canvi i l’historial de commits registra qui ha canviat què. Les comprovacions deterministes mantenen cada repositori dins del seu contracte, en lloc de dependre d’un operador humà per gestionar-ne el creixement.

Emmagatzematge: fer que la feina perduri

La capa d’emmagatzematge desa les dades del repositori de manera duradora, independentment dels entorns de proves i de les rèpliques del servei Git. Els repositoris es troben a AWS S3Files, que exposa l’emmagatzematge basat en S3 mitjançant una interfície de sistema de fitxers que el Git estàndard pot utilitzar sense modificacions. Cadascun és un repositori Git nu (bare) al sistema de fitxers compartit, que conté els objectes i les referències del repositori en lloc d’un checkout de treball.

Desacoblar l’emmagatzematge i la capacitat de càlcul permet que els entorns de proves siguin efímers. Cada agent té el seu propi entorn de proves, i molts agents poden treballar en el mateix projecte sense compartir màquina. Si un entorn de proves falla, només corre perill la feina que encara no s’ha enviat.

En canvi, podríem donar a cada projecte un entorn de proves de llarga durada compartit per tots els seus agents, de manera que els fitxers del projecte residirien al disc d’aquella màquina. Tanmateix, això lligaria la capacitat de càlcul dels agents al lloc on s’executés la màquina i obligaria a dimensionar-la per als períodes de més activitat. A més, hauria de mantenir-se en bon estat durant mesos, amb les còpies de seguretat i la recuperació gestionades com a part del sistema d’emmagatzematge del projecte.

Amplia

Processament posterior: fer que els documents siguin llegibles per als agents

El principal component posterior és una cadena d’anàlisi que extreu text i metadades dels documents nous o actualitzats perquè els agents puguin llegir fàcilment els fitxers del projecte. Un procés de treball de l’analitzador consumeix les actualitzacions de la cua del flux de canvis, dedueix els fitxers modificats a partir de les metadades del commit i obté els bytes en brut mitjançant el hash del contingut. A continuació, analitza el document per generar el text extret i les metadades del document.

Els resultats de l’anàlisi es desen fora del repositori, en un magatzem indexat pel hash del document d’origen. Aquests artefactes no s’incorporen mai al repositori com a commits, ja que això embrutaria innecessàriament l’historial i augmentaria el nombre d’escriptures concurrents. En lloc d’això, els resultats de l’anàlisi arriben a l’entorn de proves mitjançant el checkout i la sincronització. Cada checkout inclou un directori reservat que la CLI utilitza per materialitzar els artefactes. L’anàlisi es fa de manera asíncrona, de manera que el procés de treball de l’analitzador en segon pla no bloqueja els checkouts.

Com utilitzen els agents l’espai de treball

Els agents exploren la versió del repositori carregada a l’entorn de proves amb eines estàndard del sistema de fitxers. En lloc de seguir un procés fix de cerca i lectura, llisten carpetes, cerquen en el contingut dels fitxers amb grep, llegeixen els fragments rellevants i fan servir el que troben per decidir on buscar a continuació.

Igual que Computer, Search utilitza el mateix enfocament mitjançant les seves eines de fitxers estàndard. Un agent d’exploració independent cerca al projecte amb un pressupost més limitat i retorna els camins dels fitxers rellevants i fragments de suport. Després, el model que respon llegeix els fitxers seleccionats i genera la resposta. Reutilitzar un entorn de proves de projecte existent redueix el temps de configuració: connectar-se a un checkout ja preparat triga uns 2,9 segons, en comparació amb uns 8 segons d’un inici en fred.

Amplia

El text analitzat permet cercar amb les mateixes eines en documents més grans, com ara PDF i fitxers d’Office. L’agent primer consulta un manifest, una llista que mostra quins documents tenen text extret disponible, i després cerca i llegeix aquest text com a fitxers ordinaris. Només baixa el document original quan el text no és suficient, per exemple, per examinar figures, la maquetació o dades incrustades.

Vam comparar aquest enfocament amb la cerca semàntica sobre un índex en 150 preguntes financeres d’un sol document sobre el mateix corpus. L’agent d’exploració va obtenir 0,867 en la recuperació del document correcte i 0,627 en la resposta correcta, davant d’aproximadament 0,39 i 0,37 de la cerca semàntica, és a dir, uns resultats aproximadament 1,7 vegades millors en les respostes i 2 vegades millors en la recuperació, amb una latència aproximadament un 25 % inferior. L’agent d’exploració treballa sobretot amb text extret i rarament baixa els PDF originals.

Amplia

Una infraestructura compartida

La memòria persistent de Computer utilitza la mateixa infraestructura de sistema de fitxers. Perplexity Brain, la wiki de coneixement de Computer, emmagatzema la memòria en repositoris de coneixement amb el seu propi historial i les seves pròpies polítiques. Mantenir el coneixement separat dels fitxers del projecte fa que les actualitzacions de memòria en segon pla no competeixin amb les edicions d’aquests fitxers. Una sessió que necessita tots dos carrega tots dos repositoris.

Els agents en segon pla llegeixen el coneixement existent, hi incorporen informació nova i desen les pàgines actualitzades com a commits. Altres agents llegeixen aquestes pàgines amb eines de fitxers ordinàries, i les persones també les poden editar. Els escriptors comparteixen la seva feina a través del repositori en lloc de coordinar-se directament amb cada lector. L’historial de commits registra qui ha canviat què, mentre que la safata de sortida comunica les actualitzacions acceptades als serveis posteriors. Les persones i els agents poden basar-se en la feina dels altres, amb un registre de com ha evolucionat el coneixement.

Conclusió

Quan persones i agents comparteixen un projecte, l’espai de treball fa més que emmagatzemar fitxers. Proporciona un lloc comú per combinar les contribucions i fer el seguiment del que ha canviat. Git ja aporta bona part d’aquesta base. Nosaltres hi afegim coordinació i comprovacions automatitzades perquè els agents puguin enviar feina sense que una persona n’hagi d’aprovar cada actualització. El resultat és una forja reduïda a l’essencial, perquè, en el fons, la col·laboració entre agents i el desenvolupament de programari amb diversos col·laboradors són el mateix problema.

Els agents treballen en entorns de proves independents i temporals mentre contribueixen a repositoris persistents. Els límits dels repositoris mantenen el creixement sota control, les baixades explícites permeten als agents triar què volen obtenir i els fitxers ordinaris els permeten explorar amb eines conegudes. Les actualitzacions en segon pla, les edicions interactives i les tasques programades poden basar-se en la feina de les altres sense coordinar-se directament.

A mesura que més agents treballen de manera autònoma dins dels projectes, el seu espai de treball compartit ha de continuar sent fiable i comprensible per a les persones. L’objectiu és senzill: cada canvi ha de durar més que l’agent que l’ha generat, ha d’estar disponible per al següent col·laborador i ha de deixar un registre clar del que ha canviat.

Citació

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