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 al launchable.

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. Usa _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 prueba de NemoClaw agota el tiempo de espera o devuelve 502. Es probable que el entorno del agente aún no haya terminado de arrancar. Esto suele ocurrir cuando el launchable se inicia antes de que OpenClaw termine de cargar su política YAML. Espera 30 segundos y vuelve a probar. Si sigue sin responder, usa la celda Recuperar de la sección del gateway 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.

Un único POST activa un bucle dentro del gateway, donde la clave de sesión conserva la memoria para la llamada siguiente.

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 débil 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.

Una vez preparado el runtime, puedes enviar un mensaje al bucle del agente. Ejecuta los tres nodos siguientes en orden: el primero conecta con el gateway; el segundo enumera modelos y tareas cron; el tercero envía un turno de chat y transmite la 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.

Cada ejecución de chat comprueba su estado. Si aparece ⚠ DEGRADED, vuelve aquí, ejecuta Recuperar y repite el intento.

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 · La memoria vive en la clave de la sesión

Cada chat.send recibe una sessionKey, que determina lo que el turno recuerda:

La misma clave, dos veces: el gateway restaura el historial del primer turno antes de ejecutar el segundo, por lo que el agente responde a partir de una conversación que el cliente nunca volvió a enviar.
Una clave distinta: comienza desde cero, sin conservar nada.

La primera celda introduce un dato y después pide recuperarlo con la misma clave. El agente responde a partir de un turno que tu cliente nunca reenvió, porque el gateway reconstruyó ese historial en el servidor. Las otras dos celdas te permiten gestionar el estado almacenado:

Limpiar borra una sesión con una sola llamada; el turno siguiente comienza sin historial. Cada celda de chat también contiene una línea sessions.reset comentada para reiniciar allí mismo.
Limpiar sesiones elimina las sesiones desechables acumuladas durante las pruebas, incluidas las claves por ejecución del Paso 2, y conserva únicamente la sesión principal.

La clave de sesión es la única identificación de la conversación enviada por el cliente. A partir de ella, el gateway recupera en el servidor toda la sesión antes de cada llamada; el cliente no necesita reenviar la transcripción. Dos claves diferentes siempre identifican sesiones separadas, aunque las conversaciones tengan contenido idéntico.

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 de modelos que utiliza el proxy del curso; pega tu clave nvapi- en el campo de autenticación.
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 utilice 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 →