Cycle de vie des sessions Hermes Agent et tâches planifiées

Politique de réinitialisation de session

La politique de réinitialisation contrôle le moment où une session "perd automatiquement la mémoire" — elle obtient un nouveau session_id et l'ancien contexte est archivé.

Une configuration raisonnable de la politique de réinitialisation empêche le contexte de l'Agent de croître indéfiniment tout en garantissant que l'expérience utilisateur n'est pas affectée.

Quatre modes de réinitialisation

Configurer la politique de réinitialisation

Effet de réinitialisation

Lorsqu'une session déclenche une réinitialisation, voici ce qui se produit :

• Les anciennes sessions sont marquées comme terminées dans SQLite (raison : "session_reset")
• Générer un nouveau session_id (format : YYYYMMDD_HHMMSS_hexadécimal aléatoire à 8 chiffres)
• Le was_auto_reset du nouveau SessionEntry est marqué comme true
• Les instances d'Agent en cache sont nettoyées
• L'utilisateur verra une notification "Session réinitialisée" dans le prochain message.

Les sessions avec des processus d'arrière-plan actifs ne sont jamais réinitialisées. Hermes vérifie le callback has_active_processes pour s'assurer qu'il n'interrompt jamais les tâches en cours.

Mécanisme de récupération après redémarrage

Le mécanisme de récupération après redémarrage d'Hermes Gateway garantit que les sessions en cours ne sont pas perdues après un plantage inattendu ou un redémarrage planifié.

Deux marqueurs de récupération

Processus de récupération au démarrage

Lorsque le Gateway démarre, le processus de récupération est le suivant :

Étape 1 : Vérifier le marqueur .clean_shutdown.

S'il existe, l'arrêt précédent était propre, donc le processus de récupération est ignoré.

Étape 2 : si le marqueur .clean_shutdown n'existe pas, la sortie précédente était anormale.

Gateway appelle suspend_recently_active(), marquant les sessions actives au cours des 120 dernières secondes comme resume_pending.

Étape 3 : détecter la boucle bloquée (boucle infinie).

Si une session est encore active après 3 redémarrages consécutifs, elle peut être bloquée dans une boucle infinie ; le Gateway la marquera comme suspendue.

Étape 4 : reprendre les sessions en attente.

Gateway synthétise un MessageEvent pour chaque session resume_pending, déclenchant l'Agent pour qu'il continue automatiquement.

Marqueur de délai de drainage

Lors d'un arrêt/redémarrage propre, si une session est en cours de traitement mais dépasse le temps d'attente de drainage, le Gateway la marquera comme resume_pending.

Raisons du marquage dans différents scénarios :

Le marqueur resume_pending n'est pas effacé à get_or_create_session() — il est effacé après la prochaine réponse réussie de l'Agent. Si la session récupérée est à nouveau interrompue, le marqueur reste, permettant une nouvelle tentative au prochain redémarrage. Après 3 échecs consécutifs, il est promu en suspended.

Mécanisme de file d'attente de messages

Lorsqu'un utilisateur envoie plusieurs messages consécutivement pendant que l'Agent traite un message, le mécanisme de file d'attente de messages de la Gateway garantit que les messages ne sont pas perdus.

Structure de la file d'attente

La Gateway utilise une conception de file d'attente à deux niveaux :

• Pending à emplacement unique (_pending_messages) : chaque session n'a qu'un seul emplacement "next" ; les envois répétés l'écrasent.
• File d'attente de débordement (_queued_events) : lorsque l'emplacement est occupé, les messages suivants sont ajoutés à la fin de la file d'attente de débordement.

commande /queue

La commande /queue vous permet de soumettre des tâches par lots, et chaque tâche produit un tour complet de l'Agent.

Chaque tâche dans la file d'attente est exécutée dans l'ordre FIFO, chaque tâche produisant un tour complet de l'Agent ; elles ne sont pas fusionnées.

Utilisez la commande /new ou /reset pour vider la file d'attente des messages de la session actuelle.

Si vous envoyez plusieurs messages consécutivement pendant que l'Agent effectue un traitement, les messages intermédiaires seront écrasés (seul le dernier est conservé) ; les messages dans la commande /queue ne sont pas écrasés — chaque tâche /queue s'exécute dans l'ordre.

Tâches planifiées (Cron)

Hermes dispose d'une prise en charge native des tâches planifiées, vous permettant de configurer l'Agent pour exécuter périodiquement des tâches spécifiques.

Les tâches planifiées peuvent se lier à une Skill et transmettre les résultats à une plateforme spécifiée.

Configurer les tâches planifiées

Les tâches planifiées sont définies dans jobs.json et prennent en charge plusieurs formats de planification.

{
  "jobs": [
    {
      "id": "daily-news-summary",
      "schedule": "0 8 * * *",
      "description": "每天早上 8 点抓取 AI 行业新闻并生成摘要",
      "skill": "ai-news-summarizer",
      "deliver_to": {
        "platform": "telegram",
        "chat_id": "-1001234567890"
      }
    },
    {
      "id": "weekly-code-review",
      "schedule": "0 10 * * 1",
      "description": "每周一早上 10 点审查项目代码变更",
      "skill": "code-review-assistant",
      "deliver_to": {
        "platform": "discord",
        "chat_id": "123456789"
      }
    },
    {
      "id": "health-check",
      "schedule": "*/30 * * * *",
      "description": "每 30 分钟检查服务器健康状态",
      "skill": "server-health-checker",
      "deliver_to": {
        "platform": "telegram",
        "chat_id": "123456789"
      }
    }
  ]
}

Formats de planification pris en charge

Peut être configuré dans la version de bureau ; cliquez sur « Planification » dans le coin inférieur gauche :

Cliquez sur « Créer une tâche planifiée » :

Créer une tâche :

Une fois qu'une tâche planifiée est liée à une Skill, la sortie est automatiquement formatée selon le format de sortie défini par la Skill. Cela garantit que, lorsque les résultats des tâches planifiées sont transmis à une plateforme de messagerie, la présentation reste cohérente et lisible.

Cron géré par Chronos (avancé)

Chronos est la solution de tâches planifiées gérée de Hermes, conçue spécifiquement pour les modèles de déploiement avec mise à l'échelle à zéro (scale-to-zero).

Lorsque votre Gateway est complètement arrêté au repos, Chronos peut tout de même garantir que les tâches planifiées se déclenchent à l'heure.

Pourquoi Chronos est-il nécessaire ?

Le ticker cron intégré exige que le processus Gateway s'exécute en continu — si le Gateway est réduit à zéro, les tâches planifiées ne se déclencheront pas.

Chronos délègue la gestion des tâches planifiées à NAS (Nous Account Service), qui réveille le Gateway via un planificateur externe lorsqu'une tâche se déclenche.

Flux de travail de Chronos

Le flux de travail de Chronos se divise en quatre étapes :

Étape 1 : l'Agent calcule l'heure de déclenchement suivante et enregistre un minuteur à usage unique auprès de NAS.

Étape 2 : NAS utilise un planificateur externe (tel que les déclencheurs planifiés de Fly Machines) pour déclencher un rappel à l'heure spécifiée.

Étape 3 : Le planificateur externe effectue un rappel vers NAS, et NAS génère un jeton JWT de courte durée.

Étape 4 : NAS appelle le point de terminaison /api/cron/fire de l'Agent à l'aide d'un jeton JWT. L'Agent le vérifie, exécute la tâche et réenregistre le prochain minuteur à usage unique.

Garantie d'exécution au plus une fois

Chronos utilise des opérations CAS (Compare-And-Set) au niveau du store pour garantir que chaque tâche planifiée n'est exécutée qu'une seule fois.

Même si le planificateur envoie des requêtes de déclenchement en double en raison de nouvelles tentatives réseau, l'Agent peut dédupliquer via CAS, garantissant que les tâches ne sont pas exécutées de manière répétée.

Configurer Chronos

Chronos est la solution de planification recommandée pour les déploiements Hermes gérés. Si vous utilisez un déploiement auto-hébergé et que votre Gateway ne passe jamais à zéro, le ticker cron intégré est amplement suffisant. Si callback_url est vide ou si l'Agent n'a pas de connexion Nous, le système revient automatiquement au ticker intégré.