Wenn der Context voll ist — strategisch vergessen

Warum Komprimierung nötig ist

Je länger ein Agent läuft, desto größer wird messages[]: jedes read_file bringt tausende Token, jedes bash hunderte, jede Antwort hat Denk-Text des Modells. Nach 50 Runden kann der Context 100K+ Token erreichen. Zwei Folgen:

• Limit-Erreichen: Bei Fenstergröße Absturz, oder jeder API-Aufruf kostet linear mehr.
• Aufmerksamkeitsverdünnung: Die aktuelle Aufgabe ertrinkt in irrelevanten tool_results von vor 30 Runden.

s06-Ansatz: Der Agent vergisst unwichtige Inhalte aktiv, behält aber kritischen Zustand. Drei Schichten, von leicht bis schwer.

Schicht 1 · micro_compact (jede Runde still)

Die günstigste Schicht. Vor jedem LLM-Aufruf wird ausgeführt: alte tool_results außer den letzten 3 werden durch Platzhalter ersetzt:

# Ab Runde 10 werden die meisten tool_results zu:
{
  "type": "tool_result",
  "tool_use_id": "toolu_01A",
  "content": "[Previous: used bash]"   # von Tausenden auf wenige Zeichen
}

Ausnahme: read_file-Ergebnisse werden nie komprimiert. Warum? Read-Ausgaben sind Referenzmaterial — komprimiert müsste das Modell erneut lesen, was teurer wäre.

PRESERVE_RESULT_TOOLS = {"read_file"}  # niemals komprimieren

micro_compact beim Altern alter Ergebnisse beobachten

Die Simulation zeigt 10 Interaktionsrunden Schritt für Schritt, mit micro_compact vor jeder Runde. Beobachte wie alte tool_results zu [Previous: ...] werden, während die letzten 3 vollständig bleiben.

Schicht 2 · auto_compact (Schwellenwert-Trigger)

Selbst mit laufendem micro_compact kann der Context irgendwann explodieren. s06 setzt einen Schwellenwert (Standard: 50.000 Token):

1. Token schätzen: len(str(messages)) // 4 (grob, aber ausreichend).
2. Schwellenwert überschritten → vollständiges Transcript in .transcripts/transcript_TIMESTAMP.jsonl speichern (Backup).
3. LLM generiert eine Zusammenfassung des Gesprächsverlaufs.
4. messages wird komplett durch einen "[compressed] SUMMARY..."-Eintrag ersetzt.

Der Preis ist deutlich: spezifische Tool-Ausgaben und Gesprächsdetails gehen verloren, nur die Zusammenfassung bleibt. Aber der Agent kann weiterarbeiten — das ist der Kerngewinn.

Schicht 3 · Modell ruft compact selbst auf

auto_compact wird vom Harness ausgelöst, das Modell weiß nichts davon. Schicht 3 dreht das um: Das Modell bekommt ein compact-Tool und kann es aktiv anfordern — wenn es z.B. die vorangegangene Exploration als abgeschlossen betrachtet und eine neue Phase beginnen will.

Modell-Aufruf:

tool_use("compact", focus="keep the API design decisions")

Funktioniert wie auto_compact, akzeptiert aber einen focus-Parameter, der die Zusammenfassung steuert. In der Praxis sehr nützlich — das Modell weiß, welche Phasen "abgeschlossen" sind, besser als eine heuristische Schwelle.

Welche Schicht passt wann?

Entscheide für die folgenden Szenarien: micro / auto / manual?