Hermes Agent¶
Stand: 2026-06-03
Status¶
Hermes ist als produktionsnaher Agent-LXC im VLAN70 ausgerollt und verifiziert.
Wichtig: Der bestehende Lanstyle-Service ist der Governance-/Gateway-Layer. Der eigentliche Nous Research Hermes Agent Core läuft zusätzlich auf demselben LXC und wird vom Gateway intern angesprochen.
| Feld | Wert |
|---|---|
| Hostname | lanstyle-hermes-01 |
| CTID | 260 |
| Plattform | Proxmox LXC, unprivileged |
| OS | Debian 13 |
| VLAN | 70 LS_AI_Services |
| IP | 10.222.70.30/24 |
| Gateway | 10.222.70.1 |
| Storage | local-zfs |
| Ressourcen | 2 vCPU, 2 GiB RAM, 16 GiB Disk |
| Onboot | aktiv |
| Gateway Health | http://10.222.70.30:8088/health |
| Nous Core API | http://127.0.0.1:8642 im LXC, nicht public |
Basishärtung¶
Umgesetzt:
- System aktualisiert per
apt full-upgrade - Zeitzone
Europe/Berlin - Benutzer
maximilianmit SSH-Key-Login - SSH Password Login deaktiviert
sudo,unattended-upgrades,fail2ban- persistentes journald
- Runtime-User
hermesohne Login-Shell - systemd Service
hermes-agent.service
Lanstyle AI Gateway¶
Der Gateway liegt im LXC unter:
| Pfad | Zweck |
|---|---|
/opt/hermes/hermes_agent.py |
Lanstyle Gateway HTTP-Service |
/etc/hermes/hermes.env |
Runtime-Konfiguration und Secrets, 0640 root:hermes |
/var/lib/hermes |
Runtime-State |
/var/log/hermes/audit.jsonl |
Audit-Log ohne Secretwerte |
/etc/systemd/system/hermes-agent.service |
systemd Unit |
Aktive Endpunkte:
GET /health: unauthentifizierter HealthcheckGET /ready: Bereitschaft mit KonfigurationsprüfungenGET /openapi.json: API-Beschreibung ohne SecretwerteGET /voice/health: Voice-Pilot-Health ohne Server-AudiozugriffGET /voice/config: sichere Client-Konfiguration ohne SecretwertePOST /voice/session: auditierte Voice-SessionPOST /voice/message: auditierte Voice-Nachricht, keine Infrastruktur-AusführungPOST /voice/end: auditierte Voice-Session beendenPOST /v1/messages: authentifizierter Operator-EndpunktPOST /teams/messages: authentifizierter Teams-Endpoint-Platzhalter
Der Gateway übernimmt Auth, RBAC-Kontext, Audit, Voice-/Teams-Endpunkte und die harte Grenze: keine Infrastrukturänderungen direkt. Echte Changes müssen weiter über MCP und den Controlled Execution Layer laufen.
Der Gateway ergaenzt vor Core-Antworten kuratierten Kontext aus drei Qdrant Collections: lanstyle_obsidian_memory (Obsidian Vault), lanstyle_docs (MkDocs Wiki) und lanstyle_inventory (NetBox/NPM/Proxmox). Die Retrieval-Ergebnisse werden als Quellen mit confidence an den Core übergeben. Rohdaten und Secretwerte werden nicht ausgegeben.
Bei expliziten Online-/Web-/Wetter-/News-Anfragen nutzt der Gateway zusaetzlich einen kontrollierten read-only Web-Fallback ueber SearXNG (https://search.lanstyle.de/search). Diese Treffer werden dem Core als externe, unbestaetigte Webquellen markiert. Fuer Kundensysteme und Infrastrukturfragen bleiben Obsidian/Qdrant und bestaetigte interne Quellen vorrangig; Websuche wird dort nicht blind als Ersatz fuer internes Wissen genutzt.
Generische Erstellaufgaben wie Website-, Landingpage-, Text- oder Frontend-Strukturen laufen im Creation Mode direkt ueber lanstyle/fast. Dabei werden Obsidian/Qdrant, Websuche und Infrastrukturtools bewusst uebersprungen. Der Kundenscope-Guard bleibt fuer echte Kunden-/Infrastrukturfragen wie UDM, Proxmox, Firewall, VLAN, NetBox, M365 oder Intune aktiv.
Nous Hermes Agent Core¶
Der Nous Research Hermes Agent Core ist separat installiert:
| Pfad | Zweck |
|---|---|
/opt/nous-hermes/source |
Git-Checkout NousResearch/hermes-agent |
/opt/nous-hermes/venv |
Python venv |
/etc/nous-hermes/nous-hermes.env |
Core Runtime-Secrets, 0640 root:hermes-agent |
/var/lib/nous-hermes/config.yaml |
Core-Konfiguration |
/var/lib/nous-hermes/memories/MEMORY.md |
native Core-Memory |
/var/lib/nous-hermes/memories/USER.md |
native User-Memory |
/var/lib/nous-hermes/state.db |
native Sessions/FTS-State |
/etc/systemd/system/nous-hermes-core.service |
systemd Unit |
Status:
nous-hermes-core.serviceaktiv- OpenAI-kompatibler API-Server auf
127.0.0.1:8642 - Modellname intern:
lanstyle-nous-hermes-core - Provider: LiteLLM unter
https://litellm.lanstyle.de/v1 - Default-Modell:
lanstyle/agent-stable - API-Server-Key liegt nur in Runtime-Secret/Vaultwarden-Kontext, nicht in Doku
Tool-Grenzen:
- Core-API-Toolset:
web,skills,todo - keine Terminal-/File-Write-Toolsets fuer API-Server
- keine direkten Proxmox-/DNS-/Firewall-/NetBox-Aktionen
- Gateway routet Voice-Anfragen an den Core und auditiert das Ergebnis
Jarvis / Voice Pilot¶
Der Jarvis-Voice-Assistant wurde als Architekturvorlage analysiert. Das Originalprojekt ist desktoplastig und wird nicht blind auf Hermes betrieben. Der produktive Zielpfad ist jetzt:
Voice Client / Jarvis Device
-> Lanstyle AI Gateway
-> Nous Hermes Agent Core
-> LiteLLM / Memory / Skills / Sessions
-> MCP / Controlled Execution nur fuer geregelte Aktionen
Details:
- Jarvis Voice Assistant
- Voice Assistant Architektur
- Device Onboarding für Voice-Terminals
- Hermes Knowledge und Memory
Voice-Modellstrategie:
- Level 1:
lanstyle/fastfür kurze Dialog-/Statusfragen - Level 2:
lanstyle/agent-stableals Default im Nous Core - Level 3:
lanstyle/architect/große Modelle für komplexe Planungen - Level 4: ChatGPT Login-Fallback nur manuell und auditiert
Multi-User Modell¶
Hermes erfasst pro Request den Audit-Kontext:
user_idtenant_idroletoken_fingerprint- Request-ID
- Payload-Key-Liste, keine Inhalte mit Secretwerten
Das Modell ist für mehrere Benutzer und Rollen vorbereitet. Rollen- und Tool-Scope-Erzwingung bleibt serverseitig über die bestehenden Governance-Komponenten.
OpenWebUI Integration¶
OpenWebUI kann den Gateway im VLAN70 erreichen. Die sichere Integrationsvariante bleibt API-/Tool-basiert ohne Secret-Ausgabe im Chat:
- interner Zielpfad:
http://10.222.70.30:8088 - OpenAPI:
http://10.222.70.30:8088/openapi.json - Auth: Bearer Token aus Vaultwarden/Runtime-Secret, nicht im Chat oder Tooltrace
- normale Benutzer dürfen keine direkten Write- oder Destructive-Aktionen über Hermes erhalten
- Nous Core bleibt hinter dem Gateway und wird nicht direkt als Public-Service freigegeben
Backup und Rollback¶
Backups vor dem Rollout:
- Proxmox Config-/Storage-/Template-Export:
/root/config-backups/hermes-deploy-*aufpve - Pre-Service-Export:
/root/config-backups/hermes-service-*aufpve - Service-/Config-Backups im LXC unter
/root/hermes-service-backup-*und/root/hermes.env.before-*
Rollbackpfad:
hermes-agent.servicestoppen.- Vorherige
/etc/hermes,/opt/hermes,/var/lib/hermes,/var/log/hermesaus LXC-Backup zurückspielen. systemctl daemon-reload && systemctl restart hermes-agent.- Bei LXC-Problemen Proxmox-Config aus
/root/config-backups/hermes-deploy-*prüfen und LXC gestoppt lassen.
Vaultwarden¶
Die Hermes-Secrets wurden nach der Runtime-Rotation in Vaultwarden abgelegt. Secretwerte werden nicht in Doku, Chat oder Logs ausgegeben.
Angelegte Einträge:
Lanstyle / Hermes Service Token / lanstyle-hermes-01Lanstyle / Hermes Service Secret / lanstyle-hermes-01Lanstyle / Hermes OpenWebUI Integration Secret / lanstyle-hermes-01Lanstyle / SSH Public Key / Maximilian Eberhardt
Neu fuer Nous Core vorzuhalten oder nach sicherem Vaultwarden-Unlock zu verifizieren:
Lanstyle / Nous Hermes Core API / lanstyle-hermes-01Lanstyle / Nous Hermes LiteLLM Routing / lanstyle-hermes-01
Offene Punkte¶
- NetBox/DNS/NPM wurden nicht verändert, weil der Service intern im VLAN70 erreichbar ist und kein Public-FQDN für den ersten Betrieb nötig war.
- Teams-Livebetrieb benötigt Azure App Registration, Bot Secret und Tenant Consent.