Cambiar tema

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

Easton editorial illustration: tool-socket control board

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_NAME distinto 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 stop en 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_PATH para 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 bot curl

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:

  1. Configure tu trabajo/personal hoy: no es difícil
  2. Preguntas: Problemas de GitHub o Discord de OpenClaw
  3. 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. 1

    Step 1: Preparar archivos de configuración

    Copia la configuración predeterminada para dos agentes:
  2. 2

    Step 2: Configurar work-agent

    Edita .env.work:
  3. 3

    Step 3: Configurar personal-agent

    Edita .env.personal, evita conflictos con work:
  4. 4

    Step 4: Iniciar y verificar el aislamiento

    Arranca ambos agentes y prueba:
  5. 5

    Step 5: Uso y mantenimiento

    Tras la puesta en marcha:
  6. 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?
El aislamiento a nivel de agente es más adecuado para uso a largo plazo:

• 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 ?
Con una configuración razonable, el consumo queda bajo control:

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?
Convención de nomenclatura y consejos de cambio:

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 ?
Por defecto, no: este es el corazón del aislamiento físico:

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?
Sin red, no hay API en la nube, pero posibles modelos locales:

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?
Múltiples usuarios autorizados, separados por comas:

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?
Diagnóstico sistemático:

Paso 1: registros de contenedores
• registros de la ventana acoplable &lt;container_name&gt;
• ~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

Comentarios

Inicia sesión con GitHub para dejar un comentario

Easton BlogEaston Blog