Usar un modelo más pequeño como capa de higiene en tiempo de ejecución mejora la confiabilidad del agente OpenClaw.

Problema: Las salidas descuidadas degradan los agentes de larga duración

Al ejecutar OpenClaw localmente en un Mac Studio M4 (36GB) con Qwen 3.5 27B (4-bit, oMLX) como agente doméstico, el modelo no se volvió menos capaz con el tiempo—se volvió descuidado. Los problemas específicos incluían:

• Llamadas a herramientas que se filtran como texto crudo en lugar de uso estructurado de herramientas
• Pensamientos de planificación que se filtran en respuestas finales
• Repetición de resultados de herramientas y texto de políticas al usuario
• Salidas malformadas que envenenan el contexto, causando degradación con cada turno posterior

El problema central no era la capacidad sino la higiene en tiempo de ejecución: el modelo sabía qué hacer pero fallaba en el comportamiento adecuado dentro del entorno de ejecución de OpenClaw.

Solución: Arquitectura de cuatro capas para higiene en tiempo de ejecución

El desarrollador implementó un enfoque de cuatro capas que resultó más efectivo que simplemente usar un modelo más grande:

• Resumen: Compactación de contexto mediante lossless-claw (basado en DAG, freshTailCount=12, contextThreshold=0.60). Esto proporcionó la mayor mejora individual.
• Sheriff: Comprobaciones por expresiones regulares y heurísticas que detectan respuestas malformadas antes de que entren en OpenClaw. Esto evita que el marcado de herramientas filtrado, divagaciones del planificador y JSON crudo se conviertan en contexto duradero.
• Juez: Un modelo más pequeño y económico que clasifica salidas dudosas como "respuesta final válida" vs "basura". Este modelo no es para inteligencia sino para higiene en tiempo de ejecución—es un sistema inmunológico más que un segundo cerebro. También maneja todo el resumen para lossless-claw.
• Ozempic (nombre interno): Limpieza agresiva de memoria que asegura que el modelo solo relea solicitudes de usuario, respuestas finales y hechos compactos derivados de herramientas en turnos futuros—no divagaciones del planificador, JSON crudo de herramientas, artefactos de reintento o autodiálogo de políticas.

Por qué esto supera usar un modelo más grande

Un solo modelo debe resolver tareas simultáneamente, mantener disciplina de formato, gestionar coherencia de contexto, evitar envenenarse con sus propias salidas y recuperarse de salidas malas—especialmente desafiante en niveles de cuantización local. Dividir responsabilidades para que el modelo principal haga el trabajo mientras un modelo más pequeño mantiene la higiene en tiempo de ejecución resultó más efectivo que añadir más parámetros.

Resultado: Operación sostenida sin reinicios

El enfoque pasó de necesitar reinicios /new cada 20-30 minutos a operación sostenida en sesión única en un Mac Studio M4 con 36GB de RAM, completamente local sin llamadas API.