Architecture multi-nœuds

Vue d'ensemble

L'architecture multi-nœuds permet à plusieurs appareils de collaborer, offrant une expérience distribuée où « l'appareil A dialogue, l'appareil B exécute ». Le Gateway agit comme un hub d'orchestration central, gérant l'enregistrement, la découverte et le routage intelligent de tous les nœuds.

Aperçu de l'architecture

                      
                      ┌─────────┐   WebSocket   ┌─────────────┐   WebSocket   ┌──────────┐
│ Web端    │ ◄────────────► │   Gateway    │ ◄────────────► │ Nœud APP A│
│(Browser) │               │  (Node.js)   │               │ (macOS)  │
└─────────┘               │              │               └──────────┘
                          │  - Enregistrement des nœuds │
                          │  - Routage intelligent      │               ┌──────────┐
                          │  - Transfert de messages    │ ◄────────────► │ Nœud APP B│
                          │  - Vérification des droits  │               │(Windows) │
                          └─────────────┘               └──────────┘

                    

Types de nœuds

Informations d'enregistrement des nœuds

Chaque nœud enregistre les informations suivantes lors de sa connexion au Gateway :

Portée de visibilité des nœuds

Nœuds de niveau account : l'utilisateur se connecte sur plusieurs appareils et peut orchestrer des tâches entre n'importe lesquels d'entre eux.

Nœuds de niveau enterprise : ressources d'exécution partagées au sein de l'organisation, que tous les membres peuvent utiliser via le Gateway.

Routage intelligent du Gateway

Lorsqu'un utilisateur côté Web engage une conversation, le Gateway utilise une stratégie de repli à trois niveaux pour sélectionner le nœud d'exécution le plus approprié :

Premier niveau : routage sémantique par LLM

Utilise l'API OpenAI pour analyser l'intention de l'utilisateur et faire correspondre le meilleur nœud :

Le LLM retourne : {nodeId, confidence, reason}

Mesures de sécurité :

• La description du nœud est traitée comme des DONNÉES, jamais exécutée comme des instructions
• Empêche les injections de prompt via la description du nœud

Remarque : le routage LLM actuel n'a pas encore de modèle configuré ; il bascule automatiquement vers le deuxième niveau.

Deuxième niveau : correspondance de mots-clés BM25

Effectue une correspondance de mots-clés entre la requête de l'utilisateur et la description du nœud à l'aide de l'algorithme BM25 :

Retourne le nœud au score le plus élevé, ou null (aucune correspondance).

Troisième niveau : repli sur la connexion la plus récente

Sélectionne le nœud connecté le plus récemment selon l'horodatage connectedAtMs, garantissant qu'il y a toujours un résultat de repli.

Exécution à distance

Flux de conversation

                      
                      1. Le côté Web envoie chat.send au Gateway
2. Le Gateway effectue le routage intelligent et sélectionne le nœud cible
3. Le Gateway transfère le message au nœud APP
4. Le nœud APP lance l'Agent Loop pour exécuter la tâche
5. Les événements en flux durant l'exécution sont renvoyés via chat.event
6. Le côté Web affiche le processus d'exécution en temps réel

                    

Appel d'outils à distance

                      
                      1. L'Agent principal désigne le nœud distant via dispatch_multi_node_agent
2. Le Gateway envoie node.invoke.request au nœud cible
3. Le nœud distant lance un Agent Loop indépendant
4. Une fois terminé, il renvoie le résultat via node.invoke.result

                    

Hoisting des pièces jointes (mise à jour 2026-04) NEW

Lors d'un envoi inter-nœuds, si le message contient des pièces jointes base64 en ligne (images, documents, etc.), le système les téléverse automatiquement vers le stockage cloud et les remplace par des références URL :

• Raison : éviter que les messages RPC du Gateway soient trop volumineux et provoquent des échecs de transmission
• Moment : exécuté automatiquement avant l'envoi distant, de manière transparente pour l'utilisateur
• Normalisation des chemins OS : conversion automatique des séparateurs de chemin lors d'un envoi entre systèmes d'exploitation (macOS/Windows/Linux)

Règles de distribution des fenêtres de demande d'autorisation

Lors d'une exécution inter-nœuds, décider « sur quel côté afficher » la fenêtre de demande d'autorisation d'un outil est une décision produit clé — il faut trouver un équilibre entre « la capacité de l'utilisateur à répondre à temps » et « la prévention du déclenchement non autorisé d'opérations sensibles ».

Scénario même compte (l'appelant et l'exécutant sont le même compte)

Scénario comptes différents (appel inter-comptes d'un nœud enterprise)

• node-D est un nœud de type enterprise (découvrable par d'autres utilisateurs de la même organisation), actuellement connecté sous user001
• node-E (connecté sous user002, côté APP ou Web) envoie un message à node-D via le Gateway
• Si node-D a besoin d'une autorisation d'outil durant son exécution :
  • La fenêtre ne s'affiche que sur l'interface locale de node-D, sans distribution inter-côtés vers node-E
  • Refus par défaut si personne ne répond au bout de 5 minutes

Motivation de conception

Rappel d'implémentation : le chemin de distribution inter-côtés du même compte node-A APP → node-B APP n'existe pas actuellement. Tout besoin impliquant ce chemin nécessite l'ajout d'un routage Gateway + une logique de réception/affichage côté APP ; ne présumez pas qu'il est déjà disponible.

Isolation Gateway inter-comptes NEW

Au-delà des règles d'emplacement des fenêtres d'autorisation, l'accès aux données lui-même est également isolé :

Isolation de la mémoire personnelle

Lorsqu'un nœud est appelé entre comptes dans une portée enterprise :

• Mémoire de niveau compte (liée au userId) : ❌ non accessible
• Mémoire de niveau entreprise (liée à l'orgId) : ✅ accessible
• Mémoire de niveau session (session en cours) : ✅ accessible

Le filtrage est forcé lors des requêtes de mémoire via le drapeau isRemoteSession — l'appelant inter-comptes ne peut pas lire la mémoire personnelle du propriétaire du nœud cible via memory_query.

Pourquoi cette conception

• Protection de la vie privée : vos préférences personnelles, habitudes de travail et informations de compte ne peuvent pas être lues par un collègue appelant votre nœud
• Partage en entreprise : les connaissances d'entreprise (pile technique, normes, etc.) restent normalement partagées, sans nuire à la collaboration
• Exigences de conformité : répond aux exigences de « moindre privilège » des réglementations sur la vie privée telles que le RGPD

Distinction des icônes de conversation

Dans la liste des sessions, les conversations d'origines différentes affichent des icônes différentes :

La distinction repose sur les champs isLocalInitiated, targetNodeId et sourceChannel.

Protocole WebSocket

Établissement de la connexion (handshake)

                      
                      1. Client → Gateway : connect.challenge
2. Gateway → Client : challenge (avec nonce)
3. Client → Gateway : connect (avec JWT signé)
4. Gateway → Client : hello-ok (connexion confirmée)

                    

Maintien de la connexion (keep-alive)

• Mécanisme tick : battements de cœur périodiques pour maintenir la connexion
• Reconnexion après coupure : nouvelles tentatives avec repli exponentiel
• Nettoyage des sessions expirées : le Gateway nettoie périodiquement les sessions de nœuds expirées

Contrôle de flux

• Limitation des deltas : agrégation des événements en flux SSE sur 150 ms, réduisant le nombre de trames WebSocket
• TTL des runs : délai d'expiration de 10 minutes, nettoyage des runs expirés toutes les heures

Ce que cela signifie pour vous

L'architecture multi-nœuds vous permet de lancer une tâche depuis n'importe où et de la faire exécuter par l'appareil le plus approprié.

Scénarios typiques :

• Dans un café, vous lancez depuis le navigateur de votre téléphone (côté Web) une tâche nécessitant l'accès aux fichiers de l'ordinateur du bureau → le Gateway route automatiquement la tâche vers le nœud APP du bureau pour l'exécuter
• Un serveur performant de l'équipe (macOS Pro) garde en permanence l'APP ouverte et configurée en enterprise → tous les membres de l'équipe peuvent lui déléguer les tâches lourdes depuis leur propre navigateur

Ce que vous ressentirez :

• Lorsque vous lancez une conversation côté Web, le système sélectionne automatiquement un nœud APP en ligne pour l'exécuter
• La liste des sessions affiche différentes icônes, pour vous indiquer si la conversation s'exécute localement ou à distance
• Si aucun nœud APP n'est en ligne, le côté Web vous avertit qu'il ne peut pas exécuter une tâche nécessitant des capacités Agent
• Si l'APP est installée sur plusieurs ordinateurs, vous pouvez choisir manuellement sur quel ordinateur exécuter

Ce à quoi vous devez faire attention :

• Le côté Web ne peut pas exécuter de tâches Agent de façon autonome ; il faut au moins un nœud APP en ligne
• Les conversations exécutées à distance subissent une latence réseau (selon la qualité du réseau entre le Gateway et les nœuds)
• Lorsque vous définissez un nœud en portée enterprise, les membres de l'équipe peuvent lui déléguer des tâches — mais votre mémoire personnelle ne sera pas accessible

Documents associés

• Gestion des nœuds Work — consulter les nœuds en ligne depuis l'interface de gestion
• Sécurité d'exécution — Nœuds — configuration de sécurité des nœuds
• Sous-agent — Envoi inter-nœuds — dispatch_multi_node_agent
• Système de mémoire tridimensionnel — isolation de la mémoire inter-comptes