Un système de fichiers virtuel basé sur MongoDB pour les agents avancés de LangChain.

Les attentes envers les agents d’IA ont dépassé le simple fait de répondre aux questions. On leur demande d’effectuer des tâches complètes : élaborer un plan en plusieurs étapes, examiner des fichiers sources, créer des artefacts intermédiaires et déléguer des parties du problème à d’autres agents, ce qui transforme ce qui prenait autrefois des jours en quelques heures. Une telle vitesse n’est possible que lorsque l’agent peut naviguer avec confiance dans son système de fichiers, rechercher, lire et mettre à jour des fichiers au fur et à mesure. Le système de fichiers virtuel (VFS) de MongoDB pour LangChain Deep Agents répond à ce besoin. Il relie une vue de système de fichiers familière à MongoDB Atlas ainsi qu’à un stockage d’objets en arrière-plan, comme un bucket S3, permettant ainsi aux agents d’avoir un espace de travail recherchable qui perdure au-delà des sessions, des déploiements et des sous-agents. Les développeurs travaillant avec Deep Agents peuvent considérer Atlas comme la plateforme de données pour leurs agents, avec des fonctionnalités de recherche plein texte et vectorielle à portée de main.

Les sections suivantes expliquent ces deux concepts, montrent comment le backend MongoDB fonctionne au sein d’une application d’agent, et indiquent dans quels cas ce modèle convient aux systèmes d’entreprise.

Agents avancés et leurs outils de système de fichiers

Les agents avancés constituent un cadre construit sur LangChain et LangGraph, conçu pour des tâches complexes et multi-étapes. La planification, les sous-agents ainsi que des outils de type système de fichiers sont intégrés par défaut, ce qui permet à un agent de diviser une tâche importante en petites actions au lieu de devoir tout placer dans une seule fenêtre de contexte. Les opérations intégrées sont :

• ls liste les dossiers afin que l’agent puisse voir leur organisation
• glob recherche des fichiers selon un motif de chemin
• grep examine le contenu des fichiers
• read renvoie le contenu d’un fichier
• write et edit créent ou modifient des fichiers

upload_files et download_files gèrent les transferts en masse

Ces outils fonctionnent selon un contrat backend. L’agent n’a pas besoin de savoir si les fichiers se trouvent sur un disque local, dans un stockage LangGraph, dans un système de stockage d’objets ou derrière un autre niveau de persistance. Il utilise la même interface de système de fichiers, et le backend configuré fournit les données.

Ce que ajoute un système de fichiers virtuel

Un système de fichiers virtuel présente les données sous forme de chemins logiques tout en cachant l’endroit où elles sont physiquement stockées. Un agent peut voir des dossiers tels que docs/, reports/ ou projects/customer-a/, bien que les vrais fichiers soient stockés dans un système de stockage d’objets et que la version consultable se trouve dans une base de données.

La navigation dans un système de fichiers s’effectue par de petits pas, ce qui convient aux agents. Sans avoir à utiliser l’instruction de traitement du corpus entier, l’agent liste un répertoire, affine la recherche selon des modèles de noms de fichiers, cherche un concept, ouvre le fichier pertinent et enregistre ses résultats sous forme d’un nouvel artefact. Chaque étape ne récupère que ce dont il a besoin, permettant ainsi à l’agent de rester dans les limites du contexte et d’utiliser moins de ressources. Dans ce sens, le système de fichiers virtuel est un outil pour gérer le contexte pendant le travail de l’agent, au-delà d’être simplement une couche de stockage.

Le paquet et son mécanisme de routage

Le paquet langchain-mongodb-deepagents-vfs met en œuvre le BackendProtocol des Deep Agents de manière directe. Un corpus hébergé dans un stockage d’objets apparaît à l’agent comme un système de fichiers, et chaque appel est redirigé vers le système qui le traite le mieux :

• Les opérations axées sur la recherche (grep, glob, ls) s’exécutent sur MongoDB Atlas.
• Les opérations sur les octets de fichiers (read, write, edit, upload_files, download_files) sont directement dirigées vers le stockage d’objets.
• Une couche de synchronisation en arrière-plan maintient la représentation de recherche en accord avec le stockage d’objets.

Cela permet une séparation claire entre la source de vérité et l’index de recherche. Le stockage d’objets contient les documents originaux, tandis qu’Atlas gère les fragments recherchables, les embeddings ainsi que les métadonnées de chemin qui rendent le corpus accessible.

On pourrait se demander pourquoi la recherche devrait exister dans un système séparé et non sur une plateforme compatible S3 qui regroupe la recherche textuelle, vectorielle et hybride sur les mêmes données. Cette séparation est intentionnelle. Le stockage d’objets excelle dans le stockage durable, peu coûteux et à long terme de fichiers, mais il n’a pas été conçu pour gérer en même temps des index en temps réel, classer des requêtes hybrides et fournir des recherches de métadonnées structurées à faible latence. Atlas est une base de données opérationnelle où la recherche, la recherche vectorielle et le classement hybride sont des fonctionnalités indexées dès le départ. Le plan de recherche fonctionne donc avec un logiciel conçu spécifiquement à cet effet, tandis que le stockage d’objets continue de faire appel à ses propres capacités.

Recherche hybride derrière grep

Derrière grep, le paquet combine MongoDB Search avec MongoDB Vector Search. La recherche de texte complet est idéale pour les termes exacts, les identifiants, les noms de fichiers et les chaînes rares, tandis que les vecteurs conviennent aux paraphrases et aux questions en langue naturelle. En les associant, un agent peut rechercher un terme littéral comme MAX_RETRIES ou demander où les tentatives de répétition sont configurées, tout cela à travers une seule interface.

Les deux listes de résultats sont fusionnées par l’étape d’agrégation $rankFusion dans MongoDB. Comme le classement reste au sein de la base de données, aucun réclassificateur côté client n’est nécessaire, et le déplacement supplémentaire d’un agent qui en serait requis disparaît. Il existe également ici un compromis plus large. Sur une plateforme compatible S3, obtenir un classement plein texte, vectoriel ou hybride signifie généralement assembler plusieurs systèmes spécialisés : un moteur pour le texte, une base de données vectorielle pour les embeddings, ainsi qu’une couche de réclassement pour les fusionner, chacun disposant d’un pipeline d’indexation qui doit suivre les données sources. Dans Atlas, un seul moteur couvre les trois cas, et $rankFusion les fusionne dans une seule requête native.

Chunking, formats et embeddings

Le découpage tient compte des tokens. Les entrées pris en charge sont du texte brut, Markdown, PDF, DOCX, XLSX, XLS, PPTX et PPT. Chaque morceau conserve des métadonnées de position, à savoir le chemin d’origine, le numéro de page, les offsets de caractères et les informations de ligne, ce qui permet que les résultats soient fournis dans le format orienté ligne attendu par Deep Agents.

Les embeddings utilisés par défaut sont ceux d’Amazon Bedrock ; une option OpenAI est disponible via les extras du package, et une application peut injecter directement n’importe quelle implémentation d’embedding compatible avec LangChain. Une configuration typique ressemble à ceci :

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,
)

Par la suite, l’agent utilise ses outils de système de fichiers habituels, sans recourir à des outils personnalisés de MongoDB ou de S3 dans son cycle de raisonnement.

L’architecture à deux plans

Imaginez le système comme deux plans. Le stockage d’objets constitue le plan des données, qui contient les octets des fichiers, tandis que MongoDB Atlas représente le plan de contrôle et de recherche, gérant les métadonnées, les fragments et les index de récupération.

La figure montre comment le backend envoie les octets des fichiers via le stockage d’objets et effectue les opérations de recherche à travers Atlas.

Lorsque l’objet backend est créé, l’initialisation se poursuit en arrière-plan. La mise en place des index, la première synchronisation ainsi que le démarrage des surveillants s’exécutent tous sur un thread daemon. Les opérations sur les fichiers sont traitées immédiatement, tandis que les opérations de recherche attendent que la synchronisation initiale soit terminée. L’ingestion se déroule comme suit :

1. Lister les objets situés dans le bucket S3 et le préfixe configurés.
2. Télécharger chaque objet éligible.
3. Extraire le texte à l’aide du parseur adapté à ce format.
4. Diviser le texte en blocs contenant des métadonnées de position.
5. Créer des embeddings.
6. Insérer les blocs et les métadonnées dans Atlas.
7. Mettre en place ou vérifier les index de recherche et de recherche vectorielle.

Chaque bloc comprend 512 tokens avec une superposition de 64 tokens. Les ETags rendent la synchronisation initiale et l’ingestion par les surveillants idempotentes, de sorte que les objets inchangés sont ignorés et ne sont ni téléchargés ni re-embedded.

C’est ce que fait chaque appel. ls demande à Atlas les métadonnées des chemins et les regroupe en entrées de répertoire. glob utilise des règles de motifs de chemin standard pour trouver les fichiers correspondants. grep fait en sorte qu’Atlas combine la recherche par texte intégral et la recherche vectorielle sur le corpus en blocs pour retourner des résultats classés par pertinence. read récupère les octets actuels depuis le stockage d’objets plutôt que depuis l’index, et la différence est significative, car les résultats de recherche servent à la découverte tandis que les lectures fournissent le document original.

Il existe deux modes de surveillance. Un surveillant par sondage vérifie périodiquement le stockage d’objets et n’a pas besoin d’infrastructure supplémentaire d’événements AWS. Un surveillant SQS consomme les notifications d’événements S3 via Amazon SQS et convient à une synchronisation en production à plus faible latence.

Consistance éventuelle pour la recherche

La recherche est délibérément cohérente à terme. Une écriture réussit d’abord dans S3, puis l’observateur détecte le changement, fragmente et réinsère l’objet avant de mettre à jour les index. Les lectures affichent donc immédiatement l’état de S3, tandis que grep, glob et ls peuvent rester en retard jusqu’à ce que la synchronisation et l’indexation soient terminées.

Voici quelques règles pratiques pour le travail partagé : lisez directement lorsque les données sont fréquemment utilisées et partagées, utilisez edit pour une concurrence optimiste sur les fichiers partagés, et reservez la recherche pour trouver des éléments une fois que le corpus est stable. En attribuant à chaque agent son propre espace de noms de sortie, comme shared/outputs//, on réduit encore les conflits entre les travailleurs en parallèle.

Où ce modèle s’applique

Exploration du code. Plutôt que de recevoir un ensemble massif de code, un agent de programmation peut parcourir un grand répertoire : lister sa structure, localiser des fichiers à l’aide de glob, exécuter des recherches hybrides avec grep pour un concept ou un identifiant, lire le fichier en question et effectuer des modifications protégées par ETag. Les utilisations typiques incluent l’intégration à un répertoire, l’enquête sur des incidents, l’analyse des dépendances et de la configuration, la recherche de tests nécessitant des corrections ciblées, ainsi que la génération de documentation à partir du code.

Corpus de documents. Les politiques, contrats, procédures, guides opérationnels, documents produits et dossiers clients s’accumulent souvent dans des systèmes de stockage d’objets, et l’interface backend permet à un agent d’y accéder de manière similaire à un système de fichiers. Un agent de documents peut rechercher la politique de remboursement destinée aux clients entreprises, afficher des passages formulés différemment, ouvrir le fichier PDF ou DOCX source et rédiger un résumé avec des références vers un autre emplacement. Cela convient à la génération améliorée par la récupération d’informations lorsque la navigation est nécessaire, et non seulement à une simple recherche.

Équipes multi-agents. Un coordinateur peut assigner des tâches ciblées à des sous-agents spécialisés sur un corpus partagé. Un agent de sécurité recherche des motifs de code à risque, un agent de documentation rassemble les étapes de déploiement et les références de configuration, un agent de test trouve les fichiers de test pertinents et rédige des notes sur le niveau de couverture, tandis qu’un agent de synthèse lit tout cela et compile un rapport. Tous partagent un espace de noms unique, avec Atlas en tant que couche de découverte.

Stockage de documents en cours d’évolution. Le contenu d’entreprise est en perpétuelle modification : des rapports arrivent, des politiques changent, des artefacts opérationnels sont révisés. Comme le suiveur maintient Atlas en synchronisation avec le stockage d’objets, un agent démarré ultérieurement peut rechercher le contenu actuel sans devoir reconstruire un index à chaque exécution. Cela facilite le travail des assistants de manuels opérationnels, du suivi de la conformité et des politiques, des assistants de recherche grâce à des données constamment mises à jour, des agents d’assistance avec des documents sur les produits et la résolution de problèmes, ainsi que des assistants de partenaires travaillant à partir d’artefacts d’implémentation partagés.

Espaces de travail durables. Les Deep Agents peuvent enregistrer des plans, des notes rapides, des résumés et des livrables finaux sous forme de fichiers. Leur stockage dans le stockage d’objets et leur indexation dans Atlas permettent de disposer d’un espace de travail qui survit aux redémarrages et qui peut être consulté par des personnes ou d’autres agents.

Limites de production et points d’extension

L’utilisation en production exige que des contrôles d’accès, une isolation des utilisateurs, des règles de résidence des données, de conservation et d’audit soient appliqués par l’application, la configuration de stockage et le modèle de métadonnées. Le paquet lui-même est responsable du contrat de système de fichiers Deep Agents ainsi que du trajet allant du stockage d’objets à la recherche Atlas.

Il est possible de l’élargir : d’autres systèmes de stockage tels qu’Azure Blob Storage ou Google Cloud Storage, davantage de fournisseurs d’incorporation et de stratégies configurables, des analyseurs de documents supplémentaires et une ingestion plus rapide, des outils de surveillance plus fiables avec fonction de complétion des données et des données plus récentes, une amélioration de la qualité de recherche, du filtrage, du classement et des métadonnées, ainsi que des exemples, des benchmarks et des conseils de déploiement plus complets. Une bonne règle consiste à garder tout ce qui est spécifique au stockage derrière l’interface du stockage d’objets, de sorte que le découpeur, l’incorporeur, la logique de synchronisation et le routage de recherche ne traitent que des chemins, des octets, des métadonnées et de la recherche, jamais l’API d’un fournisseur en particulier.

La séparation des préoccupations est l’idée fondamentale. Les agents voient un seul système de fichiers virtuel simple, les applications stockent de grands documents variés dans un système de stockage d’objets en tant que source de vérité pour les données binaires, Atlas les transforme en une couche consultable dotée de métadonnées, de fonctionnalités de recherche plein texte, de classement vectoriel et hybride, tandis que la couche de synchronisation assure que la découverte reste en adéquation avec le corpus en temps réel.