Architektur

Die Anwendung folgt einem geschichteten Aufbau mit einer klaren Trennung zwischen Benutzeroberfläche, Orchestrierung, agentischer Verarbeitung, Code-Generierung und Rendering. Die zentrale Verarbeitungspipeline ist nach dem IPE-Muster (Intent → Plan → Execute) aufgebaut. Das System wird in einem Container betrieben, der sowohl die Python-Komponenten als auch das Mermaid-CLI-Rendering einschließlich Headless-Chromium bündelt.

Auf einen Blick

• Geschichteter Aufbau: UI → Event-Orchestrierung → IPE-Services → Renderer → Export.
• IPE-Architektur: drei eigenständige Services für Intent-Erkennung, Planung und Ausführung.
• Multi-Agent-LLM-System: Chat-, Diagramm- und Validierungs-Agent mit eigenen LLM-Profilen.
• Deterministische Code-Generierung: Plan-zu-Mermaid-Konverter ohne LLM-Aufruf.
• Validierungs-Schleife: Pre-Validierung, LLM-Korrektur und Template-Fallback vor dem Rendering.
• Sitzungs-State mit Versionierung, Historie und Persistenz.
• Container-Deployment mit Mermaid CLI, Chromium und optionaler Subpath-Unterstützung.

Architekturbeschreibung

Schichten und Komponenten

Die Anwendung ist in mehrere Schichten unterteilt. Die Benutzeroberfläche basiert auf Gradio und enthält Chat, Daten-Panel, Code-Editor, Diagramm-Galerie und Historie. Sämtliche UI-Ereignisse laufen über einen zentralen Event-Handler, der die Sitzung verwaltet, den eingegebenen Datenstrom an den Smart-Data-Processor übergibt und je nach Konfiguration zwischen einem Legacy-Verarbeitungspfad und der IPE-Pipeline routet.

Im Zentrum der IPE-Pipeline stehen drei Services. Der Intent Service analysiert die Nachricht zunächst regelbasiert über Trigger-Wörter und domänenspezifische Muster und greift bei niedriger Konfidenz auf das LLM zurück. Das Ergebnis ist ein strukturierter Intent mit Diagrammtyp, Aktion (Erstellen, Modifizieren, Erweitern, Analysieren), extrahierter Struktur (Lanes, Knoten, Verbindungen) und Konfidenzwert. Der Plan Service transformiert den Intent in einen vollständigen Diagramm-Plan, ergänzt fehlende Lanes und Aktivitäten aus Domänen-Defaults für IT-Support, Personalwesen und Vertrieb und legt die Verbindungen zwischen den Elementen fest. Der Execution Service konvertiert den Plan deterministisch über den Plan-to-Mermaid-Konverter in Code, validiert ihn über den Validation Agent und übergibt ihn an die Renderer-Factory.

Diagramm

flowchart TD
    User([Nutzer]) --> UI[Gradio UI]
    UI --> EH[Event Handler]
    EH --> SM[State Manager]
    EH --> DP[Smart Data Processor]
    EH --> TL[Template Library]

    EH --> IS

    subgraph IPE [IPE-Pipeline]
        direction TB
        IS[Intent Service] --> PS[Plan Service]
        PS --> ES[Execution Service]
        ES --> P2M[Plan-to-Mermaid Konverter]
        P2M --> VA[Validation Agent]
    end

    subgraph LLMS [Multi-Agent-LLM-System]
        direction LR
        CA[Chat-Profil]
        DA[Diagramm-Profil]
        VP[Validierungs-Profil]
    end

    IS -.-> CA
    PS -.-> DA
    VA -.-> VP
    CA --> LLM[Interner LLM-Dienst]
    DA --> LLM
    VP --> LLM

    VA --> RF[Renderer Factory]
    RF --> MR[Mermaid Renderer]
    RF --> DR[draw.io Renderer]
    RF --> GR[Gantt Renderer]
    MR --> MCLI[Mermaid CLI und Chromium]
    DR --> N2G[N2G Library]
    GR --> PG[python-gantt]

    MR --> EM[Export Manager]
    DR --> EM
    GR --> EM
    EM --> Out[SVG, PNG, Code, ZIP]

Workflow

Eine Anfrage durchläuft die Anwendung von oben nach unten. Zunächst nimmt die Gradio-UI die Eingabe entgegen und übergibt sie an den Event-Handler, der die Sitzung über den State Manager verwaltet und die Daten aus dem Daten-Panel über den Smart Data Processor parst und in eine kanonische Form überführt. Anschließend leitet der Event-Handler die Anfrage in die IPE-Pipeline.

Der Intent Service kombiniert eine regelbasierte Schnellanalyse (Trigger-Wörter, Domänen-Hinweise, Verbindungstypen) mit einer optionalen LLM-Stufe und liefert einen Intent mit Konfidenzwert. Der Plan Service entscheidet anhand des Diagrammtyps über die Planungsstrategie (Lane-basiert, hierarchisch, Flowchart-spezifisch oder generisch), füllt fehlende Strukturen mit Domänen-Defaults auf und erzeugt einen vollständigen Plan mit Lanes, Knoten und Verbindungen.

Der Execution Service konvertiert den Plan über den Plan-to-Mermaid-Konverter in Mermaid-Code. Diese Konvertierung erfolgt regelbasiert ohne LLM-Aufruf und liefert reproduzierbare Ergebnisse. Der erzeugte Code durchläuft anschließend den Validation Agent, der zunächst eine Pre-Validierung mit bekannten Fehlermustern durchführt, bei verbleibenden Fehlern eine LLM-basierte Korrektur mit vollständiger Mermaid-Syntax-Referenz anstößt und im Misserfolg auf ein Template zurückfällt. Der validierte Code wird über die Renderer-Factory an den passenden Renderer weitergereicht: Mermaid-Diagramme werden über die Mermaid-CLI mit Headless-Chromium gerendert, draw.io-Diagramme über N2G und Gantt-Diagramme über python-gantt.

Multi-Agent-LLM-System

Die Anwendung verwendet drei eigenständige LLM-Profile mit jeweils eigener Konfiguration. Der Chat Agent betreut die Konversation, erkennt Modifikationsabsichten im Verlauf und steuert die Diagrammtyp-Auswahl; er arbeitet mit einer höheren Temperatur für sprachliche Vielfalt. Der Diagram Agent ist für die Code-Generierung im Legacy-Pfad und für JSON-Zwischenformate zuständig und arbeitet mit niedriger Temperatur für deterministische Ausgaben. Der Validation Agent korrigiert syntaktische Fehler und arbeitet mit Temperatur 0 für maximale Reproduzierbarkeit. Alle drei Profile sprechen denselben LLM-Endpunkt über eine OpenAI-kompatible API an, sind aber in Verhalten und Parameter-Profil klar getrennt.

Nebenläufigkeit, Robustheit und Konfiguration

Der State Manager pflegt sitzungsgebundene Zustände inklusive Diagramm-Versionierung mit Eltern-Beziehungen, sodass Modifikationen nachvollziehbar bleiben. Die Validierungs-Schleife begrenzt die Anzahl der Korrekturversuche und greift bei wiederholtem Misserfolg auf vorbereitete Templates zurück. Die Konfiguration wird zentral aus einer YAML-Datei geladen; sie steuert Server-Parameter (inklusive eines optionalen Subpath für Reverse-Proxy-Deployments), die LLM-Profile pro Agent, die Validierungstiefe, das JSON-Zwischenformat, die Domänen-Defaults und die Renderer-Aktivierung. Die Anwendung lässt sich vollständig containerisiert betreiben; das Container-Image enthält neben den Python-Komponenten auch Node.js, Mermaid CLI und ein Headless-Chromium für das Rendering.

Technologie-Übersicht

• Sprache und Laufzeit: Python 3.10
• UI-Framework: Gradio
• Datenverarbeitung: pandas, python-dateutil
• LLM-Anbindung: OpenAI-kompatible HTTP-API über requests und aiohttp; interner LLM-Dienst
• Rendering: Mermaid CLI (mmdc) mit Headless-Chromium, N2G für draw.io, python-gantt; plotly als Alternative
• Bildverarbeitung: cairosvg (SVG-zu-PNG), Pillow
• Konfiguration: YAML
• Containerisierung: Docker, Docker Compose
• Protokolle: HTTP/HTTPS für die LLM-API, lokale Subprozess-Aufrufe für die Mermaid CLI