Hermes WebUI: eine Browser-Oberfläche für Hermes Agent
Hermes WebUI: um Hermes Agent über das Internet oder Ihr Telefon zu nutzen!
Auf einen Blick
- Was ist das?
- Eine Oberfläche aus einem Python-Standardbibliotheksserver und Vanilla-JS, die die Hermes-Agent-CLI nachbildet, den Agenten prozessintern ausführt und Docker-, Nix- und SSH-Tunnel-Zugänge bietet.
- Für wen ist es gedacht?
- Das Projekt steht unter der MIT-Lizenz. Zur Kompatibilität ist das README eindeutig: WebUI und hermes-agent sollten zusammen aktualisiert oder gepinnt werden, da der Betrieb mit nicht zusammenpassenden Versionen bis zur stabilen Grenzarbeit in #1925 und #2491 ungetestet und ununterstützt ist.
- Darf ich es kommerziell nutzen?
- Ja. MIT ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 2 Tagen.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich Python, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 15. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Eine Browser-Oberfläche für einen Server-Agenten
Hermes WebUI ist eine browserbasierte Oberfläche für Hermes Agent, den das README als autonomen Agenten beschreibt, der auf einem Server lebt und normalerweise über ein Terminal oder Messaging-Apps bedient wird. Die WebUI ist eine leichte, dunkel gestaltete Web-App, deren erklärtes Ziel eine nahezu vollständige Parität mit der CLI ist: Das README sagt, dass man alles, was man in einem Terminal tun kann, auch in der Oberfläche tun kann. Es gibt keinen Build-Schritt, kein Framework und keinen Bundler, nur Python und Vanilla-JS. Die Repository-Beschreibung nennt sie den besten Weg, Hermes Agent vom Web oder vom Telefon aus zu nutzen.
Ein Standardbibliotheks-Server und ein Vanilla-JS-Frontend
Der Server ist ein HTTP-Server aus der Python-Standardbibliothek, kein Web-Framework. Das Backend liegt in api/: server.py ist die Routing-Hülle und Auth-Middleware, routes.py hält alle GET- und POST-Handler mit if/elif-Dispatch ohne Dekorateure. Weitere Module decken Auth, Konfigurationserkennung, Sessions, die SSE-Streaming-Engine, Uploads und Workspace-Dateioperationen ab. Das Frontend in static/ besteht aus Vanilla-JS-Dateien, darunter ui.js für DOM-Helfer und Tool-Karten, workspace.js für Dateioperationen und Git-Erkennung, messages.js für SSE, panels.js für das Control Center und commands.js für die Slash-Command-Autovervollständigung. Der Zustand liegt außerhalb des Repos, standardmäßig unter ~/.hermes/webui/.
Drei Panels, eine Composer-Fußzeile und ein Control Center
Das Layout besteht aus drei Panels: einer linken Seitenleiste für Sessions und Navigation, einem Chat-Bereich in der Mitte und einem rechten Panel für die Workspace-Dateisuche. Modell-, Profil- und Workspace-Steuerung sitzen in der Composer-Fußzeile, die beim Schreiben sichtbar bleibt, und ein kreisförmiger Kontextring zeigt die Token-Nutzung. Alle Einstellungen und Session-Werkzeuge sind im Hermes Control Center gebündelt, das über die Seitenleisten unten gestartet wird. Das Erscheinungsbild teilt sich in zwei Achsen, Theme (system, dark, light) und Skin (ares, slate, poseidon, catppuccin, nous und weitere), umgesetzt mit einem data-skin-Attribut plus CSS-Variablen, wobei der Dunkelmodus über die .dark-Klasse aufgelöst wird.
Startwege: bootstrap, start.sh und ctl.sh
Drei Startwege sind dokumentiert. python3 bootstrap.py erkennt den Hermes-Agenten, versucht den offiziellen Installer, falls er fehlt, findet oder erstellt eine Python-Umgebung mit den WebUI-Abhängigkeiten, startet den Server und wartet auf /health, öffnet den Browser, sofern nicht --no-browser übergeben wird, und führt dann in einen Erststart-Assistenten. ./start.sh ist der Shell-Launcher. Für selbst gehostete VMs oder Homelabs kapselt ctl.sh die Daemon-Lebenszyklus-Befehle (start, status, logs, restart, stop), ohne fuser oder pkill zu benötigen, und schreibt eine PID nach ~/.hermes/webui.pid und Logs nach ~/.hermes/webui.log. Die Stopp-Wege unterscheiden sich je nach Startmethode: bootstrap.py läuft im Vordergrund und stoppt mit Ctrl-C, während ctl.sh stop nur Prozesse verwaltet, die es selbst gestartet hat. Natives Windows wird für den Bootstrap nicht unterstützt; Linux, macOS oder WSL2 sind nötig. Ein von der Community gepflegtes natives Windows-Setup ist separat dokumentiert, mit gemessenen Werten von rund 330 MB nativ gegenüber etwa 1080 MB mit WSL2 und Docker.
Der Chat läuft im WebUI-Prozess
Standardmäßig führt die WebUI den Hermes-Agenten prozessintern aus und liest die HERMES_HOME-Konfiguration direkt, statt für den Chat eine externe Hermes- oder OpenAI-kompatible API-Verbindung zu nutzen. Das README stellt klar, dass HERMES_API_URL nur vom Tasks/cron-Health-Probe gelesen wird und den Chat nicht routet. Für externe Endpunkte gibt es zwei Optionen: einen benutzerdefinierten OpenAI-kompatiblen Provider in den Einstellungen mit einer base_url hinzufügen oder den Chat über einen Hermes-Gateway-API-Server mit HERMES_WEBUI_CHAT_BACKEND=gateway routen, mit dem Hinweis, dass die vollständige Agent-Loop-Delegation noch nicht veröffentlicht ist und in Issue #1925 verfolgt wird. Die Konfiguration wird weitgehend von start.sh automatisch erkannt, das Agent-Verzeichnis, Python-Executable, Zustandsverzeichnis, Standard-Workspace und Port findet, mit HERMES_WEBUI_*-Umgebungsvariablen als Overrides.
Docker, Nix und Fernzugriff
Vorgefertigte Docker-Images für amd64 und arm64 werden bei jedem Release zu GHCR veröffentlicht. Eine Einzelcontainer-Compose-Datei führt den Agenten prozessintern aus und wird als Fünf-Minuten-Weg beschrieben; Zwei- und Drei-Container-Compose-Dateien trennen Agent und Dashboard. Die Compose-Dateien verwenden standardmäßig benannte Volumes, was UID/GID-Probleme konstruktiv vermeidet. Eine dokumentierte Einschränkung (#681) ist, dass im Zwei-Container-Setup vom WebUI ausgelöste Tools im WebUI-Container laufen statt im Agent-Container. Ein Nix-Flake-Paket und ein NixOS-Servicemodul ermöglichen deklarative Installationen. Der Fernzugriff bindet standardmäßig an 127.0.0.1; die dokumentierten Wege sind ein SSH-Tunnel (ssh -N -L 8787:127.0.0.1:8787 user@host) oder die Teilnahme von Server und Telefon an einem Tailscale-Netzwerk mit HERMES_WEBUI_HOST=0.0.0.0 und gesetztem HERMES_WEBUI_PASSWORD.
Versionskopplung und Tests
Das README ist zur Kopplung offen: Die WebUI importiert Hermes-Agent-Module direkt (api/config.py, api/providers.py, api/streaming.py) und liest das Agent-Zustands-Layout direkt, sodass Versionsabweichungen Import- oder Verhaltensdrift verursachen können. Release-Zweige werden gegen das passende Agent-Release getestet, und die genannte Politik ist, beide zusammen zu aktualisieren oder zu pinnen; gepinnte ältere oder neuere Kombinationen sind ungetestet und ununterstützt, bis die stabile Grenzarbeit in #1925 und #2491 eintrifft. Docker-Nutzer werden angewiesen, beide Image-Tags zu pinnen, statt latest mit einem festen Tag zu mischen. Die Testsuite umfasst etwa 11.500 Tests in rund 1.150 Testdateien, läuft in CI auf Python 3.11, 3.12 und 3.13 mit drei parallelen Shards, gegen einen isolierten Server mit separatem Zustandsverzeichnis; das README sagt, dass Produktionsdaten und echte Cron-Jobs nie berührt werden.
Redaktionelles Fazit
Das Projekt steht unter der MIT-Lizenz. Zur Kompatibilität ist das README eindeutig: WebUI und hermes-agent sollten zusammen aktualisiert oder gepinnt werden, da der Betrieb mit nicht zusammenpassenden Versionen bis zur stabilen Grenzarbeit in #1925 und #2491 ungetestet und ununterstützt ist.
Community-Notizen