OpenClaw Implementa la Compresión del Historial del Agente para Reducir el Uso de Contexto

Problema de Gestión de Contexto

Al ejecutar OpenClaw dentro de Docker, la escritura directa de código por el agente llena el contexto con ruido: lectura de archivos (5K tokens), escritura de ediciones (500 tokens), ejecución de pruebas (200 tokens) y recepción de trazas de pila (3K tokens). Un solo ciclo de depuración consume 10K-15K tokens, principalmente de salida de consola y trazas de pila que se vuelven inútiles después de las correcciones de errores. Con 20-30 ciclos de depuración por sesión, toda la ventana de contexto se consume por ruido.

Arquitectura Cerebro/Trabajador

La solución implica separar responsabilidades: OpenClawd (en Docker) actúa como el cerebro para planificar, dividir el trabajo en subtareas, delegar y coordinar. Un trabajador local en el host macOS, impulsado por Qwen3.5-27B ejecutándose en Apple Silicon a través de MLX sin costo, sirve como las manos para leer archivos, escribir código, ejecutar pruebas y depurar. Esto mantiene el ruidoso ir y venir en el contexto del trabajador, con el cerebro solo viendo resultados finales como "tarea completada, aquí están los archivos que cambiaron".

Estrategia de Compresión

Incluso con la división cerebro/trabajador, el contexto del orquestador aún se llena con documentos operativos: AGENTS (~6.6K tokens), SOUL (~1.5K tokens), LESSONS (~10K tokens) y planes/guias (~13K tokens en disco), totalizando 20K-30K tokens antes de que comience cualquier trabajo. Las sesiones pueden alcanzar 100K-200K tokens.

La idea clave: el trabajo terminado no necesita detalles crudos. Una vez que se completa una subtarea, su historial crudo se convierte en peso muerto. El agente solo necesita saber: cuál era la tarea, si tuvo éxito, qué archivos cambiaron y cualquier error.

Detalles de Implementación

Paso 1: Detectar límites del ciclo de vida - El orquestador descompone el trabajo en subtareas con ciclos de vida: Generar (el agente llama a sessions_spawn o delegate_task), Ejecutar (llamadas a herramientas, razonamiento) y Completar (Mensaje del Sistema "subagente 'nombre_tarea' completado"). Un escáner de 4 pasadas recorre el JSONL de la sesión:

• Paso 1: Encontrar eventos de generación
• Paso 2: Encontrar errores de generación
• Paso 3: Encontrar marcadores de finalización
• Paso 4: Calcular recuento de tokens y duración por ciclo de vida

Esto identifica rangos de mensajes pertenecientes a subtareas completadas.

Paso 2: Resumir en "lenguaje de agente" (enmascaramiento) - Los resúmenes se generan para parecerse a la salida normal del agente y mantener la compatibilidad con el formato de mensaje esperado por el orquestador (roles, bloques de contenido, estructuras de llamadas a herramientas, cadenas de ID padre-hijo). Estos resúmenes enmascarados reemplazan el historial crudo de la tarea.

Ejemplo de resumen de tarea compactado:

── TAREA COMPACTADA ──
origen: agente
tarea: Implementar tiempo de espera inactivo para servidor MLX
resultado: éxito
resultado: Se añadió temporizador de inactividad de 5 min a MlxServerManager.
El servidor se descarga automáticamente cuando no se reciben solicitudes.
archivos+: src/services/mlx_idle_monitor.py
archivos~: src/services/mlx_server.py, config.json
errores: ninguno
intentado_y_fallado: threading.Timer — condición de carrera
debe_recordar: El servidor MLX solo debe recargarse ante solicitud explícita del trabajador, no ante cualquier llamada a herramienta
─────────────────

Este resumen de ~100 tokens reemplaza 5K tokens de llamadas a herramientas y razonamiento crudo (reducción del 99.2%). Los resúmenes son generados por un LLM económico (Gemini Flash Lite o MLX local), con mecanismos de respaldo si falla la generación.