Automatiser Hermes Agent avec les cron jobs
Configurez un cron Hermes Agent fiable : planning, gateway, livraison, pré-checks, reprise et contrôles de production.
Introduction
Configurer un hermes agent cron devient utile dès qu'une même tâche doit tourner toutes les heures ou tous les matins, et que la faire à la main coûte plus cher que de l'oublier. La gateway lance une session agent fraîche à chaque tick, applique un prompt, livre la sortie vers Telegram, Discord, Slack, le Bot Chat local ou un fichier, et journalise l'exécution. C'est un bon choix pour les veilles, audits récurrents, résumés quotidiens et toute tâche qui supporte un démarrage à froid ; ce n'est en revanche pas le bon choix pour des workflows qui doivent tourner à la seconde près ou garantir un ordre causal strict, car un cron n'est ni une queue ni un orchestrateur durable.
Résumé rapide
| Signal | Contrôle | Critère de réussite |
|---|---|---|
| Tick à l'heure | hermes cron status | next_run_at cohérent, pas d'alerte drift |
| Session démarrée | Ligne started dans ~/.hermes/cron/executions.db | Statut ≠ blocked_config |
| Sortie rédigée | Fichier ~/.hermes/cron/output/<job_id>/<ts>.md | Schéma respecté |
| Livraison OK | ACK Telegram / Discord / Slack / Bot Chat | last_delivery_error=null |
| Job sain | failure_streak à 0 | Pas de nudge de revue |
À retenir vite : un cron fiable se juge à la sortie livrée, pas au statut completed. Si la cible n'a pas reçu le message, le job a échoué même si la gateway l'a marqué vert.
Ce que couvre réellement un cron Hermes et ses prérequis
Un cron Hermes Agent n'est pas une commande shell réécrite, c'est une session agent planifiée orchestrée par la gateway. À chaque tick elle charge les définitions depuis ~/.hermes/cron/jobs.json, identifie les jobs dont next_run_at ≤ maintenant, démarre une nouvelle instance AIAgent, applique le prompt et les éventuelles skills attachées, capture la sortie markdown et la délivre vers la cible configurée. Trois états doivent être validés séparément : l'horaire (le job doit tourner à ce moment-là), l'exécution (la session a produit une sortie) et la livraison (la cible a effectivement reçu le message). Les fusionner dans un seul test est la première cause de faux positifs en production.
La gateway expose un preflight qui bloque un job sans appel LLM si la configuration est incohérente : provider key manquante, skills non prêtes, plateforme de livraison sans credentials. Le job passe alors en blocked_config, une alerte unique est envoyée, et aucun token n'est dépensé. Trois points différenciants par rapport à un cron Unix : les modèles et providers pinnés ou hérités via cron.model (avec drift guard qui fait échouer en silence plutôt que de payer un modèle coûteux par accident) ; les outils limités à la plateforme cron, donc une fonction accessible en chat peut être indisponible pour un cron ; et le file write safety sur jobs.json — passez toujours par hermes cron create/edit, le tool cronjob ou /cron add/edit.
Avant la moindre commande, validez quatre préconditions : Hermes installé avec une requête locale déjà aboutie (Installer Hermes Agent pas à pas sinon), gateway qui supervise ses jobs (sudo hermes gateway install --system pour un VPS, hermes gateway run sinon — voir Déployer Hermes Agent avec Docker sur un VPS), plateforme de livraison testée (hermes send telegram "ping" doit arriver avant), profil et toolsets explicites pour un usage multi-profile. Côté design, formalisez : entrée stable (chemin, format, fréquence de changement), sortie vérifiable (message reçu, fichier présent, webhook acquitté), délai maximal pour calibrer timeout et choisir entre no_agent, script pur ou session agent, et comportement d'échec (retry, alerte d'astreinte, bascule de canal, pause après N échecs). Pour les workflows avec ordre causal strict ou fan-out dynamique, migrez vers une queue ; le comparatif Cron vs queue workers pour agents IA cadre les seuils.
Créer, tester et optimiser le job pas à pas
La création passe par trois surfaces équivalentes : la CLI hermes cron create, le slash /cron add, et le tool cronjob(action="create", …). Le calendrier accepte une durée (30m), du langage naturel (every 2h, every day 7am), une expression cron à cinq champs (0 9 * * *) ou une date ISO pour un one-shot. Le fuseau reste explicite : 0 7 * * * Europe/Paris ou cron.timezone dans config.yaml ; un fuseau implicite produit des dérives silencieuses sur les changements d'heure d'été/hiver.
hermes cron create \
--name 'veille-quotidienne-ia' \
--schedule '0 7 * * * Europe/Paris' \
--deliver telegram \
--reasoning-effort low \
--provider openai --model gpt-4o-mini \
--skill veille-summarizer \
--prompt 'Si le pré-check autorise le réveil, résume le flux en 5 bullet points et envoie sur telegram. Sinon no-op.'
Trois commandes de contrôle donnent l'état réel : hermes cron list --all, hermes cron status et hermes cron runs <nom> --limit 5. Pour tester sans attendre le tick : hermes cron run <nom>. Résultat attendu : le prompt s'exécute, le pré-check décide ou non de réveiller le LLM, et le message arrive sur Telegram. Un blocked_config indique un problème de preflight (clé API, skill manquante, credentials Telegram). Un nudge de revue apparaît après trois échecs consécutifs (failure_nudge_threshold, 0 pour désactiver).
L'optimisation coût passe par trois leviers. Le pré-check déterministe en script (--script ou script=) s'exécute avant l'agent : s'il imprime {"wakeAgent": false}, aucun appel LLM n'est fait ; s'il imprime {"wakeAgent": true, "context": …}, l'agent démarre avec le contexte injecté. Pour une veille RSS qui ne change pas 90 % du temps, ce mécanisme fait chuter le coût à quasi-zéro sur les jours creux. Le mode no_agent livre stdout tel quel sans LLM, parfait pour les checks de garde et exports de base. Le champ context_from injecte la dernière sortie completed d'autres jobs au-dessus du prompt — utile pour des pipelines courts, mais il lit la dernière sortie, il n'attend pas les ticks simultanés.
Les noms dupliqués sont supportés par design mais protégés : hermes cron pause/edit/run/remove accepte un nom (case-insensitive), mais si plusieurs jobs le partagent, la commande refuse et liste les IDs hexadécimaux.
Exemple concret : une veille quotidienne à coût borné
1. Provisionner la cible. Vérifiez que TELEGRAM_HOME_CHANNEL est défini, que hermes send telegram "ping" arrive sur votre canal dédié, et que ce canal n'est pas le DM racine (les topics Telegram isolent les livraisons cron).
2. Déposer le pré-check. Copiez dans ~/.hermes/scripts/feed-changed.sh (rendez-le exécutable) :
#!/usr/bin/env bash
set -euo pipefail
FEED="${FEED_PATH:-/var/lib/veille/feed.xml}"
STATE_FILE="${STATE_FILE:-$HOME/.hermes/cron/state/veille-quotidienne-ia.last_mtime}"
mkdir -p "$(dirname "$STATE_FILE")"
current_mtime=$(stat -c %Y "$FEED" 2>/dev/null || echo 0)
last_mtime=0
[[ -f "$STATE_FILE" ]] && last_mtime=$(cat "$STATE_FILE" || echo "0")
if [[ "$current_mtime" == "$last_mtime" ]]; then
echo '{"wakeAgent": false, "reason": "feed unchanged"}'
exit 0
fi
echo "$current_mtime" > "$STATE_FILE"
echo '{"wakeAgent": true, "reason": "feed changed", "mtime": "'"$current_mtime"'" }'
Testez à la main : {"wakeAgent": false} quand le flux n'a pas bougé, {"wakeAgent": true, …} après un touch.
3. Créer le job. Commande CLI de la section précédente. Vérifiez hermes cron status puis hermes cron list --all pour confirmer échéance et fuseau.
4. Tester avec changement. touch /var/lib/veille/feed.xml, puis hermes cron run veille-quotidienne-ia. Vous devez recevoir un message Telegram en moins d'une minute.
5. Tester sans changement. Relancez hermes cron run sans toucher au flux. Aucun message ne doit arriver ; le ledger doit montrer un statut skipped_no_wake.
6. Redémarrer la gateway. hermes gateway restart. Le lock ~/.hermes/cron/.tick.lock sérialise les ticks ; un run en cours se termine, le suivant repart proprement.
7. Surveiller. hermes cron runs veille-quotidienne-ia --limit 20 quotidiennement, plus une alerte sur failure_streak ≥ 1. Au seuil de nudge (3 par défaut), mettez en pause, corrigez, puis reprenez. Pour diagnostiquer un job qui s'exécute mais ne livre pas, consultez last_delivery_error dans hermes cron runs, testez la cible hors-cron (hermes send), puis basculez sur Hermes Agent ne fonctionne pas : diagnostic.
Bonnes pratiques
Nommez vos jobs de manière unique et descriptive. Un nom dupliqué est supporté mais transforme chaque opération en exercice de désambiguïsation. Préférez veille-rss-ia-quotidienne à veille.
Documentez le fuseau à deux endroits. Dans le calendrier (0 7 * * * Europe/Paris) et dans config.yaml (cron.timezone). Un fuseau implicite dérivre sur les changements d'heure et produit des bugs silencieux au pire moment.
Borner les effets de bord. Un cron qui réécrit un fichier partagé, envoie un mail ou supprime des lignes doit avoir une sortie idempotente. Préfixez les fichiers par YYYY-MM-DD et testez deux exécutions consécutives.
Gardez un test manuel. hermes cron run <nom> doit toujours rester disponible pour rejouer le job sans attendre le tick.
Secrets hors du prompt. Les prompts cron sont scannés à la création pour détecter les patterns d'exfiltration ; un prompt qui contient une clé API sera bloqué. Gérez les clés via hermes auth ou hermes secrets.
N'autorisez pas un cron à reprogrammer d'autres jobs par défaut. allow_agent_scheduling: false (valeur par défaut) bloque les outils de gestion cron dans les sessions lancées par le scheduler — un garde-fou contre les boucles de planification incontrôlées. Activez-le seulement pour un cas d'usage précis et documenté.
Traitez le timeout de livraison. Un job peut être completed côté agent mais échouer côté Telegram si le bot rate un timeout. Calibrez sur votre SLO ; un cron sans ACK de livraison est un cron échoué.
Ne désactivez pas le preflight "pour aller plus vite". Le preflight évite à un job mal configuré de dépenser des tokens.
Une fois vos jobs stables, configurez les modèles de Hermes Agent pour fixer coût, contexte et stratégie de secours — la page /tutorials/configurer-modeles-hermes-agent couvre ce sujet.
Questions fréquentes
Quel est le coût réel d'un cron Hermes Agent ?
Le coût dépend de la fréquence du tick, du pré-check wakeAgent (qui peut annuler l'appel LLM à coût zéro) et du modèle choisi par job ou hérité. Pour une veille quotidienne avec pré-check, vous payez essentiellement les jours où le flux change ; les autres jours, le coût est nul. Pour un audit toutes les 5 minutes sans pré-check, c'est un agent complet 288 fois par jour — c'est là que wakeAgent ou no_agent devient obligatoire.
Peut-on chaîner plusieurs crons entre eux ?
Oui, via context_from. Vous listez les noms ou IDs des jobs amont et leur dernière sortie completed est injectée au-dessus du prompt. Limites : context_from lit la dernière sortie, il n'attend pas les ticks simultanés et il n'y a pas d'ordre causal strict entre jobs parallèles. Pour ces garanties, migrez vers une queue.
Que faire si un cron s'exécute mais ne livre jamais le message ?
Trois causes fréquentes. La plateforme de livraison a perdu ses credentials : testez hermes send hors-cron. Le timeout de livraison Bot Chat est trop court : ajustez-le ou basculez sur bot-chat:<profile> robuste. Le prompt a renvoyé une sortie vide : vérifiez hermes cron runs <job>. Pour aller plus loin, Hermes Agent ne fonctionne pas : diagnostic couvre les incidents plus larges, et Timeouts et retries pour agents IA cadre la politique de retry.
Comment tester un cron sans attendre le tick ?
hermes cron run <nom> déclenche le job sur le prochain tick de la gateway. Pour itérer vite, gardez un script de pré-check testable à la main (bash feed-changed.sh) et un prompt minimal. Une fois le run nominal validé, programmez le calendrier final.
Quand migrer d'un cron vers une queue ?
Quand vous avez besoin d'ordonnancement causal strict, de rejeu après incident, de fan-out dynamique ou de SLA plus serré que la minute. Au-delà de quelques centaines de jobs ou de workflows multi-états, une queue devient rentable. Le comparatif Cron vs queue workers pour agents IA cadre les seuils.
Articles liés
Pour la vision d'ensemble de l'agent et de son architecture, commencez par Hermes Agent : guide pour builders IA, le pilier du cluster. Pour mettre en place un runtime prêt à planifier, Installer Hermes Agent pas à pas couvre la première exécution locale, et Déployer Hermes Agent avec Docker sur un VPS explique comment garantir une gateway durable au boot. Pour arbitrer entre cron et queue, Cron vs queue workers pour agents IA cadre les seuils.
Restez informé sur les agents IA
Nouveaux tutoriels, comparatifs et guides pratiques directement dans votre boîte mail.