Framework Multi-Agente para Desarrollo de Software Autónomo en Bare Metal
Arquitectura KISS para SDLC Enterprise con Agentes de IA Especializados
Índice
- 1. Introducción
- 2. Arquitectura del Sistema
- 3. Infraestructura de Colaboración: Gitea como Sistema de Control de Versión
- 3.1. ¿Por qué Git como Columna Vertebral?
- 3.2. ¿Por qué Gitea?
- 3.3. ¿Por qué Gitea como Contenedor Docker?
- 3.4. Configuración de Gitea en el Sistema
- 3.5. El Rol de Gitea en el Flujo Multi-Agente
- 3.6. Gestión de Tokens por Agente
- 3.7. El Flujo Completo con Gitea
- 3.8. Ventajas de esta Arquitectura con Gitea
- 3.9. Comparación con Alternativas
- 4. Integración con el Resto del Sistema
- 5. Conclusión sobre Gitea
- 6. Implementación Técnica
- 7. Caso de Uso: Aplicación Todo-List Full-Stack
- 8. Ventajas Comparativas
- 9. Automatización (Futura Mejora)
- 10. Conclusión
- 11. Apéndices
1. Introducción
1.1. El Problema con las Herramientas Actuales
Las herramientas comerciales de desarrollo asistido por IA (Claude Code, OpenCode, Kilo Code, etc.) ofrecen capacidades "multi-agente" en su marketing, pero en la práctica presentan limitaciones fundamentales:
- Agentes monolíticos: Un solo agente con acceso a todas las herramientas y permisos
- Sin aislamiento real: Todos los "sub-agentes" comparten el mismo sistema de archivos
- Comunicación síncrona: No hay bus de mensajes ni eventos asíncronos
- Sin roles estrictos: Las restricciones son solo sugerencias en el prompt, no restricciones del sistema
- Sin iteración autónoma: El humano debe detectar errores y pedir correcciones manualmente
1.2. Nuestra Solución
Construimos un Framework Multi-Agente Real que implementa un Ciclo de Vida de Desarrollo de Software (SDLC) completo, autónomo y profesional, utilizando únicamente herramientas nativas de Linux y filosofía Unix/KISS.
2. Arquitectura del Sistema
2.1. Principios Fundamentales
- Especialización: Cada agente tiene un rol único y definido
- Aislamiento: Los permisos se aplican a nivel de sistema operativo
- Comunicación Asíncrona: Bus de mensajes nativo de Linux (/var/spool/mail)
- Filosofía KISS: Sin Docker para la IA, sin MCPs, sin sobreingeniería
- Trazabilidad Completa: Cada acción genera un registro formal
2.2. Agentes y Roles
| Agente | Rol | Dominio Exclusivo | Permisos |
|---|---|---|---|
| pm agent | Project Manager / Orquestador | Todo (solo lectura) | read, bash |
| dev frontend | Desarrollador Frontend | /client | read, write (solo /client) |
| dev backend | Desarrollador Backend | /server | read, write (solo /server) |
| qa agent | Quality Assurance / Auditor | Todo (solo lectura) | read, bash |
| ci cd | CI/CD / DevOps | Infraestructura Docker | read, write, bash |
| doc agent | Documentación y Calidad | /docs | read, write (solo /docs) |
| security agent | Seguridad y Cumplimiento | Auditoría (solo lectura) | read, bash |
2.3. Flujo de Comunicación
3. Infraestructura de Colaboración: Gitea como Sistema de Control de Versión
3.1. ¿Por qué Git como Columna Vertebral?
Git no es solo una herramienta de versionado en este framework; es el sistema nervioso central que permite la colaboración entre agentes. Sin Git, los agentes estarían trabajando en silos aislados, sin forma de:
- Versionar el código: Cada cambio queda registrado con autor, timestamp y mensaje descriptivo
- Trabajar en paralelo: Múltiples agentes pueden trabajar en ramas independientes sin pisarse
- Revisar el trabajo: Los Pull Requests permiten la revisión formal antes de la integración
- Trazabilidad completa: Cada commit está vinculado a un Issue, a un agente y a un propósito
- Rollback seguro: Si algo falla, se puede revertir a un estado anterior conocido
En un entorno multi-agente, Git proporciona las garantías que normalmente da un equipo humano: quién hizo qué, cuándo, por qué y con qué autorización.
3.2. ¿Por qué Gitea?
Gitea es una implementación ligera de Git escrita en Go, diseñada para ser auto-hospedada. Lo elegimos sobre alternativas como GitHub, GitLab o Gogs por razones específicas:
3.2.1. Ventajas sobre Soluciones Comerciales (GitHub/GitLab)
| Característica | GitHub/GitLab | Gitea |
|---|---|---|
| Dependencia de internet | ❌ Requiere conexión | ✅ 100% local |
| Costo | ❌ Suscripciones | ✅ Gratuito y open source |
| Privacidad | ❌ Código en la nube | ✅ Datos 100% en tu servidor |
| Latencia | ❌ Depende de red | ✅ Localhost (< 1ms) |
| Control | ❌ Sujeto a ToS | ✅ Control total |
| Consumo de recursos | N/A | ✅ ~100MB RAM |
| API REST | ✅ Compleja | ✅ Simple y documentada |
3.2.2. Ventajas sobre Gogs
- Mantenimiento activo: Gitea tiene una comunidad más grande y releases frecuentes
- Mejor API REST: Más completa y mejor documentada para automatización
- Interfaz más pulida: Mejor UX para revisión manual de PRs
- Soporte para Actions: Permite CI/CD nativo si se desea en el futuro
3.3. ¿Por qué Gitea como Contenedor Docker?
Esta decisión sigue el mismo principio KISS que aplicamos al resto del sistema, pero con una excepción deliberada:
3.3.1. La Excepción al Principio "No Docker para la IA"
Mientras que los agentes de IA corren nativamente en Bare Metal (para evitar la sobrecarga de múltiples contenedores de LLM), Gitea sí corre en Docker. ¿Por qué esta asimetría es correcta?
- Aislamiento del servicio: Gitea es un servicio de infraestructura, no un agente de IA. No consume tokens de API ni tiene "pensamiento" que proteger.
- Facilidad de despliegue: Un solo comando = Gitea funcionando con base de datos incluida
- Portabilidad: Si mañana migras el servidor, mueves el contenedor y listo
- Actualizaciones seguras: Cambiar de versión es tan fácil como cambiar la etiqueta de la imagen
- Recursos predecibles: Gitea consume ~100MB RAM constante, sin picos
3.3.2. Lo que NO hacemos con Docker
- ❌ No corremos los agentes de IA en contenedores (sería lento y complejo)
- ❌ No usamos Docker Compose para orquestar los agentes
- ❌ No usamos volúmenes Docker para el spool de correo (usamos /var/spool/mail nativo)
3.3.3. Lo que SÍ hacemos con Docker
- ✅ Corremos Gitea como servicio de infraestructura
- ✅ El agente CI/CD genera imágenes Docker para la aplicación final
- ✅ El agente CI/CD usa docker-compose para desplegar la app
Esta es la aplicación correcta del principio KISS: Docker donde aporta valor (servicios), Bare Metal donde aporta valor (agentes de IA).
3.4. Configuración de Gitea en el Sistema
3.4.1. Despliegue del Contenedor
# Crear directorio persistente para Gitea mkdir -p /opt/gitea/data /opt/gitea/config # Ejecutar Gitea docker run -d \ --name gitea \ --restart always \ -p 3000:3000 \ -p 222:22 \ -v /opt/gitea/data:/data \ -v /opt/gitea/config:/data/gitea/conf \ -e USER_UID=1000 \ -e USER_GID=1000 \ gitea/gitea:latest
3.4.2. Acceso e Inicialización
- Interfaz Web: http://localhost:3000
- API REST: http://localhost:3000/api/v1
- Git SSH: ssh://git@localhost:222
- Git HTTP: http://localhost:3000/%7Bowner%7D/%7Brepo%7D.git
3.5. El Rol de Gitea en el Flujo Multi-Agente
Gitea cumple tres funciones críticas en la arquitectura:
3.5.1. 1. Fuente de Verdad del Código
Todos los agentes clonan desde Gitea y hacen push a Gitea. Esto garantiza:
- Un solo lugar donde vive el código
- Historial completo de cambios
- Resolución automática de conflictos mediante merge
3.5.2. 2. Mecanismo de Revisión (Pull Requests)
Los Pull Requests son el equivalente digital de la "revisión de código" en un equipo humano:
Flujo típico: 1. Dev Frontend crea rama feature/todo-list-frontend 2. Hace push de sus cambios 3. Crea PR #3 apuntando a main 4. QA Agent revisa el PR (código + tests) 5. Si hay bugs → QA rechaza con comentarios 6. Dev corrige y actualiza el PR 7. QA aprueba → PM fusiona a main
3.5.3. 3. API REST para Automatización
Los agentes interactúan con Gitea programáticamente mediante su API REST:
# Crear un Issue (PM Agent) curl -X POST "http://localhost:3000/api/v1/repos/pm_agent/test/issues" \ -H "Authorization: token $TOKEN" \ -H "Content-Type: application/json" \ -d '{"title": "Implementar Todo-List", "body": "..."}' # Crear un Pull Request (Dev Agent) curl -X POST "http://localhost:3000/api/v1/repos/pm_agent/test/pulls" \ -H "Authorization: token $TOKEN" \ -H "Content-Type: application/json" \ -d '{"title": "Frontend implementation", "head": "feature/frontend", "base": "main"}' # Fusionar un PR (PM Agent) curl -X POST "http://localhost:3000/api/v1/repos/pm_agent/test/pulls/3/merge" \ -H "Authorization: token $TOKEN" \ -H "Content-Type: application/json" \ -d '{"merge_commit_id": "auto"}' # Cerrar un Issue (PM Agent) curl -X PATCH "http://localhost:3000/api/v1/repos/pm_agent/test/issues/2" \ -H "Authorization: token $TOKEN" \ -H "Content-Type: application/json" \ -d '{"state": "closed"}'
3.6. Gestión de Tokens por Agente
Cada agente tiene su propio token de API en Gitea, con permisos específicos según su rol:
| Agente | Permisos en Gitea | Propósito |
|---|---|---|
| pm agent | Lectura y Escritura (Issues, PRs, Repos) | Crear Issues, fusionar PRs, cerrar |
| dev frontend | Lectura y Escritura (Repos) | Clonar, crear ramas, push, crear PRs |
| dev backend | Lectura y Escritura (Repos) | Clonar, crear ramas, push, crear PRs |
| qa agent | Solo Lectura (Repos) | Clonar para auditar, no modificar |
| ci cd | Lectura y Escritura (Repos) | Clonar, push de infraestructura |
| doc agent | Lectura y Escritura (Repos) | Clonar, push de documentación |
| security agent | Solo Lectura (Repos) | Clonar para auditar, no modificar |
3.6.1. Principio de Mínimo Privilegio
Cada token solo tiene los permisos estrictamente necesarios:
- Los agentes que no modifican código (QA, Security) tienen solo lectura
- Los agentes que escriben código (Devs, CI/CD, Docs) tienen lectura y escritura
- Solo el PM puede fusionar PRs y cerrar Issues
Esto previene que un agente mal comportado o con alucinaciones pueda dañar el repositorio más allá de su dominio.
3.7. El Flujo Completo con Gitea
3.8. Ventajas de esta Arquitectura con Gitea
- Trazabilidad completa: Cada Issue, PR y commit está registrado con autor y timestamp
- Revisión formal: Los Pull Requests obligan a una revisión antes de la integración
- Paralelismo seguro: Múltiples agentes trabajan en ramas independientes
- Rollback garantizado: Si algo falla, se puede revertir cualquier cambio
- Auditoría automática: El historial de Git documenta todo el proceso
- Independencia total: No dependes de servicios externos ni de internet
- Escalabilidad: Puedes agregar más agentes sin cambiar la infraestructura base
3.9. Comparación con Alternativas
3.9.1. ¿Por qué no GitHub/GitLab?
- Dependencia externa: Si GitHub cae, todo tu SDLC se detiene
- Costo recurrente: Suscripciones mensuales por equipo privado
- Privacidad: Tu código vive en servidores de terceros
- Latencia: Cada operación de API depende de tu conexión a internet
- ToS restrictivo: GitHub puede suspender tu cuenta por cualquier motivo
3.9.2. ¿Por qué no Git puro sin interfaz?
- Sin Pull Requests: No hay mecanismo formal de revisión
- Sin Issues: No hay sistema de tickets integrado
- Sin API REST: Los agentes tendrían que manipular archivos .git directamente (frágil)
- Sin interfaz web: No puedes revisar el código manualmente cuando quieras
- Sin webhooks: No puedes automatizar acciones basadas en eventos
Gitea nos da todo esto en un paquete ligero, auto-hospedado y gratuito.
4. Integración con el Resto del Sistema
4.1. Gitea + Correo Local = Orquestación Completa
La combinación de Gitea (para el código) y el spool de correo local (para la comunicación) crea un sistema de orquestación completo:
4.2. Flujo de Datos Completo
5. Conclusión sobre Gitea
Gitea no es un componente opcional en esta arquitectura; es la columna vertebral que hace posible la colaboración multi-agente. Sin él, los agentes estarían trabajando en aislamiento, sin forma de integrar su trabajo de manera segura y trazable.
La decisión de correr Gitea como contenedor Docker (mientras los agentes corren nativamente) es una aplicación pragmática del principio KISS: usar la herramienta correcta para cada trabajo. Docker aporta valor para servicios de infraestructura; Bare Metal aporta valor para agentes de IA.
Esta combinación de Gitea + Correo Local + Agentes Especializados crea un sistema que es:
- Autónomo: Los agentes se coordinan sin intervención humana constante
- Seguro: Los permisos están restringidos a nivel de sistema operativo y de API
- Trazable: Todo queda registrado en Git y en el spool de correo
- Profesional: Sigue los mismos patrones que usaría un equipo humano de ingeniería
- Ligero: Consume mínimos recursos, sin dependencias externas
6. Implementación Técnica
6.1. Configuración del Sistema Operativo
6.1.1. Creación de Usuarios y Grupos
# Crear grupo compartido para herramientas groupadd tools # Crear usuarios para cada agente for agent in pm_agent dev_frontend dev_backend qa_agent ci_cd doc_agent security_agent; do useradd -m -s /bin/bash $agent passwd $agent usermod -aG tools $agent done # Agregar ci_cd al grupo docker para construir contenedores usermod -aG docker ci_cd
6.1.2. Instalación de Herramientas Globales
# Instalar Node.js, npm, OpenCode en /opt/tools mkdir -p /opt/tools cd /opt/tools # Descargar e instalar Node.js curl -fsSL https://nodejs.org/dist/v22.0.0/node-v22.0.0-linux-x64.tar.xz | tar -xJ ln -s node-v22.0.0-linux-x64 node ln -s node/bin/node /usr/local/bin/node ln -s node/bin/npm /usr/local/bin/npm ln -s node/bin/npx /usr/local/bin/npx # Instalar OpenCode npm install -g opencode # Configurar permisos chown -R root:tools /opt/tools chmod -R 775 /opt/tools
6.1.3. Configuración del Servidor de Correo Local
# Instalar Postfix (o usar el MTA nativo de Slackware) # Configurar para entrega local únicamente postconf -e "inet_interfaces = loopback-only" postconf -e "mydestination = localhost, mtk.org" systemctl restart postfix
6.2. Configuración de Cada Agente
6.2.1. Estructura de Archivos
/home/{agente}/
├── .opencode/
│ ├── opencode.json # Configuración de permisos
│ └── system-prompt.md # Instrucciones especializadas
└── .bashrc # Configuración del shell
6.2.2. Ejemplo: opencode.json para devfrontend
{
"$schema": "https://opencode.ai/config.json",
"agent": {
"default": {
"prompt": "{file:/home/dev_frontend/.opencode/system-prompt.md}",
"permission": {
"write": "allow",
"edit": "deny",
"read": "allow",
"bash": "allow"
}
}
}
}
6.2.3. Ejemplo: system-prompt.md para dev frontend (fragmento)
# DIRECTRICES OPERATIVAS: AGENTE DESARROLLADOR FRONTEND (NIVEL SENIOR) ## 1. MISIÓN Y ALCANCE Usted actúa como Desarrollador Frontend Senior. Su responsabilidad es implementar la interfaz de usuario según los requisitos del Product Manager. DOMINIO EXCLUSIVO: - Trabajar EXCLUSIVAMENTE en la carpeta /client - Implementar componentes React, estilos CSS, y lógica de UI PROHIBICIONES ABSOLUTAS: - NO tocar archivos en /server - NO escribir lógica de base de datos - NO instalar dependencias globales ## 2. REGLA DE ORO DE AISLAMIENTO DE ROL - Su único trabajo es el frontend - Si necesita algo del backend, solicítelo por correo al PM ## 3. PROTOCOLO DE HERRAMIENTAS (POLÍTICA KISS) Queda estrictamente prohibido el uso de MCPs. Toda interacción se ejecuta exclusivamente vía bash usando utilidades POSIX. REGLA DE ESCAPADO SEGURO: - Para correos: Use heredocs con comillas simples (cat << 'EOF' | mail ...) ## 4. REGLA DE ENTORNO PRECONFIGURADO (CRÍTICO) El sistema ya tiene Node.js, npm, npx y OpenCode instalados globalmente en /opt/tools. - NUNCA intente instalar Node.js, npm o NVM - NUNCA use apt install - Ejecute npm install dentro del directorio del proyecto
6.3. Flujo de Trabajo Estándar (SOP)
6.3.1. Fase 1: Ingesta de Correo
# Comando obligatorio para leer el último correo formail -s cat < /var/spool/mail/{agente}
6.3.2. Fase 2: Análisis del Contexto
- Extraer número de Issue
- Identificar tarea específica
- Verificar permisos y alcance
6.3.3. Fase 3: Ejecución de la Tarea
- Clonar repositorio si es necesario
- Implementar la funcionalidad
- Hacer commit y push a rama feature/
6.3.4. Fase 4: Notificación
# Enviar reporte al PM cat << 'EOF' | mail -s "[COMPLETADO] Issue #X: Descripción" pm_agent@mtk.org Estimado PM, Se ha completado la implementación. DETALLES TÉCNICOS: - Issue: #X - Rama: feature/descripcion - Commit: hash - PR: http://localhost:3000/pm_agent/test/pulls/Y Atentamente, {Agente} EOF
7. Caso de Uso: Aplicación Todo-List Full-Stack
7.1. Requerimiento Inicial
De: Founder Para: pm_agent Asunto: [REQUERIMIENTO] Crear aplicación Todo-List Full-Stack Necesito una aplicación de lista de tareas con: - Frontend en React - Backend REST con SQLite - Capacidad de agregar, completar y eliminar tareas - Despliegue con Docker
7.2. Ejecución del Flujo
- PM Agent: Crea Issue #2, delega a Frontend y Backend
- Dev Frontend: Implementa UI en /client (PR #3)
- Dev Backend: Implementa API en /server (PR #4)
- QA Agent: Detecta 2 bugs:
- Falta endpoint PUT tasks:id
- Proxy mismatch en package.json
- Devs: Corrigieron bugs
- QA Agent: Aprueba PRs
- CI/CD Agent: Genera Dockerfiles y docker-compose.yml
- Bug de Integración: Frontend no conecta con backend en Docker
- CI/CD Agent: Implementa Nginx Reverse Proxy
- Doc Agent: Genera documentación técnica
- Security Agent: Audita seguridad
7.3. Resultado Final
Repositorio: http://localhost:3000/pm_agent/test Rama main: Código fusionado y funcional Artefacto: docker-compose.yml listo para producción Para desplegar: git clone http://localhost:3000/pm_agent/test.git cd test docker-compose up -d Acceder a: http://localhost:3002
8. Ventajas Comparativas
8.1. vs. Herramientas Comerciales (Claude Code, OpenCode, etc.)
| Característica | Herramientas Comerciales | Nuestro Framework |
|---|---|---|
| Aislamiento de permisos | ❌ Solo sugerencias | ✅ Restricciones reales |
| Comunicación asíncrona | ❌ Síncrona | ✅ Bus de mensajes |
| Roles estrictos | ❌ Configuración | ✅ Sistema operativo |
| Iteración autónoma | ❌ Manual | ✅ Automática |
| Trazabilidad | ❌ Un solo hilo | ✅ Correos formales |
| Filosofía | ❌ Productos comerciales | ✅ Unix/KISS |
| Replicabilidad | ❌ Dependencias externas | ✅ 100% Bare Metal |
8.2. Casos de Uso Recomendados
8.2.1. Usar Herramientas Comerciales si:
- Proyecto personal pequeño
- Prototipado rápido
- No se requiere trazabilidad
- Proyecto efímero
8.2.2. Usar Nuestro Framework si:
- Software profesional con calidad empresarial
- Separación de responsabilidades requerida
- Trazabilidad y auditoría necesarias
- Sistema debe autocorregirse
- Filosofía Unix y control total
9. Automatización (Futura Mejora)
9.1. Script de Cron para Despertar Agentes
#!/bin/bash # /usr/local/bin/check-and-run-agent.sh USER="qa_agent" MAILBOX="/var/spool/mail/$USER" # Verificar si el archivo de correo fue modificado en los últimos 10 minutos if find "$MAILBOX" -mmin -10 2>/dev/null | grep -q .; then echo "[$(date)] Nuevo correo detectado para $USER" >> /var/log/agent-trigger.log # Ejecutar OpenCode en modo headless su - "$USER" -c 'opencode run "Ejecuta tu flujo operativo estricto con el último correo. Finaliza tu turno."' >> /var/log/agent-trigger.log 2>&1 else exit 0 fi
9.1.1. Configuración de Cron
# Ejecutar cada 5 minutos */5 * * * * /usr/local/bin/check-and-run-agent.sh
10. Conclusión
Este framework demuestra que es posible construir un Sistema Multi-Agente de Desarrollo de Software completamente autónomo, profesional y robusto, utilizando únicamente herramientas nativas de Linux y aplicando principios de ingeniería de software clásicos.
La clave no está en la complejidad tecnológica, sino en la arquitectura: agentes especializados, aislamiento de permisos, comunicación asíncrona y orquestación event-driven.
Este enfoque no solo es viable, sino que es superior a las soluciones comerciales en términos de seguridad, calidad, trazabilidad y mantenibilidad.
11. Apéndices
11.1. A. Comandos Útiles
# Ver correos de un agente formail -s cat < /var/spool/mail/{agente} # Limpiar buzón de un agente > /var/spool/mail/{agente} # Ver grupos de un usuario groups {usuario} # Cambiar a un agente su - {agente} # Ejecutar OpenCode opencode
11.2. B. Estructura del Repositorio Final
test/ ├── client/ │ ├── src/ │ ├── public/ │ ├── package.json │ └── Dockerfile ├── server/ │ ├── routes/ │ ├── database/ │ ├── index.js │ ├── package.json │ └── Dockerfile ├── docs/ │ ├── README.md │ ├── API_SPEC.md │ ├── ADR_001.md │ └── ISO_25010_CHECKLIST.md ├── docker-compose.yml ├── nginx.conf └── .dockerignore
11.3. C. Referencias
- Filosofía Unix: https://en.wikipedia.org/wiki/Unix_philosophy
- Principio KISS: https://en.wikipedia.org/wiki/KISS_principle
- SDLC: https://en.wikipedia.org/wiki/Systems_development_life_cycle
- ISO/IEC 25010: Calidad de producto de software
- ISO/IEC 12207: Procesos del ciclo de vida de software
- OWASP Top 10: https://owasp.org/www-project-top-ten/