Wie ich meinen eigenen Bug-Report widerlegte: OpenClaw-Telegram-Debugging per apiRoot-Proxy

Die apiRoot-Konfiguration von OpenClaw für Telegram kann pro Konto auf einen lokalen Proxy zeigen, um die tatsächlichen Wire-Payloads zu erfassen. So können Sie zwischen echten Wiedereinfügungsfehlern und clientseitigen Rendering-Artefakten unterscheiden. Ein Entwickler nutzte dies, um seinen eigenen Bugreport zu widerlegen – und zog ihn zurück.

Die Saga des Bugreports

Letzte Woche weigerte sich ein Hauptagent, Anweisungen zu befolgen, und behauptete, Nachrichten enthielten einen eingeschleusten Systemblock. Der Benutzer reichte Issue #137927 ein. Es stellte sich heraus, dass der interne Laufzeitkontext von OpenClaw in den sichtbaren Nachrichtentext durchsickerte und wie eine Injektion wirkte. Das Issue wurde geschlossen, nachdem drei Fixes zusammengeführt wurden, aber die Maintainer merkten an, dass die Fixes das vom Benutzer gemeldete Symptom „vollständiger Block erneut in sauberen Text eingefügt“ nicht behoben hatten. Sechs verwandte Issues blieben offen.

Warum die Beweise schwach waren

Als der Benutzer erneut testete, indem er HTML entfernte und den sauberen Text kopierte, erschienen die Begrenzer erneut. Ein Kommentator wies darauf hin, dass dies vier verschiedene Dinge sein könnten: Modell-Echo, Replay-Kontamination, Client-Rendering oder tatsächliche Kanal-Wiedereinfügung. Die Beweise des Benutzers – Text, der aus einem Chat-Client eingefügt wurde – konnten diese nicht unterscheiden. Niemand in elf Threads hatte den tatsächlich übertragenen Payload erfasst.

Erfassen des Wire-Payloads

Die Telegram-Konfiguration von OpenClaw hat ein apiRoot pro Konto. Wenn Sie es auf einen lokalen Protokollierungs-Proxy richten, laufen die API-Aufrufe dieses Kontos über den Proxy statt über Telegram. Schritte:

• Erstellen Sie einen Wegwerf-Bot über BotFather.
• Fügen Sie ihn als zweites Telegram-Konto in der Konfiguration hinzu, gebunden an denselben Agenten.
• Setzen Sie nur das apiRoot dieses Kontos auf einen lokalen Protokollierungs-Proxy.
• Der Proxy protokolliert den Anfragekörper, leitet an api.telegram.org weiter und gibt die Antwort zurück.
• Produktionskonten behalten echte Token und das Standard-apiRoot – nichts anderes läuft darüber.

Etwa 120 Zeilen Python aus der Standardbibliothek reichen für den Proxy aus.

Die Ergebnisse

Test eins: Klare Prosa ohne Begrenzer. Der Wire-Payload war völlig sauber. Aber die Antwort des Agenten erwähnte, dass seine Eingabe mit dem vollständigen Laufzeitkontextblock angekommen war – der Block erreicht das Modell also auch bei sauberem ausgehendem Verkehr.

Test zwei: Der Benutzer sendete den entfernten Präambeltext. Der Wire-Payload zeigte <<<BEGIN_OPENCLAW_INTERNAL_CONTEXT>>> (HTML-escaped), aber was herauskopiert wurde, war das wörtliche <<<BEGIN\_OPENCLAW\_INTERNAL\_CONTEXT>>>. Der wörtliche Begrenzer wurde nie übertragen – der Agent zitierte ihn bei der Beschreibung des Blocks, OpenClaw maskierte ihn mit HTML (parse_mode ist HTML), Telegram rendert ihn zurück zur wörtlichen Zeichenfolge, und das Kopieren ergab die unescaped Version.

Das Fazit

Jedes Transkript, das in einen Bugreport eingefügt wird, hat bereits Rendering und Kopieren durchlaufen – es kann keine Übertragung vs. Zitat beweisen. Mehrere Berichte stützen sich auf solch schwache Beweise. Diese Debugging-Methode erweist sich als zuverlässiger. Außerdem fand der Benutzer beim Lesen der Fixes etwas Schlimmeres – ein separates architektonisches Problem –, das er separat melden will.