OpenClaw: guía completa de enrutamiento multiagente para aislar el trabajo, la vida y la experimentación

El lunes a las 9 a. m., abro mi asistente de IA para ayudar a un cliente con una API de pago. De repente responde: “Basado en tu estrategia de rodar y esquivar contra el jefe de Elden Ring anoche, sugiero el mismo enfoque aquí…”
Je suis resté figé.
Peor: fue durante una reunión compartida con el cliente. El silencio al otro lado del vídeo era palpable.
Ese día lo entendí: el asistente se vuelve más inteligente, pero mezcla trabajo, ocio y experimentación. Como un cajón sin divisores: todo está apilado, es difícil encontrar algo y a menudo tomamos el artículo equivocado.
Si sientes lo mismo, este artículo es para ti. Un fin de semana estudiando el enrutamiento de múltiples agentes de OpenClaw me mostró cómo “clonar” al asistente en múltiples perfiles: trabajo a trabajo, vida a vida, experimentación en sandbox.
He aquí por qué es útil, cómo configurarlo y 5 escenarios que realmente utilizo.
Guía económica para “criar una langosta”: ArkClaw democratiza al agente de IA
¿OpenClaw (langosta) es poderoso pero la configuración es desalentadora? ArkClaw de ByteDance Volcano Engine reduce la barrera: no hay servidores ni tokens con los que jugar, un asistente las 24 horas que controla el navegador, ejecuta scripts y administra el calendario.
El precio importa: ¥9,9/mes, código de invitación ZLKUK54M (registro) → ¥8,9. Desarrolladores: Coding Plan Pro puede ofrecer acceso.
¿Por qué el asistente de IA “mezcla contextos”?
Tres momentos incómodos con un solo asistente
Solía usar un asistente para todo, hasta estas situaciones:
Escenario 1: contaminación contextual
Solicita optimizar una consulta SQL en los negocios; La IA de repente cita: “Como el script Python de la semana pasada…”, excepto que este rastreador era un proyecto personal que no querías exponer.
Escenario 2: fuga de privacidad
En la demostración del equipo, abres el historial para mostrar una función y la lista muestra “cómo negociar un aumento”, “declarar ingresos secundarios”… Conocemos la vergüenza.
Escenario 3: la experimentación interrumpe la producción
Una prueba de cambio de nombre masivo: la IA recuerda un directorio de proyecto de cliente antiguo y cambia el nombre de toda la base de datos de origen. Por suerte, Git estaba ahí.
¿Por qué sucede esto?
El asistente no tiene la culpa: recuerda todo y conecta los contextos. Pero :
- el trabajo requiere rigor y confidencialidad;
- vida personal, consejos relajados;
- experimentación, libertad sin tocar la producción.
Ces trois mondes ne devraient pas cohabiter.
El enfoque de enrutamiento multiagente
El enrutamiento multiagente OpenClaw es una “sala” por escenario:
- Espacio de trabajo aislado: el agente de trabajo solo ve
/work, el agente personal solo ve/personal— aislamiento a nivel de archivo - Historia separada: lo que se le dice al agente-trabajo lo desconoce el agente-personal
- Permisos separados: zona de pruebas sin conexión y FS de solo lectura; trabajar con Git Enterprise; vida con nube personal
En jargon Docker : isolation au niveau conteneur. En clair : plusieurs « cerveaux » indépendants.
En 2026, los estándares de seguridad de la IA exigirán un estricto aislamiento de datos por inquilino. El entorno limitado de Docker de OpenClaw va más allá de las herramientas que dependen de “grupos de conversación”.
Arquitectura de aislamiento de tres niveles
Gateway, Brain, Skills: al principio estaba perdido. Después de una configuración completa, está claro.
Tres capas, como un sistema de entrega
- Gateway (hub): recibe Telegram, Discord, Slack… luego enruta al agente correcto según la configuración
- Cerebro (despacho): interpreta la intención (codificar, buscar, ejecutar) y orquesta el flujo.
- Habilidades (ejecución): trabajo concreto en un contenedor Docker dedicado por agente
Tres niveles de aislamiento
Aislamiento de sesión (tareas temporales)
Contenedor nuevo por conversación, destruido al final. Ideal para “analizar este CSV”. Limpio, pero ambiente para recrear.
Aislamiento de agentes (escenarios a largo plazo)
Un contenedor persistente por agente. Mi agente de trabajo y mi agente personal trabajan así: mi modo preferido.
Aislamiento del usuario del sistema operativo (paranoia saludable)
Agentes bajo diferentes usuarios del sistema. No lo necesitaba; útil para las finanzas o la salud.
Prueba personal: con el aislamiento del agente, un archivo creado en el agente A es inaccesible para el agente B, excepto en un volumen compartido explícito. Tranquilizador.
5 scénarios que j’utilise
Configuraciones reales, reutilizables tal cual.
Escenario 1: trabajo versus personal
Problema: código de empresa y blog personal mezclados. Casi envié el código del cliente a mi GitHub personal.
Solution :
- work-agent :
D:\work, clé SSH GitLab entreprise, clés API pro uniquement - personal-agent :
D:\personal, compte GitHub perso
Points clés :
Deux fichiers .env, WORKSPACE_PATH distincts. Deux bots Telegram : @my_work_bot et @my_personal_bot.
Escenario 2: aislamiento multicliente
Problema: Profesional independiente, tres clientes: asesoramiento para el Cliente A con convenciones de nomenclatura del Cliente B.
Solution :
Trois agents : client-nike-agent, client-adidas-agent, client-puma-agent (noms fictifs).
Puntos clave:
- Directorio y repositorio Git por cliente
PROJECT_NAMEdistinto en cada.env- Claves API y DB estrictamente separadas
Escenario 3: zona de pruebas segura
Problema: probar un script de archivo sin correr el riesgo de borrarlo todo.
Solution :
sandbox-agent en mode strict.
Points clés :
ENABLE_NETWORK=false # hors ligne
HOST_FILESYSTEM_MODE=readonly # FS hôte en lecture seule
TEMP_STORAGE=true # modifications temporaires, effacées au redémarrage
Cualquier operación arriesgada pasa primero por aquí.
Escenario 4: equipo y espacio privado
Problema: asistente de equipo compartido: notas personales y todos visibles para todos.
Solución:
- agente de equipo: repositorio de equipo y documentos
- agente privado: ideas, borradores, todos personales
Puntos clave:
agente de equipo en NAS compartido; agente privado en la partición cifrada local. agente de equipo en el grupo Telegram; agente privado en DM en solitario.
Escenario 5: comparación de múltiples modelos
Problème : comparer Claude, GPT-4 et Llama local — bascule de config fastidieuse.
Solution :
Trois agents : claude-agent, gpt-agent, llama-agent.
Puntos clave:
LLM_PROVIDER y API_KEY diferentes por .env. La misma pregunta para los tres, comparación calidad/velocidad/costo.
Observación: Claude es el más confiable para el código; GPT-4 más natural en la conversación; Llama local lenta pero discreta para datos sensibles.
Consejos:
- Denominación:
escenario-fecha-de-uso, p.e.cliente-nike-backend-20260201 - Alternar: varias cuentas de Telegram, un agente por cuenta
- Recursos:
docker stopen llama-agent cuando no se usa
Configura tu primer par de agentes
Requisitos previos: Docker y OpenClaw instalados (de lo contrario, consulte la guía oficial de introducción).
Objectif : work et personal
Étape 1 : fichiers de config
cd openclaw
cp .env .env.work
cp .env .env.personal
Paso 2: agente de trabajo
En .env.work:
AGENT_NAME=work-agent
WORKSPACE_PATH=/path/to/your/work/directory
TELEGRAM_BOT_TOKEN=your_work_bot_token
ALLOWED_USERS=your_telegram_user_id
Paso 3: agente personal
En .env.personal:
AGENT_NAME=personal-agent
WORKSPACE_PATH=/path/to/your/personal/directory
TELEGRAM_BOT_TOKEN=your_personal_bot_token
CONTAINER_PORT=8001 # port différent
Étape 4 : démarrage
docker-compose --env-file .env.work up -d
docker-compose --env-file .env.personal up -d
Attendre Status: Running.
3 pruebas de aislamiento
Prueba 1: archivos
- agente de trabajo: “Crear test.txt con ‘datos de trabajo’”
- agente personal: “Listar los archivos en el directorio”
- Resultado: no hay test.txt en el lado personal
Prueba 2: conversación
- agente de trabajo: “Recuerda que el código de mi proyecto es ProjectX”
- agente personal: “¿Cuál es el código de mi proyecto?” »
- Resultado: “No lo sé”
Prueba 3: características
.env.work:ENABLE_CODE_EXECUTION=true.env.personal:ENABLE_CODE_EXECUTION=falso- Resultado: ejecución autorizada sólo en obra.
Solución de problemas:
- Puerto ocupado:
CONTAINER_PORTúnico por agente - Silenciar bot: token y
ALLOWED_USERS - Permisos: derechos a
WORKSPACE_PATHpara Docker
Astuces avancées et pièges
Rendimiento: no saturar la máquina
Cinq agents au départ → ventilateur à fond, 8 Go de RAM. Optimisations :
Limites de ressources
deploy:
resources:
limits:
cpus: '0.5'
memory: 512M
Comienza bajo demanda
# start-sandbox.sh
docker start sandbox-agent-container
# après usage
docker stop sandbox-agent-container
Imagen base compartida
Una imagen de OpenClaw, diferentes configuraciones: ~1 a 2 GB para cinco agentes, no cinco copias completas.
Seguridad: la comodidad no debe prevalecer
Mínimo privilegio
Sube sólo por los caminos necesarios. El agente personal no necesita /trabajo.
Datos confidenciales
Claves API en variables de entorno, nunca difíciles. Compruebe que .env no esté en Git.
Audit régulier
docker logs work-agent-container --since 7d | grep ERROR
Dépannage courant
Agent ne démarre pas
docker logs <container_name>- Souvent port ou permissions Docker
Error de enrutamiento
- Token de Telegram,
ALLOWED_USERS, prueba de botcurl
Permisos de archivos
- Host vs contenedor UID/GID:
usuario: "${UID}:${GID}"en docker-compose.yml
La mayoría de los problemas se pueden ver en los registros.
Resumen y próximos pasos
Por qué: un único asistente mezcla contextos → fugas y pérdida de eficiencia. El enrutamiento multiagente aísla físicamente.
Comentario: varios agentes a través de distintos .env, directorios, entradas de correo y permisos. Cinco minutos para trabajo/personal.
Mejores prácticas: privilegio mínimo, apagado a pedido, auditoría periódica.
Uso diario: trabajo más concentrado, experimentación sin miedo, demostraciones sin sorpresas desagradables.
Acciones:
- Configure tu trabajo/personal hoy: no es difícil
- Preguntas: Problemas de GitHub o Discord de OpenClaw
- Compartir con quienes también viven la “mezcla de contextos”
La IA debería hacer la vida más fácil, no confusa. El enrutamiento multiagente significa orden: cada asistente en tu lugar, flujo de trabajo más claro.
Pruébalo, te lo agradecerás.
Configurar el flujo de doble agente en OpenClaw
Configurar work y personal desde cero para aislar trabajo y vida personal
Estimated time: PT10M
-
1
Step 1: Preparar archivos de configuración
Copia la configuración predeterminada para dos agentes: -
2
Step 2: Configurar work-agent
Edita .env.work: -
3
Step 3: Configurar personal-agent
Edita .env.personal, evita conflictos con work: -
4
Step 4: Iniciar y verificar el aislamiento
Arranca ambos agentes y prueba: -
5
Step 5: Uso y mantenimiento
Tras la puesta en marcha: -
6
Step 6: • Auditoría: docker logs
grep ERROR
FAQ
¿Por qué priorizar el aislamiento a nivel de agente en lugar de a nivel de sesión?
• Aislamiento de sesión: nuevo contenedor para cada conversación, destruido al final; adecuado para tareas puntuales, pero requiere reconfigurar el entorno.
• Aislamiento de agentes: contenedor persistente, configuración duradera, siempre disponible: este es el modo de mis agentes personales/de trabajo
En la práctica: el aislamiento del agente se ejecuta continuamente, las respuestas rápidas (sin esperas para la creación del contenedor), las variables de entorno y las dependencias se conservan, ideal para los flujos de trabajo diarios. Desventaja: consumo de recursos, mitigado por la parada de Docker para agentes no utilizados.
Plusieurs agents consomment-ils trop de mémoire et de disque ?
Memoria:
• Limite cada agente a 512 MB (resources.limits en docker-compose.yml)
• 5 agentes ≈ 2,5 GB: caben fácilmente en una computadora portátil
• parada de ventana acoplable para agentes poco utilizados
Disco:
• Todos los agentes comparten la misma imagen base de OpenClaw (~500 MB)
• Datos adicionales por agente: a menudo <100 MB
• 5 agentes: 1 a 2 GB en total, no 5×500 MB
Mi configuración: 3 agentes permanentes (trabajo/personal/sandbox), 2 bajo demanda: 16 GB de RAM sin problema.
¿Cómo evitar confundir los tokens de Telegram de diferentes agentes?
Bots:
• Trabajo: @my_work_bot, @company_project_bot
• Personal: @my_personal_bot, @my_hobby_bot
• Experimentación: @my_sandbox_bot
Cambio rápido:
• Múltiples cuentas de Telegram, un bot por cuenta (desliza para cambiar)
• O una sola cuenta, distinga por @work vs @personal
• Avatares de diferentes colores (azul de trabajo, verde personal, amarillo sandbox)
Gestión:
• Tokens centralizados en un administrador de contraseñas (1Password/Bitwarden)
• Comentarios en .env
• Verifique .gitignore regularmente para evitar comprometer tokens
personal-agent peut-il accéder aux fichiers de work-agent ?
Mecanismos:
• Separe WORKSPACE_PATH por agente (/trabajo vs /personal)
• Montaje de Docker limitado al directorio del agente: aislamiento del sistema operativo
• Archivo creado por el agente A inaccesible para el agente B
Necesito compartir:
• Posible volumen compartido: /shared:/shared:ro (más seguro de solo lectura)
• No recomendado: debilita el aislamiento; mejor copiar manualmente
Mi práctica: laboral y personal completamente separadas; compartir a través de Git o la nube si es necesario.
¿Puede el agente sandbox sin red seguir utilizando un modelo de IA?
Límites sin conexión:
• ENABLE_NETWORK=falso → no OpenAI/Claude/etc.
• Adecuado para pruebas de archivos/scripts sin inferencia en la nube
Soluciones:
• Modelos locales (Llama/Mistral) vía Ollama en el sandbox
• O red limitada: firewall que solo permite ciertos dominios API
• Mi configuración: red habilitada pero HOST_FILESYSTEM_MODE=solo lectura: IA autorizada, sin escritura en el host
Escenarios:
• Pruebas de archivos puros: fuera de línea + FS de solo lectura
• Experimentos con IA: red + permisos estrictos de archivos
• Adaptar el aislamiento al nivel de riesgo
¿Cómo configurar ALLOWED_USERS para un equipo?
Ejemplos:
• Un usuario: ALLOWED_USERS=123456789
• Múltiples: ALLOWED_USERS=123456789,987654321,555666777
• Equipo: agente de equipo para todos los miembros, agente privado solo para usted
Obtenga las identificaciones:
1. Cada miembro envía un mensaje a @userinfobot
2. El administrador recopila y configura .env.work
3. Reiniciar: reinicio de Docker-Compose
Seguridad:
• Audite ALLOWED_USERS regularmente, elimine las salidas
• Proyectos sensibles: agente dedicado, solo miembros del proyecto
• Registros con ID de usuario para trazabilidad
Mi práctica: agente de equipo para 5 personas, agente privado en solitario.
Agente que no inicia por error de configuración: ¿qué hacer?
Paso 1: registros de contenedores
• registros de la ventana acoplable <container_name>
• ~90% de los errores aparecen allí (puerto, permisos, configuración)
Errores comunes:
• Puerto ocupado: cambiar CONTAINER_PORT (8001/8002…)
• WORKSPACE_PATH no existe: verifique la ruta o cree el directorio
• Token de Telegram no válido: @BotFather, cuidado con los espacios
• Permiso denegado: chmod 755 en WORKSPACE_PATH
Depurar:
• Comparar con un agente que funcione
• Configuración mínima: AGENT_NAME, WORKSPACE_PATH, TELEGRAM_BOT_TOKEN
• Agregar opciones una por una
Último recurso: docker-compose down && docker-compose up: el aislamiento de Docker le permite comenzar de nuevo.
8 min de lectura · Publicado el: 5 feb 2026 · Actualizado el: 21 ago 2026
Despliegue y práctica de OpenClaw
Si llegaste desde búsqueda, lo más rápido es ir al artículo anterior o siguiente de esta misma serie.
Anterior
Sistema de memoria local OpenClaw: almacenamiento de memoria AI en Markdown
Análisis profundo de la memoria persistente de OpenClaw mediante archivos Markdown: arquitectura de dos niveles, búsqueda híbrida y protección de la privacidad local.
Parte 14 de 36
Siguiente
Análisis en profundidad de la arquitectura OpenClaw: principios del diseño en tres capas y práctica de extensión
Análisis profundo de la arquitectura en tres capas de OpenClaw: principios técnicos de gestión de sesiones Gateway, enrutamiento de mensajes Channel e interfaz LLM, con guía práctica para desarrollo personalizado y extensión.
Parte 16 de 36



Comentarios
Inicia sesión con GitHub para dejar un comentario