English简体中文繁體中文日本語EspañolPortuguês (BR)한국어DeutschFrançaisالعربيةItalianoTiếng ViệtNederlandsTürkçeУкраїнськаBahasa IndonesiaPolskiفارسیไทย

Sessions and memory

Gestion des sessions

OpenClaw organise les conversations en sessions. Chaque message est routé vers une session selon sa provenance : DM, discussions de groupe, tâches cron, etc.

Comment les messages sont routés

Source Comportement
Messages directs Session partagée par défaut
Discussions de groupe Isolée par groupe
Salles/canaux Isolée par salle
Tâches cron Nouvelle session à chaque exécution
Webhooks Isolée par hook

Isolation des DM

Par défaut, tous les DM partagent une session pour assurer la continuité. Cela convient aux configurations mono-utilisateur.

La correction :

{
  session: {
    dmScope: "per-channel-peer", // isolate by channel + sender
  },
}

Autres options :

  • main (par défaut) -- tous les DM partagent une session.
  • per-peer -- isole par expéditeur (sur tous les canaux).
  • per-channel-peer -- isole par canal + expéditeur (recommandé).
  • per-account-channel-peer -- isole par compte + canal + expéditeur.

Ancrer les canaux liés

Les commandes d'ancrage permettent à un utilisateur de déplacer la route de réponse de la session de discussion directe actuelle vers un autre canal lié sans démarrer une nouvelle session. Consultez Ancrage de canal pour des exemples, la configuration et le dépannage.

Vérifiez votre configuration avec openclaw security audit.

Cycle de vie des sessions

Les sessions sont réutilisées jusqu'à leur expiration :

  • Réinitialisation quotidienne (par défaut) -- nouvelle session à 4 h 00, heure locale, sur l'hôte du Gateway. La fraîcheur quotidienne est basée sur le moment où le sessionId actuel a démarré, et non sur les écritures de métadonnées ultérieures.
  • Réinitialisation après inactivité (facultative) -- nouvelle session après une période d'inactivité. Définissez session.reset.idleMinutes. La fraîcheur d'inactivité est basée sur la dernière interaction réelle utilisateur/canal, de sorte que les événements système heartbeat, cron et exec ne maintiennent pas la session active.
  • Réinitialisation manuelle -- saisissez /new ou /reset dans la discussion. /new <model> change aussi le modèle.

Lorsque les réinitialisations quotidienne et après inactivité sont toutes deux configurées, la première qui expire l'emporte. Les tours Heartbeat, cron, exec et autres événements système peuvent écrire des métadonnées de session, mais ces écritures ne prolongent pas la fraîcheur des réinitialisations quotidienne ou après inactivité. Lorsqu'une réinitialisation fait basculer la session, les notifications d'événements système en file d'attente pour l'ancienne session sont supprimées afin que les mises à jour d'arrière-plan obsolètes ne soient pas ajoutées au début de la première invite de la nouvelle session.

Les sessions avec une session CLI active appartenant au fournisseur ne sont pas interrompues par la valeur quotidienne implicite par défaut. Utilisez /reset ou configurez explicitement session.reset lorsque ces sessions doivent expirer selon un minuteur.

Où réside l'état

Tout l'état de session appartient au Gateway. Les clients d'interface interrogent le Gateway pour obtenir les données de session.

  • Stockage : ~/.openclaw/agents/<agentId>/sessions/sessions.json
  • Transcriptions : ~/.openclaw/agents/<agentId>/sessions/<sessionId>.jsonl

sessions.json conserve des horodatages de cycle de vie distincts :

  • sessionStartedAt : moment où le sessionId actuel a commencé ; la réinitialisation quotidienne l'utilise.
  • lastInteractionAt : dernière interaction utilisateur/canal qui prolonge la durée d'inactivité.
  • updatedAt : dernière mutation de ligne du stockage ; utile pour l'affichage et l'élagage, mais pas faisant autorité pour la fraîcheur des réinitialisations quotidienne/après inactivité.

Les anciennes lignes sans sessionStartedAt sont résolues à partir de l'en-tête de session JSONL de la transcription lorsqu'il est disponible. Si une ancienne ligne n'a pas non plus lastInteractionAt, la fraîcheur d'inactivité revient à l'heure de début de cette session, et non aux écritures comptables ultérieures.

Maintenance des sessions

OpenClaw borne automatiquement le stockage des sessions au fil du temps. Par défaut, il s'exécute en mode warn (signale ce qui serait nettoyé). Définissez session.maintenance.mode sur "enforce" pour un nettoyage automatique :

{
  session: {
    maintenance: {
      mode: "enforce",
      pruneAfter: "30d",
      maxEntries: 500,
    },
  },
}

Pour les limites maxEntries de taille production, les écritures d'exécution du Gateway utilisent un petit tampon de seuil haut et nettoient par lots jusqu'au plafond configuré. Les lectures du stockage de sessions n'élaguent ni ne plafonnent les entrées au démarrage du Gateway. Cela évite d'exécuter un nettoyage complet du stockage à chaque démarrage ou session cron isolée. openclaw sessions cleanup --enforce applique le plafond immédiatement.

La maintenance préserve les pointeurs durables vers des conversations externes, y compris les sessions de groupe et les sessions de discussion limitées à un fil, tout en permettant aux entrées synthétiques cron, hook, heartbeat, ACP et sous-agent de vieillir.

Si vous utilisiez auparavant l'isolation des messages directs puis avez remis session.dmScope à main, prévisualisez les lignes de DM obsolètes indexées par pair avec openclaw sessions cleanup --dry-run --fix-dm-scope. L'application du même indicateur retire ces anciennes lignes de DM directs et conserve leurs transcriptions comme archives supprimées.

Prévisualisez avec openclaw sessions cleanup --dry-run.

Inspecter les sessions

  • openclaw status -- chemin du stockage de sessions et activité récente.
  • openclaw sessions --json -- toutes les sessions (filtrer avec --active <minutes>).
  • /status dans la discussion -- utilisation du contexte, modèle et bascules.
  • /context list -- ce qui se trouve dans l'invite système.

Pour aller plus loin

Connexe