Patrones de Fallas de OpenClaw: 42 Incidentes Reales en 28 Días

Qué es esto

Una guía de campo detallada de un desarrollador que ejecutó OpenClaw diariamente durante 28 días, documentando 42 incidentes reales donde el sistema de agentes de IA falló. La fuente organiza los fallos en ocho categorías con ejemplos específicos y lecciones aprendidas.

Categorías clave de fallos y ejemplos

1. La IA reporta con confianza cosas que no sucedieron

• Alucinación en el reporte matutino: El trabajo cron reportó "noche tranquila" cuando en realidad se había realizado trabajo significativo durante la noche. La IA no verificó nada, simplemente inventó información que sonaba plausible.
• Búsqueda en memoria vs. realidad: Al pedirle que enumerara las herramientas disponibles, la IA buscó en sus notas SOBRE herramientas en lugar de verificar las definiciones reales de las herramientas, reportando capacidades que no existían mientras ignoraba las reales.
• La "solución" no arregla de "estaré más atento": Después de cometer errores, la IA respondió con promesas de "estaré más atento" sin ningún mecanismo real. Los mismos errores se repitieron.

Lección: Cualquier sistema de IA que reporte, resuma o monitoree necesita pasos de verificación explícitos. "Revisar los datos" no es lo mismo que "ejecutar esta consulta específica y reportar el resultado". Instrucciones vagas producen ficción confiada.

2. La autenticación falla constantemente

• Trampa de OAuth de Google de 7 días: La aplicación OAuth dejada en modo "pruebas" causó que los tokens expiraran cada 7 días. El acceso a correo y calendario falló repetidamente durante 14 días antes de una solución de 15 minutos (publicar la aplicación a producción).
• Google suspendió la cuenta de la IA: La cuenta de Google creada para el bot fue marcada como creada por bot y suspendida, causando 24 horas de acceso cero al correo.
• Las cookies de LinkedIn rotan agresivamente: La cookie li_at expiró al menos 3 veces en la primera semana, matando toda la automatización de LinkedIn hasta que se refrescó manualmente el navegador.
• Desajuste en el nombre de variable de entorno de Twitter: La herramienta esperaba AUTH_TOKEN pero el sistema almacenaba TWITTER_AUTH_TOKEN, causando un fallo silencioso sin mensajes de error.
• El modelo de respaldo Kimi simplemente murió: La API de modelo de terceros devolvió 401 sin advertencia, dejando el sistema funcionando con cero respaldo durante días.

Lección: Cada integración de IA que toque servicios externos fallará regularmente por problemas de autenticación. Presupueste para ello, monitoree, tenga respaldos.

3. El modelo más inteligente comete los errores más tontos

• Opus añadiendo propiedades a archivos: Usar Opus 4.6 para trabajos cron simples causó que "creativamente" añadiera metadatos no deseados a los archivos, creando páginas huérfanas en la base de conocimiento.
• El contenido de IA suena como IA: El pipeline completo de contenido (raspar 743 publicaciones, analizar patrones, generar borradores) produjo publicaciones que se leían como si las hubiera escrito una IA. Las publicaciones de framework obtuvieron 0 likes mientras que las publicaciones personales escritas a mano obtuvieron 6 likes y 2 comentarios en 2 horas.
• Las reescrituras largas fueron malas: Dos borradores generados por IA de un artículo resultaron ser resúmenes genéricos. El desarrollador tuvo que aparcar el artículo.

Lección: Los modelos más caros no siempre son mejores. Use el modelo más barato que haga el trabajo. Nunca deje que la IA sea la voz final para nada que necesite sonar humano.

4. La automatización que ahorra tiempo cuesta tiempo

• 23 iteraciones para una infografía: HTML/CSS a Chrome headless a PNG consumió un día completo para un activo visual. "La IA puede generar imágenes, pero generar y generar lo que realmente quieres están separados por 22 revisiones."
• 4 horas de limpieza por cada 1 hora "ahorrada": La fuente nota este patrón pero no proporciona el ejemplo completo.

Categorías adicionales de fallos mencionadas

La fuente menciona ocho categorías en total pero solo detalla cuatro en el texto proporcionado. Las categorías restantes son referenciadas pero no elaboradas.

Para quién es esto

Desarrolladores que construyen o usan sistemas de agentes de IA que quieren entender patrones de fallos del mundo real y estrategias prácticas de mitigación.