Warum wir den Anzeigeserver entkoppelt haben: Der Schritt zu Headless-First KI-Laufzeiten 🖥️
KnotenCore v2.12.0 enthält eine fundamentale Architekturentscheidung: Der Standard-Build hat keinen Anzeigeserver, keinen GPU-Kontext und keine Windowing-Abhängigkeit. WGPU, Winit, Egui, Rodio, cpal und jede physikalische Grafik-Crate sind hinter einem optionalen --features ui Gate gesperrt. Dieser Beitrag erklärt, warum diese Entscheidung für eine KI-Agenten-Laufzeit unvermeidlich war — und wie wir sie umgesetzt haben, ohne eine einzige Zeile bestehender Logik zu brechen.
1. LLM-Agenten brauchen selten einen Bildschirm
Das ursprüngliche KnotenCore enthielt WGPU als Kernabhängigkeit, da die frühe Vision das Rendern von 3D-Primitiven und Partikeleffekten umfasste. Diese Vision war sinnvoll, als der primäre Nutzer ein menschlicher Entwickler war, der ein Fenster beobachtete. Als sich das Projekt jedoch zu einer agentischen Laufzeit entwickelte — bei der LLMs JSON-AST-Programme über einen JSON-RPC-Socket senden — wurde der Anzeigeserver zu reinem Overhead.
Ein KI-Agent, der einen MathDiv-Node kompiliert, einen Sensorwert abfragt oder eine mehrstufige Datenpipeline orchestriert, hat absolut keinen Bedarf an einer Winit-Event-Loop. Dennoch zog selbst ein kopfloser cargo build in der alten Architektur WGPU, cpal und glam als unbedingte Abhängigkeiten — was die Kompilierzeit und das Binärgewicht jedes Server-Deployments erheblich erhöhte.
2. Das --features ui Gate: Zero Overhead als Standard
Die Lösung war, jede physikalische Grafik- und Audio-Crate in eine optionale Feature-Gruppe zu verschieben. In Cargo.toml steuert das ui-Feature jetzt: wgpu, winit, egui, rodio, cpal, image, noise, glam und bytemuck. Der Standard-Feature-Satz ist [] — leer.
Ein Standard-Headless-Build — cargo build --release — kompiliert nun in einem Bruchteil der bisherigen Zeit und erzeugt ein Binary, das ohne Anzeigeserver, ohne GPU-Treiber und ohne X11/Wayland-Socket läuft. Dies ist das ideale Profil für CI-Pipelines, containerisierte Microservices und LLM-Inference-Hosts.
3. Sichere No-Op-Stubs für UI-AST-Nodes
Der schwierigste Teil der Entkopplung war der Umgang mit AST-Nodes, die UI-Operationen referenzieren — DrawRect, PlayTone, DispatchCompute — in einem Headless-Kontext. Ein Absturz bei diesen Nodes wäre inakzeptabel; ein Agentenprogramm sollte graceful degradieren.
Die Lösung war bedingte Kompilierung: Wenn ohne --features ui gebaut wird, werden alle UI-nativen Funktionen durch sichere No-Op-Stubs ersetzt, die sofort mit Ok(KncValue::Null) zurückkehren. Die VM setzt die Ausführung fort, die JSON-RPC-Antwort ist weiterhin gültig, und keine Winit-Event-Loop wird je benötigt. Der Agent stürzt nie ab — er läuft einfach in einem Kontext, in dem Rendering ein No-Op ist.
4. Das Ergebnis: Eine echte Dual-Profil-Engine
KnotenCore wird jetzt als zwei distinct Build-Profile aus einer einzigen Codebasis ausgeliefert. cargo build --release erzeugt eine leichtgewichtige Headless-Laufzeit für Server- und CI-Einsatz. cargo build --release --features ui erzeugt die vollständige interaktive Desktop-Engine. Beide bestehen 244/244 Tests. Beide kompilieren sauber mit -D warnings. Das bedeutet Headless-First in der Praxis: UI ist ein Feature, keine Anforderung.