Plugin de mémoire OpenClaw: Choisissez avec une passerelle à cinq tests

Le paramètre le plus sûr est de ne pas installer le plugin de mémoire OpenClaw le plus capable. Commencez par le backend intégré, écrivez l'exigence qu'il ne peut pas satisfaire, et ne déménagez que lorsqu'un candidat passe cinq tests: persévérance, récupération, confidentialité, comportement d'échec et récupération. Cette règle produit des choix différents pour différents problèmes. Utilisez le moteur intégré pour une petite mémoire locale Markdown. Considérez QMD lorsqu'un grand corpus local a besoin d'un réaffichage ou d'un répertoire indexé supplémentaire. Considérez memory lancedb lorsque la capture automatique et le rappel vectoriel justifient une dépendance de base de données native. Considérez Honcho lorsque la modélisation automatique de l'utilisateur et la mémoire supportée par le service de session sont les exigences réelles. Traitez memory wiki comme une couche de connaissances complémentaire, et non comme un substitut de l'arrière plan mémoire active. Dans cet article, il est utilisé le contrat de documentation OpenClaw 2026.7.1 2 et un dispositif de sélection exécutable. Elle ne prétend pas que l'appareil de référence indique la qualité de la récupération. Le point est plus étroit: rejeter une architecture dont les limites opérationnelles ne peuvent être vérifiées avant qu'elle ne possède une mémoire durable. Décidez d'abord quelle couche vous remplacez Le plugin de mémoire cache deux décisions différentes. L'arrière plan de mémoire active possède le rappel. Le OpenClaw de vue d'ensemble de la mémoire indique que memory search et memory get proviennent du plugin de mémoire active, avec memory core comme par défaut. Seul un plugin possède cette fente de mémoire active à la fois. Le changement de la fente modifie une dépendance à l'heure d'exécution. Une couche complémentaire ajoute une autre représentation sans prendre cet espace. Le mémoire wiki regroupe les revendications, les preuves, l'origine, les tableaux de bord et les pages wiki à côté du backend actif. Rappelez vous, l'indexation, la promotion et le rêve restent avec le plugin de mémoire active. L'installation pour améliorer la recherche est donc une mauvaise décision si la vraie exigence est un moteur de récupération de remplacement. Les choix documentés ont des limites matériellement différentes: Builtin stocke un indice SQLite par agent sur MEMORY.md et memory/ .md . Il prend en charge la recherche de mots clés, vecteurs et hybrides. Le documentation du moteur de construction indique que la recherche de mots clés reste disponible lorsqu'aucun fournisseur d'intégration n'est configuré. Il s'agit de la ligne de base car il n'ajoute pas de sidecar ou de service séparé. QMD est un sidecar local first avec BM25, recherche vectorielle, réaffichage, expansion de requête et annuaires supplémentaires. Le Documentation de QMD démontre également le retour du moteur de construction si le QMD échoue complètement. Ce retrait est un avantage opérationnel concret, pas simplement une autre caractéristique. memory lancedb est un plugin externe qui possède la fente de mémoire. Son documentation officielle décrit le rappel automatique, la capture automatique facultative, une dépendance à l'intégration, la propriété par agent et un paquet natif @lancedb/lancedb . La même page note une limitation de la plateforme pour Intel macOS et ne promet pas une rétroaction automatique de l'arrière plan. Honcho persiste les conversations vers un service dédié et construit des modèles d'utilisateur et d'agent. Le Documentation d'intégration à Honcho prend en charge l'exploitation gérée ou auto hébergée et dit que la mémoire locale Markdown peut rester à côté de lui. Le service, sa limite de rétention et sa disponibilité font partie de la santé de la mémoire. memory wiki est destiné à la synthèse riche en provenance et aux pages de connaissances maintenues. C'est une bonne réponse à Comment garder les revendications et les sources vérifiables? Ce n'est pas la réponse à Quel backend actif devrait posséder le rappel? Sur l'hôte d'essai, openclaw version a déclaré 2026.7.1 2 . openclaw plugins list json a montré que memory core était regroupé et chargé, memory wiki regroupé mais désactivé, et ni LanceDB ni Honcho n'étaient installés. Cette observation n'est pas une recommandation universelle. Il illustre pourquoi la sélection doit commencer par l'inventaire actuel plutôt que par une capture d'écran du marché. Exécuter cinq tests avec des cas délibérément inconvenients Une installation réussie ne prouve qu'une commande a été terminée. Il ne prouve pas que la mémoire nécessaire a survécu, peut être trouvée, restée privée, se dégrade en toute sécurité, ou peut être restaurée. 1. Persistance: nom du propriétaire durable Créez un fait synthétique avec une identification canarienne unique dans un agent d'essai jetable. Enregistrez où réside la source de la vérité, où réside l'index et si un plugin stocke une deuxième copie. Réinitialisez la passerelle, reconstruisez l'index si l'arrière plan en a besoin, et récupérez le canary. Un passe a besoin de tous les trois faits: l'enregistrement source existe toujours; le backend actif indique un indice ou une connexion saine; le canary est récupérable après redémarrage. N'utilisez pas une véritable carte d'identité, le nom d'un client ou une conversation privée comme canary. Un résultat qui est tout simplement toujours présent dans le contexte actuel ne prouve rien de la persistance. 2. Retour: mesure manquées, pas un seul coup chanceux Construisez un petit fichier avec des identifiants exacts, des décisions paraphrasées, deux révisions contradictoires et un élément qui ne devrait pas correspondre. Testez la recherche exacte, la recherche sémantique, la récente, le traitement des contradictions et la suppression. Enregistrez le chemin source attendu ou l'identifiant d'enregistrement avant d'exécuter la requête. Le défaut raisonnable est l'acceptation déterministe: chaque élément requis est trouvé, la révision périmée ne dépasse pas celle actuelle et le contrôle négatif reste absent. Une requête démo avec une réponse plausible ne peut pas distinguer la récupération de la coïncidence. 3. La vie privée: prouver la prédiction de l'isolement Utilisez deux agents jetables et deux canaries. Chaque agent doit récupérer son canary et ne pas récupérer l'autre. Puis inspectez ce qui sort de l' hôte: le texte intégré; si un service hébergé reçoit des messages bruts ou des observations dérivées; où se trouvent les informations d'identification de l'API; si la suppression supprime les copies de source, d'index et de service; si les journaux comprennent le contenu de la mémoire. La documentation LanceDB décrit explicitement un prédicat propriétaire appliqué avant le classement vectoriel. Honcho transforme délibérément les conversations dans un service dédié à moins d'être auto hébergé. Ce sont des limites de confiance différentes. Aucun d'eux ne doit être inclus dans une boîte de contrôle générique appui à la vie privée. 4. Échec: interrompre la dépendance Ne pas mettre à disposition le fournisseur d'intégration, retirer le sidecar de la PATH dans un environnement d'essai ou bloquer le point final de service. Puis pose une question dont on connaît la réponse. Le résultat requis n'est pas nécessairement une réponse correcte. Il s'agit d'un état honnête: disponible à travers une chute documentée, indisponible avec une erreur utile, ou dégradé d'une manière que l'opérateur peut voir. Retourner un résultat vide comme si aucune mémoire n'existait est un faux échec vert. Les frontières documentées comptent ici. La recherche intégrée peut conserver la recherche de mots clés sans intégrations. Le QMD peut revenir à la construction. Une charge native ou une défaillance d'intégration de LanceDB a besoin de sa propre manipulation. Un plugin supporté par le service ajoute la disponibilité du réseau et du service à l'enveloppe de santé. 5. Récupération: restauration, réindexation et vérification Prenez une capture instantanée vérifiée avant la migration. Après l'essai de défaillance, restaurer dans un environnement jetable, reconstruire tout indice dérivé et redémarrer le dispositif de récupération. La récupération ne se fait que lorsque les éléments attendus, la propriété, l'état de suppression et la révision actuelle sont d'accord. Les sondes utiles en lecture seule dépendent du chemin choisi: Le QMD doit indiquer si la voiture latérale est prête ou si la rechute de construction est active. LanceDB ajoute openclaw ltm stats . Honcho ajoute le openclaw honcho status . Memory Wiki ajoute openclaw wiki doctor et openclaw wiki status . Exécuter la sonde pertinente après récupération; ne pas déduire la santé à partir de la disponibilité du processus seul. Ce que la passerelle exécutable a réellement sélectionné L'appareil d'accompagnement codifiait les capacités documentées comme des exigences strictes, puis évaluait cinq profils. Le résultat a été: La sortie est utile parce que chaque choix comporte également une déclaration de rétroaction et une sonde de récupération. Ce n'est pas intentionnellement une carte de score. L'ajout de points pour chaque fonctionnalité rendrait le candidat le plus complexe gagnant même lorsque le lecteur n'a besoin que de Markdown local durable. L'appareil révèle également une frontière importante. Le memory wiki remporte le profil de provenance mais reste en dehors de la voie active. Honcho gagne la modélisation automatique de l'utilisateur mais introduit une limite de service. LanceDB remporte la capture vectorielle locale automatique mais introduit des dépendances d'intégration et de paquets natifs. QMD gagne le grand profil local du corps parce qu'un renouvellement est nécessaire. Builtin gagne le défaut parce qu'aucune de ces exigences supplémentaires n'existe. Vous pouvez reproduire la règle sans faire confiance à la conclusion: 1. Lisez l'exigence en termes observables. 2. Marquez les restrictions de confidentialité et de plateforme non négociables. 3. Rejetez les candidats qui ne peuvent pas satisfaire toutes les contraintes. 4. Je préfère le candidat survivant avec la plus petite surface de défaillance. 5. Exécuter les cinq tests contre les données jetables avant la migration. C'est aussi là que les pages de fonctionnalités cessent d'être des preuves suffisantes. Le fichier est basé sur la documentation actuelle et non sur un indice de référence de récupération partagé. Si deux candidats survivent, testez les deux contre votre corpus, les requêtes, le budget de latence et les modes d'échec. L'inconnu reste inconnu. Gardez le roulement disponible jusqu'à ce que le nouveau chemin se révèle Une migration de mémoire n'est pas complète lorsque les enregistrements sont copiés. Il est complet lorsque le nouvel arrière plan récupère la bonne décision actuelle après le redémarrage, garde les limites de l'agent intactes, expose les défaillances et peut être retourné sans perdre de notes. Utilisez une coupe progressive: congeler l'appareil, et non toute la mémoire de production; prendre une capture instantanée du contenu et en enregistrer le hash; la population du candidat dans un agent isolé; effectuer les cinq essais; les requêtes représentatives de l'ombre contre les voies anciennes et nouvelles; classer les désaccords avant de changer la fente active; maintenir la source précédente intacte à travers une fenêtre de stabilité; supprimer le chemin de retour uniquement après que la restauration ait été testée. La capture automatique mérite une attention particulière. Il peut réduire les écrits manqués, mais il change aussi la limite d'ingestion. Vérifiez si les métadonnées de transport, le contexte injecté, les secrets et les copies sont rejetés. Confirmez quels types de messages sont admissibles, comment la suppression fonctionne et si une capture ratée est visible. La commodité ne remplace pas l'origine. Le même principe s'applique à la rechute. Le dossier de QMD sur la construction de l'appareil conserve un chemin de recherche, mais la qualité des résultats et la couverture du corpus peuvent changer. C'est un état dégradé, pas un vert automatique. Si le backend sélectionné n'a pas de rétroaction documentée, indiquez explicitement l'indisponibilité et conservez un retrait testé. Utilisez une règle de libération, pas un plugin préféré Sélectionnez la plus petite architecture qui répond à l'exigence et passe les cinq tests. La migration de bloc lorsque le propriétaire durable n'est pas clair, une récupération requise est manquée, l'isolement entre agents échoue, une panne semble pas de souvenirs trouvés,ou l'instantané ne peut pas être restauré. Cette règle résout la question initiale: Restez à l'écoute pour le cas local ordinaire. Ajoutez QMD pour l'échelle locale du corpus, la réévaluation ou les chemins supplémentaires. Choisissez LanceDB seulement lorsque la mémoire vectorielle automatique vaut son intégration et sa dépendance native. Choisissez Honcho lorsque la modélisation des utilisateurs en session croisée supportée par le service est l'objectif et que sa limite de données est acceptable. Ajouter un wiki de mémoire lorsque la compilation de connaissances riches en provenance est requise; ne le confondre pas avec le backend actif. Sidewisp est actuellement en préversion privée. Il n'inspecte pas, ne sélectionne pas, ne migre pas ou ne récupère pas les arrière plan de mémoire OpenClaw. Sa direction de produit est de rendre visibles les preuves de santé des agents, l'incertitude et les limites de récupération sûres; la passerelle de cinq tests ci dessus est une méthode que vous pouvez utiliser aujourd'hui sans prétendre que la capacité est expédiée.