Как я опроверг свой собственный баг-репорт: отладка OpenClaw Telegram через прокси apiRoot

Параметр apiRoot в OpenClaw для Telegram может быть указан на локальный прокси, чтобы захватывать фактические передаваемые данные, что позволяет отличить реальные баги повторной вставки от артефактов клиентского отображения. Один разработчик использовал это, чтобы доказать, что его собственный баг-репорт был неверен — и отозвать его.

Сага с баг-репортом

На прошлой неделе главный агент начал отказываться выполнять инструкции, утверждая, что сообщения содержат внедрённый системный блок. Пользователь подал issue #137927. Оказалось, что внутренний runtime-контекст OpenClaw просачивался в видимый текст сообщения, и это выглядело как инъекция. Проблема была закрыта после объединения трёх исправлений, но мейнтейнеры отметили, что эти исправления не устраняли симптом «полный блок вставлен в чистый текст», о котором сообщал пользователь. Шесть смежных проблем остались открытыми.

Почему доказательства были слабыми

Когда пользователь повторно протестировал, удалив HTML и скопировав чистый текст, разделители появились снова. Один комментатор указал, что это может быть четыре разных вещи: повторение моделью, загрязнение повтором, отображение клиентом или фактическая повторная вставка каналом. Доказательства пользователя — текст, вставленный из чат-клиента — не могли этого различить. Никто в одиннадцати ветках не захватил фактическую передаваемую полезную нагрузку.

Захват передаваемых данных

Конфигурация Telegram в OpenClaw имеет параметр apiRoot для каждого аккаунта. Указав его на локальный логирующий прокси, вы заставите вызовы API этого аккаунта проходить через прокси вместо Telegram. Шаги:

• Создайте одноразового бота через BotFather.
• Добавьте его как второй аккаунт Telegram в конфигурации, привязанный к тому же агенту.
• Установите только для этого аккаунта apiRoot на локальный логирующий прокси.
• Прокси логирует тело запроса, пересылает его на api.telegram.org, возвращает ответ.
• Рабочие аккаунты сохраняют реальные токены и стандартный apiRoot — ничего больше не маршрутизируется через прокси.

Около 120 строк на Python из стандартной библиотеки достаточно для прокси.

Результаты

Тест первый: Обычная проза без разделителей. Передаваемые данные были полностью чистыми. Но ответ агента упоминал, что его вход прибыл с полным блоком runtime-контекста, добавленным в конец — значит, блок достигает модели даже когда исходящие данные чисты.

Тест второй: Пользователь отправил текст без преамбулы. Передаваемые данные показали <<<BEGIN_OPENCLAW_INTERNAL_CONTEXT>>> (HTML-экранировано), но то, что скопировали, было буквальным <<<BEGIN\_OPENCLAW\_INTERNAL\_CONTEXT>>>. Буквальный разделитель никогда не передавался — агент процитировал его, описывая блок, OpenClaw экранировал HTML (parse_mode = HTML), Telegram отрендерил его обратно в буквальную строку, и копирование дало неэкранированную версию.

Вывод

Любая расшифровка, вставленная в баг-репорт, уже прошла через рендеринг и копирование — она не может доказать передачу против цитирования. Некоторые отчёты основаны на таких слабых доказательствах. Этот метод отладки более надёжен. Кроме того, читая исправления, пользователь нашёл кое-что хуже — отдельную архитектурную проблему, которую планирует сообщить отдельно.