OpenClaw: Gemeldeter Streaming-Engpass bei großen Tool-Aufrufen

Der Agent wirkt eingefroren. Kein Fortschritt, kein Fehler: Ein Modell streamt gerade ein großes Tool-Argument, Fragment für Fragment. Wer in diesem Moment sofort beim Provider sucht, übersieht womöglich die eigentliche Ursache — sie kann in der OpenClaw-Laufzeit selbst liegen.

Der Puffer wächst, die Parse-Arbeit noch schneller

Ein OpenClaw-Issue vom 10. August beschreibt den Mechanismus dahinter: Jedes eintreffende Fragment eines Tool-Aufrufs landet im bisherigen Argumentpuffer, und die Laufzeit parst danach jedes Mal den gesamten bis dahin empfangenen JSON-Inhalt erneut.

Bei wenigen Fragmenten fällt das kaum auf. Über N Fragmente hinweg liest die Laufzeit dem Issue zufolge aber 1 + 2 + … + N Pufferabschnitte, und der Aufwand wächst damit quadratisch zur finalen Größe der Argumente. Diese Arbeit läuft auf dem Event-Loop des Agenten. Genau dort blockiert sie ihn — ausgerechnet während des Streamings.

Der Engpass klebt nicht an einem Anbieter. Der betroffene Reducer ist laut Issue transportunabhängig und kann deshalb auf unterschiedlichen Provider-Routen auftauchen, sobald ein Modell große Tool-Argumente in vielen Fragmenten ausgibt.

Provider ausschließen, Runtime prüfen

Erwartbar wäre: Der Agent bleibt während des Streamings ansprechbar. Tatsächlich scheint er genau dann stehen zu bleiben, wenn der Argumentpuffer stark wächst — die zeitliche Korrelation ist für die Diagnose entscheidend. Stimmen Beginn des Stillstands und ein großer, fragmentierter Tool-Aufruf überein, ist der lokale Parse-Pfad mindestens so verdächtig wie der Provider.

Der Patch braucht noch den Grenztest

Der zugehörige Änderungsvorschlag setzt bei der wiederholten Parse-Arbeit im Streaming-Pfad an. Die im Issue dokumentierten Prüfungen zeigen keine offensichtliche Regression im bisherigen Streaming-Verhalten, beantworten aber noch nicht die entscheidende Performancefrage.

Dafür braucht es einen realistischen Grenztest: Derselbe große Tool-Aufruf muss vor der Änderung den Engpass sichtbar machen und danach flüssig durchlaufen. Erst dieser Vorher-nachher-Vergleich zeigt, ob der Patch die relevante Größenordnung trifft — Funktionstests allein belegen nur, dass die Argumente korrekt ankommen.

Mein Urteil: Der technische Mechanismus ist plausibel, der Runtime-Nachweis noch nicht abgeschlossen. Für Plattform- und Betriebsteams folgt daraus eine brauchbare Mindestregel: einen scheinbar hängenden Agenten nicht vorschnell dem Modellanbieter zuschreiben, sondern zuerst prüfen, ob der Stillstand mit einem großen, stark fragmentierten Tool-Argument zusammenfällt.

Ohne Grenztest gibt es weder einen belastbaren Schwellenwert noch einen verifizierten Workaround für den produktiven Betrieb.