Multi-Node-Architektur

Überblick

Die Multi-Node-Architektur ermöglicht das Zusammenwirken mehrerer Geräte und realisiert das verteilte Erlebnis „Gerät A führt den Dialog, Gerät B führt aus". Das Gateway fungiert als zentrale Steuerungsdrehscheibe und verwaltet die Registrierung, Erkennung und intelligente Weiterleitung aller Nodes.

Architekturübersicht

                      
                      ┌─────────┐   WebSocket   ┌─────────────┐   WebSocket   ┌──────────┐
│ Web-Seite│ ◄────────────► │   Gateway    │ ◄────────────► │ APP-Node A│
│(Browser) │               │  (Node.js)   │               │ (macOS)  │
└─────────┘               │              │               └──────────┘
                          │  - Node-Registrierung │
                          │  - Intelligentes Routing │               ┌──────────┐
                          │  - Nachrichtenweiterleitung │ ◄────────────► │ APP-Node B│
                          │  - Berechtigungsprüfung │               │(Windows) │
                          └─────────────┘               └──────────┘

                    

Node-Typen

Node-Registrierungsinformationen

Jeder Node registriert beim Verbinden mit dem Gateway die folgenden Informationen:

Sichtbarkeitsbereich von Nodes

Nodes der Ebene account: Der Benutzer meldet sich auf mehreren Geräten an und kann Aufgaben zwischen beliebigen Geräten steuern.

Nodes der Ebene enterprise: Geteilte Ausführungsressourcen innerhalb der Organisation, die alle Mitglieder über das Gateway nutzen können.

Intelligentes Gateway-Routing

Wenn ein Web-Benutzer einen Dialog startet, verwendet das Gateway eine dreistufige Degradationsstrategie, um den am besten geeigneten Ausführungs-Node auszuwählen:

Erste Stufe: LLM-semantisches Routing

Verwendet die OpenAI API zur Analyse der Benutzerabsicht und ordnet den besten Node zu:

Das LLM gibt zurück: {nodeId, confidence, reason}

Sicherheitsmaßnahmen:

• Node-Beschreibungen werden als DATA behandelt und nicht als Anweisungen ausgeführt
• Verhindert Prompt Injection über Node-Beschreibungen

Hinweis: Für das aktuelle LLM-Routing ist noch kein Modell konfiguriert, daher erfolgt automatisch eine Degradation auf die zweite Stufe.

Zweite Stufe: BM25-Keyword-Matching

Führt ein Keyword-Matching zwischen Benutzeranfrage und Node-Beschreibung auf Basis des BM25-Algorithmus durch:

Gibt den Node mit der höchsten Punktzahl zurück oder null (kein Treffer).

Dritte Stufe: Fallback auf die neueste Verbindung

Wählt den zuletzt verbundenen Node anhand des Zeitstempels connectedAtMs aus, um sicherzustellen, dass immer ein Fallback-Ergebnis vorhanden ist.

Remote-Ausführung

Dialogablauf

                      
                      1. Web-Seite sendet chat.send an das Gateway
2. Gateway führt intelligentes Routing aus und wählt den Ziel-Node
3. Gateway leitet die Nachricht an den APP-Node weiter
4. APP-Node startet die Agent Loop und führt die Aufgabe aus
5. Streaming-Ereignisse während der Ausführung werden über chat.event zurückgesendet
6. Web-Seite rendert den Ausführungsprozess in Echtzeit

                    

Remote-Werkzeugaufruf

                      
                      1. Haupt-Agent gibt über dispatch_multi_node_agent den Remote-Node an
2. Gateway sendet node.invoke.request an den Ziel-Node
3. Remote-Node startet eine unabhängige Agent Loop
4. Nach Abschluss wird das Ergebnis über node.invoke.result zurückgegeben

                    

Anhang-Hoisting (Update 2026-04) NEW

Wenn eine Nachricht bei der knotenübergreifenden Weiterleitung inline eingebettete base64-Anhänge (Bilder, Dokumente usw.) enthält, lädt das System diese automatisch in den Cloud-Speicher hoch und wandelt sie in eine URL-Referenz um:

• Grund: Vermeidet, dass zu große Gateway-RPC-Nachrichten zu Übertragungsfehlern führen
• Zeitpunkt: Wird vor der Remote-Weiterleitung automatisch ausgeführt, für den Benutzer nicht wahrnehmbar
• OS-Pfadnormalisierung: Bei der Weiterleitung zwischen Betriebssystemen (macOS/Windows/Linux) werden die Pfadtrennzeichen automatisch konvertiert

Verteilungsregeln für Berechtigungs-Popups

Bei der knotenübergreifenden Ausführung ist die Frage, „auf welcher Seite" das Werkzeug-Berechtigungs-Popup angezeigt wird, eine zentrale Produktentscheidung – es gilt, ein Gleichgewicht zwischen „der Benutzer kann rechtzeitig reagieren" und „das Auslösen sensibler Operationen durch unbefugten Zugriff verhindern" zu finden.

Szenario gleiches Konto (Aufrufer und Ausführender sind dasselbe Konto)

Szenario unterschiedliche Konten (kontenübergreifender Aufruf eines enterprise-Nodes)

• node-D ist ein Node vom Typ enterprise (innerhalb derselben Organisation von anderen Benutzern auffindbar), aktuell angemeldet als user001
• node-E (angemeldet als user002, APP- oder Web-Seite) sendet über das Gateway eine Nachricht an node-D
• Falls node-D während der Ausführung eine Werkzeugberechtigung benötigt:
  • Das Popup wird nur auf der lokalen Oberfläche von node-D angezeigt und nicht knotenübergreifend an node-E verteilt
  • Bei ausbleibender Reaktion über 5 Minuten gilt standardmäßig Ablehnung

Designmotivation

Umsetzungshinweis: Die knotenübergreifende Verteilungsstrecke für node-A APP → node-B APP bei gleichem Konto existiert derzeit nicht. Anforderungen, die diesen Pfad betreffen, erfordern neues Gateway-Routing + Empfangs-/Anzeigelogik auf der APP-Seite; gehen Sie nicht standardmäßig davon aus, dass sie bereits verfügbar ist.

Kontenübergreifende Gateway-Isolation NEW

Neben den Regeln zur Position der Berechtigungs-Popups ist auch der Datenzugriff selbst isoliert:

Isolation des persönlichen Gedächtnisses

Wenn ein Node im enterprise-Bereich kontenübergreifend aufgerufen wird:

• Kontenbezogenes Gedächtnis (an userId gebunden): ❌ Kein Zugriff
• Unternehmensbezogenes Gedächtnis (an orgId gebunden): ✅ Zugriff möglich
• Sitzungsbezogenes Gedächtnis (aktuelle Sitzung): ✅ Zugriff möglich

Über das Flag isRemoteSession wird bei Gedächtnisabfragen eine zwangsweise Filterung durchgesetzt – kontenübergreifende Aufrufer können über memory_query nicht das persönliche Gedächtnis des Node-Besitzers lesen.

Warum dieses Design

• Datenschutz: Ihre persönlichen Präferenzen, Arbeitsgewohnheiten und Kontoinformationen können nicht von Kollegen durch das Aufrufen Ihres Nodes gelesen werden
• Unternehmensweites Teilen: Der Technologie-Stack, die Standards und anderes Unternehmenswissen der Organisation werden weiterhin normal geteilt, ohne die Zusammenarbeit zu beeinträchtigen
• Compliance-Anforderungen: Erfüllt die Anforderung der „minimalen Berechtigung" von Datenschutzvorschriften wie der DSGVO

Unterscheidung der Dialog-Symbole

In der Sitzungsliste werden Dialoge unterschiedlicher Herkunft mit unterschiedlichen Symbolen angezeigt:

Die Bestimmung erfolgt anhand der Felder isLocalInitiated, targetNodeId und sourceChannel.

WebSocket-Protokoll

Verbindungs-Handshake

                      
                      1. Client → Gateway: connect.challenge
2. Gateway → Client: challenge (mit nonce)
3. Client → Gateway: connect (mit signiertem JWT)
4. Gateway → Client: hello-ok (Verbindung bestätigt)

                    

Heartbeat-Aufrechterhaltung

• tick-Mechanismus: Regelmäßiger Heartbeat zur Aufrechterhaltung der Verbindung
• Wiederverbindung nach Abbruch: Exponentielles Backoff bei Wiederholungsversuchen
• Bereinigung abgelaufener Einträge: Das Gateway bereinigt regelmäßig abgelaufene Node-Sitzungen

Flusskontrolle

• Delta-Drosselung: SSE-Streaming-Ereignisse werden über 150 ms aggregiert, um die Anzahl der WebSocket-Frames zu reduzieren
• Run-TTL: 10 Minuten Timeout, stündliche Bereinigung abgelaufener Runs

Was das für Benutzer bedeutet

Die Multi-Node-Architektur ermöglicht es Ihnen, Aufgaben von überall aus zu starten und vom am besten geeigneten Gerät ausführen zu lassen.

Typische Szenarien:

• Im Café über den Handy-Browser (Web-Seite) eine Aufgabe starten, die den Zugriff auf Dateien des Bürocomputers erfordert → das Gateway leitet die Aufgabe automatisch zur Ausführung an den APP-Node im Büro weiter
• Ein leistungsstarker Server im Team (macOS Pro) hat ständig die APP geöffnet und ist als enterprise eingestellt → alle Teammitglieder können rechenintensive Aufgaben von ihrem eigenen Browser aus dorthin verteilen

Das Erlebnis, das Sie spüren können:

• Beim Starten eines Dialogs auf der Web-Seite wählt das System automatisch einen online befindlichen APP-Node zur Ausführung aus
• In der Sitzungsliste werden unterschiedliche Symbole angezeigt, damit Sie erkennen, ob ein Dialog lokal oder remote ausgeführt wird
• Wenn kein APP-Node online ist, weist die Web-Seite darauf hin, dass Aufgaben, die Agent-Fähigkeiten erfordern, nicht ausgeführt werden können
• Wenn auf mehreren Computern die APP installiert ist, können Sie manuell auswählen, auf welchem Computer die Ausführung erfolgt

Worauf Sie achten müssen:

• Die Web-Seite kann Agent-Aufgaben nicht eigenständig ausführen und benötigt mindestens einen online befindlichen APP-Node
• Bei remote ausgeführten Dialogen tritt eine Netzwerkverzögerung auf (abhängig von der Netzwerkqualität zwischen Gateway und Node)
• Wenn Sie einen Node auf den enterprise-Bereich einstellen, können Teammitglieder Aufgaben an Ihr Gerät verteilen – aber auf Ihr persönliches Gedächtnis wird nicht zugegriffen

Verwandte Dokumente

• Work-Node-Verwaltung — Online-Nodes über die Verwaltungsoberfläche einsehen
• Laufzeitsicherheit — Nodes — Sicherheitskonfiguration von Nodes
• Subagent — Knotenübergreifende Verteilung — dispatch_multi_node_agent
• Dreidimensionales Gedächtnissystem — Kontenübergreifende Gedächtnisisolation