Módulo 3 · Parte A de 3

Conecta el stack de NemoClaw

En los Módulos 1 y 2, mantuvimos la orquestación en el navegador y cada workflow terminaba cuando la página dejaba de conservar sus mensajes, resultados intermedios o el estado de sus ramas. El Módulo 3 traslada los mismos patrones de agentes a un launchable de NemoClaw en Brev.

Los principales componentes funcionales de este despliegue son:

Endpoint del LLM. Convierte los prompts y los resultados de las herramientas en respuestas semánticas, pero no conserva el estado de la sesión del agente.
Entorno de ejecución de OpenClaw. Conserva el historial de la sesión, un workspace respaldado por archivos y el acceso a herramientas.
Sandbox de OpenShell. Limita lo que puede alcanzar el agente en ejecución.
Blueprint de NemoClaw. Configura OpenClaw y OpenShell para que funcionen juntos.

En esta lección, conectarás el navegador al launchable, inspeccionarás sus cuatro rutas de conexión, usarás una llamada directa al modelo como control, enviarás un turno del agente con herramientas a través del gateway y comprobarás que una sessionKey restaura el historial que el cliente no reenvió.

Funciones del runtime en el blueprint de NemoClaw, adaptadas del workflow NemoClaw for OpenClaw de NVIDIA.

Inicia el launchable

Abre el launchable de NemoClaw e inicia sesión.
Abre <launchable>/dashboard.
Busca la tarjeta my-assistant en ejecución y selecciona Chat with Agent.
Vuelve aquí e introduce la URL del launchable. Si el curso no se sirve desde el launchable, pega también la sesión de acceso del navegador del launchable.

Copia la sesión de acceso al launchable cuando esta página se aloje por separado

El token del gateway y la sesión de acceso al launchable autorizan cosas distintas:

El token del gateway autoriza las llamadas JSON-RPC en /cli/gateway.
La sesión de acceso, una cookie del navegador _pomerium o CF_Authorization, autoriza el acceso a los launchables anteriores, y los launchables de Skybridge usan __Host-skybridge-brev-prd para el mismo propósito.

Si el curso no se sirve desde el launchable, copia esa cookie del navegador en el campo Sesión de acceso que aparece abajo:

Mantén abierta la pestaña del launchable donde iniciaste sesión y usa __Host-skybridge-brev-prd para un host gobrev.dev, _pomerium para un host apps.run.brev.nvidia.com o CF_Authorization para un host brevlab.com.
Chrome, Edge o Brave: abre las herramientas para desarrolladores, selecciona Application (Aplicación) → Storage (Almacenamiento) → Cookies y elige el origen del launchable.
Firefox: abre las herramientas para desarrolladores, selecciona Storage (Almacenamiento) → Cookies y elige el origen del launchable.
Safari: si es necesario, activa las funciones de desarrollo web en Settings (Ajustes) → Advanced (Avanzado), abre el Inspector web y selecciona Storage (Almacenamiento) → Cookies y el origen del launchable.
Busca el nombre de cookie correspondiente y copia solo su Value (Valor) completo. No copies todo el encabezado Cookie ni pegues el valor en ningún lugar que no sea el campo Sesión de acceso de esta página.

Si la comprobación de NemoClaw agota el tiempo de espera o devuelve un 502. Inspecciona la ruta que falló, los diagnósticos de conexión y los registros del runtime del launchable antes de elegir cómo recuperarlo. Un tiempo de espera agotado o un 502 por sí solos no identifican la causa. Si la puerta de enlace sigue sin estar disponible, inspecciona la celda Recover de abajo y sus comprobaciones antes de continuar.

Inspecciona las cuatro rutas de conexión

La prueba de conexión y el código visible comparten la conexión normalizada del launchable y la decisión del proveedor. Ejecuta la celda editable para probar, en orden, los metadatos del agente, el gateway, la terminal y el estado; después, inspecciona el resultado renderizado automáticamente con los datos sensibles ocultos.

Un launchable de Pomerium mantiene directo el tráfico de arranque y WebSocket: las comprobaciones HTTP se ejecutan mediante el loopback de su terminal. Cloudflare envía las comprobaciones HTTP mediante el relay aprobado; sus WebSockets prueban primero el launchable y pueden recuperarse mediante el relay. La comprobación muestra la ruta sin revelar la sesión.

Paso 1 · Establece el control directo del modelo

Las comprobaciones anteriores del launchable demuestran que el stack en ejecución es accesible. Antes de enviar un turno del agente, realiza una solicitud directa de Chat Completions mediante la ruta del modelo utilizada en los Módulos 1 y 2. Este control no tiene una sesión de OpenClaw ni herramientas del gateway, de modo que el Paso 2 pueda mostrar lo que agrega el entorno de ejecución. No inspecciona ni reconfigura el modelo dentro de tu launchable.

Confirma la conexión directa al modelo

La tarjeta de configuración refleja la ruta del modelo del curso guardada en la página de inicio o en el Módulo 1a. Cámbiala solo si falla la sonda directa. La ruta del modelo del curso y la conexión al launchable conservan credenciales y estado separados.

Paso 2 · Opera el agente a través de su gateway

El Paso 1 estableció el control exclusivo del modelo: una solicitud POST de Chat Completions contenía el modelo, los mensajes y la autorización del emisor. OpenClaw llama a su modelo configurado dentro del launchable, pero esta página opera el agente en ejecución mediante una interfaz distinta.

El diagrama compara interfaces utilizadas en capas distintas, no una sola ruta de solicitud:

Tres interfaces en capas distintas: HTTP acotado para el modelo, integración de herramientas mediante MCP dentro del runtime y el WebSocket activo hacia el gateway de OpenClaw.

REST (transferencia de estado representacional). El control directo del modelo del Paso 1 utiliza una solicitud HTTP acotada y su respuesta. Una API puede seguir identificando estado del servidor entre llamadas.
Model Context Protocol (MCP). Dentro del runtime de un agente, MCP estandariza el descubrimiento y la invocación de herramientas y contexto. No transporta el tráfico del gateway de este navegador.
Gateway de OpenClaw. El ejercicio siguiente y la interfaz de control utilizan el mismo WebSocket /cli/gateway. Transporta eventos JSON-RPC entre el cliente del navegador y el agente en ejecución.

Autoriza el gateway

Para acceder al launchable y operar su gateway se requieren credenciales distintas:

Acceso al launchable. La sesión del navegador permite alcanzar el host.
Autoridad del gateway. El token del gateway autoriza las llamadas JSON-RPC.

Después de autenticarte en el launchable, GET /api/agent devuelve el token del gateway en agent.dashboardUrl. Deja vacío el campo del token y permite que la sonda lo complete.

Ese token tiene asignado el alcance operator.admin, la misma autoridad que la interfaz de control. Con él puedes hacer lo siguiente:

models.list enumera todos los modelos que ofrece el runtime.
cron.add programa trabajo que se ejecuta sin tu intervención.
chat.send con una sessionKey envía un mensaje directamente al bucle del agente en ejecución.

Una solicitud chat.send inicia un ciclo dentro de la puerta de enlace; la clave de sesión permite recuperar el contexto en la siguiente llamada.

Comprueba antes de cambiar el runtime

Los launchables compatibles de NemoClaw suelen mostrar tools.toolSearch=false. Una configuración personalizada aún puede activarlo, por lo que la comprobación de estado lee el valor activo antes de que Recuperar cambie algo:

Síntoma: pides un comando, no llega ninguna respuesta, la ejecución se detiene y termina por agotar el tiempo de espera.
Causa: toolSearch permite que el modelo acceda a herramientas escribiendo código para un puente (tool_search_code · “run bridge code”). El modelo puede quedar atrapado en ese puente en lugar de llamar exec.
Recuperación: ejecuta la comprobación de estado. Si toolSearch está activado y falla la sonda de exec, Recuperar puede desactivarlo con config.patch. La limpieza de sesiones y el reinicio siguen siendo opcionales.

La ruta saludable usa exec directamente. Recuperar cambia toolSearch solo cuando la comprobación activa lo encuentra habilitado.

Las tres celdas siguientes conectan con el gateway, enumeran los modelos y las tareas programadas y, después, envían un turno de chat y muestran su traza. Lee la traza fila por fila:

Cada fila ⚙️ es una llamada a herramienta con sus argumentos de entrada.
Cada fila ✓/✗ es el resultado de esa herramienta.
El razonamiento del modelo no se envía por el gateway, por lo que esta traza de entrada y salida ofrece la vista por pasos más detallada. Cuando una ejecución se detenga sin resultado, usa la celda de logs anterior para monitorizar el runtime.

Si un chat falla o alcanza su plazo máximo, inspecciona la traza y ejecuta Health check. Usa Recover solo si esos resultados señalan un problema de configuración o de sesión.

Cualquiera que pueda leer el entorno del launchable también puede leer ese token; quien posea el token es un operador con todas las capacidades anteriores. El Módulo 4 convierte esta comodidad en la pregunta central de seguridad.

Paso 3 · Compara el historial de la conversación

Introduce un código nuevo, pide que lo recuerde sin volver a enviarlo, restablece esa sesión y pregunta de nuevo. El restablecimiento elimina el historial de la conversación; los archivos compartidos del espacio de trabajo permanecen. Estos prompts piden al agente que no guarde el código en un archivo. Examina los eventos antes de interpretar el resultado.

La limpieza elimina solo los identificadores de sesión creados por este flujo. Vuelve a ejecutar únicamente el paso de recuperación para preguntar sin introducir de nuevo el código.

La clave de sesión es lo único que envía el cliente para identificar una conversación. A partir de esa cadena, la puerta de enlace resuelve la sesión completa en el servidor antes de cada llamada, por lo que el cliente no tiene que enviar la transcripción. Los identificadores de sesión distintos separan las conversaciones. La puerta de enlace también puede aceptar alias para una misma conversación, como una clave corta y su forma canónica agent:<agent-id>:<key>.

Qué sigue

El Módulo 3b abre los archivos que configuran cada turno de OpenClaw. El Módulo 3c añade skills y activadores programados; después, el Módulo 4 comprueba cómo OpenShell limita las acciones que esas instrucciones persistentes pueden iniciar.

Referencias

OpenAI Chat Completions API. El formato del endpoint del modelo, incluido el campo finish_reason que muestra esta página.
NVIDIA build.nvidia.com. La API del modelo detrás del proxy configurado. Comprueba sus requisitos de autenticación antes de introducir una credencial bearer.
Anthropic, Claude Code (docs). El patrón de directorio como sesión que la siguiente página aplica al editar la configuración de OpenClaw.
Park et al., Generative Agents (2023). Presenta memoria e identidad mantenidas en el servidor como estructuras duraderas del runtime, patrón implementado aquí mediante la clave de sesión.

Lista completa en Para ir más lejos · Referencias.

Prueba · conversa con tu launchable

Cuando la sonda anterior esté en verde, este artefacto abrirá el mismo WebSocket en /cli/gateway y te permitirá conversar con el agente OpenClaw activo. Transmitirá la respuesta y mostrará un indicador cada vez que el agente solicite una herramienta. Todas las respuestas que veas aquí se han recibido mediante esa conexión en vivo con el gateway.

← Módulo 2c: Agentes de investigación profunda Módulo 3b: OpenClaw →