Que ton agent IA donne une réponse utile ou invente n'importe quoi avec aplomb, ça dépend avant tout d'une chose : la gestion du contexte. Comment l'historique de conversation, les sorties d'outils et les connaissances externes sont compactés dans la fenêtre de contexte finie d'un modèle. Avant OpenClaw 2026.3.7, cette logique était codée en dur. Maintenant, c'est un plugin.
Le problème
OpenClaw utilisait la compaction par fenêtre glissante : la conversation devient trop longue, les anciens messages sont résumés, les nouveaux gagnent de la place. Ça marchait. Mais avec des compromis, et tout le monde ne s'y retrouvait pas :
- •La synthèse perd des détails. Un agent de code a besoin de référencer une fonction d'il y a 50 tours ? Disparue.
- •Aucune mémoire entre les sessions. Tu fermes la session, tu perds le contexte. Chaque conversation repart de zéro.
- •Une seule stratégie, à prendre ou à laisser. Tu veux de l'assemblage basé sur du RAG ? De la ramification de conversations ? Des budgets de tokens personnalisés ? Pas de moyen propre de le faire.
Les gens bricolaient : monkey-patching des composants internes, fork du noyau, orchestration externe par-dessus. Rien de tout ça n'était pérenne.
ContextEngine : un slot de plugin pour la gestion du contexte
La version 2026.3.7 prend tout le cycle de vie du contexte, l'extrait dans une interface bien définie et l'ouvre en tant que plugin slot. Tu écris un plugin, tu implémentes l'interface, et la gestion du contexte t'appartient.
Comment ça se branche
Enregistre ton moteur via l'API de plugins :
// In your plugin's bootstrap
export default function myContextPlugin(api: PluginAPI) {
api.registerContextEngine('my-engine', (config) => {
return new MyCustomContextEngine(config);
});
}
Sélectionne-le dans la config :
plugins:
slots:
contextEngine: my-engine
Pas de plugin configuré ? OpenClaw encapsule l'ancien comportement dans un LegacyContextEngine. Rien ne change pour les utilisateurs existants.
Sept hooks de cycle de vie
L'interface te donne sept hooks — un pour chaque étape qui compte dans un tour de conversation :
1. `bootstrap()`
Le moteur démarre. Connecte-toi à ta base vectorielle, construis ton graphe, charge l'état sauvegardé.
async bootstrap(): Promise<void> {
this.vectorStore = await connectToVectorDB(this.config.dbUrl);
this.sessionGraph = new DAG();
}
2. `ingest(message: Message)`
Un nouveau message arrive — entrée utilisateur, réponse de l'assistant, sortie d'outil. C'est toi qui décides comment le stocker et l'indexer.
async ingest(message: Message): Promise<void> {
// Add to the DAG
const node = this.sessionGraph.addNode(message);
// Index for retrieval
const embedding = await embed(message.content);
await this.vectorStore.upsert(node.id, embedding, message);
}
3. `assemble(budget: TokenBudget): AssembledContext`
Le hook crucial. Avant chaque appel au modèle, OpenClaw te passe un budget de tokens et te demande : construis-moi un contexte. Ce que tu renvoies, c'est exactement ce que le modèle voit.
Des moteurs différents, des stratégies radicalement différentes :
async assemble(budget: TokenBudget): AssembledContext {
const recentMessages = this.sessionGraph.getRecent(budget.soft * 0.6);
const relevantHistory = await this.vectorStore.query(
this.currentQuery,
budget.soft * 0.3
);
const systemContext = this.buildSystemPrompt(budget.soft * 0.1);
return {
system: systemContext,
messages: [...relevantHistory, ...recentMessages],
tokenEstimate: this.estimateTokens([systemContext, ...relevantHistory, ...recentMessages]),
};
}
4. `compact()`
Le contexte a dépassé la limite dure de tokens. Il faut dégraisser. Le moteur par défaut résume les anciens messages. Ton plugin pourrait élaguer des nœuds du graphe, décharger vers un store vectoriel, ou ne rien faire du tout si assemble() reste déjà dans le budget.
5. `afterTurn(turn: Turn)`
Un tour complet est terminé — l'utilisateur a parlé, l'agent a répondu. Bon moment pour persister l'état, mettre à jour les index ou lancer du travail en arrière-plan.
6. `prepareSubagentSpawn(parentContext: Context): SubagentContext`
L'agent lance un sous-agent. Combien de contexte donner à l'enfant ? Tout ferait exploser son budget de tokens. Rien le rendrait aveugle. Ce hook te permet d'être précis.
prepareSubagentSpawn(parentContext: Context): SubagentContext {
// Give the subagent a focused slice of context
const relevantNodes = this.sessionGraph.getSubtree(parentContext.taskId);
return {
messages: relevantNodes.map(n => n.message),
metadata: { parentSessionId: this.sessionId },
};
}
7. `onSubagentEnded(result: SubagentResult)`
Le sous-agent a terminé. Ses résultats doivent revenir dans le contexte parent d'une façon ou d'une autre : tout fusionner, résumer, sélectionner l'essentiel. C'est ton choix.
Architecture : slots vs. hooks
ContextEngine est un slot, pas un hook. Les hooks sont additifs : dix plugins peuvent écouter onMessage en même temps. Les slots sont exclusifs. Un seul ContextEngine à la fois.
┌─────────────────────────────────────┐
│ Plugin Registry │
│ │
│ Hooks (additifs) : │
│ onMessage → [plugin1, plugin2] │
│ onTool → [plugin3] │
│ │
│ Slots (exclusifs) : │
│ contextEngine → my-engine │
│ (défaut : LegacyContextEngine) │
└─────────────────────────────────────┘
Au démarrage, OpenClaw lit plugins.slots.contextEngine, trouve la factory enregistrée et l'instancie. Si le moteur n'existe pas, le démarrage échoue bruyamment. Pas de fallback silencieux — c'est un choix délibéré. Tu dois savoir quel moteur de contexte tourne.
L'isolation des sous-agents utilise AsyncLocalStorage : chaque enfant obtient son propre runtime isolé. L'état des plugins ne fuite pas entre les frontières d'agents.
Ce que les gens construisent déjà
Lossless-Claw
GitHub · Martian Engineering
Le premier plugin ContextEngine digne de ce nom. Remplace la compaction par fenêtre glissante par un système de synthèse basé sur un DAG qui conserve chaque message original tout en respectant les limites de tokens.
- •Chaque message devient un nœud dans un graphe acyclique dirigé
- •Les nœuds se regroupent en "épisodes" par sujet
- •Hors budget ? Les anciens épisodes sont résumés, mais les originaux restent dans le graphe
- •Si un tour ultérieur fait référence à du contenu ancien, le moteur récupère l'original — pas le résumé
Si ton agent de code a déjà oublié une fonction qu'il avait écrite une heure plus tôt, voilà la solution.
MemOS Cloud Plugin
GitHub · MemTensor
Fait une seule chose : donne à ton agent une mémoire qui survit entre les sessions.
- •Au
bootstrap(): récupère les souvenirs pertinents depuis MemOS Cloud en se basant sur le message d'ouverture - •Au
afterTurn(): sauvegarde les nouveaux tours dans le cloud - •Au
assemble(): injecte les souvenirs rappelés dans le contexte système
Ton agent se souvient de la conversation de la semaine dernière, de tes préférences, de tes projets. Tu arrêtes de te répéter.
Et la suite ?
D'après les issues GitHub et Discord, les gens travaillent sur :
- •Assemblage natif RAG : Oublier l'historique de messages, assembler le contexte à partir de fragments de documents récupérés. OpenClaw comme moteur de recherche conversationnel.
- •Mémoire partagée multi-agents : Plusieurs agents qui partagent un graphe de connaissances. Des workflows collaboratifs sans contexte redondant.
- •Optimisation du budget de tokens : Ajustement dynamique de la composition du contexte selon le modèle utilisé — son prix, ses forces, sa longueur de contexte.
- •Ramification de conversations : Un contexte en arborescence. Explorer différents chemins, revenir en arrière, tout garder.
Pourquoi ça change la donne
OpenClaw a toujours pu ajouter des channels, des modèles et des outils. Mais le contexte — la façon dont l'agent pense réellement — était verrouillé dans le noyau. Impossible d'y toucher sans forker.
ContextEngine ouvre cette boîte. Et une fois ouverte, les effets s'accumulent :
- 1.Les développeurs de plugins peuvent enfin se mesurer sur le problème le plus dur de l'UX agent : la qualité du contexte.
- 2.Les utilisateurs entreprise obtiennent des contrôles de conformité : anonymiser avant que le modèle ne voie les données, appliquer des politiques de rétention, auditer chaque prompt.
- 3.Les chercheurs peuvent tester de nouvelles stratégies de contexte sans maintenir un fork.
- 4.Les fournisseurs de modèles peuvent livrer des plugins calibrés pour leurs architectures. Les modèles à contexte long et les modèles à contexte court ne devraient pas utiliser la même stratégie.
Voilà ce que ça veut dire concrètement quand un framework devient une plateforme. Pas un changement de nom. Pas un post de blog qui annonce une "vision". Un changement architectural concret qui rend l'écosystème auto-renforçant. Plus de plugins → plus d'utilisateurs → plus de développeurs → plus de plugins. Une fois que cette boucle démarre, elle est difficile à arrêter.
Le homard vient de se faire pousser une nouvelle pince.