Adaptadores RPC en OpenClaw: Cómo conectar CLIs externas

¿Alguna vez has intentado integrar una herramienta de línea de comandos externa en tu aplicación y has terminado peleando con procesos que se cuelgan o comunicaciones inconsistentes? Gestionar el ciclo de vida de herramientas de terceros y asegurar que los mensajes lleguen correctamente suele ser un desafío técnico tedioso que complica el mantenimiento de cualquier Gateway.

Para solucionar esto, OpenClaw utiliza adaptadores RPC que estandarizan la comunicación con CLIs externas mediante JSON-RPC. Aquí te explico cómo funcionan estos patrones y cuál deberías elegir para tu integración.

Requisitos previos

• Una instancia activa de OpenClaw.
• Configuración previa de Signal o iMessage.

Inicio rápido

OpenClaw utiliza dos patrones principales para conectar con herramientas externas. Elige el que corresponda a tu proveedor:

Patrón A: Daemon HTTP (Recomendado para Signal)

Este patrón es ideal para herramientas como signal-cli que funcionan de forma persistente.

• Funcionamiento: La herramienta corre como un daemon y se comunica mediante JSON-RPC sobre HTTP.
• Eventos: Utiliza un flujo de eventos SSE en /api/v1/events.
• Salud: El Gateway monitorea el estado en /api/v1/check.
• Control: Si estableces channels.signal.autoStart=true, OpenClaw gestiona automáticamente el inicio y cierre del proceso.

Patrón B: Proceso hijo stdio (Legacy)

Este método se utiliza para la integración antigua de iMessage mediante imsg.

• Funcionamiento: OpenClaw lanza imsg rpc como un proceso hijo.
• Comunicación: JSON-RPC delimitado por líneas a través de stdin y stdout.
• Simplicidad: No requiere puertos TCP ni daemons externos.

Nota: Si vas a configurar iMessage desde cero, te recomiendo usar BlueBubbles en lugar de este método legacy.

Solución de problemas

Si encuentras problemas de conexión o pérdida de mensajes, revisa estos puntos basados en los lineamientos del adaptador:

• Identificadores inestables: Evita usar strings de visualización para referenciar chats. Prefiere siempre identificadores estables como chat_id.
• Caídas de proceso: Los clientes RPC deben ser resilientes. Configura reinicios automáticos al detectar que el proceso hijo ha finalizado.
• Bloqueos por timeout: Asegúrate de implementar timeouts en tus peticiones para evitar que el Gateway quede esperando indefinidamente.
• Métodos fallidos: Verifica que estás utilizando los métodos core correctos: watch.subscribe, watch.unsubscribe, send o chats.list.

---

¿Necesitas ayuda con una configuración específica? Prueba el AI Setup Assistant.

Próximos pasos

• Configuración de Signal
• Configuración de BlueBubbles
• Configuración de iMessage (Legacy)
• Guía de Gateways