Des tâches cron qui se souviennent : mémoire et continuité pour vos agents planifiés

Votre tâche de briefing de 9 h vous a redit les trois mêmes éléments ce matin — comme hier, et avant-hier. Pas parce qu’elle est bête : chaque exécution partait de zéro, sans savoir ce qu’elle vous avait déjà dit, si bien qu’une tâche qui surveillait une page et rapportait les changements continuait de re-rapporter tout l’historique. Les tâches planifiées étaient des poissons rouges. v0.21.0 corrige le volet mémoire de cette histoire : les agents cron chargent et mettent à jour une mémoire persistante comme tous les autres agents, un nouveau flag --continuity injecte la propre sortie précédente de chaque exécution dans l’exécution suivante, chaque tâche obtient un bloc-notes durable que vous pouvez lire et écrire depuis le CLI, et les tâches en monitor mode peuvent sauter entièrement le LLM quand rien n’a changé.
Ce qui change, en trois points
1. La mémoire est chargée, pas ignorée. Les agents cron lisent désormais MEMORY.md / USER.md dans le system prompt et peuvent mettre à jour la mémoire persistante entre les exécutions — le même mécanisme qu’utilisent les agents interactifs. Une tâche qui apprend quelque chose un jour le sait réellement le lendemain.
2. --continuity fait avancer la dernière exécution. Le planificateur injecte la sortie précédente de la tâche dans le prompt de la nouvelle exécution : « utilisez-la pour la continuité — évitez de répéter ce qui a déjà été rapporté ». C’est exactement ce qu’il faut à un monitor pour dédupliquer. Ajoutez-le à la création ou activez-le plus tard :
hermes cron create --schedule "0 9 * * *" \
--prompt "Summarize new activity on the status page" \
--continuity
hermes cron edit <job_id> --continuity # ou --no-continuity pour la désactiver
La première exécution est inchangée ; à partir de la deuxième, la tâche se réveille en sachant ce qu’elle a dit la dernière fois. Le texte d’aide résume les cas d’usage : éclaireurs, monitors, digestifs incrémentaux.
3. Un bloc-notes que la tâche — et vous — pouvez lire et écrire. Chaque tâche dispose d’un scratchpad clé-valeur durable :
hermes cron notepad <job_id> list
hermes cron notepad <job_id> set last_sync "2026-09-01"
hermes cron notepad <job_id> get last_sync
hermes cron notepad <job_id> delete last_sync
Le contenu du bloc-notes est injecté dans le prompt de la tâche à chaque exécution, si bien que l’agent lui-même peut mettre à jour son propre état entre les exécutions — un checkpoint de ce qu’il a déjà traité, sans que la sémantique du système de mémoire s’en mêle.
Monitor mode : pas de changement, pas de facture LLM
La pièce complémentaire, c’est le raffinement du monitor mode : les tâches qui surveillent un script ou une URL à la recherche de changements utilisent une détection de changement supprimée par hash, et quand rien n’a changé, la tâche peut sauter entièrement le LLM — aucun token brûlé pour rapporter « toujours pareil ». C’est la différence entre un chien de garde qui coûte quelques centimes par vérification et un qui ne coûte rien tant que quelque chose ne bouge pas vraiment.
Améliorations de soutien autour des bords
La fenêtre a aussi livré des voisins pratiques : validation de config avant dispatch (une tâche cassée échoue avant de se déclencher, pas pendant), signatures d’échec acquittées (acquittez un incident une fois et la tâche cesse de vous re-contacter à son sujet), fixation de l’effort de raisonnement par tâche (--reasoning-effort none|low|medium|… remplace le réglage global pour cette tâche seulement), et « Trigger now » s’exécute immédiatement au lieu de faire la queue. Combiné aux health checks de cron doctor de la même fenêtre, les tâches planifiées sont passées de « on configure et on prie » à un système qui se souvient, déduplique et vous prévient quand il est cassé.
Tout assembler
Un motif réaliste : une tâche nocturne surveille la page de changelog d’un concurrent avec --monitor-url, tient son bloc-notes avec le dernier commit vu, et tourne avec --continuity — elle ne rapporte donc que les éléments réellement nouveaux, et si elle rate une exécution, la suivante sait encore ce qu’elle a vu en dernier. Pour le reste de la surface cron — planifications, livraison, tâches script-only — notre guide d’automatisation cron propose la visite complète, et la plongée dans monitor + notepad couvre les mécaniques de prévol.