Ein von MongoDB unterstütztes virtuelles Dateisystem für LangChain Deep Agents

Die Erwartungen an KI-Agenten haben sich über das bloße Beantworten von Fragen hinaus entwickelt. Von ihnen wird erwartet, ganze Aufgaben auszuführen: mehrstufige Pläne zu erstellen, Quelldateien zu analysieren, vorläufige Ergebnisse zu generieren und Teilaufgaben an andere Agenten zu delegieren – wodurch Aufgaben, die früher Tage in Anspruch nahmen, nun in Stunden erledigt werden können. Eine solche Geschwindigkeit ist nur möglich, wenn der Agent selbstbewusst in seinem Dateisystem navigieren kann, dabei nach Dateien suchen, sie lesen und aktualisieren kann. Das virtuelle Dateisystem (VFS) von MongoDB für LangChain Deep Agents deckt diesen Bedarf ab. Es verbindet einen vertrauten Dateisystemansatz mit MongoDB Atlas sowie einer darunterliegenden Objektspeicherlösung wie einem S3-Bucket, sodass die Agenten über einen suchbaren Arbeitsraum verfügen, der über Sitzungen, Deployments und Unteragenten hinausbesteht. Entwickler von Deep Agents können Atlas als Datenplattform für ihre Agenten nutzen, bei der Volltext- und Vektorsuche direkt verfügbar sind.

Die folgenden Abschnitte erläutern die beiden Konzepte, zeigen, wie der MongoDB-Backend innerhalb einer Agentenanwendung funktioniert, und weisen darauf hin, wo dieses Muster für Unternehmenssysteme geeignet ist.

Deep Agents und ihre Dateisystemwerkzeuge

Deep Agents bilden eine Erweiterung über LangChain und LangGraph, die für komplexe, mehrschrittige Aufgaben konzipiert ist. Planung, Subagenten sowie dateisystemähnliche Werkzeuge sind bereits integriert, wodurch ein Agent eine große Aufgabe in kleine Schritte aufteilen kann, anstatt alles in ein einziges Kontextfenster zu pressen. Zu den integrierten Operationen gehören:

• ls listet Verzeichnisse auf, damit der Agent erkennen kann, wie die Struktur aussieht
• glob findet Dateien anhand von Pfadmustern
• grep durchsucht den Inhalt von Dateien
• read gibt eine Datei zurück
• write und edit erzeugen oder ändern Dateien

upload_files und download_files kümmern sich um Massenübertragungen

Diese Tools arbeiten hinter einem Backend-Vertrag. Der Agent muss nicht wissen, ob die Dateien auf einer lokalen Festplatte, in einem LangGraph-Speicher, in einem Objektspeicher oder hinter einer anderen Persistenzschicht gespeichert sind. Er ruft dieselbe Dateisystem-Schnittstelle auf, und das konfigurierte Backend liefert die Daten.

Was ein virtuelles Dateisystem hinzufügt

Ein virtuelles Dateisystem präsentiert Daten als logische Pfade, während es versteckt, wo sie physisch gespeichert sind. Ein Agent kann Verzeichnisse wie docs/, reports/ oder projects/customer-a/ sehen, obwohl die tatsächlichen Bytes in einem Objektspeicher und die suchbaren Kopien in einer Datenbank liegen.

Das Navigieren in einem Dateisystem erfolgt in kleinen Schritten, was für Agenten geeignet ist. Anstatt den Befehl für das gesamte Korpus zu verwenden, listet ein Agent einen Ordner auf, beschränkt die Suche nach Muster im Dateinamen, sucht nach einem Konzept, öffnet die entsprechende Datei und dokumentiert seine Erkenntnisse als neues Artefakt. Jeder Schritt liefert nur das, was benötigt wird, sodass der Agent innerhalb der Kontextgrenzen bleibt und weniger Ressourcen verbraucht. In diesem Licht ist das virtuelle Dateisystem mehr als nur eine Speicherschicht – es dient dazu, den Kontext während der Arbeit der Agenten zu verwalten.

Das Paket und seine Routenlogik

Das langchain-mongodb-deepagents-vfs-Paket implementiert das Deep Agents BackendProtocol als direkten Ersatz. Ein durch einen Objektspeicher unterstütztes Korpus erscheint dem Agenten als Dateisystem, und jeder Aufruf wird an das System weitergeleitet, das ihn am besten handhaben kann:

• Suchorientierte Operationen (grep, glob, ls) werden gegen MongoDB Atlas durchgeführt.
• Operationen an Dateibyten (read, write, edit, upload_files, download_files) gehen direkt zum Objektspeicher.
• Eine Hintergrund-Synchronisationsschicht hält die Suchrepräsentation in Einklang mit dem Objektspeicher.

Dadurch entsteht eine klare Trennung zwischen der Quelle der Wahrheit und dem Suchindex. Der Objektspeicher enthält die ursprünglichen Dokumente, während Atlas die suchbaren Abschnitte, Embeddings sowie Pfadmetadaten bereitstellt, die es ermöglichen, das Korpus zu finden.

Man könnte sich fragen, warum die Suche in einem separaten System stattfinden sollte und nicht auf einer S3-kompatiblen Plattform, die Text-, Vektor- und hybride Suchfunktionen für dieselben Daten bündelt. Diese Trennung ist beabsichtigt. Objektspeicher sind hervorragend dafür geeignet, dauerhafte, günstige und langfristig nutzbare Dateibyte zu speichern, wurden aber nicht dafür konzipiert, gleichzeitig aktuelle Indizes zu pflegen, hybride Abfragen zu bewerten und strukturierte Metadaten mit geringer Latenz bereitzustellen. Atlas ist eine operative Datenbank, in der Suche, Vektor Suche und hybride Ranking-Methoden von Anfang an als indizierte Funktionen vorhanden sind. Der Suchbereich läuft daher auf Software, die speziell für diese Aufgabe entwickelt wurde, während der Objektspeicher weiterhin seine eigenen Stärken ausspielt.

Hybride Suche hinter grep

Hinter grep kombiniert das Paket MongoDB Search mit MongoDB Vector Search. Die Volltextsuche eignet sich hervorragend für exakte Begriffe, Identifikatoren, Dateinamen und seltene Zeichenketten, während Vektoren sich besonders für Paraphrasen und Fragen in natürlicher Sprache eignen. Durch diese Kombination kann ein Agent nach einem literal wie MAX_RETRIES suchen oder fragen, wo die Wiederholungsversuche konfiguriert sind – und das alles über eine einzige Schnittstelle.

Die beiden Ergebnislisten werden in MongoDB in der Aggregationsstufe $rankFusion zusammengeführt. Da die Rangliste im Datenbankinneren verbleibt, ist kein erneuter Rangierungsprozess auf der Client-Seite erforderlich, wodurch auch die zusätzlichen Übertragungsaufwände entfallen. Hier gibt es ebenfalls ein größeres Abwägungsspiel. Auf einer S3-kompatiblen Plattform bedeutet die Erstellung von Volltext-, Vektor- und hybriden Ranglisten in der Regel die Zusammenstellung mehrerer spezialisierter Systeme: ein Motor für Texte, eine Vektordatenbank für Embeddings sowie eine Schicht zur erneuten Rangierung, um diese zu verknüpfen – wobei jedes System über einen Indexierungsprozess verfügt, der die Quelldaten verfolgen muss. In Atlas übernimmt ein einziger Motor alle drei Aufgaben, und $rankFusion fügt sie in einer einzigen nativen Abfrage zusammen.

Chunking, Formate und Embeddings

Das Chunking berücksichtigt Tokens. Unterstützte Eingaben sind reiner Text, Markdown, PDF, DOCX, XLSX, XLS, PPTX und PPT. Jedes Chunk behält positionale Metadaten bei, nämlich den Quellpfad, die Seitenzahl, die Zeichenzuordnungen sowie Informationen zu den Zeilen, wodurch die Ergebnisse im zeilenorientierten Format zurückgegeben werden, das Deep Agents erwartet.

Standardmäßig werden Embeddings von Amazon Bedrock verwendet, es gibt außerdem eine OpenAI-Option über die Package Extras, und eine Anwendung kann direkt jede langchain-kompatible Embedding-Implementierung einbinden. Eine typische Einrichtung sieht wie folgt aus:

from deepagents import create_deep_agent
from langchain_mongodb_deepagents_vfs import MongoFilesystemBackend

backend = MongoFilesystemBackend(
    s3_bucket_name="acme-docs",
    mongodb_connection_string="mongodb+srv://<user>:<password>@<cluster>/",
)

agent = create_deep_agent(
    tools=[],
    instructions="You are a research assistant over the ACME documents corpus.",
    backend=backend,
)

Danach verwendet der Agent seine üblichen Dateisystemwerkzeuge, ohne in seinem Entscheidungsprozess spezielle MongoDB- oder S3-Werkzeuge einzusetzen.

Die Zwei-Ebenen-Architektur

Betrachten Sie das System als zwei Ebenen. Die Objektspeicherung ist die Datenebene, die Dateibyten enthält, während MongoDB Atlas die Steuer- und Suchebene darstellt, die Metadaten, Blöcke sowie Suchindizes verwalten.

Die Abbildung zeigt, wie der Backend die Dateibyten über die Objektspeicherung sendet und Suchvorgänge über Atlas abwickelt.

Während das Backend-Objekt erstellt wird, setzt die Initialisierung im Hintergrund fort. Die Bereitstellung von Indizes, die erste Synchronisierung sowie der Start des Überwachungsdienstes laufen alle auf einem Daemon-Thread ab. Durchlaufende Dateioperationen funktionieren sofort, während Suchvorgänge warten, bis die initiale Synchronisierung abgeschlossen ist. Die Eingabe erfolgt wie folgt:

1. Listen Sie die Objekte unter dem konfigurierten S3-Bucket und Präfix auf.
2. Herunterladen Sie jedes geeignete Objekt.
3. Entnehmen Sie mit dem Parser für dieses Format den Text.
4. Teilen Sie den Text in Blöcke auf, die Positionsmetadaten enthalten.
5. Erstellen Sie Embeddings.
6. Fügen Sie die Blöcke sowie die Metadaten in Atlas hinzu oder ersetzen Sie vorhandene Daten.
7. Stellen Sie die Such- und Vektor-Such-Indizes bereit oder überprüfen Sie sie.

Die Blöcke bestehen aus 512 Tokenn mit einer Überlappung von 64 Tokenn. ETags sorgen dafür, dass die anfängliche Synchronisierung sowie die Aufnahme neuer Daten idempotent abläuft, sodass unveränderte Objekte übersprungen und nicht erneut heruntergeladen sowie in Embeddings umgewandelt werden.

So funktioniert jeder Aufruf. ls bittet Atlas um Metadaten zu Pfaden und gruppiert diese in Verzeichnis-Einträge. glob verwendet standardmäßige Pfadmuster-Regeln, um passende Dateien zu finden. grep lässt Atlas Volltext- und Vektorabfragen im Chunk-Korpus durchführen und gerankte Ergebnisse zurückgeben. read holt die aktuellen Bytes aus dem Objektspeicher statt aus dem Index – der Unterschied ist bedeutend, da Suchergebnisse zur Entdeckung dienen und Lesevorgänge das ursprüngliche Dokument liefern.

Es gibt zwei Überwachungsmodi. Ein polling-basierter Überwacher prüft den Objektspeicher regelmäßig und benötigt keine zusätzliche AWS-Event-Infrastruktur. Ein SQS-Überwacher verarbeitet S3-Event-Benachrichtigungen über Amazon SQS und eignet sich für eine synchronisierte Produktion mit geringerer Latenz.

Eventuelle Konsistenz bei Suchvorgängen

Die Suche ist absichtlich letztendlich konsistent. Eine Schreiboperation ist zunächst in S3 erfolgreich, anschließend bemerkt der Überwacher die Änderung, teilt das Objekt in Blöcke auf, embeddet es erneut und aktualisiert die Indizes. Lesungen zeigen daher sofort den Zustand von S3, während grep, glob und ls bis zum Abschluss der Synchronisierung und Indexierung verzögert reagieren können.

Es gelten einige Faustregeln für die gemeinsame Nutzung. Lesen Sie direkt, wenn die Daten häufig genutzt und geteilt werden, verlassen Sie sich bei optimistischer Konkurrenz bei gemeinsamen Dateien auf edit und nutzen Sie die Suche, um Dinge zu finden, sobald das Korpus stabil ist. Indem jedem Agenten sein eigener Ausgabennamenraum wie shared/outputs// zugewiesen wird, werden Zusammenstöße zwischen parallelen Prozessen weiter reduziert.

Wo dieses Muster anwendbar ist

Code-Exploration. Anstatt mit einem riesigen Code-Stack überhäuft zu werden, kann ein Programmieragent durch ein großes Repository schreiten: Es listet die Struktur auf, findet Dateien mithilfe von glob, führt hybride grep-Suchen nach einem Konzept oder Identifikator durch, liest die jeweilige Datei und vornimmt unter Verwendung eines ETag-Schutzes Änderungen. Typische Anwendungsfälle sind die Einführung in ein Repository, die Untersuchung von Vorfällen, die Analyse von Abhängigkeiten und Konfigurationen, das Finden von Tests mit gezielten Korrekturen sowie die Erstellung von Dokumentation aus dem Code.

Dokumentkorpora. Richtlinien, Verträge, Verfahren, Anleitungen, Produktdokumente und Kundendaten sammeln sich oft im Objektspeicher an, und die Backend-Plattform bietet einem Agenten einen auf einem Dateisystem basierenden Zugang zu diesen Daten. Ein Dokumentenagent kann beispielsweise nach der Rückerstattungsrichtlinie für Unternehmenskunden suchen, anders formulierte Passagen hervorheben, die ursprüngliche PDF- oder DOCX-Datei öffnen und eine Zusammenfassung mit Verweisen auf andere Dateipfade erstellen. Dies eignet sich für generationstechnische Verfahren, die durch Suchfunktionen unterstützt werden, wenn eine Navigation erforderlich ist – und nicht nur für einfache Abfragen.

Mehre-Agenten-Teams. Ein Koordinator kann fokussierte Aufgaben an spezialisierte Unteragenten innerhalb eines gemeinsamen Korpus zuweisen. Ein Sicherheitsagent sucht nach riskanten Codemustern, ein Dokumentationsagent sammelt Bereitstellungsanleitungen und Konfigurationsreferenzen, ein Testagent findet relevante Testdateien und erstellt Abdeckungsnotizen, und ein Synthesizeragent liest alles und erstellt einen Bericht. Alle teilen sich einen Namespace, wobei Atlas als Entdeckungsschicht dient.

Lebende Dokumentenspeicher. Unternehmensinhalte ändern sich ständig: Es kommen Berichte hinzu, Richtlinien ändern sich, operative Dokumente werden überarbeitet. Da der Überwachungsmechanismus Atlas stets mit dem Objektspeicher in Einklang hält, sucht ein später gestarteter Agent nach aktuellen Inhalten, ohne bei jedem Aufruf einen Index neu erstellen zu müssen. Dadurch können Runbook-Assistenten, Tools zur Einhaltung von Vorschriften und Richtlinienüberwachung sowie Forschungsassistenten auf ständig aktualisierten Daten zurückgreifen. Support-Agenten erhalten Zugang zu Produkt- und Fehlerbehebungsunterlagen, und Partner-Assistenten können mit gemeinsam genutzten Implementierungsunterlagen arbeiten.

Dauerhafte Arbeitsräume. Deep Agents können Pläne, Notizen, Zusammenfassungen sowie endgültige Ergebnisse als Dateien speichern. Durch das Speichern dieser Dateien im Objektspeicher und das Indizieren im Atlas entsteht ein Arbeitsraum, der auch nach Neustarts erhalten bleibt und von Personen oder anderen Agenten inspiziert werden kann.

Produktionsbeschränkungen und Erweiterungspunkte

Zur Produktivnutzung sind Zugriffskontrollen, Isolation der Nutzer, Datenresidenz, Aufbewahrungs- und Prüfregeln erforderlich, die durch die Anwendung, die Speicherkonfiguration sowie das Metadatenmodell durchgesetzt werden müssen. Das Paket selbst ist für den Dateisystemvertrag der Deep Agents sowie für den Weg vom Objektspeicher zur Atlas-Suche verantwortlich.

Es gibt Raum zur Erweiterung: weitere Objektspeicher wie Azure Blob Storage oder Google Cloud Storage, mehr Embedding-Anbieter sowie konfigurierbare Strategien, zusätzliche Dokumentparser und schnellere Einpflegung, zuverlässigere Überwachungsfunktionen mit Nachfüllung sowie aktuellere Daten, verbesserte Suchqualität, Filterfunktionen, Ranking-Methoden und Metadaten sowie umfassendere Beispiele, Benchmarks und Bereitstellungsberatungen. Eine gute Regel ist es, alles, was speziell mit dem Speichern zu tun hat, hinter der Objektspeicherschnittstelle zu halten, sodass der Chunker, der Embedder, die Synchronisierungslogik sowie der Suchrouter nur mit Pfaden, Bytes, Metadaten und Suchfunktionen umgehen – niemals mit der API eines bestimmten Anbieters.

Die Trennung von Aufgaben ist die zentrale Idee. Agenten sehen ein einziges, einfaches virtuelles Dateisystem; Anwendungen lagern große und vielfältige Dokumente in Objektspeichern ab, die als Quelle der Wahrheit für die Daten dienen. Atlas wandelt diese in eine suchfähige Schicht mit Metadaten, Volltextsuche, Vektor- und hybriden Ranking-Methoden um, während die Synchronisationsschicht sicherstellt, dass die Entdeckungsfunktionen stets mit dem aktuellen Datensatz übereinstimmen.