Crear espazos de traballo compartidos para persoas e axentes

Lanzamos recentemente Proxectos, onde persoas e axentes traballan xuntos en tarefas de longa duración en Perplexity Computer. Cada proxecto ten como base un espazo de traballo compartido cun sistema de ficheiros que acumula contexto entre sesións, axentes e usuarios. A colaboración entre múltiples participantes que se estende durante meses require persistencia, concorrencia e trazabilidade:

• Persistencia: o traballo debería perdurar máis alá de calquera sesión ou contorno illado dun axente concreto, para que o mesmo usuario ou axente poida continualo no futuro e calquera colaborador poida construír sobre el.
• Concorrencia: varios usuarios do mesmo proxecto poden ter cada un varios axentes facendo edicións en paralelo que fan avanzar un estado compartido en lugar de sobrescribirse entre si.
• Trazabilidade: tanto os usuarios como os axentes deberían poder ver o historial para comprobar quen cambiou que desde a súa última sesión sen volver ler todo o proxecto, e reverter edicións cando sexa necesario.

Estes desafíos resúltanlles familiares aos enxeñeiros de software. As forxas de Git xurdiron hai décadas para satisfacer estes requisitos: un servizo aloxado que envolve o control de versións con funcións colaborativas para que moitos colaboradores poidan converxer nunha única fonte de verdade. O sistema de ficheiros que impulsa os Proxectos é unha forxa de Git deste tipo, creada para a colaboración entre persoas e axentes e entre axentes.

Ampliar

Arquitectura

Git xa se encarga da persistencia, a concorrencia e a trazabilidade. Identifica cada ficheiro polo seu contido, de modo que os ficheiros sen cambios se almacenan unha soa vez e as copias gardadas nunca quedan desactualizadas. Cada commit garda todos os ficheiros actualizados á vez, polo que os colaboradores nunca ven un estado a medio rematar. Cando dous escritores entran en conflito, o que perdeu pode volver aplicar os seus cambios sobre a nova versión e tentalo de novo. A cadea de commits mostra quen cambiou que e facilita restaurar versións anteriores. O que os axentes non necesitan é o resto dunha forxa creada para humanos, como as pantallas de revisión, a xestión de ramas e as notificacións.

A nosa arquitectura executa todo o proceso na nube e admite todas as formas de traballo do coñecemento, máis alá da programación. Cada proxecto de Computer está respaldado por un repositorio Git servido por 5 compoñentes:

• A CLI mantén os checkouts locais, sincroniza as actualizacións e envía os cambios do axente en cada contorno illado.
• O plano de control localiza o repositorio do proxecto e emite credenciais de curta duración para acceder a el.
• O servizo Git envía os datos dos repositorios aos contornos illados, recibe os seus envíos e decide que envío se converte no último commit aceptado.
• O almacenamento baseado en AWS S3 garda de forma duradeira os datos dos repositorios.
• O procesamento posterior extrae texto e outra información útil dos documentos gardados e ponos á disposición dos axentes cando cargan ou actualizan o proxecto.

Cada axente ten o seu propio contorno illado. Dentro dese contorno illado, traballa cunha copia local do repositorio, xestionada por unha pequena CLI. A CLI pídelle ao plano de control que localice o repositorio e despois obtén e envía os cambios a través do servizo Git. Un proxy de axentes verifica o acceso das solicitudes dos contornos illados antes de que cheguen ao servizo Git. O servizo Git le e escribe repositorios nun sistema de ficheiros compartido e decide se cada envío se converte no último commit aceptado. Ese sistema de ficheiros proporciónao AWS S3Files, que fai que o almacenamento baseado en S3 sexa accesible como ficheiros e directorios comúns. O almacenamento divídese en celas illadas, cada unha co seu propio sistema de ficheiros e as súas propias réplicas do servizo Git. Despois de que se acepte un commit, os traballadores en segundo plano extraen texto e outra información útil dos documentos modificados, almacenan os resultados por separado do historial do repositorio e ponos á disposición dos axentes cando cargan ou actualizan o proxecto.

A continuación, repasamos os compoñentes un por un.

Ampliar

CLI: traballar con ficheiros locais nos contornos illados

Os axentes execútanse en SPACE, a nosa plataforma propia de contornos illados. Cada contorno illado ten unha pequena CLI que materializa o repositorio e o mantén sincronizado. Por cada unidade de traballo significativa que realiza o axente, a CLI envía os cambios como un commit.

Os axentes adoitan tocar só unha pequena fracción dos ficheiros do proxecto, polo que non é necesario materializar todo o repositorio de antemán. Por iso, a CLI materializa de forma diferida: os ficheiros grandes e binarios almacenados mediante Git Large File Storage (LFS) chegan como pequenos ficheiros punteiro que almacenan o tamaño real do obxecto, de modo que o axente pode usar o nome e o tamaño para decidir se paga a pena descargalos. En documentos como os PDF, o axente le primeiro o texto analizado e só descarga os ficheiros orixinais cando é necesario.

Outra opción natural sería usar un sistema de ficheiros virtual. Probamos unha implementación baseada en FUSE, pero era aproximadamente 400 veces máis lenta que os ficheiros locais en cargas de traballo con uso intensivo do sistema de ficheiros, xa que cada solicitude require unha viaxe de ida e volta pola rede. Ademais, adoita requirir capacidades privilexiadas no servidor anfitrión, polo que cada axente tería que executarse nun contorno illado privilexiado.

Ampliar

Plano de control: localizar repositorios e conceder acceso

O plano de control localiza onde se almacena cada repositorio e concede acceso a el. Cando se crea un repositorio, o plano de control asígnao a unha cela de almacenamento, unha unidade illada de almacenamento coas súas propias réplicas do servizo Git. Cando un axente comeza a traballar nun proxecto, a CLI pregúntalle ao plano de control onde se almacena o repositorio. O plano de control devolve a localización e unhas credenciais temporais para o servizo Git. O plano de control nunca le nin escribe datos do repositorio. É o servizo Git quen decide que entra nun repositorio.

Servizo Git: mover datos e coordinar actualizacións

O servizo Git executa as operacións de Git e transfire o contido e o historial de versións dos repositorios entre os contornos illados e o almacenamento. É un envoltorio lixeiro arredor dos propios comandos de servizo de Git. Admite o descubrimento de referencias para indicarlle ao cliente onde está o head do repositorio, upload-pack para clonar e obter, e receive-pack para recibir obxectos novos e unha solicitude para facer avanzar o head do repositorio. Tamén serve a API de Git LFS: para os ficheiros grandes e binarios, emite ligazóns de curta duración para que os contornos illados poidan cargar e descargar eses ficheiros directamente desde S3.

Comezamos cun servidor de forxa xa existente no mercado para poder crear prototipos das interfaces do axente e do usuario en paralelo mentres construiamos a nosa propia forxa lixeira, centrada só nas operacións de Git que necesitamos.

O servizo consiste nunha frota de réplicas, cada unha delas unha instancia en execución do mesmo servidor. Unha cela agrupa o almacenamento compartido cun conxunto de réplicas e os seus servizos de apoio. Así, as réplicas dunha cela poden acceder ao mesmo sistema de ficheiros compartido, en lugar de manter copias independentes de cada repositorio.

Este almacenamento compartido permite que as réplicas sigan sen estado. Calquera réplica da cela pode servir calquera dos seus repositorios, polo que substituír ou engadir réplicas non require mover datos de repositorios entre servidores. As solicitudes para un repositorio adoitan dirixirse á mesma réplica para que as súas cachés sigan sendo útiles, pero o repositorio non depende de que esa instancia concreta siga dispoñible.

O paso de aceptación comproba os invariantes do repositorio para garantir que un commit aceptado sexa un estado válido do repositorio. Definimos un contrato explícito para cada repositorio, de modo que as comprobacións mecánicas poidan evitar que medre en exceso. Os ficheiros grandes e binarios, como os PDF e as imaxes, almacénanse mediante Git LFS en lugar de como blobs de Git en bruto. A compactación mantén dispoñible o historial recente e limita o tamaño do repositorio. Despois dun envío correcto, a CLI pregúntalle ao servizo Git se o repositorio necesita compactación. Se o número de commits conservados supera un limiar, o servizo Git conserva só un conxunto máis pequeno cos commits máis recentes. O historial máis antigo substitúese por unha única instantánea inicial, e os commits recentes reprodúcense para actualizar os identificadores dos commits.

Ampliar

Un paso de sincronización sinxelo controla os escritores concorrentes. Fai un seguimento do último commit aceptado, ou head. Cando recibe un envío, só o acepta se se construíu sobre ese head. Se non, envía unha resposta estruturada de base obsoleta; o perdedor ten entón que reproducir o seu cambio sobre o novo head e volver envialo. Este deseño garante que os axentes concorrentes non se sobrescriban uns a outros en silencio, sen provocar ralentizacións significativas. Nos nosos fluxos de traballo de produción, menos do 2 % dos envíos son rexeitados por obsoletos. En conxunto, a latencia mediana dos envíos é inferior a 1,7 segundos e a latencia p99 é inferior a 8 segundos.

Ampliar

O servizo Git tamén rexistra cada cambio aceptado. Por cada escritura aceptada, engade unha entrada a unha caixa de saída (outbox), un rexistro que indica o repositorio, o novo commit, o usuario que fixo o cambio e as rutas que cambiaron. Os servizos posteriores, como o analizador, len este rexistro para atopar traballo novo.

En conxunto, estas pezas forman unha capa de xestión de repositorios, sen as partes que os axentes non necesitan. As pull requests son innecesarias, porque ningunha persoa revisa cada cambio. No seu lugar, o servizo Git comproba o contrato no momento do envío, o axente que perde unha carreira volve aplicar o seu propio cambio e o historial de commits rexistra quen cambiou que. As comprobacións deterministas manteñen cada repositorio dentro do seu contrato, en lugar de depender dunha persoa operadora para xestionar o crecemento.

Almacenamento: garantir a durabilidade do traballo

A capa de almacenamento garda de forma duradeira os datos dos repositorios con independencia dos contornos illados e das réplicas do servizo Git. Os repositorios residen en AWS S3Files, que expón almacenamento baseado en S3 mediante unha interface de sistema de ficheiros que Git estándar pode usar sen modificacións. Cada un deles é un repositorio Git de tipo bare no sistema de ficheiros compartido, que contén os obxectos e as referencias do repositorio en lugar dunha copia de traballo.

Desacoplar o almacenamento e a computación permite que os contornos illados sigan sendo efémeros. Cada axente obtén o seu propio contorno illado, e moitos axentes poden traballar no mesmo proxecto sen compartir unha máquina. Se un contorno illado falla, só corre perigo o traballo que aínda non se enviou.

Poderiamos, en cambio, dar a cada proxecto un contorno illado de longa duración que compartisen todos os seus axentes, de modo que os ficheiros do proxecto residirían no disco desa máquina. Con todo, isto vincularía a computación dos axentes ao lugar onde se execute a máquina e obrigaría a dimensionala para os seus períodos de maior actividade. Ademais, tería que manterse en bo estado durante meses, coas copias de seguranza e a recuperación xestionadas como parte do sistema de almacenamento do proxecto.

Ampliar

Procesamento posterior: facer que os documentos sexan lexibles para os axentes

O principal compoñente posterior é unha canle de análise que extrae texto e metadatos dos documentos engadidos ou actualizados recentemente para que os axentes poidan ler facilmente os ficheiros do proxecto. Un traballador de análise consume as actualizacións da cola do fluxo de cambios, deduce os ficheiros modificados a partir dos metadatos do commit e obtén os bytes en bruto mediante o hash do contido. Despois analiza o documento para producir o texto extraído e os metadatos do documento.

Os resultados da análise residen fóra do repositorio, nun almacén indexado polo hash do documento orixinal. Estes artefactos nunca se envían como commits ao repositorio, xa que iso contaminaría o historial innecesariamente e aumentaría o número de escrituras concorrentes. En cambio, os resultados da análise chegan a un contorno illado mediante o checkout e a sincronización. Cada checkout inclúe un directorio reservado que a CLI usa para materializar os artefactos. A análise realízase de forma asíncrona, polo que un traballador de análise en segundo plano non bloquea os checkouts.

Como usan os axentes o espazo de traballo

Os axentes exploran a versión do repositorio cargada no contorno illado mediante ferramentas estándar do sistema de ficheiros. En lugar de seguir unha canle fixa de buscar e despois ler, listan cartafoles, buscan no contido dos ficheiros con grep, len os fragmentos relevantes e usan o que atopan para decidir onde buscar a continuación.

Do mesmo xeito que Computer, Search aplica este enfoque a través das súas ferramentas de ficheiros estándar. Un axente de exploración independente busca no proxecto cun orzamento máis limitado e devolve as rutas dos ficheiros relevantes e fragmentos de apoio. A continuación, o modelo de resposta le os ficheiros seleccionados e xera a resposta. Reutilizar un contorno illado de proxecto existente reduce o tempo de configuración: conectarse a un checkout xa quente leva uns 2,9 segundos, fronte a aproximadamente 8 segundos nun arranque en frío.

Ampliar

O texto analizado permite buscar coas mesmas ferramentas en documentos máis grandes, como os PDF e os ficheiros de Office. O axente consulta primeiro un manifesto, unha lista que mostra que documentos teñen texto extraído dispoñible, e despois busca e le ese texto como ficheiros comúns. Só descarga o documento orixinal cando o texto non é suficiente, por exemplo, para examinar figuras, a maquetación ou datos incrustados.

Comparamos este enfoque coa busca semántica sobre un índice en 150 preguntas financeiras dun só documento sobre o mesmo corpus. O axente de exploración obtivo 0,867 na recuperación do documento correcto e 0,627 nas respostas correctas, fronte a aproximadamente 0,39 e 0,37 da busca semántica: uns resultados preto de 1,7 veces mellores nas respostas e 2 veces mellores na recuperación, cunha latencia arredor dun 25 % menor. O axente de exploración traballa sobre todo con texto extraído e raramente descarga os PDF orixinais.

Ampliar

Unha infraestrutura compartida

A memoria persistente de Computer usa a mesma infraestrutura de sistema de ficheiros. Perplexity Brain, a wiki de coñecemento de Computer, almacena a memoria en repositorios de coñecemento co seu propio historial e as súas propias políticas. Manter o coñecemento separado dos ficheiros do proxecto significa que as actualizacións da memoria en segundo plano non compiten coas edicións deses ficheiros. Unha sesión que necesita ambos carga os dous repositorios.

Os axentes en segundo plano len o coñecemento existente, incorporan información nova e gardan as páxinas actualizadas como commits. Outros axentes len esas páxinas con ferramentas de ficheiros comúns, e as persoas tamén poden editalas. Os escritores comparten o seu traballo a través do repositorio en lugar de coordinarse directamente con cada lector. O historial de commits rexistra quen cambiou que, mentres que a caixa de saída informa das actualizacións aceptadas aos servizos posteriores. As persoas e os axentes poden basearse no traballo uns dos outros, cun rexistro de como evolucionou o coñecemento.

Conclusión

Cando persoas e axentes comparten un proxecto, o espazo de traballo fai algo máis que almacenar ficheiros. Ofrece un lugar común onde combinar as contribucións e facer un seguimento do que cambiou. Git xa proporciona boa parte desa base. Nós engadimos coordinación e comprobacións automatizadas para que os axentes poidan enviar traballo sen que unha persoa aprobe cada actualización. O resultado é unha forxa reducida ao esencial, xa que a colaboración entre axentes e o desenvolvemento de software con múltiples colaboradores son, no fondo, o mesmo problema.

Os axentes traballan en contornos illados independentes e temporais mentres contribúen a repositorios duradeiros. Os límites dos repositorios manteñen o crecemento baixo control, as descargas explícitas permiten que os axentes escollan que obter e os ficheiros comúns permítenlles explorar con ferramentas coñecidas. As actualizacións en segundo plano, as edicións interactivas e as tarefas programadas poden basearse no traballo unhas das outras sen coordinarse directamente.

A medida que máis axentes traballan de forma autónoma dentro dos Proxectos, o seu espazo de traballo compartido debe seguir sendo fiable e comprensible para as persoas. O obxectivo é sinxelo: cada cambio debería ser máis duradeiro que o axente que o produciu, quedar dispoñible para o seguinte colaborador e deixar un rexistro claro do que cambiou.

Citación

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