Creé un sistema operativo colaborativo de IA de 5 roles con OpenClaw: Un desglose técnico completo

He pasado mucho tiempo transformando OpenClaw de un asistente único a un sistema operativo colaborativo multirol. No se trata simplemente de "abrir varios bots para chatear por separado".

5 roles de IA, compartiendo una única puerta de enlace, funcionando en canales duales de Discord y Telegram, con una clara división de trabajo, enrutamiento, aislamiento de memoria y reglas de colaboración, capaces de trabajar en relevo como un equipo.

En este artículo, desgloso todo el proceso de construcción, las decisiones de diseño en cada capa, las configuraciones específicas y los problemas con los que me encontré.

Si también estás usando OpenClaw o te interesa "cómo hacer que múltiples IAs realmente colaboren", este artículo debería ayudarte a evitar muchos rodeos.

Conclusión primero: Esto no es "multi-bot", es un sistema operativo multi-agente bajo una única puerta de enlace

Cuando muchos escuchan "5 roles de IA", su primera reacción es: estás ejecutando 5 bots independientes, ¿verdad?

Sí, pero también no.

Mi arquitectura es así:

• 1 proceso de puerta de enlace (Gateway), unificando el acceso a los canales y el enrutamiento
• 5 Agentes independientes: Comandante, Estratega, Ingeniero, Creador, Pensador
• Cada Agente tiene su propio espacio de trabajo independiente (personalidad, reglas, memoria y sesiones están completamente aislados)
• Ejecutando canales duales Discord + Telegram simultáneamente (puede ejecutar muchas plataformas, pero solo uso Discord), usando bindings para una distribución precisa de mensajes
• Los chats privados y grupales utilizan mecanismos completamente diferentes

Una analogía: Esto no es contratar a 5 personas y ponerlas en una sala para que actúen libremente. Esto es construir una empresa: con estructura organizativa, descripciones de trabajo, protocolos de comunicación, oficinas independientes y reglas de reuniones.

OpenClaw en sí mismo es un framework de asistente de IA personal de código abierto que soporta múltiples plataformas (Discord, Telegram, WhatsApp, etc.) y múltiples modelos (Claude, GPT, Gemini, etc.), con datos completamente localizados.

Su capacidad multi-agente es la razón principal por la que lo elegí: soporte nativo para espacios de trabajo independientes multi-agente + enrutamiento mediante bindings, lo que me permitió construir un verdadero sistema colaborativo sobre él.

1. Arquitectura General: Puerta de enlace única + Multi-agente + Multi-espacio de trabajo + Multi-canal

Primero, hablemos de las decisiones arquitectónicas de nivel inferior.

1) Alojamiento unificado mediante una única puerta de enlace (Gateway)

Actualmente tengo un proceso de puerta de enlace de OpenClaw que gestiona todas las capacidades: acceso a mensajes, enrutamiento, gestión de sesiones, llamadas a herramientas, indexación de memoria y gestión de estados, todo en una sola puerta de enlace.

¿Por qué no ejecutar un conjunto de servicios para cada rol? Tres razones:

• Mantenimiento centralizado: Solo hay que mantener una puerta de enlace, sin necesidad de ejecutar servicios independientes para cada rol.
• Configuración unificada: Una configuración maestra gestiona las estrategias globales, y la monitorización y resolución de problemas también están centralizadas.
• Base de colaboración: Para que los roles colaboren, deben estar en el mismo entorno de ejecución para una comunicación eficiente.

2) 5 Agentes en paralelo, no 5 bots sueltos

Mis 5 roles fijos:

• Comandante (zongzhihui): Conciencia situacional global, descomposición de tareas, asignación, corrección y cierre.
• Estratega (junshi): Análisis estratégico, evaluación de propuestas y predicción de riesgos.
• Ingeniero (engineer): Ejecución técnica, implementación de código y mantenimiento del sistema.
• Creador (creator): Creación de contenido, optimización de expresión y salida externa.
• Pensador (zhiku): Auditoría de conocimiento, control de calidad y verificación de cumplimiento.

Cada agente tiene su propio espacio de trabajo, como workspace-engineer, workspace-junshi, etc. Los archivos de personalidad, archivos de reglas, archivos de memoria y activos de scripts son completamente independientes y no se contaminan entre sí.

3) Acceso de doble pila multicanal: Discord + Telegram

La misma puerta de enlace está conectada tanto a Discord como a Telegram. Cada rol tiene bindings a nivel de accountId en ambos canales. Por supuesto, puedes usar este mismo archivo de configuración para integrar más plataformas como Lark, WeChat, etc.

Esto no es "implementación duplicada entre plataformas", sino "el mismo grupo de cerebros, diferentes capas de acceso". Configuré Discord como el campo de batalla principal de colaboración.

Si quieres que múltiples agentes cooperen y colaboren dentro de un grupo, simplemente elige Discord; una plataforma es suficiente. Otras no son perfectas, ¡lo he intentado!

2. Capa de enrutamiento: Bindings que mapean "cuentas" a "roles"

Esta es la lógica de entrada de todo el sistema.

Configuré una estrategia de binding explícita para canales duales: channel + accountId -> agentId.

Específicamente:

• discord + zongzhihui -> zongzhihui
• discord + engineer -> engineer
• telegram + creator -> creator
• ... un total de 10 mapeos (5 roles × 2 canales)

¿Por qué hacer esto?

Porque el sistema decide "quién debe manejar este mensaje" en la capa de entrada, en lugar de dejar que todos los agentes lo escuchen y luego se apresuren a responder. Si este paso no se hace bien, toda la colaboración posterior será un caos.

Puedes pensar en los bindings como el "triage de recepción" de este sistema. Cuando llega un mensaje, primero verifica qué canal y cuenta lo recibió, luego lo enruta directamente al rol correspondiente: limpio y eficiente.

3. Aislamiento de sesiones: Por qué los chats privados no se cruzan y los chats grupales no son un desastre

Este es uno de los puntos de ingeniería más críticos en mi sistema.

Configuración central: session.dmScope = per-account-channel-peer

Este parámetro significa: El contexto del chat privado está aislado por tres dimensiones: "cuenta + canal + usuario par."

¿Por qué elegir esto?

• Si la misma persona contacta al mismo rol a través de Discord y Telegram, los contextos no se cruzan.
• Si diferentes usuarios contactan al mismo rol, los contextos están completamente aislados.
• En escenarios multi-agente + multi-cuenta, el riesgo de "interferencia cruzada" se minimiza.

En otras palabras, no solo creé "multi-roles"; también hice "ingeniería de estrategia de aislamiento de contexto."

Muchas personas construyen sistemas multi-agente donde los roles están claramente divididos, pero la gestión del contexto es un desastre: el contenido del chat privado del Usuario A termina en la respuesta del Usuario B, o la memoria de la conversación de Discord contamina el contexto de Telegram.

per-account-channel-peer es la estrategia de aislamiento recomendada por OpenClaw para escenarios multi-cuenta, y mis pruebas muestran que es, de hecho, la opción más estable.

4. Orquestación de chats grupales: Colaboración impulsada por reglas, no charla libre

Esta parte es la más interesante y tiene más trampas.

Estrategia central: Comandante con escucha global + Otros roles activados por @

Mi estrategia de chat grupal en el lado de Discord es la siguiente:

Comandante: requireMention = false (Escucha global)

• Puede ver todos los mensajes en el grupo por defecto.
• Responsable de captar la situación global, juzgar si se necesita colaboración, realizar la descomposición de tareas y asignar trabajo.

Otros 4 roles: `requireMention = true` (Activado por @)

• Solo actúan cuando se les menciona explícitamente con @.
• Reduce el ruido y evita que hablen unos sobre otros.

Cada rol está configurado con `mentionPatterns`

• Por ejemplo, el ingeniero puede ser activado por @Engineer o [@engineer](https://x.com/@engineer).
• Hace que la convocatoria en el grupo sea más estable y predecible.

¿Cuál es la esencia de esta combinación?

• El Comandante "ve el panorama general", como un PM en un equipo.
• Los roles especializados son "activados según sea necesario", como expertos en varias posiciones.
• El discurso grupal cambia de "forma libre" a "relevo controlado".

Efecto real: Haces una pregunta en el grupo, el Comandante primero juzga qué tipo de tarea es, luego @menciona al rol correspondiente para que la maneje. Una vez que el rol termina, el Comandante cierra el ciclo. Todo el proceso es como un equipo real teniendo una reunión.

5. Discord vs Telegram: Por qué Discord es el campo de batalla principal

Estrictamente hablando, no es que "solo Discord pueda colaborar". Es solo que, bajo mi configuración actual, Discord es el más adecuado para la orquestación de colaboración pública multi-rol.

Razones específicas:

1. Configuré 5 cuentas paralelas en Discord + un mecanismo de @colaboración claro.
2. Las identidades de los roles, las cadenas de conversación y el proceso de relevo son todos visibles: parece una discusión de equipo.
3. La estrategia de escucha global del Comandante + puerta de mención de otros roles es más intuitiva en escenarios de chat grupal.
4. Actualmente configuro el groupPolicy de Discord como open, lo que ofrece una mayor flexibilidad.

En el lado de Telegram, mi estrategia se inclina hacia allowlist + puerta de mención, que es más restringida y segura, adecuada para "canales de producción controlados".

Entonces, el resumen es: Discord es el escenario de colaboración.

6. Capa de configuración + Capa de prompt: Gobernanza de doble vía

Esta es la mayor diferencia entre este sistema y "simplemente jugar".

No confío únicamente en la configuración, ni únicamente en los Prompts. Uso dos vías superpuestas.

A. Vía de configuración (Control a nivel de plataforma)

Estas son configuraciones duras a nivel de plataforma de OpenClaw:

• channel policy: groupPolicy, dmPolicy, controlando las estrategias básicas para chats grupales y privados.
• requireMention: Quién debe ser @mencionado por defecto para responder.
• bindings: Mapeo de enrutamiento de mensajes.
• dmScope: Granularidad del aislamiento de sesiones.
• Límite de ping-pong agentToAgent: Lo configuré a 0, suprimiendo directamente el ir y venir sin sentido entre agentes.

El último es crucial: si no limitas el ping-pong entre agentes, verás dos IAs en un grupo siendo educadas, confirmándose mutuamente y en bucle infinito. Configurarlo a 0 le dice al sistema: los agentes no deben hacerse ping automáticamente entre sí.

B. Vía de reglas (Control a nivel de comportamiento)

Estos son los archivos de reglas que escribí en cada espacio de trabajo:

• SOUL.md: El archivo del alma del rol: personalidad, tono, responsabilidades y nivel mínimo de calidad de salida.
• AGENTS.md: Manual de operaciones: procesos de verificación de colaboración, normas de lectura/escritura de memoria y estrategias de carga diferida.
• ROLE-COLLAB-RULES.md: Límites de colaboración específicos del rol y líneas rojas.
• TEAM-RULEBOOK.md: Reglas duras unificadas para el equipo (compartidas por todos los roles).
• TEAM-DIRECTORY.md: Tabla de mapeo de roles a IDs reales para evitar @mencionar a la persona equivocada.

El efecto de superponer estas dos vías es: la capa de plataforma limita el flujo + la capa de comportamiento añade restricciones.

No se trata de poner todo en la "autoconciencia" del modelo. Los modelos cometen errores, se desvían y olvidan las reglas. Por lo tanto, las restricciones duras deben establecerse primero en la capa de configuración, seguidas de la guía suave en la capa de prompt. Doble seguro.

7. Sistema de archivos del espacio de trabajo: La "oficina independiente" de cada rol

El esqueleto de archivos para cada espacio de trabajo es básicamente consistente, lo cual es importante: muestra que estoy estandarizando, no solo amontonando archivos al azar para cada rol.

Estructura de archivos estándar

8. Sistema de memoria: Carga diferida + Capas + Archivado

La gestión de la memoria es la parte más fácil de pasar por alto pero la más problemática en un sistema multi-agente.

Mi estrategia no es "recordar tanto como sea posible", sino un claro分层:

1) Registros a corto plazo (memoria diaria)

• Registra los procesos de tareas del día, fragmentos de contexto y decisiones in situ.
• Los archivos se nombran por fecha, creando naturalmente una línea de tiempo.

2) Memoria a largo plazo (MEMORY.md)

• Destila preferencias estables, decisiones a largo plazo, experiencia reutilizable y reglas duras.
• No todo entra; solo se escribe información verificada y estable.

3) Memoria a largo plazo del grupo (GROUP_MEMORY.md)

• Solo retiene información reutilizable y segura del grupo.
• No mezcla contenido de chat privado; esta es una línea roja de privacidad.

4) Archivado en frío (archive)

• Los datos antiguos se archivan periódicamente para evitar que el contexto activo se expanda sin control.
• No se eliminan, sino que se mueven a un almacenamiento de baja prioridad.

5) Mecanismo de recuperación (memory_search + memory_get)

• Recuperación semántica primero, luego lectura precisa.
• Evita la carga completa: la ventana de contexto es un recurso limitado y no se puede desperdiciar.

El valor central de este分层:

• La calidad del chat privado no se contamina con el historial del chat grupal.
• La colaboración grupal no se ve interferida por el contexto privado personal.
• La ventana de contexto se "carga bajo demanda", no se "vierte completamente".

Trato el presupuesto de contexto como un problema de gestión de recursos. Los tokens son finitos; cada memoria que se guarda ocupa espacio de inferencia. Por lo tanto, cada bit debe calcularse cuidadosamente.

9. Modo privado vs Modo grupal: Dos estrategias para el mismo rol

Esto es algo que muchos no consideran: el mismo rol debe comportarse de manera diferente en chats privados y grupales.

Distingo explícitamente entre los dos modos en el SOUL.md de cada rol:

Modo Privado:

• Cada rol actúa como un experto en solitario, manejando los problemas del usuario de principio a fin.
• No se necesita proceso de colaboración; proporciona respuestas completas directamente.
• El estándar de calidad es "una persona puede manejarlo".

Modo Grupal:

• Realiza un relevo incremental según los protocolos de colaboración del equipo.
• Cada rol es responsable solo de lo que sabe hacer.
• El Comandante es responsable de enlazar y cerrar.

Específico para cada rol:

• Comandante: Permanece en silencio y observa por defecto en los grupos, solo interviene fuertemente cuando es necesario para evitar hablar sobre otros.
• Ingeniero: Los entregables deben ser ejecutables, verificables y reversibles, no solo proporcionar una idea.
• Estratega: Las conclusiones deben venir con suposiciones y vías de verificación, no solo improvisadas.
• Pensador: Las auditorías deben proporcionar una clasificación del problema + planes de reparación, no solo decir "hay un problema".
• Creador: La expresión no puede sacrificar la autenticidad y la ejecutabilidad, no solo perseguir la estética.

Esta es la fuente de "el mismo rol desempeñándose de manera diferente en diferentes escenarios". No depende del juicio del modelo, sino que se le dice explícitamente a través de archivos de reglas.

Palabras finales

Multi-Agente no es solo abrir algunos bots más. Es un sistema de ingeniería completo: desde el diseño arquitectónico, las estrategias de enrutamiento, el aislamiento de sesiones, la orquestación de la colaboración, la gestión de la memoria y la gobernanza de reglas hasta las comprobaciones automatizadas; cada capa necesita un diseño cuidadoso.

OpenClaw proporciona una gran base, pero la cantidad de ingeniería desde "ejecutable" hasta "funcionando bien" es mucho mayor de lo que la mayoría de la gente imagina.

Si estás haciendo algo similar, espero que este artículo te sirva de referencia. Por supuesto, este contenido es solo el comienzo; publicaré varios artículos más adelante para compartir más problemas "específicos y refinados".