ContextEngine im Detail: Wie OpenClaw 2026.3.7 das Kontextmanagement zum Plugin machte

Ob dein KI-Agent eine brauchbare Antwort liefert oder sich selbstbewusst etwas zusammenfantasiert, hängt vor allem von einer Sache ab: Kontextmanagement. Also davon, wie Gesprächsverlauf, Tool-Ausgaben und externes Wissen in das endliche Kontextfenster eines Modells gepackt werden. Vor OpenClaw 2026.3.7 war diese Logik fest verdrahtet. Jetzt ist sie ein Plugin.

Das Problem

OpenClaw nutzte Sliding-Window-Kompaktierung: Wird die Konversation zu lang, werden alte Nachrichten zusammengefasst, neue bekommen Platz. Hat funktioniert. Aber es gab Kompromisse, und nicht alle waren damit zufrieden:

• •Zusammenfassungen verlieren Details. Ein Coding-Agent muss auf eine Funktion von vor 50 Turns zugreifen? Weg.
• •Kein Gedächtnis über Sessions hinweg. Session schließen, Kontext verlieren. Jedes Gespräch startet bei null.
• •Eine Strategie, friss oder stirb. RAG-basiertes Assembly? Gesprächsverzweigung? Eigene Token-Budgets? Kein sauberer Weg rein.

Die Leute haben sich beholfen: Monkey-Patching interner Strukturen, Forks des Kerns, externe Orchestrierung drumherum gebaut. Nichts davon war nachhaltig.

ContextEngine: Ein Plugin-Slot für Kontextmanagement

Version 2026.3.7 nimmt den gesamten Kontext-Lebenszyklus, extrahiert ihn in ein klar definiertes Interface und öffnet ihn als Plugin-Slot. Plugin schreiben, Interface implementieren, und das Kontextmanagement gehört dir.

So wird's eingebunden

Registriere deine Engine über die Plugin-API:

// In your plugin's bootstrap
export default function myContextPlugin(api: PluginAPI) {
  api.registerContextEngine('my-engine', (config) => {
    return new MyCustomContextEngine(config);
  });
}

In der Konfiguration auswählen:

plugins:
  slots:
    contextEngine: my-engine

Kein Plugin konfiguriert? OpenClaw verpackt das alte Verhalten in eine LegacyContextEngine. Für bestehende Nutzer ändert sich nichts.

Sieben Lifecycle-Hooks

Das Interface bietet sieben Hooks — einen für jede Phase, die in einem Gesprächsturn zählt:

1. `bootstrap()`

Die Engine startet. Verbindung zur Vektor-DB aufbauen, Graphen konstruieren, gespeicherten State laden.

async bootstrap(): Promise<void> {
  this.vectorStore = await connectToVectorDB(this.config.dbUrl);
  this.sessionGraph = new DAG();
}

2. `ingest(message: Message)`

Eine neue Nachricht kommt rein — Benutzereingabe, Assistenten-Antwort, Tool-Ausgabe. Du entscheidest, wie sie gespeichert und indiziert wird.

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`

Der entscheidende Hook. Vor jedem Model-Call übergibt OpenClaw dir ein Token-Budget und sagt: Bau mir einen Kontext. Was du zurückgibst, ist exakt das, was das Modell sieht.

Unterschiedliche Engines, grundlegend unterschiedliche Strategien:

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()`

Der Kontext hat das harte Token-Limit gesprengt. Zeit zum Abspecken. Die Standard-Engine fasst alte Nachrichten zusammen. Dein Plugin könnte Graph-Knoten beschneiden, in einen Vektorspeicher auslagern — oder es ganz lassen, wenn assemble() ohnehin im Budget bleibt.

5. `afterTurn(turn: Turn)`

Ein kompletter Turn ist durch — Nutzer hat gesprochen, Agent hat geantwortet. Guter Zeitpunkt, um State zu persistieren, Indizes zu aktualisieren oder Hintergrundarbeit anzustoßen.

6. `prepareSubagentSpawn(parentContext: Context): SubagentContext`

Der Agent erstellt einen Subagenten. Wie viel Kontext bekommt das Kind? Alles würde sein Token-Budget sprengen. Nichts würde ihn blind lassen. Dieser Hook gibt dir die Kontrolle.

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)`

Der Subagent ist fertig. Seine Ergebnisse müssen irgendwie zurück in den Elternkontext — alles mergen, zusammenfassen, gezielt auswählen. Deine Entscheidung.

Architektur: Slots vs. Hooks

ContextEngine ist ein Slot, kein Hook. Hooks sind additiv — zehn Plugins können gleichzeitig auf onMessage lauschen. Slots sind exklusiv. Eine ContextEngine zur Zeit.

┌─────────────────────────────────────┐
│           Plugin Registry           │
│                                     │
│  Hooks (additiv):                   │
│    onMessage  → [plugin1, plugin2]  │
│    onTool     → [plugin3]           │
│                                     │
│  Slots (exklusiv):                  │
│    contextEngine → my-engine        │
│    (default: LegacyContextEngine)   │
└─────────────────────────────────────┘

Beim Start liest OpenClaw plugins.slots.contextEngine, findet die registrierte Factory und instanziiert sie. Existiert die Engine nicht, schlägt der Start laut fehl. Kein stilles Fallback — das ist Absicht. Du sollst wissen, welche Context-Engine du fährst.

Subagent-Isolation nutzt AsyncLocalStorage: Jedes Kind bekommt seine eigene, abgegrenzte Runtime. Plugin-State leakt nicht über Agentengrenzen hinweg.

Was die Leute jetzt schon bauen

Lossless-Claw

GitHub · Martian Engineering

Das erste ernstzunehmende ContextEngine-Plugin. Ersetzt die Sliding-Window-Kompaktierung durch ein DAG-basiertes Zusammenfassungssystem, das jede Originalnachricht behält und trotzdem im Token-Limit bleibt.

• •Jede Nachricht wird zu einem Knoten in einem gerichteten azyklischen Graphen
• •Knoten werden nach Thema zu "Episoden" gruppiert
• •Über Budget? Alte Episoden werden zusammengefasst, aber die Originale bleiben im Graphen
• •Referenziert ein späterer Turn alten Inhalt, holt die Engine das Original — nicht die Zusammenfassung

Wenn dein Coding-Agent schon mal eine Funktion vergessen hat, die er vor einer Stunde geschrieben hat — das hier ist die Lösung.

MemOS Cloud Plugin

GitHub · MemTensor

Macht genau eine Sache: gibt deinem Agenten Erinnerungen, die Sessions überleben.

• •Bei bootstrap(): holt relevante Erinnerungen aus MemOS Cloud basierend auf der Eröffnungsnachricht
• •Bei afterTurn(): speichert neue Turns in die Cloud
• •Bei assemble(): injiziert abgerufene Erinnerungen in den Systemkontext

Dein Agent erinnert sich an das Gespräch von letzter Woche, an deine Vorlieben, an deine Projekte. Du hörst auf, dich zu wiederholen.

Was als Nächstes kommt

Aus GitHub-Issues und Discord: Woran die Leute gerade arbeiten:

• •RAG-natives Assembly: Nachrichtenhistorie überspringen, Kontext aus abgerufenen Dokumentfragmenten zusammenbauen. OpenClaw als konversationelle Suchmaschine.
• •Multi-Agent Shared Memory: Mehrere Agenten teilen sich einen Knowledge Graph. Kollaborative Workflows ohne redundanten Kontext.
• •Token-Budget-Optimierung: Dynamische Anpassung der Kontextzusammensetzung je nach Modell — Preisgestaltung, Stärken, Kontextlänge.
• •Gesprächsverzweigung: Baumstrukturierter Kontext. Verschiedene Pfade erkunden, zurückwechseln, alles behalten.

Warum das alles verändert

OpenClaw konnte schon immer Channels, Modelle und Tools hinzufügen. Aber der Kontext — wie der Agent tatsächlich denkt — war im Kern eingesperrt. Ohne Fork kam man da nicht ran.

ContextEngine bricht das auf. Und einmal offen, fangen die Effekte an, sich zu verstärken:

1. 1.Plugin-Entwickler können endlich am schwierigsten Problem der Agent-UX konkurrieren: Kontextqualität.
2. 2.Enterprise-Nutzer bekommen Compliance-Kontrollen — Schwärzen bevor das Modell es sieht, Aufbewahrungsrichtlinien durchsetzen, jeden Prompt auditieren.
3. 3.Forscher können neue Kontextstrategien testen, ohne einen Fork zu pflegen.
4. 4.Model-Anbieter können Plugins ausliefern, die auf ihre Architekturen abgestimmt sind. Long-Context-Modelle und Short-Context-Modelle sollten nicht dieselbe Strategie fahren.

So sieht es aus, wenn ein Framework tatsächlich zur Plattform wird. Kein Rebranding. Kein Blogpost, der eine "Vision" verkündet. Eine konkrete Architekturänderung, die das Ökosystem selbstverstärkend macht. Mehr Plugins → mehr Nutzer → mehr Entwickler → mehr Plugins. Wenn diese Schleife einmal läuft, ist sie schwer zu stoppen.

Der Hummer hat gerade eine neue Schere bekommen.