Der Cron-Scheduler von Hermes Agent ist die dritte große Form, in der Agent-Arbeit aussieht, nach Runde-für-Runde-Chat und /goal-Loops. Im Cron-Modus läuft der Agent unbeaufsichtigt nach Zeitplan, mit Ergebnissen, die an die Messaging-Plattform deiner Wahl gehen — oder über deliver=all auf einmal an alle (#21495).
Dieser Durchgang baut einen konkreten Job — einen Morgenreport — und nutzt ihn, um zu erklären, wie der Scheduler wirklich funktioniert. Dasselbe Muster trägt auch nächtliche Backups, wöchentliche Security-Audits, On-Call-Schichtwechsel oder was du sonst gerade mit einem brüchigen Bash + Cron verdrahten würdest.
Was wir bauen
Jeden Werktag um 8 Uhr morgens:
- 1.Nächtliche Mails lesen (seit gestern 17:00)
- 2.GitHub-Benachrichtigungen ziehen (Issues, PR-Reviews, Mentions)
- 3.Den heutigen Kalender für die ersten 4 Stunden checken
- 4.Alle drei zu einer einzigen Telegram-Nachricht zusammenfassen
Wenn etwas Wichtiges passiert ist, wird die Nachricht ausführlich. Wenn nichts war, ist sie ein Satz: „Ruhige Nacht. Kalender bis 11 Uhr leicht."
Schritt 1: den Job definieren
hermes cron add führt dich durch. Die CLI fragt nach: einem Namen, einem Zeitplan, der Job-Beschreibung (natürliche Sprache) und Zustelltargets.
$ hermes cron add
Name: daily-morning-report
Schedule (cron expression or natural language): 0 8 * * MON-FRI
Description: |
Read overnight email (since 5 PM yesterday).
Pull GitHub notifications via the github skill.
Check today's calendar via google-calendar for the first 4 hours.
Summarize all three into one Telegram message.
Be brief when nothing important happened.
Delivery: telegram
0 8 <em class="italic text-slate-200"> </em> MON-FRI ist Standard-Cron-Syntax: Minute 0, Stunde 8, jeder Tag im Monat, jeder Monat, Montag bis Freitag. Hermes nimmt sowohl Cron-Syntax als auch lockerere natürlich-sprachliche Wendungen wie „every weekday at 8 AM".
Schritt 2: was um 8 Uhr läuft
Am nächsten Werktag um 8 Uhr fährt Hermes eine isolierte Agent-Session hoch, mit:
- •der Job-Beschreibung als erster User-Message
- •den Skills, die der Agent von sich aus aufruft (
email,github,google-calendar) - •einem Delivery-Hook, der die finale Antwort an Telegram weiterreicht
Kein persistenter Kontext, kein User, der tippt. Der Agent liest die Beschreibung, ruft die Skills, entwirft eine Nachricht, schickt sie ab. Typischerweise in 15–30 Sekunden durch.
Die Ausgabe taucht in Telegram als Nachricht von deinem Hermes-Bot auf. Hat der Job länger gebraucht als üblich oder einen Fehler getroffen, kommt im selben Channel auch eine Fehlermeldung.
Schritt 3: deliver=all — Auffächerung auf alle Plattformen
Standardmäßig geht die Auslieferung an eine Plattform — die, die du bei cron add angegeben hast. Wenn der Report überall landen soll, wo dich jemand erreichen kann, setzt du:
hermes cron edit daily-morning-report --deliver all
Jetzt geht die Nachricht gleichzeitig an jede angebundene Messaging-Plattform — Telegram, Discord, Slack, WhatsApp, Signal, LINE, SimpleX, was immer du konfiguriert hast. v0.14.0 hat die Pro-Plattform-Auslieferung speziell für Cron explizit verdrahtet (#21495).
Wann sinnvoll: du willst die Garantie, die Nachricht zu sehen, egal in welcher App du gerade bist.
Wann übertrieben: du checkst morgens eh nur eine Plattform. Dann nimm die.
Schritt 4: sehen, was geplant ist
hermes cron list
Zeigt alles Geplante, nächste Laufzeit, Status des letzten Laufs. v0.14.0 hat namensbasiertes Lookup für Job-Operationen ergänzt (#26231), du kannst Jobs also per Name statt ID referenzieren:
hermes cron logs daily-morning-report --last 5
hermes cron disable daily-morning-report
hermes cron run-now daily-morning-report # sofort starten, außerhalb des Plans
Was passiert, wenn ein Job scheitert
Cron-Jobs laufen in ihrer eigenen Sandbox-Session (dieselben Backends wie das interaktive Hermes — siehe den Sandbox-Backends-Beitrag). Wenn ein Skill-Call scheitert, bekommt der Agent den Fehler und versucht es entweder erneut oder meldet ihn.
Wenn der ganze Job kippt (der Agent selbst läuft auf einen Fehler), benachrichtigt Hermes dich über deine Default-Messaging-Plattform mit dem Fehler und einem Link auf die Logs. Die Session-Durability-Arbeit aus v0.13.0 sorgt dafür, dass ein Gateway-Neustart keine ausstehenden Cron-Auslieferungen verliert — die Dedup-Sicherung läuft über atomares Claim mit Rewind im Fehlerfall (#23401).
Ein paar Jobs, die wirklich laufen
Das sind Muster, die Leute tatsächlich fahren:
Nächtliche Backup-Verifikation. Cron um 3 Uhr: Backup-Snapshots auflisten, prüfen, dass das heutige existiert und nicht leer ist, lautstark scheitern, wenn es fehlt. deliver=all, damit du beim Aufwachen vom Fehler erfährst, falls einer da war.
Wöchentliches Security-Audit. Cron Sonntag 22 Uhr: Dependency-Advisories ziehen, nach bekannten CVEs in deinen Lockfiles scannen, neue Schwachstellen zusammenfassen. Der Supply-Chain-Advisory-Checker aus v0.14.0 (#24220) macht das sauberer als DIY-Skripte.
On-Call-Übergabe. Cron Freitag 17 Uhr: die Pages dieser Woche lesen, einen Absatz Übergabe für die On-Call der nächsten Woche schreiben. Auslieferung an den gemeinsamen Slack-Channel.
Watchers (der v0.14.0-Skill, #21881). Pollt einen RSS-Feed, einen HTTP-JSON-Endpoint oder ein GitHub-Repo auf Änderungen; benachrichtigt nur, wenn sich was geändert hat. Mit Cron kombiniert wird daraus „sag mir Bescheid, wenn X sich ändert" — eine der am stärksten unterschätzten Automatisierungs-Primitiven überhaupt.
Wo die Logs landen
hermes cron logs daily-morning-report
Standardmäßig die letzten 10 Läufe. Jeder zeigt: Timestamp, Dauer, welche Skills aufgerufen wurden, was zugestellt wurde, was schiefging, falls etwas schiefging. Logs liegen unter ~/.hermes/cron/logs/ und rotieren automatisch.
Warum das einem Shell-Skript überlegen ist
Denselben Tagesreport kannst du als Bash-Skript + Cron + curl-zu-Telegram + vielleicht einem kleinen LLM-Call schreiben. Viele Leute haben es so gemacht.
Warum Cron auf einem Agenten interessant ist:
- 1.Die Job-Beschreibung ist die Spec. Kein Code zu pflegen. Du änderst „erste 4 Stunden" zu „erste 6 Stunden" — Beschreibung anpassen, kein Redeploy.
- 2.Skills komponieren sich. „Schau auch in Linear nach neuen Tickets" ist ein Satz in der Beschreibung. Mit einem Shell-Skript ist es ein neuer API-Client.
- 3.Auslieferung ist entkoppelt.
deliver=allheißt, du schreibst nicht 5 verschiedene Webhooks für 5 verschiedene Chat-Apps. Das Gateway spricht alle 22. - 4.Fehler sind debugbar. Wenn ein Job scheitert, sagt dir der Agent in Klartext, was er versucht hat und warum es gescheitert ist. Bash-Skripte geben dir Exit Code 1.
Das macht Agent-Cron nicht zur immer richtigen Antwort — für Jobs, die zu 100 % deterministisch in 30 ms durchlaufen müssen, ist ein Shell-Skript weiter besser. Aber für „mach um diese Uhrzeit etwas Durchdachtes und sag mir Bescheid" ist Cron-auf-Hermes das sauberste Werkzeug im Werkzeugkasten.