technical architecture plugins contextengine

ContextEngine w szczegółach: jak OpenClaw 2026.3.7 zamienił zarządzanie kontekstem we wtyczkę

OpenClaws.io Team

OpenClaws.io Team

@openclaws

March 9, 2026

10 min czytania

ContextEngine w szczegółach: jak OpenClaw 2026.3.7 zamienił zarządzanie kontekstem we wtyczkę

To, czy twój agent AI udzieli przydatnej odpowiedzi, czy z pełnym przekonaniem wymyśli bzdury, zależy przede wszystkim od zarządzania kontekstem—czyli od tego, jak historia rozmowy, wyniki narzędzi i zewnętrzna wiedza zostają upakowane w skończone okno kontekstowe modelu. Przed OpenClaw 2026.3.7 ta logika była zahardkodowana. Teraz to plugin.

Problem

OpenClaw stosował sliding-window compaction: rozmowa robi się za długa, stare wiadomości są streszczane, nowe dostają miejsce. Działało. Ale miało swoje kompromisy i nie wszystkim się to podobało:

  • Streszczanie traci szczegóły. Agent programistyczny potrzebuje funkcji sprzed 50 tur? Przepadła.
  • Brak pamięci między sesjami. Zamknij sesję, stracisz kontekst. Każda rozmowa zaczyna się od zera.
  • Jedna strategia—bierz albo nie. Chcesz assembly oparte na RAG? Rozgałęzianie rozmów? Własne budżety tokenów? Nie ma czystego sposobu.

Ludzie sobie radzili—monkey-patching wewnętrznych mechanizmów, forkowanie rdzenia, opakowywanie w zewnętrzną orkiestrację. Nic z tego nie było trwałe.

ContextEngine: plugin slot do zarządzania kontekstem

Wersja 2026.3.7 bierze cały cykl życia kontekstu, wyciąga go do dobrze zdefiniowanego interfejsu i udostępnia jako plugin slot. Napisz plugin, zaimplementuj interfejs i zarządzanie kontekstem należy do ciebie.

Jak to działa

Rejestrujesz swój engine przez plugin API:

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

Wybierasz go w konfiguracji:

yaml
plugins:
  slots:
    contextEngine: my-engine

Nie skonfigurowano żadnego pluginu? OpenClaw owija stare zachowanie w LegacyContextEngine. Dla dotychczasowych użytkowników nic się nie zmienia.

Siedem lifecycle hooks

Interfejs daje ci siedem hooków—po jednym na każdy etap, który ma znaczenie w turze rozmowy:

1. `bootstrap()`

Engine startuje. Połącz się z vector DB, zbuduj graf, załaduj zapisany stan.

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

2. `ingest(message: Message)`

Przychodzi nowa wiadomość—dane wejściowe użytkownika, odpowiedź asystenta, wynik narzędzia. Ty decydujesz, jak ją przechować i zaindeksować.

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

Ten najważniejszy. Przed każdym wywołaniem modelu OpenClaw daje ci budżet tokenów i mówi: zbuduj mi kontekst. To, co zwrócisz, jest dokładnie tym, co model zobaczy.

Różne engine'y, radykalnie różne strategie:

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

Kontekst przekroczył twardy limit tokenów. Czas odchudzić. Domyślny engine streszcza stare wiadomości. Twój plugin może przycinać węzły grafu, przenosić dane do vector store albo w ogóle to pominąć, jeśli assemble() i tak mieści się w budżecie.

5. `afterTurn(turn: Turn)`

Pełna tura zakończona—użytkownik powiedział, agent odpowiedział. Dobry moment, żeby zapisać stan, zaktualizować indeksy albo odpalić zadania w tle.

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

Agent spawnuje subagenta. Ile kontekstu dostaje dziecko? Wszystko wysadzi mu budżet tokenów. Nic zostawi go na ślepo. Ten hook pozwala precyzyjnie kontrolować, co trafia do subagenta.

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

Subagent skończył. Jego wyniki muszą jakoś wrócić do kontekstu rodzica—zmergować wszystko, streścić, wybrać najważniejsze. Twoja decyzja.

Architektura: Sloty vs. Hooki

ContextEngine to slot, nie hook. Hooki są addytywne—dziesięć pluginów może nasłuchiwać onMessage jednocześnie. Sloty są ekskluzywne. Jeden ContextEngine na raz.

┌─────────────────────────────────────┐
│           Plugin Registry           │
│                                     │
│  Hooki (addytywne):                 │
│    onMessage  → [plugin1, plugin2]  │
│    onTool     → [plugin3]           │
│                                     │
│  Sloty (ekskluzywne):               │
│    contextEngine → my-engine        │
│    (domyślny: LegacyContextEngine)  │
└─────────────────────────────────────┘

Przy starcie OpenClaw odczytuje plugins.slots.contextEngine, szuka zarejestrowanej fabryki i tworzy instancję. Jeśli engine nie istnieje, start kończy się błędem. Głośno i wyraźnie. Żadnego cichego fallbacku—to świadoma decyzja. Musisz wiedzieć, na jakim context engine pracujesz.

Izolacja subagentów wykorzystuje AsyncLocalStorage: każde dziecko dostaje własny, wyizolowany runtime. Stan pluginu nie przecieka przez granice agentów.

Co ludzie już budują

Lossless-Claw

GitHub · Martian Engineering

Pierwszy poważny plugin ContextEngine. Zastępuje sliding-window compaction systemem streszczania opartym na DAG, który zachowuje każdą oryginalną wiadomość, jednocześnie mieszcząc się w limicie tokenów.

  • Każda wiadomość staje się węzłem w skierowanym grafie acyklicznym
  • Węzły grupują się w "epizody" według tematu
  • Przekroczony budżet? Stare epizody zostają streszczone, ale oryginały pozostają w grafie
  • Jeśli późniejsza tura odwołuje się do starszej treści, engine wyciąga oryginał—nie streszczenie

Jeśli kiedykolwiek twój agent programistyczny zapomniał funkcję, którą sam napisał godzinę temu—to jest na to rozwiązanie.

MemOS Cloud Plugin

GitHub · MemTensor

Robi jedną rzecz: daje twojemu agentowi pamięć, która przetrwa między sesjami.

  • W bootstrap(): pobiera istotne wspomnienia z MemOS Cloud na podstawie pierwszej wiadomości
  • W afterTurn(): zapisuje nowe tury do chmury
  • W assemble(): wstrzykuje przywołane wspomnienia do kontekstu systemowego

Twój agent pamięta rozmowę z zeszłego tygodnia, twoje preferencje, twoje projekty. Przestajesz się powtarzać.

Co dalej

Na podstawie GitHub issues i Discorda ludzie pracują nad:

  • RAG-native assembly: Pomiń historię wiadomości, buduj kontekst z pobranych fragmentów dokumentów. OpenClaw jako konwersacyjna wyszukiwarka.
  • Współdzielona pamięć multi-agent: Wielu agentów współdzielących graf wiedzy. Wspólne workflow bez redundantnego kontekstu.
  • Optymalizacja budżetu tokenów: Dynamiczne dostrajanie kompozycji kontekstu w zależności od modelu—jego ceny, mocnych stron, długości kontekstu.
  • Rozgałęzianie rozmów: Kontekst o strukturze drzewa. Eksploruj różne ścieżki, wracaj, zachowuj wszystko.

Dlaczego to zmienia zasady gry

OpenClaw zawsze mógł dodawać kanały, modele i narzędzia. Ale kontekst—to, jak agent faktycznie myśli—był zamknięty w rdzeniu. Nie dało się go ruszyć bez forkowania.

ContextEngine to otwiera. A kiedy już jest otwarte, zaczyna się efekt kuli śnieżnej:

  1. 1.Twórcy pluginów mogą wreszcie konkurować na najtrudniejszym problemie w agent UX: jakości kontekstu.
  2. 2.Użytkownicy korporacyjni dostają kontrolę compliance—redakcja przed wysłaniem do modelu, egzekwowanie retencji, audyt każdego prompta.
  3. 3.Badacze mogą testować nowe strategie kontekstowe bez utrzymywania forka.
  4. 4.Dostawcy modeli mogą dostarczać pluginy dostrojone do swoich architektur. Modele z długim kontekstem i modele z krótkim kontekstem nie powinny stosować tej samej strategii.

Tak właśnie wygląda framework, który naprawdę staje się platformą. Nie rebrand. Nie post na blogu ogłaszający "wizję." Konkretna zmiana architektoniczna, która sprawia, że ekosystem sam się wzmacnia. Więcej pluginów → więcej użytkowników → więcej developerów → więcej pluginów. Kiedy ta pętla się rozkręci, trudno ją zatrzymać.

Homar właśnie zapuścił nową szczypcę.

Bądź na bieżąco

Otrzymuj informacje o nowych funkcjach i integracjach. Bez spamu, wypisanie w każdej chwili.