El agente OpenClaw
El Módulo 3a conectó el navegador a un runtime persistente. OpenClaw es el entorno de ejecución del agente dentro de ese stack de NemoClaw: combina un modelo y herramientas con una sesión en el servidor y un workspace respaldado por archivos.
NemoClaw proporciona el blueprint que integra este entorno de ejecución con OpenShell y la política de implementación. OpenClaw dirige cada turno y carga los archivos de su espacio de trabajo en el contexto activo, sin un orquestador Python independiente. Examinarás esos archivos, compararás dos instrucciones de mensaje y verificarás la memoria guardada en archivos desde una conversación nueva.
El workspace desde el punto de vista del agente
Cada archivo de la carpeta aporta una parte distinta del prompt. Como la correspondencia es estable, puedes anticipar qué comportamiento modificará cada edición.
La memoria tiene dos niveles. Mientras trabaja, el agente añade notas sin procesar a un archivo fechado en memory/ y resume lo que debe conservarse en su memoria a largo plazo, MEMORY.md. De forma predeterminada, MEMORY.md se incluye en el contexto de la sesión principal y se omite en los prompts compartidos o de grupo. Esta elección de contexto no restringe el acceso al archivo. Unos pasos más adelante leerás ambos directamente desde el sandbox en ejecución.
- qué reglas de personalidad están activas,
- qué herramientas aparecen en su lista,
- o qué recuerda sobre ti.
Paso 1 · Pide al agente que se describa
En un turno, la celda de abajo pide a OpenClaw que enumere los archivos de su espacio de trabajo y explique para qué sirve cada uno. Su respuesta refleja lo que el entorno incluye en el prompt y lo que leen sus herramientas. Después de editar un archivo, compara el nuevo informe con una lectura realizada como operador.
El mismo runtime de Kickstart. Estas celdas reutilizan el launchable conectado en 3a. El curso expone su gateway en lugar de la ruta interna /v1/chat/completions. Si una celda falla o deja de responder, ejecuta Comprobación de estado y examina sus pruebas antes de elegir una acción de recuperación. Una implementación local puede usar el playbook de configuración de NemoClaw y el mismo contrato del gateway.
¿Verificar el espacio de trabajo desde el plano del operador?
Paso 1b · Lee el workspace tú mismo
En el Paso 1, el agente describió sus archivos; no tienes que aceptar lo que afirma sin comprobarlo. Hasta ahora, el único canal era el gateway que transporta tus mensajes al agente.
El launchable también expone un terminal del operador, un shell en el host fuera del sandbox del agente. El helper helpers.terminal() abre ese shell directamente desde esta página a través de dos puntos de entrada:
helpers.terminal("bash")abre el shell de la VM del host, donde puedes ejecutaropenshell sandbox list.helpers.terminal("openshell sandbox connect <agent>")te lleva dentro del sandbox donde se ejecuta el agente y reside el workspace.
OpenShell es el sandbox a nivel del kernel que contiene al agente. Por ahora, trátalo como el límite entre operador y agente que el Módulo 4 definirá por completo y probará directamente. El nombre del agente en el comando de conexión procede de GET /api/agent, la misma llamada que usó Kickstart para descubrir el launchable.
La celda siguiente se conecta al sandbox y lee tres archivos de la instancia activa: SOUL.md, la memoria diaria y el MEMORY.md seleccionado. Edita la lista de comandos y vuelve a ejecutar la celda para explorar cualquier otro archivo.
Paso 2 · Compara las instrucciones de los mensajes
Plantea la misma pregunta de revisión en dos sesiones nuevas. La segunda solicitud pide explícitamente las comprobaciones de evidencia de un auditor. Examina ambos prompts y compara las respuestas. Cambian las instrucciones del mensaje; no se modifica SOUL.md ni se selecciona otro archivo de personalidad.
Paso 3 · El agente edita su propio contexto
Pide al agente que añada una preferencia con una etiqueta única a MEMORY.md. Una lectura desde la interfaz de operador verifica la referencia guardada antes de pedir al agente que la lea en una conversación nueva. Afirmar que se ha guardado no basta como evidencia. La nota añadida permanece disponible para examinarla.
- el sistema de archivos del host,
- el resto de la red,
- o el espacio de trabajo de otro agente.
En el próximo módulo verás cómo se prueba directamente ese límite, cuando un agente al que se han concedido demasiados privilegios de forma deliberada intenta cruzarlo.
Referencias
- NVIDIA, How to Build a Safer Autonomous Agent using OpenClaw. Referencia complementaria sobre OpenClaw, OpenShell y la arquitectura de agente en sandbox usada aquí.
- Anthropic, Claude Skills (docs). OpenClaw utiliza el mismo patrón de archivo como contexto: el runtime incorpora un archivo Markdown al prompt de sistema y lo convierte en una capacidad que el agente puede invocar.
- Claude Code. Agente de CLI utilizado en producción; muestra cómo un directorio de workspace, la memoria persistente y una superficie de herramientas se combinan a escala.
- Packer et al., MemGPT: Towards LLMs as Operating Systems (2023). La jerarquía explícita de memoria que sustenta el bucle de escritura y recuperación de MEMORY.md en esta página.
- Model Context Protocol (MCP). Formato interoperable que los agentes de CLI utilizan para descubrir herramientas en tiempo de ejecución, en lugar de registrarlas directamente en el código.
- Landlock LSM. Primitiva de sandbox del sistema de archivos en el kernel que limita el alcance del impacto cuando el agente escribe en su propio contexto.
- seccomp (man 2). La capa de sandbox que filtra syscalls en el núcleo y se explorará en el Módulo 4.
Lista completa en Para ir más lejos · Referencias.
Prueba · conversa con tu agente activo
Usa el chat para examinar un archivo del espacio de trabajo. Compara la respuesta con la lectura desde la interfaz de operador y examina las llamadas a herramientas. Puedes pedir al agente que:
- describir su workspace,
- leer un archivo
- o ejecutar un comando.
Después de editar un archivo, inicia una sesión nueva y comprueba qué contenido utiliza el agente.