openclaw20260213 hat schon 188k Sterne, ist aber noch zu neu und hat zu viele Probleme – sogar die Kontextkomprimierung ist nicht richtig gemacht: ein mühsamer Debugging-Bericht

AIDO debug
, ,
1

openclaw20260213 hat bereits 188k Sterne, ist aber immer noch zu neu, zu viele Probleme – ausgerechnet Kontext-Komprimierung nicht sauber gemacht: ein mühsames Debugging-Protokoll

Autor: 三局两胜
Zeit: 2026-02-13

Das hier ist ein vollständiges Debugging-Protokoll, das ich in den letzten zwei Tagen zusammen mit dem Bot mühsam erarbeitet habe. Fazit zuerst:

  • „Leere Antwort“ bedeutet nicht, dass das Modell nicht verfügbar ist, und es ist auch kein Single-Point-Failure des QQ-Plugins.
  • Die Grundursache ist eine außer Kontrolle geratene Aufblähung des Sitzungs-Kontexts, die einen silent overflow (output=0) auslöst.
  • Die aktuelle OpenClaw-Version hat in diesem Szenario tatsächlich das Problem „keine Hinweise, keine automatische Wiederherstellung“ (es gibt bereits ein offizielles Issue/PR).

I. Fehlerbild (die reale Situation, die ich erlebt habe)

Bei mir war es so:

  1. In der QQ-Gruppe begann der Bot plötzlich mit „leeren Antworten“ (sah so aus, als käme gar keine Antwort, oder es wurde nur ein assistant turn geloggt, aber der Inhalt war leer).
  2. Auf TG wirkte es zur gleichen Zeit wieder normal, wodurch die Illusion entstand: „Ist vielleicht das QQ-Plugin kaputt?“
  3. In der WebUI konnte man sehen, dass die Sitzung weiter Logs schrieb, aber auf der Nutzerseite kam kein verwertbarer Text an.

Am Anfang war die Fehlersuche extrem chaotisch, weil im selben Zeitraum auch noch Folgendes dazwischenfunkte:

  • Probleme in der Datei-Sende-Kette (NapCat rich media)
  • Gruppen-Triggerwörter/@-Logik
  • Admin- und Blacklist-Konfiguration

Diese Probleme stören sich gegenseitig in der Beobachtung, sodass die eigentliche Ursache der „leeren Antwort“ nicht sofort zu greifen ist.

II. Analysepfad (chronologisch)

1) Zuerst bestätigen, dass nicht die ganze API down ist

  • Ich habe zuerst verifiziert, dass die Upstream-API (newapi/cpa) in anderen Clients funktioniert.
  • Dann habe ich in die lokalen Sitzungs-Logs von OpenClaw geschaut und festgestellt: Es war kein Request-Fehler, sondern es tauchten typische Einträge auf:
    • usage.input extrem groß (200k–300k)
    • usage.output = 0
    • content = []

Dieser Schritt ist entscheidend: Das bedeutet nicht „kann nicht senden“, sondern „vom Modell kommt leerer Output zurück“.

2) QQ- und TG-Sitzungsgröße vergleichen

Ich habe die relevanten Session-Dateien herausgezogen und angeschaut:

  • QQ-Gruppen-Session: cb77ecdc-6d64-489f-8aa1-d63a92d67ce7.jsonl
  • TG-Privatchat-Session: 9c1c29b4-b309-4b71-a1bd-5a7fd8541679.jsonl

Das Ergebnis war sehr eindeutig:

  • Die QQ-Session-Historie ist sehr groß, und mehrfach tritt input≈260k~282k auf.
  • TG liegt im selben Zeitraum ungefähr bei input≈36k~38k, Antworten sind normal.

3) Exakt finden, „bei welcher Stelle es plötzlich explodiert“

In der QQ-Gruppen-Session entspricht der Aufblähungs-Knickpunkt einer „Suchaufgabe“:

  • Es wurden hintereinander mehrere superlange toolResult (SearchResults) geschrieben
  • Pro Eintrag mehrere zig KB (z. B. 48k / 38k / 24k)
  • Danach sprang die Input-Tokenzahl sofort auf 282k, und es kamen fortlaufend leere Antworten

Heißt: Nicht irgendein normaler Nutzer-Chat hat den Kontext gesprengt, sondern Tool-Ergebnisse wurden vollständig in die Sitzung geschrieben und haben die ohnehin schon große Sitzung über den kritischen Punkt geschoben.

4) Verifizieren, ob „TG-Suche in den Kontext eingeht“

Ich habe bewusst einen Vergleich gemacht:

  • TG schreibt ebenfalls toolResult (geht also auch in den Kontext)
  • Aber TG hat eine kleinere Basis, daher ist es nicht sofort explodiert

Das bricht einen Irrtum:

  • Nicht „TG geht nicht in den Kontext, nur QQ geht rein“
  • Sondern „beide gehen rein – wer zuerst am Limit ist, fliegt zuerst raus“

5) Harte Experimente (beweisen, dass es keine Einbildung ist)

Ich habe zwei Experimente gemacht:

  • Erst die Session-Zuordnung geändert (TG zeigt auf die QQ-Session)
  • Dann ein Datei-Level-Overwrite (den Inhalt der großen QQ-Session in die TG-Session-Datei kopiert)

Am Ende war klar: Sobald TG diese riesige Historie „frisst“, erscheinen auch dort leere Antworten. Das hat die Grundursache weiter erhärtet.

III. Finale Root-Cause-Zusammenfassung

Die Grundursache lässt sich in drei Sätzen zusammenfassen:

  1. Session-Historie ist zu groß (insbesondere mit viel toolResult/raw Suchinhalten).
  2. Wenn der Request das effektive Kontextfenster des Modells erreicht/überschreitet, kommt stopReason=length + output=0 zurück.
  3. Das aktuelle OpenClaw hat im „silent overflow“-Zweig zu wenig Recovery-Strategie – auf Nutzerseite wirkt es wie „Bot ist tot und antwortet leer“.

IV. Warum sich dieses Problem so schlecht anfühlt

Weil es drei „gegenintuitive Punkte“ hat:

  • Kein Fehler: Oft wird kein offensichtlicher Fehler geworfen, sondern es „sieht aus wie erfolgreich beendet, aber ohne Inhalt“.
  • Nicht sofort reproduzierbar: Meist wird es erst nach langer Akkumulation in einer Lang-Session ausgelöst.
  • Nicht plattformspezifisch: QQ/TG können beide betroffen sein; die Reihenfolge hängt nur von der Session-Größe ab.

V. Meine temporären „Blutstillungs“-Maßnahmen (praktikabel)

  1. Bei leerer Antwort zuerst /newsession oder auf einen neuen Session-Key wechseln, nicht in der aufgeblähten Session weiter „hart“ chatten.
  2. Große Tool-Originaltexte weniger in die Historie schreiben, besonders Suchergebnisse und lange Webseiten-Bodytexte.
  3. „Kontext-zu-schwer“-Warnung auf Plugin-Ebene (z. B. bei input > Schwelle Hinweis geben, die Session neu zu starten).
  4. In Gruppen-Szenarien empfiehlt sich eine „Test-Kleingruppe (Zweiergruppe)“ für Ops-Beobachtung, um den Bot-Status schnell zu prüfen.

VI. Offizieller Stand: Issue/PR existieren bereits, Fix ist aber noch in Arbeit

1) Offizielle Issues (ähnliche Probleme)

2) Passender Fix-PR (Kernidee)

Die zentrale Idee dieses PR ist:

  • Den Zweig „silent overflow“ erkennen
  • Ihn in overflow recovery aufnehmen (compaction/retry auslösen), statt ihn als normale Fertigstellung zu behandeln

Ich halte diesen Ansatz für richtig – deutlich zuverlässiger als „User löscht manuell Session-Dateien“.

VII. Weitere Anpassungen, die ich zusätzlich gemacht habe (Plugin-Seite)

Während dieses Debuggings habe ich außerdem eine Reihe begleitender Fixes umgesetzt (um zu vermeiden, dass andere Probleme mit hineinmischen):

  • Isolation der Session-Keys für QQ-Privat/Gruppe gefixt, um Cross-Channel-Vermischung zu verhindern.
  • /newsession von „nur oberflächlicher Befehl“ zu „echtes Session-Clearing“ repariert.
  • Fallback-Hinweis bei leerer Antwort hinzugefügt, damit es für Nutzer nicht wie kompletter Ausfall wirkt.
  • Doppelte Busy-Suffix-Anhäufung gefixt (verhindert 昵称(输入中)(输入中)).

Aber wichtig: Das verbessert nur die UX – das eigentliche „ultragroßer Kontext + silent overflow“ muss weiterhin auf Kernel-/Core-Ebene gelöst werden.

VIII. Empfehlungen für Nachfolger

Wenn du auch „Logs laufen weiter, aber es kommt nur leer“ hast:

  1. Prüfe zuerst usage.input/output der betreffenden Session.
  2. Wenn output=0 und input riesig ist, zuerst Kontext-Overflow vermuten.
  3. Sofort neue Session öffnen zum Gegencheck, nicht in der alten Session ständig erneut versuchen.
  4. Prüfen, ob große toolResult (Suche/Webseiten) ungekürzt in die Session geschrieben werden.
  5. Offizielle Merge-Entwicklung von #14064 / #14157 beobachten.

Das war wirklich ein „sehr mühsames, aber sehr wertvolles“ Debugging.
OpenClaw ist stark, aber eben noch sehr neu – beim Nutzen gleichzeitig nachbessern ist normal.
Ich hoffe, dieses Protokoll hilft Nachfolgenden, Umwege zu vermeiden.

— 三局两胜