Cron-scheduler Hermes Agenta to trzecia główna forma pracy agenta, po czacie tura-po-turze i pętlach /goal. Z cronem agent chodzi po harmonogramie, bez nadzoru, a wyniki idą na tę platformę komunikacyjną, którą wybrałeś — albo na wszystkie naraz przez deliver=all (#21495).
Ten wpis przechodzi przez budowę jednego konkretnego joba — codziennego porannego raportu — i wykorzystuje go, żeby wyjaśnić, jak scheduler faktycznie działa. Ten sam wzór ogarnia nocne backupy, tygodniowe audyty bezpieczeństwa, ping-i ze zmiany on-call albo cokolwiek innego, co inaczej spinałbyś kruchym bash + cron.
Co budujemy
Każdy dzień roboczy o 8 rano:
- 1.Czytaj nocną pocztę (od wczoraj 17:00)
- 2.Pobierz notyfikacje z GitHuba (issues, review PR-ów, mentions)
- 3.Sprawdź dzisiejszy kalendarz na pierwsze 4 godziny
- 4.Streść wszystkie trzy w jednej wiadomości na Telegram
Jeśli wydarzyło się coś ważnego, wiadomość jest szczegółowa. Jeśli nic się nie wydarzyło, wiadomość to jedno zdanie: „Spokojna noc. Kalendarz lekki do 11."
Krok 1: zdefiniuj joba
hermes cron add przeprowadza cię przez to. CLI pyta o: nazwę, harmonogram, opis joba (język naturalny) i targety dostawy.
$ 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 to standardowa składnia crona: minuta 0, godzina 8, każdy dzień miesiąca, każdy miesiąc, poniedziałek do piątek. Hermes łyka i składnię crona, i luźniejsze sformułowania w języku naturalnym typu „every weekday at 8 AM".
Krok 2: co się odpala o 8 rano
Następnego dnia roboczego o 8 rano Hermes podnosi izolowaną sesję agenta z:
- •opisem joba jako pierwszą wiadomością użytkownika
- •skillami, które agent zdecyduje się zawołać (
email,github,google-calendar) - •delivery-hookiem, który przepuszcza finalną odpowiedź na Telegram
Brak trwałego kontekstu, brak piszącego użytkownika. Agent czyta opis, woła skille, składa wiadomość, wysyła. Zwykle 15–30 sekund i koniec.
Output pojawia się na Telegramie jako wiadomość od twojego bota Hermes. Jeśli job trwał dłużej niż zwykle albo wpadł w błąd, na ten sam kanał dostaniesz też wiadomość o błędzie.
Krok 3: deliver=all — rozlać na każdą platformę
Domyślnie dostawa idzie do jednej platformy — tej, którą podałeś przy cron add. Jeśli chcesz, żeby raport wylądował wszędzie, gdzie cię można dosięgnąć, ustaw:
hermes cron edit daily-morning-report --deliver all
Teraz wiadomość idzie naraz do każdej podpiętej platformy komunikacyjnej — twojego Telegrama, Discorda, Slacka, WhatsAppa, Signala, LINE, SimpleX, czegokolwiek skonfigurowałeś. v0.14.0 podpiął jawnie per-platformową dostawę dla crona (#21495).
Kiedy to przydatne: chcesz mieć gwarancję, że zobaczysz wiadomość niezależnie od tego, w jakiej aplikacji akurat siedzisz.
Kiedy to jest przesada: rano sprawdzasz tylko jedną platformę. Wtedy bierz tę jedną.
Krok 4: zobacz, co jest zaplanowane
hermes cron list
Pokazuje wszystko, co jest zaplanowane, najbliższy czas uruchomienia, status ostatniego biegu. v0.14.0 dorzucił lookup po nazwie dla operacji na jobach (#26231), więc możesz odwoływać się do jobów po nazwie, a nie po ID:
hermes cron logs daily-morning-report --last 5
hermes cron disable daily-morning-report
hermes cron run-now daily-morning-report # odpal natychmiast, poza harmonogramem
Co się dzieje, kiedy job pada
Joby crona chodzą w swoich własnych sesjach sandbox (te same backendy co interaktywny Hermes — patrz wpis o sandbox-backendach). Jeśli call skilla padnie, agent dostaje błąd i albo retryuje, albo raportuje.
Jeśli pada cały job (sam agent kończy z błędem), Hermes notyfikuje cię na twojej domyślnej platformie komunikacyjnej błędem i linkiem do logów. Robota nad trwałością sesji z v0.13.0 oznacza, że restart gateway-a nie gubi czekających dostaw crona — deduplikacja idzie przez atomowe claimowanie z rewindem przy porażce (#23401).
Kilka realnych jobów, które się przydają
Wzorce, które ludzie faktycznie odpalają:
Weryfikacja nocnego backupu. Cron o 3 nad ranem: wylistuj snapshoty backupu, sprawdź, że dzisiejszy istnieje i nie jest pusty, krzycz głośno, jeśli go brakuje. deliver=all, żebyś po przebudzeniu wiedział o porażce.
Tygodniowy audyt bezpieczeństwa. Cron niedzielę 22:00: pobierz dependency advisories, przeskanuj znane CVE w lockfile'ach, streść nowe podatności. Supply-chain advisory checker z v0.14.0 (#24220) czyni tę robotę czystszą niż DIY-skrypty.
Przekazanie zmiany on-call. Cron piątek 17:00: przeczytaj pejdże z tego tygodnia, napisz akapit przekazania zmiany dla on-calla z przyszłego tygodnia. Dostawa na dzielony kanał Slacka.
Watchers (skill z v0.14.0, #21881). Pollowanie RSS-a, endpointu HTTP JSON albo repo na GitHubie pod kątem zmian; notyfikacja tylko, kiedy coś się zmieniło. Skomponowane z cronem zamienia się to w „powiadom mnie, kiedy X się zmieni", co jest jedną z najbardziej niedoużywanych prymitywów automatyzacji.
Gdzie lecą logi
hermes cron logs daily-morning-report
Domyślnie ostatnie 10 biegów. Każdy pokazuje: timestamp, czas trwania, jakie skille zostały zawołane, co zostało dostarczone, co padło, jeśli coś padło. Logi siedzą pod ~/.hermes/cron/logs/ i rotują się same.
Dlaczego to bije pisanie shellowego skryptu
Ten sam dzienny raport możesz napisać jako bash + cron + curl-na-Telegram + może maleńki call LLM-a. Wielu tak zrobiło.
Powód, dla którego cron-na-agencie jest ciekawy:
- 1.Opis joba jest specyfikacją. Brak kodu do utrzymania. Zmień „pierwsze 4 godziny" na „pierwsze 6 godzin" — edytujesz opis, bez redeployu.
- 2.Skille się komponują. Dodanie „sprawdź też Lineara pod kątem nowych ticketów" to jedno zdanie w opisie. W shellowym skrypcie to nowy klient API.
- 3.Dostawa jest rozprzęgnięta.
deliver=alloznacza, że nie piszesz 5 różnych webhooków dla 5 różnych appek czatowych. Gateway już mówi w 22 platformach. - 4.Błędy da się debugować. Kiedy job pada, agent mówi ci, co próbował i czemu padło, po ludzku. Bashowe skrypty dają ci exit code 1.
To nie znaczy, że agent-cron jest zawsze właściwą odpowiedzią — dla jobów, które muszą być deterministyczne w 100% i biec w 30 ms, shellowy skrypt nadal jest lepszy. Ale do „o tej godzinie zrób coś z głową i mi o tym powiedz" — cron-na-Hermesie to najczystsze narzędzie z całej skrzynki.