私自身のバグ報告が誤りだと証明した方法：apiRootプロキシ経由でのOpenClaw Telegramデバッグ

OpenClawのTelegram apiRoot設定はアカウントごとにローカルプロキシを向けることができ、実際のワイヤーペイロードをキャプチャできます。これにより、実際の再挿入バグとクライアント側のレンダリングによる見かけ上の問題を区別できます。ある開発者はこれを使って自身のバグ報告が誤りであることを証明し、取り下げました。

バグ報告の顛末

先週、メインエージェントが指示を拒否し、メッセージにインジェクションされたシステムブロックが含まれていると主張しました。ユーザーはissue #137927を報告しました。実際にはOpenClawの内部ランタイムコンテキストが表示メッセージに漏れ出し、インジェクションのように見えていたのです。3つの修正がマージされた後、この問題はクローズされましたが、メンテナーは修正がユーザーが報告した「クリーンなテキストに完全なブロックが再挿入される」症状を解決していないと指摘しました。関連する6つの問題が未解決のままでした。

証拠が不十分だった理由

ユーザーがHTMLを除去してクリーンなテキストをコピーして再テストしたとき、デリミタが再現しました。コメント投稿者は、これは4つの異なる原因（モデルのエコー、再生汚染、クライアントのレンダリング、実際のチャンネル再挿入）のいずれかである可能性があると指摘しました。ユーザーの証拠（チャットクライアントから貼り付けたテキスト）ではこれらを区別できませんでした。11のスレッドの誰も実際に送信されたペイロードをキャプチャしていませんでした。

ワイヤーペイロードのキャプチャ

OpenClawのTelegram設定にはアカウントごとのapiRootがあります。これをローカルロギングプロキシに向けると、そのアカウントのAPI呼び出しはTelegramではなくプロキシを経由します。手順は以下の通りです。

• BotFatherから使い捨てボットを作成します。
• 設定で2番目のTelegramアカウントとして追加し、同じエージェントにバインドします。
• そのアカウントのapiRootのみをローカルロギングプロキシに設定します。
• プロキシはリクエストボディをログし、api.telegram.orgに転送し、レスポンスを返します。
• 本番アカウントは実際のトークンとデフォルトのapiRootを保持し、他のトラフィックはそれを経由しません。

プロキシには標準ライブラリのPythonで約120行あれば十分です。

結果

テスト1: デリミタのないプレーンプローズ。ワイヤーペイロードは完全にクリーンでした。しかし、エージェントの応答は、入力に完全なランタイムコンテキストブロックが付属していたと述べました。つまり、送信がクリーンでもブロックはモデルに到達します。

テスト2: ユーザーはストリップされた前文テキストを送信しました。ワイヤーペイロードには<<<BEGIN_OPENCLAW_INTERNAL_CONTEXT>>>（HTMLエスケープ済み）が表示されましたが、コピーされたのはリテラル<<<BEGIN\_OPENCLAW\_INTERNAL\_CONTEXT>>>でした。リテラルデリミタは送信されませんでした。エージェントがブロックを説明する際に引用し、OpenClawがHTMLエスケープし（parse_modeはHTML）、Telegramがそれをリテラル文字列にレンダリングし、コピーでエスケープ解除されたバージョンが得られました。

教訓

バグ報告に貼り付けるトランスクリプトはすでにレンダリングとコピーを経ているため、送信と引用を区別できません。いくつかの報告はそのような弱い証拠に依存しています。このデバッグ方法はより信頼性があります。また、修正を読んでいる間、ユーザーはさらに悪い別のアーキテクチャ上の問題を発見し、別途報告する予定です。