openclaw20260213 ya tiene 188k stars, pero sigue siendo demasiado nuevo y con demasiados problemas; increíble que ni la compresión de contexto esté bien hecha: un registro de depuración difícil

AIDO debug
, ,
1

openclaw20260213 ya tiene 188k estrellas, pero sigue siendo demasiado nuevo y tiene demasiados problemas: increíble que ni siquiera la compresión de contexto esté bien hecha — un registro de depuración difícil

Autor: 三局两胜
Fecha: 2026-02-13

Este es un registro completo de depuración que he “masticado a la fuerza” estos dos días junto con el bot. Pongo la conclusión primero:

  • La “respuesta vacía” no significa que el modelo no esté disponible, ni es un fallo de punto único del plugin de QQ.
  • La causa raíz es que, tras una expansión fuera de control del contexto de la sesión, se activó un silent overflow (output=0).
  • La versión actual de OpenClaw, en este escenario, efectivamente tiene el problema de “sin aviso, sin recuperación automática” (ya hay issue/PR oficiales).

I. Síntomas del fallo (mi situación real)

En mi caso ocurrió lo siguiente:

  1. En el grupo de QQ el bot de repente empezó a dar “respuestas vacías” (parece que no responde, o solo registra el turn del assistant pero el contenido está vacío).
  2. En TG, en el mismo periodo, parecía normal, lo que generó la falsa impresión de “¿se habrá roto el plugin de QQ?”.
  3. En el WebUI se veía que la sesión seguía escribiendo logs, pero del lado del usuario no había texto efectivo.

Al principio la investigación fue muy caótica, porque en el mismo intervalo también se mezclaban:

  • Problemas de la cadena de envío de archivos (NapCat rich media)
  • Lógica de palabras disparadoras/menciones (@)
  • Configuración de administrador y lista negra

Estos problemas se interfieren entre sí en la observación, haciendo que la causa raíz de la “respuesta vacía” no sea fácil de captar de inmediato.

II. Ruta de investigación (en orden cronológico)

1) Confirmar primero que no es que el API esté totalmente caído

  • Primero verifiqué que el API upstream (newapi/cpa) funcionaba en otros clientes.
  • Luego miré el log de sesión local de OpenClaw y descubrí que no era un fallo de petición, sino que aparecía el típico registro:
    • usage.input extremadamente grande (nivel 200k~300k)
    • usage.output = 0
    • content = []

Este paso es clave: demuestra que no es “no se pudo enviar”, sino “el lado del modelo devolvió salida vacía”.

2) Comparar el volumen de las sesiones de QQ y TG

Saqué los archivos de sesión clave para revisarlos:

  • Sesión del grupo de QQ: cb77ecdc-6d64-489f-8aa1-d63a92d67ce7.jsonl
  • Sesión de chat privado en TG: 9c1c29b4-b309-4b71-a1bd-5a7fd8541679.jsonl

El resultado fue muy evidente:

  • El historial de la sesión de QQ era enorme, y varias veces apareció input≈260k~282k.
  • En el mismo periodo, en TG era aprox. input≈36k~38k, y las respuestas eran normales.

3) Localizar con precisión “en qué momento se disparó la expansión”

En la sesión del grupo de QQ, el punto de inflexión de la expansión correspondió a una “tarea de búsqueda”:

  • Se escribieron de forma continua múltiples toolResult súper largos (SearchResults)
  • Cada uno tenía decenas de KB (por ejemplo 48k / 38k / 24k)
  • Después, los tokens de entrada saltaron de inmediato a 282k y aparecieron respuestas vacías consecutivas

Es decir, no fue una frase normal del usuario la que reventó el contexto, sino que los resultados de herramienta se escribieron completos en la sesión, empujando una sesión ya grande por encima del punto crítico.

4) Verificar “si la búsqueda de TG entra al contexto”

Hice a propósito una comparación:

  • En TG también se escribe toolResult (también entra al contexto)
  • Pero la base del tamaño de la sesión de TG es menor, así que no explotó de inmediato

Este paso rompió un malentendido:

  • No es “TG no entra al contexto y QQ sí”
  • Sino “en ambos entra; quien llegue antes al límite explota antes”

5) Hacer un experimento forzado (probar que no es una ilusión)

Hice dos rondas de experimentos:

  • Primero cambié el apuntado de sesión (TG apuntando a la sesión de QQ)
  • Luego hice un experimento de sobrescritura a nivel de archivo (copiar el contenido de la gran sesión de QQ al archivo de sesión de TG)

Al final confirmé: en cuanto haces que TG “se coma” ese historial gigantesco, también aparecen respuestas vacías. Esta verificación afianzó aún más la causa raíz.

III. Conclusión final de la causa raíz

La causa raíz se puede resumir en tres frases:

  1. Historial de sesión demasiado grande (especialmente al incluir mucho contenido toolResult/raw de búsquedas).
  2. Cuando la petición alcanza/supera la ventana de contexto efectiva del modelo, devuelve stopReason=length + output=0.
  3. En la rama actual de OpenClaw para este “silent overflow”, la estrategia de recuperación es insuficiente; del lado del usuario se percibe como “el bot parece muerto y solo responde vacío”.

IV. Por qué este problema se siente tan mal

Porque tiene tres puntos “contraintuitivos”:

  • No es un error explícito: muchas veces no lanza un error evidente, sino que “parece terminar con éxito pero sin contenido”.
  • No se reproduce de inmediato: a menudo se activa de golpe tras acumular una conversación larga.
  • No es exclusivo de una plataforma: QQ/TG pueden verse afectados; solo depende del tamaño de la sesión cuál explota primero.

V. Mis soluciones temporales para cortar la hemorragia (aplicables)

  1. Si aparece respuesta vacía, primero usa /newsession o cambia a una tecla de nueva sesión, no forces conversación dentro de una sesión ya inflada.
  2. Reducir la entrada a la base de datos de grandes bloques de texto original de herramientas, especialmente resultados de búsqueda y cuerpos largos de páginas web.
  3. Hacer la alerta de “contexto demasiado pesado” en la capa del plugin (por ejemplo, si el input supera un umbral, avisar para reabrir sesión).
  4. En escenarios de grupo, se recomienda usar un “grupo pequeño de pruebas (grupo de dos)” para observación operativa, facilitando confirmar rápidamente el estado del bot.

VI. Estado oficial: ya hay Issue/PR, pero sigue en reparación

1) Issue oficial (problemas similares)

2) PR de corrección correspondiente (idea central)

La idea clave de este PR es:

  • Identificar esta rama de “silent overflow”
  • Incluirla en overflow recovery (disparar compaction/retry), en vez de tratarla como finalización normal

Creo que este enfoque es correcto; al menos es mucho más fiable que “que el usuario borre manualmente el archivo de sesión”.

VII. Cambios adicionales relacionados que yo implementé (lado del plugin)

Durante esta depuración, también aterricé una tanda de correcciones de soporte (para evitar mezclar otros problemas):

  • Arreglar el aislamiento de la clave de sesión entre chat privado/grupal de QQ, evitando cruces entre canales.
  • Convertir /newsession de “comando superficial” a “borrado real de sesión”.
  • Añadir un aviso de respaldo ante respuesta vacía, evitando que el usuario lo perciba como desconexión total.
  • Arreglar la superposición repetida del sufijo de ocupado (evitar 昵称(输入中)(输入中)).

Pero hay que enfatizar: esto solo mejora la experiencia; el verdadero “silent overflow de contexto súper grande” sigue necesitando tratamiento a nivel de núcleo.

VIII. Consejos para los que vengan después

Si tú también te encuentras con “los logs parecen correr, pero todo es respuesta vacía”:

  1. Primero revisa el usage.input/output de la sesión correspondiente.
  2. Si ves output=0 y el input es enorme, sospecha primero de desbordamiento de contexto.
  3. Abre inmediatamente una sesión nueva para verificar; no pruebes una y otra vez en la sesión vieja.
  4. Revisa si estás escribiendo sin recorte grandes toolResult (búsqueda/web) dentro de la sesión.
  5. Sigue el progreso de merge oficial de #14064 / #14157.

Esta vez sí fue una depuración “muy dura pero que valió la pena”.
OpenClaw es muy potente, pero también sigue siendo muy nuevo; usarlo mientras se parchea es lo normal.
Espero que este registro ayude a los siguientes a evitar rodeos.

— 三局两胜