Cómo demostré que mi propio informe de error era incorrecto: Depuración de OpenClaw Telegram mediante el proxy apiRoot

El apiRoot de Telegram en OpenClaw se puede configurar por cuenta para apuntar a un proxy local y capturar las cargas útiles reales del cable, lo que permite distinguir entre bugs reales de reinserción y artefactos de renderizado del lado del cliente. Un desarrollador usó esto para demostrar que su propio informe de error era incorrecto y retirarlo.

La saga del informe de error

La semana pasada, un agente principal comenzó a rechazar instrucciones, alegando que los mensajes contenían un bloque de sistema inyectado. El usuario presentó el issue #137927. Resultó que el contexto de ejecución interna de OpenClaw se estaba filtrando al texto visible del mensaje, pareciendo una inyección. El issue se cerró después de que se fusionaron tres correcciones, pero los mantenedores notaron que las correcciones no resolvieron el síntoma de "bloque completo reinsertado en texto limpio" que reportó el usuario. Seis issues hermanos permanecían abiertos.

Por qué la evidencia era débil

Cuando el usuario volvió a probar eliminando el HTML y copiando el texto limpio, los delimitadores reaparecieron. Un comentarista señaló que esto podía deberse a cuatro cosas diferentes: eco del modelo, contaminación por reproducción, renderizado del cliente o reinserción real del canal. La evidencia del usuario — texto pegado desde un cliente de chat — no podía distinguir entre estas. Nadie en once hilos había capturado la carga útil real transmitida.

Capturando la carga útil del cable

La configuración de Telegram en OpenClaw tiene un apiRoot por cuenta. Apuntarlo a un proxy de registro local hace que las llamadas a la API de esa cuenta pasen por el proxy en lugar de por Telegram. Pasos:

• Crea un bot desechable desde BotFather.
• Agrégalo como segunda cuenta de Telegram en la configuración, vinculado al mismo agente.
• Establece el apiRoot solo de esa cuenta a un proxy de registro local.
• El proxy registra el cuerpo de la solicitud, lo envía a api.telegram.org y devuelve la respuesta.
• Las cuentas de producción mantienen tokens reales y el apiRoot predeterminado — nada más pasa por él.

Alrededor de 120 líneas del stdlib de Python son suficientes para el proxy.

Los resultados

Prueba uno: Prosa simple sin delimitadores. La carga útil del cable estaba completamente limpia. Pero la respuesta del agente mencionaba que su entrada llegó con el bloque de contexto completo adjunto — así que el bloque llega al modelo incluso cuando la salida es limpia.

Prueba dos: El usuario envió el texto de preámbulo sin etiquetas. La carga útil mostró <<<BEGIN_OPENCLAW_INTERNAL_CONTEXT>>> (escapado HTML), pero lo que se copió fue la cadena literal <<<BEGIN\_OPENCLAW\_INTERNAL\_CONTEXT>>>. El delimitador literal nunca se transmitió — el agente lo citó mientras describía el bloque, OpenClaw lo escapó HTML (parse_mode es HTML), Telegram lo renderizó de vuelta a la cadena literal, y al copiar se obtuvo la versión sin escapar.

La conclusión

Cualquier transcripción pegada en un informe de error ya ha pasado por renderizado y copiado — no puede probar transmisión vs. cita. Varios informes se basan en evidencia tan débil. Este método de depuración es más confiable. Además, mientras leía las correcciones, el usuario encontró algo peor — un problema arquitectónico separado — que planea informar por separado.