Del agente único al sistema multiagente: implementación real en el mundo
El desarrollador comenzó con Claude Code para automatizar tareas en un servidor de producción. El problema? Solicitudes constantes de permisos para operaciones de archivos y red. La bandera --dangerously-skip-permissions ayudó, pero el agente no podía editar configuraciones de forma autónoma.
La autonomía se logró usando tmux para mantener sesiones activas y systemd para el arranque automático. Un archivo de servicio systemd aseguró reinicios tras fallos y cargó contexto desde archivos:
[Unit]
Description=Claude Code Agent
After=network.target
[Service]
Type=simple
User=ubuntu
ExecStart=/usr/local/bin/claude --dangerously-skip-permissions ...
Restart=always
RestartSec=5El agente con permisos limitados manejaba tareas del blog pero permanecía aislado.
Colaboración entre agentes para superar limitaciones
Dos instancias de Claude Code resolvieron el cuello de botella de confirmación: una solicitaba acciones, la segunda las validaba mediante tmux. Esto eliminó la dependencia de aprobaciones humanas y claves API. La suscripción Claude Max cubre los límites de uso sin consumir tokens en llamadas a la API.
La integración con Telegram reveló conflictos: el servidor oficial MCP no soportaba mensajes proactivos, y Telethon generaba problemas de polling. La solución? Un bus basado en tmux usando send-keys y comandos directos claude {texto} para entregar prompts.
El bus de mensajes como base para escalar
Un bus de mensajes construido con Bun + Hono + Redis Streams garantizó entrega al menos una vez mediante grupos de consumidores. Cada agente tiene su propio grupo, y los mensajes se mantienen hasta ser confirmados.
Seguridad:
- Tokens de administrador para gestión.
- Tokens por agente para operaciones.
- Tokens de invitación con TTL de 1 hora, uso único.
Enrutamiento:
- Directo — a un agente específico.
- Broadcast — a todos los agentes.
- Por rol — según función.
Soporta SSE para actualizaciones en tiempo real, pub/sub sobre canales temáticos y adjuntos mediante almacenamiento compartido. El campo from se rellena automáticamente desde el token.
Asignación de roles con arquetipos de Naruto
Los agentes recibieron nombres de personajes de la saga Naruto para aclarar funciones y diferenciarlos de operadores humanos:
- Naruto: Orquestador, asigna tareas.
- Sasuke: Cuenta de usuario Telegram, monitorea grupos.
- Itachi: Claude Code basado en consola en WSL para tareas complejas.
- Shikamaru: Asesor estratégico en Claude Desktop Opus.
Agentes de infraestructura:
- Kakashi (Sonnet): Líder de equipo.
- Gai: Maneja tareas rápidas.
- Shino: Líder de QA.
- Hinata: Pruebas.
- Ibiki: Auditorías de seguridad.
- Kiba + Akamaru: Monitoreo.
- Mira: Acceso a sistemas externos.
- Jiraiya: Registros y base de conocimiento.
Integraciones: Yonote, Yandex Tracker, Yandex Calendar, Bitrix24.
Delegación de entrenamiento en entornos multiagente
Inicialmente, los agentes realizaban tareas de forma independiente, ignorando la delegación. Mediante ingeniería iterativa de prompts se desarrollaron habilidades de delegación:
- Naruto verifica la preparación del equipo antes de asignar tareas.
- Kakashi delega trabajos sencillos a Gai.
El comportamiento refleja la gestión humana: la delegación requiere capacitación explícita, ya que la ejecución autónoma es el camino más fácil para los LLMs.
Arquitectura final y limitaciones
Sistema: 12 agentes, panel web de administración con registros, alertas, búsqueda de mensajes y recordatorios. Desarrollado internamente en una semana, 67 commits.
No implementado: llamadas telefónicas, bypass de captchas, avatares para videollamadas.
Conclusiones clave:
- Los sistemas multiagente crecen de forma orgánica al resolver problemas reales.
- tmux + send-keys supera a protocolos MCP.
- La confirmación mutua entre agentes elimina la dependencia del humano en el bucle.
- La suscripción Claude Max reduce costos de API.
- La delegación necesita entrenamiento iterativo — al igual que los humanos.
— Editorial Team
Aún no hay comentarios.