Visión general de la arquitectura de OpenClaw

源码版本v2026.6.11

En una frase

OpenClaw es un asistente de IA personal con gateway (gateway) residente + entrada multicanal + bucle principal de agent: el gateway recibe el mensaje → lo pasa al agent → el agent llama repetidamente al modelo y a las herramientas → el resultado se entrega de vuelta a cada canal a través del gateway. Todas las capacidades (herramientas/skills/plugins/providers/MCP/canales) son registros (registries) conectables.

Capas

Una frase por capa

• Inicio y entrada: openclaw.mjs verifica la versión de Node y reenvía a src/entry.ts, que a su vez es despachado por subcomando por src/cli/run-main.ts.
• Capa del gateway: startGatewayServer es el proceso residente, recibe peticiones vía la tabla de métodos RPC y hace broadcast de los eventos del agent a los clientes WebSocket.
• Bucle principal del agent: el while(true) de embedded-agent-runner conduce cada turno de conversación; un único attempt completa la llamada LLM y el emparejamiento tool_use/tool_result.
• Capa de capacidades: las herramientas son un Map registrado, los skills son instrucciones Markdown que el modelo lee de SKILL.md, los plugins se descubren por convención de directorio, los providers se ramifican por proveedor, MCP puentea en ambos sentidos.
• Capa de canales: 22 canales (WhatsApp/Telegram/Slack...) se integran vía registry + loader + plugin, gestionados de forma unificada por el gateway.
• Sistema de configuración: openclaw.json es la única entrada de configuración, validada en ejecución por un Zod schema.
• Memoria y contexto: Context Engine abstrae el contrato de compactación (compaction); los archivos de memoria se almacenan en la raíz del workspace.
• Scheduling y extensión: Cron ejecuta jobs en una sesión aislada de agent, Tasks usa SQLite para persistencia, ACP puentea con el IDE.
• Despliegue: el gateway es un proceso residente; el daemon lo envuelve como servicio del sistema, o se ejecuta vía Docker/Fly.

Motivación de la estratificación

¿Por qué esta separación? OpenClaw desacopla completamente «de dónde vienen los mensajes» (canales), «cómo se procesan» (bucle del agent), «qué capacidades se usan» (herramientas/skills/plugins/provider), «cómo persisten» (configuración/memoria/scheduling) y «cómo se ejecuta» (despliegue). Así, cambiar de canal no afecta a la lógica del agent, cambiar de modelo no afecta a las herramientas, añadir un plugin no requiere tocar el núcleo. El gateway es el único hub central; toda coordinación entre capas pasa por él.

Lecturas equivocadas habituales

• «OpenClaw es un bot de chat»—no del todo. El bot no es más que una cara de la capa de canales; el gateway es el núcleo del producto, y el bucle del agent es el cerebro.
• «Herramientas y skills son lo mismo»—no lo son. Las herramientas son funciones invocables; los skills son instrucciones en Markdown que el propio modelo decide cuándo leer y qué hacer tras leerlas.
• «MCP es solo un client»—OpenClaw es a la vez MCP server (expone sus capacidades a terceros) y client (consume servidores MCP externos).

Orden de lectura recomendado

Empieza por Inicio y entrada, luego consulta Núcleo del gateway y Bucle principal del agent; después sigue el orden Capa de capacidades → Capa de canales → Sistema de configuración → Memoria → Scheduling → Despliegue.

Referencias oficiales: OpenClaw website · Documentación oficial · DeepWiki.