La recherche de sessions d’OpenClaw
Des mots exacts dans les transcriptions passées, la réouverture du contexte trouvé, les règles de visibilité, et un index qui ne prend jamais de retard
Quand quelque chose a été discuté dans une session OpenClaw antérieure, l’outil de recherche de sessions le retrouve par les mots exacts employés. Il cherche dans le texte d’utilisateur et d’assistant des sessions passées visibles et renvoie pour chaque résultat une clé de session, un horodatage, un rôle et un court extrait correspondant. L’essentiel n’est pas l’extrait mais la suite : passer ensemble la clé de session, l’identifiant de message et l’identifiant de session renvoyés à l’outil d’historique rouvre le contexte trouvé, y compris l’historique conservé d’avant une réinitialisation de session. Voici comment se comportent les lectures ancrées, qui voit quelles sessions, ce qui est caviardé, comment l’index est entretenu, et où la recherche mémoire prend le relais.
Rouvrir le contexte trouvé
- Sans identifiant de message, l’historique renvoie la fin la plus récente relative à la réinitialisation ; un identifiant de message explicite qui reste dans la vue courante, y compris une ligne d’avant réinitialisation conservée après celle-ci, garde le comportement de la vue courante et peut inclure des tours postérieurs à la réinitialisation.
- Un identifiant de message explicite pour une ligne conservée du chemin actif hors de la vue courante ouvre cet intervalle fermé d’origine sans y mêler des tours postérieurs à la réinitialisation.
- Les lectures ancrées bornent les messages environnants par une limite et ne se combinent pas avec un décalage ; sur l’historique de transcription SQLite, un message manquant ou hors chemin renvoie un historique vide plutôt que la fin la plus récente, et un identifiant de session qui n’appartient pas à la clé de session choisie est rejeté.
- Les mêmes règles s’appliquent en mode embarqué local, sans passerelle en cours d’exécution.
Les nouveaux messages d’utilisateur et d’assistant sont indexés dans la même transaction qui les conserve, si bien que l’index ne prend jamais de retard sur les conversations en direct ; les résultats d’outils, les blocs de raisonnement et les images sont exclus.
Qui voit quelles sessions
La recherche utilise les mêmes règles de visibilité de session configurées que l’historique. La visibilité par défaut, toutes, laisse les appelants hors bac à sable chercher dans les sessions de tous les agents de la passerelle, y compris les conversations d’autres utilisateurs ; l’accès entre agents est activé par défaut et gouverné par le réglage d’agent à agent, qui peut être désactivé pour bloquer l’accès ordinaire entre agents ou restreint par une liste de paires d’agents autorisées, tandis que les sous-agents natifs et les sessions enfants ACP d’un demandeur restent accessibles sous les portées arbre ou toutes. Fixez une portée explicite agent, arbre ou soi quand les appelants doivent voir moins. Le routage par correspondant des messages privés sépare le contexte de conversation mais ne restreint pas la visibilité des outils de session. Les résultats hors de la portée effective de l’appelant sont retirés avant l’application des limites, les agents en bac à sable restent limités aux sessions qu’ils ont lancées quand la visibilité des sessions lancées est activée, les sessions incognito sont toujours exclues, et restreindre la visibilité en deçà de toutes bloque l’accès ordinaire entre agents. Les extraits sont caviardés avant de revenir au modèle, et les résultats sont bornés en nombre, en longueur d’extrait et en taille totale de réponse.
Le cycle de vie de l’index
- OpenClaw stocke un index plein texte à côté des lignes de transcription dans la base SQLite de chaque agent ; seule la branche active de la transcription est cherchable, et supprimer une session retire ses entrées d’index dans la même transaction.
- Les transcriptions antérieures à l’index, comme les sessions importées par la commande doctor, et les sessions dont la branche active a été rembobinée sont réindexées par une réconciliation d’arrière-plan qui démarre à la recherche suivante, si bien qu’une réponse signalée comme encore en indexation peut être incomplète et mérite une nouvelle tentative une fois l’indexation terminée.
- La recherche utilise le découpeur de mots Unicode de SQLite avec suppression des diacritiques, si bien que les graphies accentuées et non accentuées se rejoignent.
Utilisez cet outil pour des mots ou des phrases exacts tirés des transcriptions brutes et La recherche mémoire d’OpenClaw pour les fichiers de mémoire durables et le rappel sémantique ; Les sessions d’OpenClaw explique les clés et les réinitialisations vers lesquelles pointent les résultats.
Pourquoi le défaut est large
La portée par défaut existe pour qu’un opérateur faisant tourner plusieurs agents sur une passerelle retrouve une conversation où qu’elle ait eu lieu, et elle suppose des appelants dignes de cette confiance. La messagerie d’agent à agent d’OpenClaw couvre le réglage d’agent à agent qui gouverne la moitié entre agents, et Le bac à sable d’OpenClaw expliqué la frontière qui garde un agent en bac à sable dans les sessions qu’il a lancées.
Sur Diali
Sur Diali, l’index vit à côté des transcriptions sur le volume de l’assistant, donc il survit aux releases avec le reste de l’état de session, et les règles de visibilité s’appliquent à quiconque vous laissez parler à cet assistant. OpenClaw hébergé sur Diali est l’assistant et La sécurité chez Diali décrit la frontière qui l’entoure.
- Des mots exacts en entrée, trois clés en sortie, le contexte rouvert.
- La visibilité vaut toutes par défaut ; restreignez-la quand les appelants doivent voir moins.
- Indexé dans la même transaction ; réconcilié en arrière-plan.
Arrêtez de lire, construisez le vôtre
Configurez un agent, choisissez un canal, et faites-le travailler dans l’application que vous gardez déjà ouverte.
