Plugin de reclassement externe pour OpenClaw Memory-Core : réutiliser les anciens GPU
Un développeur a publié un plugin pour OpenClaw qui permet à memory-core d'utiliser un reranker externe, déplaçant l'algorithme MMR dans un plugin et ajoutant un nouveau plugin memory-external-reranker. Si vous avez un vieux GPU qui prend la poussière, c'est un moyen pratique de le faire travailler.
Comment ça marche
La conception refactorise MMR dans un plugin séparé appelé memory-mmr, et ajoute memory-external-reranker comme un autre plugin. Sans modification de openclaw.json, le nouveau plugin memory-mmr se charge automatiquement si la mémoire hybride est activée. Pour activer le reranker externe, suivez la documentation dans le dépôt. Il existe également un repli vers MMR si le reranker n'est pas disponible.
Configuration testée
- Modèle d'embeddings :
Qwen/Qwen3-Embedding-4B-GGUF:Q8_0 - Modèle de reranker :
mradermacher/Qwen3-Reranker-4B-GGUF:Q8_0 - Repli : MMR
- GPU : RTX 3060 (12 Go VRAM) — les deux modèles fonctionnent ensemble confortablement
Pourquoi pas QMD ?
QMD s'exécute localement sans capacité de décharger le modèle. Si vous exécutez OpenClaw dans Docker sur un hôte sans GPU utilisable (ou si vous ne voulez pas d'inférence CPU), QMD est un gouffre de performances. Ce plugin vous permet d'utiliser un reranking externe avec des modèles servis ailleurs (y compris ce vieux RTX 3060 qui ne fait rien).
Est-ce que ça vaut le coup ?
L'auteur rapporte que le rappel en mémoire semble amélioré, bien qu'il n'ait pas de métriques pour le quantifier. Pour les configurations avec un GPU de rechange ou un serveur d'inférence séparé, ce plugin offre un moyen propre de décharger le reranking sans changer le comportement principal de memory-core.
Dépôt et branche
Le plugin se trouve dans la branche external-reranker du fork : github.com/michmill1970/openclaw/tree/external-reranker. L'auteur maintient le fork proche de la branche principale, en le mettant à jour plusieurs fois par jour.
📖 Lire la source complète : r/openclaw
👀 See Also
Le Cadre SIDJUA Ajoute une Couche de Gouvernance aux Agents IA Autonomes
SIDJUA est un cadre avec une gouvernance intégrée, des règles d'autorité basées sur les rôles et des pistes d'audit complètes qui s'installe au-dessus de tout modèle d'IA avec une API. La démo montre une hiérarchie à trois niveaux qui s'adapte à 7+1 niveaux, avec chaque décision enregistrée et les coûts suivis en temps réel.
Runtime : des agents de codage en bac à sable pour chaque membre de l’équipe
Runtime (YC P26) fournit une infrastructure d'agents de codage en bac à sable qui permet aux non-ingénieurs d'utiliser Claude Code, Codex et d'autres agents en toute sécurité. Il capture des environnements multi-services (Docker, Kafka, Redis, bases de données initialisées) qui démarrent en quelques millisecondes, avec des garde-fous au niveau de l'infrastructure.
Mesure de la pile MCP de Claude Code : convivialité du cache vs économies d'octets, et une correction en 2 lignes pour le cache de prompt
Greg Shevchenko évalue les compresseurs MCP et les couches de récupération sur deux axes : économie d'octets et adaptabilité au cache. Un correctif de deux lignes (trier les résultats de rg, trier les entrées de Map) fait passer le cache d'environ 0 % à 100 % sans perte d'économies d'octets. Harness open source inclus.
TruthGuard : Hooks de Script Shell Qui Détectent les Mensonges des Agents d'IA de Codage
TruthGuard est un outil open-source qui utilise des hooks de script shell pour vérifier ce que font réellement Claude Code et Gemini CLI par rapport à ce qu'ils prétendent. Il détecte les modifications fantômes, les mensonges sur les codes de sortie, les raccourcis dangereux et bloque les commits lorsque les tests échouent.