OpenCode / OpenHands (anteriormente OpenDevin)

1. Visión general del concepto y problema sistémico

La aparición de "AI Software Engineers" autónomos comerciales (como Devin) ha demostrado el futuro del desarrollo, donde los modelos cierran automáticamente el backlog de tareas. Sin embargo, los servicios propietarios conllevan serios riesgos: altos costos (suscripciones desde $500/mes), falta de transparencia en los algoritmos internos, imposibilidad total de personalizar el comportamiento para el stack interno específico de la empresa y riesgo de filtración de secretos comerciales en nubes cerradas de proveedores.

OpenHands (anteriormente OpenDevin) fue creado como una alternativa libre, modular y segura. Es un marco de agentes completo capaz de clonar repositorios de manera autónoma, analizar documentación, reproducir errores mediante la escritura de pruebas, modificar la base de código y enviar Pull Requests. La seguridad se logra a través de un estricto aislamiento: cada sesión del agente se ejecuta en su propio entorno efímero de Docker (Sandboxing).

2. Taxonomía arquitectónica y modelo mental

El modelo arquitectónico de OpenHands se basa en un bus de eventos (Event Stream) y ejecución aislada:

┌─────────────────────────────────────────────────────────────┐
│                   OPENHANDS ARCHITECTURE                    │
├─────────────────────────────────────────────────────────────┤
│ 1. EventStream Core (EventController & AgentController)     │
│    Bus central de comunicación de eventos Acción ➔ Observación│
├─────────────────────────────────────────────────────────────┤
│ 2. Agent Reasoning Layer (ReAct / CodeAct / Planner)       │
│    Soporte para Claude 3.7 Sonnet, DeepSeek R1, OpenAI o1/o3│
├─────────────────────────────────────────────────────────────┤
│ 3. Isolated Sandbox Runtime (Docker / MicroVM / gVisor)     │
│    • Ejecución: Bash shell con seguimiento de procesos en segundo plano │
│    • Sistema de Archivos: Editores basados en AST y montaje de espacio de trabajo │
│    • Navegador Sin Cabeza: Chromium para pruebas de UI y documentación│
│    • Jupyter / IPython: REPL interactivo para análisis de datos │
├─────────────────────────────────────────────────────────────┤
│ 4. Integraciones de Git y CI/CD: GitHub App, Automatización de PR│
└─────────────────────────────────────────────────────────────┘

1. Arquitectura del Bus de Eventos (EventStream Architecture):
   • Todas las comunicaciones en el sistema están tipificadas como una cadena "Acción ➔ Observación" (Action ➔ Observation).
   • Cada paso del agente (ejecución de comando bash, modificación de archivo, apertura de URL en el navegador) se registra como una acción, y la respuesta del sistema (salida, error, captura de pantalla) se registra como una observación.
2. Estrategias de Razonamiento del Agente (Agent Framework):
   • Soporta la paradigma CodeAct — un enfoque donde el agente genera código ejecutable en Python o Bash en lugar de estructuras JSON complejas, lo que aumenta significativamente la precisión de operaciones complejas de múltiples pasos.
3. Entorno Aislado (Docker Sandboxing):
   • Proporciona aislamiento físico del código. El repositorio del usuario se monta como un volumen de trabajo, y todos los binarios del sistema, dependencias y servidores se ejecutan dentro del contenedor.

3. Pipeline técnico y mecánica interna

El ciclo de vida para resolver una tarea de ingeniería en OpenHands:

1. Inicialización y despliegue del entorno: La plataforma recibe una tarea (por ejemplo, un enlace a un GitHub Issue). OpenHands crea un nuevo contenedor Docker con un entorno de proyecto preconfigurado (Node.js, Python, Rust) y clona la rama objetivo del repositorio.
2. Investigación y reproducción del defecto (Repro Test Phase):
   • El agente realiza una búsqueda semántica de archivos utilizando ripgrep.
   • Antes de realizar correcciones, el agente crea un archivo de prueba separado (Reproduction Script) que falla en el error existente.
3. Ciclo de modificación autónoma (CodeAct Loop):
   • El agente realiza cambios en la lógica de negocio.
   • Ejecuta pruebas en la terminal del contenedor.
   • Obtiene el resultado: si la prueba falla nuevamente, analiza la pila de llamadas y genera una nueva acción.
4. Verificación del navegador (Inspección UI Opcional): Si la tarea se refiere a la interfaz web, el agente levanta un servidor dev local, abre la página a través de Chromium sin cabeza y verifica la representación visual.
5. Generación de PR y limpieza de recursos: Después de pasar todas las pruebas, el agente realiza un git commit, envía una nueva rama a GitHub, abre un Pull Request con una descripción detallada del trabajo realizado y detiene el contenedor.

4. Escenarios prácticos de ingeniería en producción

01. Trabajador automatizado de backlog nocturno (Automated Bug Triaging)

Conexión de OpenHands al repositorio a través de GitHub Actions / Webhooks:

• Al asignar una etiqueta needs-ai-fix a un ticket, la plataforma despliega un contenedor y asigna al agente la tarea.
• Por la mañana, el equipo recibe 5 Pull Requests listas con pruebas aprobadas, listas para la revisión final por parte de humanos.

02. Pruebas completamente seguras de código externo no confiable

Auditoría de seguridad de bibliotecas open-source de terceros o scripts sospechosos:

• El agente investiga el repositorio, ejecuta analizadores estáticos y pruebas de carga.
• Gracias al sandboxing de Docker, los intentos del código externo de conectarse al sistema host o cargar software malicioso son completamente bloqueados.

03. Actualización masiva de microservicios de la empresa

Necesidad de actualizar la configuración de Dockerfiles o Helm charts en 40 microservicios:

• OpenHands levanta secuencialmente un entorno aislado para cada microservicio, aplica cambios, verifica el éxito de la construcción local del contenedor y publica un PR en el repositorio correspondiente.

5. Errores comunes, trampas y seguridad

• Riesgo de montar el socket Docker del host: Desplegar OpenHands es extremadamente peligroso si se expone el socket /var/run/docker.sock dentro del contenedor sin protección adicional (Docker-out-of-Docker). Esto otorga al agente acceso root a la máquina host y anula el sandboxing.
• Requisitos de recursos computacionales: La ejecución paralela de múltiples agentes en Docker requiere una gran cantidad de memoria RAM (de 16 a 32 GB) y un procesador potente; de lo contrario, el sistema puede experimentar un cierre inesperado debido a OOM (Out Of Memory).
• Consumo infinito de tokens en caso de fallo del entorno: Si falta un compilador del sistema en el contenedor o hay una red rota, el agente puede gastar cientos de miles de tokens en intentos infructuosos de instalar un paquete faltante. Siempre configure los timeouts de las sesiones.
• Contenedores "huérfanos" dejados: En caso de un cierre inesperado del proceso principal de la plataforma, los contenedores temporales y los volúmenes creados pueden permanecer en el sistema, llenando gradualmente el espacio en disco del servidor.