LLM-Kontextkomprimierung für lang laufende KI-Agenten

Ein Agent, der einen einzelnen Prompt beantwortet, erreicht das Kontextfenster selten. Ein Agent, der drei Wochen lang ein Support-Gespräch führt, rund um die Uhr eine Queue verarbeitet oder eine Aufgabe mit vierzig Schritten erledigt, schon. Der Gesprächsverlauf wächst stetig, jedes KI-Modell hat ein festes Token-Limit, und wenn eine Sitzung es überschreitet, lehnt der Provider den Aufruf ab. Der Run scheitert dann mitten in der Aufgabe.

Das harte Limit ist nur die Hälfte des Problems. Die KI-Modell-Qualität sinkt deutlich, bevor das Kontextfenster voll ist. Chromas Context-Rot-Studie (2025) evaluierte 18 führende KI-Modelle und stellte fest, dass die Output-Qualität mit zunehmender Input-Länge selbst bei einfachen Aufgaben abnimmt. Zuvor zeigte Lost in the Middle (Liu et al., 2023), dass KI-Modelle Informationen am zuverlässigsten am Anfang und Ende eines Prompts abrufen; bei Informationen in der Mitte fällt die Genauigkeit deutlich ab. Ein überladener Kontext erhöht das Fehlerrisiko und verschlechtert die Antworten.

Warum lang laufende Agenten das Kontextlimit erreichen

Das Kontextfenster eines Agenten füllt sich durch:

Weiterführende Quellen: Chromas Context-Rot-Studie (2025), Lost in the Middle (Liu et al., 2023).

Kürzen, gleitende Fenster und Zusammenfassen

Es gibt drei gängige Wege, einen LLM-Kontext zu begrenzen. Ihre Fehlerbilder unterscheiden sich deutlich:

Unsere Plattform nutzt LLM-Zusammenfassungen mit Aufbewahrungsregeln, die die Fehlerbilder der beiden anderen Ansätze vermeiden.

Wie Connic den Kontext komprimiert

Standardmäßig löst genau der Fehler die Komprimierung aus, an dem der Ablauf sonst scheitern würde: ein Kontextlimit-Fehler des Providers.

Wenn ein KI-Modell-Aufruf fehlschlägt, klassifiziert der Runner den Fehler. Er erkennt Fehler am Kontextfenster über mehrere Provider hinweg und ignoriert Rate-Limit- und Quota-Fehler ausdrücklich, sodass die Komprimierung nur bei einem tatsächlichen Überlauf ausgelöst wird. Anschließend komprimiert er den Request und wiederholt den Aufruf einmal innerhalb desselben Runs. Der Nutzer sieht keinen fehlgeschlagenen Run, und keine Arbeit geht verloren. Überschreitet auch der wiederholte Aufruf das Kontextfenster, schlägt der Run mit dem ursprünglichen Fehler fehl.

Was erhalten bleibt und was zusammengefasst wird

Die neuesten Nachrichten bleiben unverändert: keep_recent_messages, standardmäßig 8. Die Grenze wird anschließend nach hinten verschoben, damit ein Tool-Ergebnis nie von dem Aufruf getrennt wird, der es erzeugt hat. Eine solche Trennung würde bei vielen Providern zu einem fehlerhaften Request führen.

Alles Ältere wird von einem LLM unter klaren Vorgaben zusammengefasst. Ziele, Einschränkungen, Entscheidungen, Tool-Namen und -Argumente, Tool-Ergebnisse, IDs, Zahlen, Fehler, offene Fragen und nächste Schritte müssen erhalten bleiben; neue Informationen dürfen nicht hinzukommen. Ein für einen Durchlauf zu langer Verlauf wird in Abschnitte mit 12.000 Zeichen geteilt. Anschließend werden die einzelnen Zusammenfassungen zu einer gemeinsamen Zusammenfassung für die weitere Bearbeitung zusammengeführt.

Das Ergebnis wird als einzelne Nachricht eingefügt und erklärt dem KI-Modell den neuen Zustand: Der frühere Verlauf wurde komprimiert, und die erhaltenen neuen Nachrichten sind für den aktuellen Gesprächsschritt maßgeblich. Das KI-Modell setzt die Aufgabe fort, statt einen Neustart zu halluzinieren.

Übergroße Tool-Ergebnisse

Die Komprimierung erfasst auch den größten einzelnen Platzverbraucher. Bei der Ausführung werden übergroße Tool-Antworten direkt innerhalb der beibehaltenen Nachrichten zusammengefasst und durch einen kompakten Datensatz aus Zusammenfassung und Originalgröße ersetzt. Aus einem umfangreichen JSON-Payload wird ein Absatz, während der Agent die daraus extrahierten Fakten behält.

Vor dem Fehler komprimieren: Token-Budgets

Wenn erst der Provider den Überlauf meldet, fällt pro Komprimierung ein fehlgeschlagener Aufruf an. Mit max_prompt_tokens komprimiert der Runner stattdessen vorausschauend: Er zeichnet nach jedem Aufruf die vom KI-Modell gemeldete Anzahl der Prompt-Tokens auf. Erreicht der letzte Aufruf das Budget, komprimiert er vor dem Senden des nächsten. Fehler und unnötige Aufrufe entfallen. Da Connic Bring Your Own Key unterstützt, erscheinen kleinere Prompts direkt als geringere Input-Kosten auf der Provider-Rechnung.

Ein günstigeres KI-Modell für Zusammenfassungen

Zusammenfassungen benötigen nicht das leistungsfähigste KI-Modell des Agenten. Über context_compression.model lassen sie sich auf einem kleinen, schnellen KI-Modell ausführen, während der Agent bei seinem konfigurierten KI-Modell bleibt. Ohne diese Angabe verwenden Zusammenfassungen das KI-Modell des Agenten. Der wiederholte Agentenaufruf verwendet in beiden Fällen das ursprünglich für den Agenten konfigurierte KI-Modell.

Konfiguration in YAML

Die Kontextkomprimierung ist für jeden LLM-Agenten Teil der Agenten-YAML. Eine vollständige Konfiguration für einen Session-basierten Chat-Agenten sieht so aus:

version: "1.0"

name: support-bot
type: llm
model: connic/gpt-5.6-terra
description: "A support chatbot that remembers conversation history"
system_prompt: |
  You are a helpful support agent. Use the conversation history
  to provide contextual responses.

# Persistent sessions keyed by chat ID
session:
  key: context.chat_id
  ttl: 86400

# Keep long conversations within the model context window
context_compression:
  enabled: true
  # Optional model for compression summaries; defaults to the agent model
  model: connic/gpt-5.6-luna
  keep_recent_messages: 12
  # Optional early compression based on model-reported prompt usage
  max_prompt_tokens: 100000
  # Optional compaction for stored session history between runs
  session_history:
    interval: 4
    keep_recent_runs: 1

Nur der Block selbst ist erforderlich. Ein context_compression mit enabled: true aktiviert die fehlergesteuerte Komprimierung mit den Standardwerten. Alle weiteren Optionen dienen der Feinabstimmung.

Gespeicherte Sitzungsverläufe komprimieren

Die Komprimierung innerhalb eines Requests bestimmt, was ein einzelner KI-Modell-Aufruf sieht. Sitzungsbasierte Agenten haben ein zweites Wachstumsproblem: den zwischen Runs gespeicherten Verlauf. Der session_history-Block komprimiert ihn. Nach jeweils interval Runs wird der ältere gespeicherte Verlauf durch eine Zusammenfassung ersetzt, während die neuesten keep_recent_runs Runs unverändert bleiben. Eine seit Monaten aktive Sitzung startet jeden neuen Run mit einer kompakten Zusammenfassung und den jüngsten Gesprächsschritten statt mit dem gesamten Verlauf.

Jede Komprimierung ist ein Trace-Span

Die Komprimierung verändert den Kontext des Agenten und muss daher nachvollziehbar bleiben. Jede Komprimierung wird im Run als OpenTelemetry-Trace-Span erfasst:

Die Komprimierung innerhalb eines Requests erscheint als context_compression-Span, die Komprimierung des gespeicherten Verlaufs als history_compression. Beide schreiben außerdem Logzeilen in den Run. Die Observability-Dokumentation enthält Details zu Traces; der Leitfaden zur Agenten-Observability bietet einen größeren Überblick.

Erste Schritte

Die Kontextkomprimierung lässt sich in wenigen Minuten zu einem bestehenden LLM-Agenten hinzufügen:

• 1.Einen context_compression Block zur YAML-Konfiguration des Agenten hinzufügen
• 2.Agenten bereitstellen. Die Komprimierung wird beim nächsten Run ohne Codeänderungen aktiv
• 3.Im Tab Traces die context_compression Spans beobachten, wenn lange Sitzungen das Kontextfenster erreichen
• 4.keep_recent_messages anpassen, ein Token-Budget ergänzen oder für Zusammenfassungen anhand der Trace-Daten zu einem günstigeren KI-Modell wechseln

Die vollständige Optionsreferenz einschließlich Sessions und Verlaufskomprimierung steht in der Dokumentation zu Runtime-Kontrollen. Für Teams, die Connic erstmals einsetzen, zeigt der Quickstart, wie ein erster Agent mit dauerhaftem Speicher bereitgestellt wird.