Gemeinsame Workspaces für Menschen und Agenten entwickeln

Wir haben kürzlich Projekte eingeführt, in denen Menschen und Agenten in Perplexity Computer gemeinsam an langfristigen Aufgaben arbeiten. Jedes Projekt basiert auf einem gemeinsamen Workspace mit einem Dateisystem, das Kontext über Sitzungen, Agenten und Nutzer hinweg sammelt. Multiplayer-Zusammenarbeit über Monate hinweg erfordert Persistenz, Nebenläufigkeit und Nachvollziehbarkeit:

• Persistenz: Arbeit sollte über jede einzelne Agentensitzung oder Sandbox hinaus erhalten bleiben, damit derselbe Nutzer oder Agent sie später fortsetzen und alle Mitwirkenden darauf aufbauen können.
• Nebenläufigkeit: Mehrere Nutzer im selben Projekt können jeweils mehrere Agenten parallel Änderungen vornehmen lassen, die einen gemeinsamen Zustand voranbringen, statt sich gegenseitig zu überschreiben.
• Nachvollziehbarkeit: Sowohl Nutzer als auch Agenten sollten den Verlauf einsehen können, um zu prüfen, wer seit ihrer letzten Sitzung was geändert hat, ohne das gesamte Projekt erneut lesen zu müssen, und um Änderungen bei Bedarf rückgängig zu machen.

Diese Herausforderungen kommen Softwareentwicklern bekannt vor. Git-Forges sind vor Jahrzehnten entstanden, um genau diese Anforderungen zu erfüllen: ein gehosteter Dienst, der Versionskontrolle mit Funktionen für die Zusammenarbeit verbindet, damit viele Mitwirkende ihre Arbeit in einer einzigen verbindlichen Quelle zusammenführen können. Das Dateisystem hinter Projekten ist eine solche Git-Forge, gebaut für die Zusammenarbeit zwischen Menschen und Agenten sowie zwischen Agenten untereinander.

Vergrößern

Architektur

Git übernimmt bereits Persistenz, Nebenläufigkeit und Nachvollziehbarkeit. Es identifiziert jede Datei anhand ihres Inhalts, sodass unveränderte Dateien nur einmal gespeichert werden und gespeicherte Kopien nie veralten. Jeder Commit speichert alle aktualisierten Dateien auf einmal, sodass Mitwirkende nie einen halbfertigen Zustand sehen. Kollidieren zwei Schreibende, kann der Unterlegene seine Änderungen auf die neue Version anwenden und es erneut versuchen. Die Kette der Commits zeigt, wer was geändert hat, und macht es einfach, frühere Versionen wiederherzustellen. Was Agenten nicht brauchen, ist der Rest einer für Menschen gebauten Forge, etwa Review-Ansichten, Branch-Verwaltung und Benachrichtigungen.

Unsere Architektur führt den gesamten Prozess in der Cloud aus und unterstützt alle Formen von Wissensarbeit über das Programmieren hinaus. Jedes Computer-Projekt basiert auf einem Git-Repository, das von 5 Komponenten bereitgestellt wird:

• Die CLI verwaltet lokale Checkouts, synchronisiert Aktualisierungen und reicht die Änderungen des Agenten in jeder Sandbox ein.
• Die Control Plane lokalisiert das Projekt-Repository und stellt kurzlebige Zugangsdaten für den Zugriff darauf aus.
• Der Git-Dienst sendet Repository-Daten an Sandboxes, nimmt deren Einreichungen entgegen und entscheidet, welche Einreichung zum zuletzt akzeptierten Commit wird.
• Der S3-basierte Speicher von AWS sichert Repository-Daten dauerhaft.
• Die nachgelagerte Verarbeitung extrahiert Text und andere nützliche Informationen aus gespeicherten Dokumenten und stellt sie bereit, wenn Agenten das Projekt laden oder aktualisieren.

Jeder Agent hat seine eigene isolierte Sandbox. Darin arbeitet er mit einer lokalen Kopie des Repositorys, die von einer kleinen CLI verwaltet wird. Die CLI bittet die Control Plane, das Repository zu lokalisieren, und ruft dann Änderungen über den Git-Dienst ab bzw. reicht sie darüber ein. Ein Agent-Proxy prüft den Zugriff für Sandbox-Anfragen, bevor sie den Git-Dienst erreichen. Der Git-Dienst liest und schreibt Repositorys auf einem gemeinsamen Dateisystem und entscheidet, ob eine Einreichung jeweils zum zuletzt akzeptierten Commit wird. Dieses Dateisystem wird von AWS S3Files bereitgestellt, das S3-basierten Speicher als gewöhnliche Dateien und Verzeichnisse zugänglich macht. Der Speicher ist in isolierte Zellen aufgeteilt, jede mit eigenem Dateisystem und eigenen Git-Dienst-Replikaten. Nachdem ein Commit akzeptiert wurde, extrahieren Hintergrund-Worker Text und andere nützliche Informationen aus geänderten Dokumenten, speichern die Ergebnisse getrennt vom Repository-Verlauf und stellen sie bereit, wenn Agenten das Projekt laden oder aktualisieren.

Im Folgenden gehen wir die Komponenten einzeln durch.

Vergrößern

CLI: Mit lokalen Dateien in Sandboxes arbeiten

Agenten laufen in SPACE, unserer hauseigenen Sandbox-Plattform. Jede Sandbox verfügt über eine kleine CLI, die das Repository materialisiert und synchron hält. Für jede sinnvolle Arbeitseinheit des Agenten reicht sie die Änderungen als Commit ein.

Agenten greifen in der Regel nur auf einen kleinen Teil der Projektdateien zu, daher ist es nicht nötig, das gesamte Repository vorab zu materialisieren. Deshalb materialisiert die CLI bedarfsgesteuert (lazy): Große und binäre Dateien, die über Git Large File Storage (LFS) gespeichert sind, kommen als kleine Pointer-Dateien an, die die tatsächliche Größe des Objekts enthalten. So kann der Agent anhand von Name und Größe entscheiden, ob sich ein Download lohnt. Bei Dokumenten wie PDFs liest der Agent zuerst den geparsten Text und lädt die Quelldateien nur bei Bedarf herunter.

Eine weitere naheliegende Option wäre ein virtuelles Dateisystem. Wir haben eine FUSE-basierte Implementierung getestet, doch sie war bei dateisystemlastigen Workloads im Vergleich zu lokalen Dateien rund 400-mal langsamer, da jede Anfrage einen Netzwerk-Roundtrip erfordert. Außerdem benötigt sie in der Regel privilegierte Berechtigungen auf dem Host, sodass jeder Agent in einer privilegierten Sandbox laufen müsste.

Vergrößern

Control Plane: Repositorys lokalisieren und Zugriff erteilen

Die Control Plane ermittelt, wo jedes Repository gespeichert ist, und erteilt Zugriff darauf. Wenn ein Repository erstellt wird, weist die Control Plane es einer Speicherzelle zu, einer isolierten Speichereinheit mit eigenen Git-Dienst-Replikaten. Wenn ein Agent mit der Arbeit an einem Projekt beginnt, fragt die CLI die Control Plane, wo das Repository gespeichert ist. Die Control Plane gibt den Speicherort und temporäre Zugangsdaten für den Git-Dienst zurück. Die Control Plane liest oder schreibt niemals Repository-Daten. Der Git-Dienst entscheidet, was in ein Repository gelangt.

Git-Dienst: Daten übertragen und Aktualisierungen koordinieren

Der Git-Dienst führt Git-Operationen aus und überträgt Repository-Inhalte und Versionsverlauf zwischen Sandboxes und Speicher. Er ist ein schlanker Wrapper um die Git-eigenen Serving-Befehle. Er unterstützt Ref Discovery, um dem Client mitzuteilen, wo sich der Head des Repositorys befindet, upload-pack zum Klonen und Abrufen sowie receive-pack zum Empfangen neuer Objekte und einer Anfrage, den Head des Repositorys vorzurücken. Außerdem stellt er die Git-LFS-API bereit: Für große und binäre Dateien stellt er kurzlebige Links aus, damit Sandboxes diese Dateien direkt in S3 hochladen und von dort herunterladen können.

Wir haben mit einem handelsüblichen Forge-Server begonnen, damit wir die Agenten- und Benutzeroberflächen als Prototyp entwickeln konnten, während wir parallel unsere eigene schlanke Forge aufbauten, die sich nur auf die Git-Operationen konzentriert, die wir benötigen.

Der Dienst besteht aus einer Flotte von Replikaten, von denen jedes eine laufende Instanz desselben Servers ist. Eine Zelle bündelt gemeinsamen Speicher mit einer Gruppe von Replikaten und deren unterstützenden Diensten. Replikate innerhalb einer Zelle können so auf dasselbe gemeinsame Dateisystem zugreifen, statt unabhängige Kopien jedes Repositorys zu pflegen.

Dank dieses gemeinsamen Speichers können die Replikate zustandslos bleiben. Jedes Replikat in der Zelle kann jedes ihrer Repositorys bedienen, sodass beim Ersetzen oder Hinzufügen von Replikaten keine Repository-Daten zwischen Servern verschoben werden müssen. Anfragen für ein Repository gehen normalerweise an dasselbe Replikat, damit dessen Caches nützlich bleiben, doch das Repository ist nicht davon abhängig, dass genau diese Instanz verfügbar bleibt.

Der Akzeptanzschritt prüft Repository-Invarianten, um sicherzustellen, dass ein akzeptierter Commit einen gültigen Repository-Zustand darstellt. Wir definieren für jedes Repository einen expliziten Vertrag, damit mechanische Prüfungen verhindern können, dass es zu groß wird. Große und binäre Dateien wie PDFs und Bilder werden über Git LFS statt als rohe Git-Blobs gespeichert. Die Kompaktierung hält den jüngeren Verlauf verfügbar und begrenzt zugleich die Größe des Repositorys. Nach einer erfolgreichen Einreichung fragt die CLI beim Git-Dienst nach, ob das Repository kompaktiert werden muss. Überschreitet die Anzahl der aufbewahrten Commits einen Schwellenwert, behält der Git-Dienst nur eine kleinere Menge der neuesten Commits. Der ältere Verlauf wird durch einen einzigen Ausgangs-Snapshot ersetzt, und die jüngeren Commits werden erneut angewendet, um die Commit-Kennungen zu aktualisieren.

Vergrößern

Ein einfacher Synchronisationsschritt regelt gleichzeitige Schreibzugriffe. Er verfolgt den zuletzt akzeptierten Commit, den sogenannten Head. Wenn er eine Einreichung erhält, akzeptiert er sie nur, wenn sie auf diesem Head aufbaut. Andernfalls sendet er eine strukturierte Stale-Base-Antwort; der Unterlegene muss seine Änderung dann auf dem neuen Head erneut anwenden und neu einreichen. Dieses Design stellt sicher, dass sich gleichzeitig arbeitende Agenten nicht unbemerkt gegenseitig überschreiben, ohne nennenswerte Verlangsamungen zu verursachen. In unseren Produktions-Workflows werden weniger als 2 % der Einreichungen als veraltet abgelehnt. Insgesamt liegt die mediane Latenz beim Einreichen unter 1,7 Sekunden und die p99-Latenz unter 8 Sekunden.

Vergrößern

Der Git-Dienst protokolliert außerdem jede akzeptierte Änderung. Für jeden akzeptierten Schreibvorgang fügt er einen Eintrag zu einer Outbox hinzu – einem Log, das das Repository, den neuen Commit, den Nutzer, der die Änderung vorgenommen hat, und die geänderten Pfade auflistet. Nachgelagerte Dienste wie der Parser lesen dieses Log, um neue Arbeit zu finden.

Zusammen bilden diese Bausteine eine Repository-Verwaltungsschicht – ohne die Teile, die Agenten nicht brauchen. Pull Requests sind überflüssig, weil kein Mensch jede einzelne Änderung prüft. Stattdessen prüft der Git-Dienst den Vertrag beim Einreichen, der Agent, der den Wettlauf verliert, wendet seine eigene Änderung erneut an, und der Commit-Verlauf hält fest, wer was geändert hat. Deterministische Prüfungen halten jedes Repository innerhalb seines Vertrags, statt sich darauf zu verlassen, dass ein menschlicher Operator das Wachstum steuert.

Speicher: Arbeit dauerhaft sichern

Die Speicherschicht sichert Repository-Daten dauerhaft und unabhängig von den Sandboxes und den Git-Dienst-Replikaten. Repositorys liegen auf AWS S3Files, das S3-basierten Speicher über eine Dateisystemschnittstelle bereitstellt, die Standard-Git ohne Anpassungen nutzen kann. Jedes davon ist ein Bare-Git-Repository auf dem gemeinsamen Dateisystem, das die Objekte und Referenzen des Repositorys enthält, aber keinen Arbeits-Checkout.

Durch die Entkopplung von Speicher und Rechenleistung können Sandboxes kurzlebig bleiben. Jeder Agent erhält seine eigene Sandbox, und viele Agenten können am selben Projekt arbeiten, ohne sich einen Rechner zu teilen. Stürzt eine Sandbox ab, ist nur Arbeit gefährdet, die noch nicht eingereicht wurde.

Stattdessen könnten wir jedem Projekt eine langlebige Sandbox geben, die sich alle seine Agenten teilen, sodass die Projektdateien auf der Festplatte dieses Rechners liegen würden. Das würde jedoch die Rechenleistung der Agenten an den Ort binden, an dem der Rechner läuft, und erfordern, dass er für seine Spitzenzeiten dimensioniert ist. Zudem müsste er monatelang fehlerfrei laufen, wobei Backups und Wiederherstellung als Teil des Speichersystems des Projekts verwaltet werden müssten.

Vergrößern

Nachgelagerte Verarbeitung: Dokumente für Agenten lesbar machen

Die wichtigste nachgelagerte Komponente ist eine Parser-Pipeline, die Text und Metadaten aus neu hinzugefügten oder aktualisierten Dokumenten extrahiert, damit Agenten die Projektdateien leicht lesen können. Ein Parser-Worker verarbeitet Aktualisierungen aus der Change-Stream-Warteschlange, leitet die geänderten Dateien aus den Commit-Metadaten ab und ruft die Rohbytes anhand des Inhalts-Hashes ab. Anschließend parst er das Dokument, um den extrahierten Text und die Dokumentmetadaten zu erzeugen.

Geparste Ausgaben liegen außerhalb des Repositorys in einem Speicher, der nach dem Hash des Quelldokuments indiziert ist. Diese Artefakte werden nie in das Repository zurückgeschrieben, da dies den Verlauf unnötig verunreinigen und die Anzahl gleichzeitiger Schreibvorgänge erhöhen würde. Stattdessen gelangen die geparsten Ausgaben über Checkout und Synchronisierung in eine Sandbox. Jeder Checkout enthält ein reserviertes Verzeichnis, das die CLI für die Materialisierung von Artefakten verwendet. Das Parsen erfolgt asynchron, sodass ein Parser-Worker im Hintergrund Checkouts nicht blockiert.

Wie Agenten den Workspace nutzen

Agenten erkunden die in die Sandbox geladene Repository-Version mit Standard-Dateisystemtools. Statt einer festen Pipeline aus Suchen und anschließendem Lesen zu folgen, listen sie Ordner auf, durchsuchen Dateiinhalte mit grep, lesen relevante Passagen und entscheiden anhand ihrer Funde, wo sie als Nächstes suchen.

Ähnlich wie Computer nutzt auch die Suche diesen Ansatz über ihre Standard-Dateitools. Ein separater Explorationsagent durchsucht das Projekt mit einem begrenzteren Budget und gibt relevante Dateipfade und unterstützende Auszüge zurück. Das antwortende Modell liest dann die ausgewählten Dateien und generiert die Antwort. Die Wiederverwendung einer bestehenden Projekt-Sandbox verkürzt die Einrichtungszeit: Das Anbinden an einen warmen Checkout dauert etwa 2,9 Sekunden, verglichen mit rund 8 Sekunden bei einem Kaltstart.

Vergrößern

Geparster Text macht größere Dokumente wie PDFs und Office-Dateien mit denselben Tools durchsuchbar. Der Agent prüft zuerst ein Manifest – eine Liste, die zeigt, für welche Dokumente extrahierter Text verfügbar ist – und durchsucht und liest diesen Text dann als gewöhnliche Dateien. Das Originaldokument lädt er nur herunter, wenn der Text nicht ausreicht, etwa um Abbildungen, Layout oder eingebettete Daten zu untersuchen.

Wir haben diesen Ansatz anhand von 150 Finanzfragen zu jeweils einem einzelnen Dokument mit einer semantischen Suche über einen Index auf demselben Korpus verglichen. Der Explorationsagent erreichte 0,867 beim Auffinden des richtigen Dokuments und 0,627 bei der korrekten Beantwortung, gegenüber rund 0,39 und 0,37 bei der semantischen Suche – etwa 1,7-mal besser bei den Antworten und 2-mal besser beim Retrieval, bei rund 25 % geringerer Latenz. Der Explorationsagent arbeitet überwiegend mit extrahiertem Text und lädt die Original-PDFs nur selten herunter.

Vergrößern

Eine gemeinsame Infrastruktur

Das persistente Gedächtnis von Computer nutzt dieselbe Dateisystem-Infrastruktur. Perplexity Brain, das Wissens-Wiki von Computer, speichert Erinnerungen in Wissens-Repositorys mit eigenem Verlauf und eigenen Richtlinien. Da Wissen getrennt von Projektdateien gehalten wird, konkurrieren Hintergrundaktualisierungen des Gedächtnisses nicht mit Bearbeitungen dieser Dateien. Eine Sitzung, die beides benötigt, lädt beide Repositorys.

Hintergrundagenten lesen vorhandenes Wissen, arbeiten neue Informationen ein und speichern aktualisierte Seiten als Commits. Andere Agenten lesen diese Seiten mit gewöhnlichen Dateitools, und Menschen können sie ebenfalls bearbeiten. Schreibende teilen ihre Arbeit über das Repository, statt sich direkt mit jedem Lesenden abzustimmen. Der Commit-Verlauf hält fest, wer was geändert hat, während die Outbox akzeptierte Aktualisierungen an nachgelagerte Dienste meldet. Menschen und Agenten können auf der Arbeit der jeweils anderen aufbauen – mit einer Aufzeichnung darüber, wie sich das Wissen entwickelt hat.

Fazit

Wenn Menschen und Agenten ein Projekt teilen, leistet der Workspace mehr, als nur Dateien zu speichern. Er bietet einen gemeinsamen Ort, um Beiträge zusammenzuführen und nachzuverfolgen, was sich geändert hat. Git liefert bereits einen Großteil dieses Fundaments. Wir ergänzen Koordination und automatisierte Prüfungen, damit Agenten Arbeit einreichen können, ohne dass ein Mensch jede Aktualisierung freigeben muss. Das Ergebnis ist eine auf das Wesentliche reduzierte Forge, denn agentenübergreifende Zusammenarbeit und Softwareentwicklung mit vielen Mitwirkenden sind im Kern dasselbe Problem.

Agenten arbeiten in unabhängigen, temporären Sandboxes und tragen zugleich zu dauerhaften Repositorys bei. Repository-Limits halten das Wachstum beherrschbar, explizite Downloads lassen Agenten selbst wählen, was sie abrufen, und gewöhnliche Dateien ermöglichen es ihnen, sich mit vertrauten Tools zurechtzufinden. Hintergrundaktualisierungen, interaktive Bearbeitungen und geplante Aufgaben können auf der Arbeit der jeweils anderen aufbauen, ohne sich direkt abzustimmen.

Da immer mehr Agenten autonom in Projekten arbeiten, muss ihr gemeinsamer Workspace zuverlässig und für Menschen nachvollziehbar bleiben. Das Ziel ist einfach: Jede Änderung sollte beständiger sein als der Agent, der sie erzeugt hat, für den nächsten Mitwirkenden verfügbar werden und eine klare Aufzeichnung dessen hinterlassen, was sich geändert hat.

Zitierhinweis

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