Bevor du HYPDB.ONE mit Discord verbinden kannst, benötigst du einen Discord Bot. Erstelle ihn im Discord Developer Portal.
Nach der Erstellung musst du den Bot in deinen Discord-Server einladen.
Jetzt verbindest du HYPDB.ONE mit deinem Discord Bot. Öffne die Konfigurationsdatei deines HYPDB.ONE-Systems.
Hermes liest die Discord-Zugangsdaten aus Umgebungsvariablen. Diese drei Namen sind im Quelltext des Gateways belegt — alles andere ist erfunden:
discord:-YAML-Block mit den Schlüsseln enabled, guild_id, channel_id oder einer commands:-Liste. Diese Struktur wurde hier frei erfunden und ist nicht lauffähig. Der Pfad lautet .env-Variable → Gateway.
Statt Variablen von Hand zu tippen, führt der Gateway einen Setup-Dialog:
Alternativ schreibt hermes config set einzelne Werte in die config.yaml. Für Ein- und Ausschalten einer Plattform existiert der Schlüssel platforms.discord.enabled:
config.yaml, in HTML, in Git oder in einer Skill-Datei. Nur die .env ist für Geheimnisse vorgesehen.
Nach der Konfiguration startest du die Discord-Bridge. HYPDB.ONE verbindet sich automatisch mit deinem Discord-Server.
hermes discord connect und hermes status | grep discord existieren nicht. Die CLI kennt nur hermes gateway … mit den Unterbefehlen run, start, stop, restart, status, install, list, setup, migrate. Eine Ausgabe wie discord: connected (guild: …) gibt es nicht.
Solange dort not configured steht, ist Discord nicht verbunden. Der Bot erscheint dann auch nicht als online im Server. Diese Anleitung beschreibt den Weg zur Verbindung — sie behauptet nicht, dass auf diesem Host bereits eine Discord-Verbindung besteht.
Sobald die Bridge aktiv ist, kannst du deine KI-Agenten direkt aus Discord steuern. Hier sind die wichtigsten Befehle:
Die folgenden Befehle stehen wörtlich in der Registry des Agenten (hermes_cli/commands.py). Sie sind gateway-fähig und stehen damit auch in Discord zur Verfügung. Die Liste umfasst 102 Befehle — hier die für den Betrieb relevanten:
| Befehl | Wirkung laut Registry |
|---|---|
/status | Sitzung, Modell, Token und Kontextfenster |
/agents | Aktive Agenten und laufende Aufgaben — Alias /tasks |
/queue — Alias /q | Prompt für den nächsten Turn einreihen oder Warteschlange verwalten (list, edit N, rm N, move A B, clear) |
/help | Verfügbare Befehle auflisten; /help skills zeigt Skill-Befehle |
/whoami | Deine Slash-Command-Berechtigung: Admin oder User |
/cron | Geplante Aufgaben verwalten |
/model | Modell wechseln, mit --global dauerhaft |
/profile | Aktives Profil und dessen Home-Verzeichnis |
/platform | Eine fehlerhafte Gateway-Plattform pausieren, fortsetzen oder auflisten |
/sethome | Diesen Chat als Home-Channel setzen |
/sessions | Vorherige Sitzungen durchsuchen und fortsetzen |
/new | Neue Sitzung mit frischer ID und leerer Historie |
/command | Befehl direkt an den Gateway weiterreichen |
/kanban | Kanban-Board verwalten |
/skill | Skill ausführen — mit Autocomplete über den Skill-Katalog |
/status zeigt keinen „Systemstatus aller Agenten", sondern Sitzungs-, Modell-, Token- und Kontextdaten. /tasks ist lediglich ein Alias von /agents, kein eigener Befehl. Eine Antwort wie „Worker: 3 aktiv · Cronjobs: 12 geplant · Memory: 78 % frei" mit diesen Zahlen wurde hier frei konstruiert und ist keine echte Hermes-Ausgabe.
Konkrete Zahlen zu Agenten, Cronjobs oder Speicher stehen dir an dieser Stelle nicht zur Verfügung. Wenn du belastbare Werte brauchst, frag den Agenten ausdrücklich — er misst sie dann über die echten Endpunkte und sagt dir, woher.
Richte Benachrichtigungen ein, damit HYPDB.ONE dich automatisch über wichtige Ereignisse informiert.
Hermes kennt keinen Konfigurationsblock discord_notifications: und keinen Block agent_output:. Beide waren in einer früheren Fassung dieser Anleitung frei erfunden. Zustellungen werden nicht per Event-Liste gesteuert, sondern über drei belegte Mechanismen:
| Mechanismus | So wird er gesetzt |
|---|---|
| Home-Channel | DISCORD_HOME_CHANNEL in der .env — oder im Chat /sethome. Ohne explizites Ziel nimmt Hermes diesen Kanal für Zustellungen ohne Channel-ID. |
| Gateway-Neustart-Hinweis | YAML-Schlüssel platforms.discord.gateway_restart_notification (Standard true). Abschaltbar, wenn der Ping als Rauschen stört. |
| Thread-Verhalten | DISCORD_REPLY_TO_MODE: off nie threaden · first nur erster Block · all jeder Block. Standard ist first. |
| Typing-Anzeige | YAML-Schlüssel platforms.discord.typing_indicator (Standard true). |
reply_to_mode: all erzeugt bei langen Antworten viele einzelne Discord-Nachrichten. Für strukturierte Langtexte ist first die ruhigere Wahl — der Rest landet in einem Thread.
Häufige Probleme und ihre Lösungen:
/whoami — sie entscheidet, welche Befehle dir überhaupt offenstehenhermes discord sync-commands existiert nicht. Es gibt kein solches Kommando und keine manuelle Sync-Funktion. Die Slash-Commands registriert der Gateway beim Start selbst.
Discord kann einen Bot-Token jederzeit zurücksetzen (Reset Token im Developer-Portal). Danach ist der alte Token ungültig und der Bot fällt offline. Der Austausch läuft ausschliesslich über die .env — der alte Token bleibt im Portal zunächst als „View old token" sichtbar, ist aber bereits tot. Nie beide Tokens parallel hinterlegen:
Drei Messstellen in dieser Reihenfolge: hermes gateway status (läuft der Gateway überhaupt?), hermes status --full → Abschnitt „Messaging Platforms" (kennt Hermes den Token?), und zuletzt der Discord-Server selbst (steht der Bot dort auf online?). Steht dort not configured, fehlt die .env-Zeile oder der Gateway hat sie beim Start nicht gelesen.
Globale Commands rollt Discord gemäss eigener Dokumentation mit Verzögerung von bis zu einer Stunde aus. Nach hermes gateway start deshalb nicht sofort alle Befehle erwarten — /whoami ist die schnellste Kontrollfrage, weil sie nur die eigene Berechtigungsstufe zurückgibt.
Der Gateway registriert Befehle beim Start selbst und überspringt Namenskollisionen (Konflikt mit einer Subcommand-Gruppe). Zusätzlich greift ab einer bestimmten Anzahl ein Limit: weitergehende Befehle werden nicht mehr registriert und im Gateway-Log vermerkt. Die genaue Zahl ist auf diesem Host nicht dokumentiert — wer viele Befehle erwartet, prüft das Gateway-Log statt die Discord-Oberfläche.
Geregelt über DISCORD_REPLY_TO_MODE: off nie threaden, first nur der erste Block als Antwort (Standard), all jeder Block einzeln. Für Status-Reports und Protokolle ist first die ruhigere Wahl — der Rest landet in einem Thread unter der ersten Nachricht.
Ein Bot-User kann in beliebig vielen Servern eingeladen werden; der Gateway bedient sie über dieselbe Token-Zeile. Getrennte Zustellziele je Server brauchen die Channel-ID: DISCORD_HOME_CHANNEL gilt genau für einen Kanal. Mehrere Zielkanäle gleichzeitig adressiert die CLI — die Web-Oberfläche kennt keinen Kanal-Endpoint (gemessen: /api/channels = 404).
Diese Anleitung beschreibt den Gateway-Weg im Detail. HYPDB.ONE liefert denselben Agenten vorkonfiguriert: Discord ist eine der Messaging-Plattformen, die das Produkt aus der Box heraus unterstützt — zusammen mit Telegram und der Web-Oberfläche. Wer nicht selbst einen Bot einrichten will, nimmt den Weg über die Tarife:
Nach erfolgreicher Integration kannst du deine Discord-Steuerung erweitern:
Abschnitt 4 nennt eine gemessene Gateway-Ausgabe von einem früheren Tag. Der Gateway-Zustand dieses Hosts lässt sich aus dem Browser nicht abfragen — es gibt dafür keine HTTP-Route. Die Befehle bleiben die Prüfstelle, und die Tabelle unten fragt ab, was tatsächlich messbar ist:
| Route | Erwartung | Gemessen |
|---|---|---|
| Routen werden geprüft … | ||
/api/discord, /api/telegram,
/api/channels und /api/platforms antworten mit 404 — gemessen,
nicht vermutet. Die Plattform-Verbindung von Hermes hat keine Web-Schnittstelle; sie
läuft ausschliesslich über hermes gateway status und hermes status --full
in der Shell. Eine Anzeige „Discord: verbunden" auf einer Webseite wäre daher eine Erfindung.
Steht unten bei den Routen etwas anderes als 404, ist das eine Korrektur dieser Zeilen.