Voice Assistant Architektur

Stand: 2026-05-29

Kurzfazit

Das Projekt Julian-Ivanov/jarvis-voice-assistant ist als Inspiration brauchbar, aber nicht direkt als produktiver Serverdienst geeignet. Es ist ein lokaler Windows/Desktop-Assistent mit sichtbarem Chrome, Web Speech API, Playwright-Browserfenster, Screen Capture, PowerShell-Window-Management, Anthropic-Direktzugriff und ElevenLabs-Direktzugriff.

Für Lanstyle wird Jarvis deshalb nicht blind auf Hermes betrieben. Der sichere Zielpfad nutzt den echten Nous Hermes Agent Core hinter dem bestehenden Lanstyle Gateway:

• Lanstyle AI Gateway im VLAN70 als Auth-/RBAC-/Audit-Schicht
• Nous Hermes Agent Core als lernender Agent mit Memory, Skills und Sessions
• ein kleines Voice-Terminal oder Browser-Client als Audio-/Mikrofon-Endpunkt
• LiteLLM statt direkter Anthropic-Nutzung
• Controlled Execution statt freier Aktionen
• Vaultwarden als Source of Truth fuer Secrets

Repo Analyse

Quelle: https://github.com/Julian-Ivanov/jarvis-voice-assistant

Bereich	Befund	Bewertung
Backend	server.py, FastAPI/WebSocket	grundsätzlich serverfähig, aber stark an lokale Config und externe Direkt-APIs gebunden
Frontend	Chrome Web Speech API	muss im Browser/Client laufen, nicht im LXC
TTS	ElevenLabs API direkt	nicht direkt übernehmen; über Vaultwarden und Policy kapseln
LLM	Anthropic SDK direkt	nicht übernehmen; Lanstyle nutzt LiteLLM
Browser Automation	Playwright headless=False	Desktop-/Kiosk-Feature, nicht für Hermes-Server geeignet
Screen Capture	PIL.ImageGrab	benötigt Desktop-Session; im Headless-LXC ungeeignet
Wakeword/Clap	sounddevice, numpy	braucht lokales Mikrofon und Audio-Hardware
Windows	PowerShell Launch-/Window-Snapping	Windows-spezifisch, nicht serverfähig
Lizenz	keine Lizenzdatei gefunden	Weiterverwendung als Codebasis unklar; nur Analyse/Architektur ableiten

Zielarchitektur

flowchart LR
  Device["Voice Terminal / Browser Client"]
  Hermes["Lanstyle AI Gateway\n10.222.70.30:8088"]
  Core["Nous Hermes Core\n127.0.0.1:8642"]
  Memory["Memory / Skills / Sessions\nstate.db + MEMORY.md"]
  LiteLLM["LiteLLM\nhttps://litellm.lanstyle.de"]
  MCP["Remote MCP / Tools\nhttps://mcphub.lanstyle.de"]
  CE["Controlled Execution Layer"]
  Vault["Vaultwarden"]
  Audit["Audit / RBAC / Policy"]

  Device -->|"HTTPS/WebSocket später\nText/Audio Events"| Hermes
  Hermes --> Audit
  Hermes --> Core
  Core --> Memory
  Core --> LiteLLM
  Hermes --> MCP
  MCP --> CE
  Hermes --> Vault

Variantenbewertung

Variante A: kleines Gerät als Voice-Terminal

Empfohlen für Pilot und späteren Produktivbetrieb.

• Aufwand: mittel
• Stabilität: hoch, wenn Browser/Kiosk oder Python-Client schlank bleibt
• Datenschutz: gut, Audio bleibt lokal bis zur expliziten Übertragung
• Latenz: gut im LAN/VLAN
• Wartbarkeit: gut mit goldenem Image und Provisioning
• Multi-User: gut über Device-/User-Token
• Kosten: mittel, typischerweise ca. 150-300 EUR plus Audiozubehör bei N100

Variante B: browserbasierter Voice-Client

Guter erster UX-Pilot.

• Aufwand: niedrig bis mittel
• Stabilität: abhängig von Browser-Audio-/Autoplay-Regeln
• Datenschutz: gut, weil Mikrofonzugriff im Browser sichtbar ist
• Wartbarkeit: gut
• Einschränkung: Wakeword nur begrenzt und browserabhängig
• Kosten: niedrig, wenn vorhandenes Gerät/Tablet genutzt wird

Variante C: Headless Audio Device

Langfristig interessant, aber erst nach erfolgreichem Browser-/Terminal-Pilot.

• Aufwand: hoch
• Stabilität: abhängig von ALSA/Pulse/PipeWire, Wakeword und Audio-Hardware
• Datenschutz: am sensibelsten
• Wartbarkeit: anspruchsvoller
• Kosten: niedrig bis mittel, aber höhere Betriebs-/Debug-Aufwände

Empfehlung

Start mit Variante A als kontrolliertes Voice-Terminal auf Intel N100 Mini-PC oder Raspberry Pi 5. Für den ersten Software-Pilot reicht Variante B mit Browser-Client gegen Hermes.

Der Lanstyle AI Gateway bleibt das Backend fuer Clients. Der Nous Hermes Core verarbeitet Dialog, Memory und Skills. Audioaufnahme, Web Speech API, Wakeword und Lautsprecher laufen auf dem Gerät oder im Browser.

Governance

Jarvis/Hermes Voice darf keine freien Infrastrukturaktionen ausführen.

Erlaubt:

• Statusabfragen
• Operator Summary
• read-only MCP Tools
• Preflight/Approval Preview
• Controlled-Execution-Pläne

Nicht erlaubt:

• freier Shell-Zugriff
• direkte Proxmox-/DNS-/Firewall-/NetBox-Writes
• Desktop-Screen-Capture auf Hermes
• direkte Secret-Ausgabe
• direkte Anthropic-/ElevenLabs-Keys im Code

Nous Hermes Core Status

Auf lanstyle-hermes-01 läuft zusätzlich zum Gateway der Nous Research Hermes Agent Core:

• Installation: /opt/nous-hermes/source
• Runtime: /var/lib/nous-hermes
• Service: nous-hermes-core.service
• interner API-Server: 127.0.0.1:8642
• Memory: /var/lib/nous-hermes/memories/MEMORY.md und USER.md
• Session Search: SQLite/FTS in /var/lib/nous-hermes/state.db
• Provider: LiteLLM mit lanstyle/agent-stable

Der API-Server ist nicht public exposed. Clients sprechen weiterhin mit dem Lanstyle Gateway.

Pilotstatus

Auf lanstyle-hermes-01 ist ein backend-only Voice-Pilot aktiv:

• GET /voice/health
• POST /voice/session
• POST /voice/message

Der Pilot nutzt noch kein echtes Audio und keine produktive TTS/STT-Strecke. Er validiert API, Auth, Audit, Multi-User-Kontext, Governance-Grenzen und Gateway-zu-Nous-Core-Routing.

Modellstrategie Voice

Ziel ist gefühlte Geschwindigkeit vor maximaler Modellqualität. Hermes routet Voice-Anfragen in Stufen:

Level	Zweck	Modell/Route	Bemerkung
1	einfache Gespräche, kurze Statusfragen	lanstyle/fast	bevorzugt für Antwortbeginn < 1s
2	normale Assistentenlogik	Nous Hermes Core via lanstyle/agent-stable	Default
3	komplexe Infrastrukturplanung/Governance	lanstyle/architect oder großes GB10-Modell	nur bei erkennbarer Komplexität
4	Spezialfall außerhalb interner Modellfähigkeit	ChatGPT Login-Fallback	manuelle Eskalation, kein heimliches Routing

Hermes muss bei Eskalation dokumentieren:

• warum eskaliert wurde
• welches Modell genutzt wurde
• welche Daten übertragen wurden
• ob Benutzerbestätigung erforderlich war
• Audit-Referenz

STT/TTS/Wakeword Empfehlung

Baustein	Empfehlung Pilot	Empfehlung später	Einschätzung
Wakeword	Push-to-talk	openWakeWord lokal auf Device	Wakeword nicht auf Hermes
STT	Browser Web Speech API	faster-whisper small/int8 oder whisper.cpp small lokal/Device	Deutsch brauchbar, geringe Kosten
TTS	Browser speechSynthesis	Piper de_DE lokal oder ElevenLabs optional	Browser-TTS ist schnell, ElevenLabs natürlicher aber kosten-/secretpflichtig
Transport	HTTP JSON	WebSocket/Sentence Streaming	Streaming später für Latenz

Latenzoptimierung

Priorität:

1. Antwortbeginn
2. Sprachqualität
3. Modellqualität

Geplante Optimierungen:

• Push-to-talk statt Wakeword im ersten Pilot
• kurze Level-1-Antworten über lanstyle/fast
• sentence-level Streaming für TTS
• WebSocket Voice Sessions
• lokale STT auf Gerät, wenn Browser-STT nicht stabil genug ist
• keine Screen-/Browser-Automation in der schnellen Sprachschleife

Zielwert: Antwortbeginn unter 1 Sekunde für einfache Status-/Dialogfragen.