¿Qué Sucede Cuando una IA Tiene Acceso a un Entorno de Node.js? Spoiler: Cosas Salvajes

Hola a todos. Muchas gracias por estar aquí hoy. Soy Alfonso y hoy vamos a hablar de algo que es muy emocionante. Así que vamos a aprender y vamos a ver qué sucede cuando una IA, es decir, un LLM, tiene acceso a un entorno Node.js y por lo tanto puede escribir su propio código y ejecutar su propio código. Antes de comenzar, una breve introducción de mi parte. Hola, de nuevo, soy Alfonso, probablemente de Italia, y soy líder técnico en una empresa llamada NearForm y básicamente somos una empresa de consultoría especialmente para Node.js y algunas otras tecnologías. Pero si estás interesado en los temas que vamos a discutir hoy, si quieres aprender más sobre el uso de agentes de IA en Node.js o IA en el ciclo de vida del desarrollo de software, por favor contáctame en LinkedIn. Siempre estoy más que feliz de tener charlas y recibir comentarios sobre estos proyectos porque son muy, muy valiosos. Así que de nuevo, si quieres, tengamos una charla en LinkedIn.

Comencemos. Así que todo lo que se va a discutir en esta charla está en este sitio web, que es js.ai.com. Y este proyecto es el Node.js Sandbox MCP server. La idea detrás de este proyecto es que permitirá a cualquier LLM ejecutar su propio código. Así que va a escribir algo de código, ejecutarlo, instalar dependencias, tener acceso al sistema de archivos, y mucho más, como puedes imaginar. En caso de que quieras intentarlo, en caso de que quieras probarlo, puedes echar un vistazo a este sitio web. O si quieres, este proyecto es uno de los proyectos verificados en el Docker Hub. Así que es mcp slash Node.js Sandbox. Puedes descargarlo fácilmente si estás usando Docker Desktop. Es súper fácil, toma alrededor de 30 segundos. Así que comencemos.

Y antes de entrar en los detalles técnicos y los detalles técnicos de la implementación, veamos cuáles son las razones de este proyecto. Y primero que nada, ¿qué es el MCP? Entonces, ¿qué es el Model Context Protocol? No voy a invertir demasiado tiempo en esta sección, porque estoy seguro de que ya has oído bastante sobre MCP, y ya sabes qué es y cómo funciona. Pero solo quiero traerte, solo quiero traer cuáles son los problemas que MCP se supone que debe resolver. Así que antes de MCP, al crear conexiones entre agentes de IA o aplicaciones de IA y fuentes de datos y herramientas, teníamos un problema común, que era el problema amp-for-end. Así que la idea es que tienes M aplicaciones, como tu aplicación de calendario, tal vez tu Gmail, tal vez, no sé, cualquier cosa que puedas pensar, ¿verdad? Y luego tienes que conectar esas aplicaciones a las fuentes de datos, que podrían ser como una base de datos o un programador, lo que sea. El problema aquí es que no tienes una forma unificada de conectar esas dos cosas, ¿verdad? Así que en el caso de un agente de IA, no tienes ninguna forma estándar de conectar tu IA a una fuente de datos o a algo que te permita usar herramientas. Y ahí es donde entra en juego MCP. Así que la idea principal es que puedes simplemente comunicarte, puedes simplemente usar el protocolo. Así que el LLM, va a implementar el cliente MCP. Así que, por ejemplo, Cloud Desktop va a implementarlo, ShareGP lo implementó recientemente.

Así que la idea es que puedes simplemente integrarte con el, y luego puedes, y luego puedes implementar tus propias herramientas. Puedes simplemente conectarte a un servidor MCP. Así de fácil es. Lo veremos en un momento. La forma en que funciona desde un punto de vista técnico, es relativamente fácil, pero aún así interesante de ver. {{^}}Así que la idea es que tenemos un cliente MCP, como mencioné. En realidad, se llama, por ejemplo, Cloud, es el host MCP, porque luego cada servidor va a tener su propio cliente. Pero la forma en que funciona es que simplemente hacemos una solicitud MCP al servidor. Luego el servidor MCP va a actuar como un proxy y va a hacer lo que necesitemos. Así que va a hacer llamadas API, ejecutar código, no sé, pasar por una base de datos, lo que sea que tengamos que hacer. Y luego va a devolver los resultados al servidor MCP. Y luego el servidor MCP, por supuesto, va a devolver los resultados al cliente.

Ahora, la pregunta es, bien, más o menos entendimos qué es MCP, pero ¿por qué debería construir un servidor MCP? Bueno, hay algunas razones para eso. La primera razón es que quiero que mi IA pueda escribir y ejecutar su propio código de manera segura localmente. Así que la cosa es que ya sabemos que cosas como ChargePT, Gemini y Cloud, ya tienen sus propias herramientas, pero se ejecutan en la nube, ¿verdad? Se ejecutan en algunas cosas tal vez como un runtime de borde o algo más. Pero queremos algo que se ejecute localmente porque esto nos permite hacer algunas cosas geniales. Así que, por ejemplo, una cosa que podemos hacer es análisis de datos local y visualización. Así que digamos que tenemos algunos datos de finanzas personales datos médicos, no sé, cualquier cosa que queramos mantener privada. En lugar de subir a ChargePT, queremos mantenerlo privado en nuestras máquinas. Y también podemos hacer, de nuevo, visualización y análisis usando herramientas como ChargeJS, Danfo JS, y así sucesivamente. Así que esta es una cosa genial que tenerlo ejecutándose localmente desbloquea. Por supuesto, esto tiene algunas mejoras tanto en términos de seguridad y privacidad y así sucesivamente. La siguiente es que DLLM piensa en texto o tokens, si queremos ser precisos, pero no en bits. Así que como podemos ver a la izquierda, tenemos una expresión relativamente simple y el modelo, especialmente los modelos que no son de última generación, pueden fácilmente alucinar y dar resultados incorrectos porque no han sido entrenados para ejecutar una expresión matemática, sino que han sido entrenados para predecir el siguiente token. Entonces, ¿cómo solucionamos esto? Bueno, como podemos ver a la derecha, podemos simplemente decir verificar con código. Así que el DLLM va a escribir algún código que luego se va a ejecutar y el resultado va a ser, como en este caso, tres errores en fresa. Así que va a haber algo como contar el número de errores, y este código se va a ejecutar. Por último, pero no menos importante, la pregunta es, bien, pero ¿por qué JavaScript? ¿Por qué no JS? Bueno, la razón es que el ecosistema de JavaScript es realmente enorme. Tenemos más de 3.1 millones de paquetes, lo que significa que para cada problema o para cada idea que tenemos, probablemente hay al menos una dependencia que va a resolver ese problema. Muy bien.

Ahora que vimos cuáles son las razones, como puedes adivinar, hay bastantes casos de uso que se desbloquean gracias a este servidor MCP. Así que, en primer lugar, podemos generar códigos QR. Podemos buscar en la web. Podemos generar PDFs. Podemos hacer muchas cosas, desde manipulación de archivos hasta fetch. Podemos, ya sabes, incluso generación de diapositivas en markdown. Experimenté un poco y descubrí muchas cosas interesantes.

Pero sigamos adelante y veamos cómo implementar realmente estas cosas, ¿verdad?, que es la parte interesante. Así que este es el flujo. Esto es lo que podemos gestionar en un radio, que es el LLM escribe algún código. El código se envía al servidor MCP. Luego el servidor MCP, va a ejecutar este código de alguna manera segura con Node.js. Y luego la salida de este código, que se ejecuta, se envía de vuelta al LLM.

Tenemos que entender cómo ejecutar este código de manera segura y localmente. Así que hay algunas opciones posibles. Como podemos ver en el eje x, tenemos la complejidad de implementación, y en el eje y, tenemos la seguridad. Lo primero que podemos hacer es el eval. Así que simplemente tomamos este código, lo pasamos a través de un eval, y más o menos funciona. Luego tenemos el módulo via, que es algo similar, pero tiene más seguridad. El principal problema con esto es que el código que genera el LLM es código no confiable, y tenemos que tratarlo como código no confiable.

Así que todavía lo estamos ejecutando en el espacio del usuario, y no queremos hacer eso. Otra opción en el otro lado es usar cosas como microVMs, o incluso edge run times. Como puedes adivinar, el edge run time es muy seguro, porque no está en tu máquina, está en la máquina de otra persona. Así que no puede causar ningún daño, con suerte. Y más o menos lo mismo se aplica para los microVMs, dado que están muy bien aislados. Pero entonces tiene que haber un punto óptimo aquí. Y el punto óptimo entre complejidad y seguridad, como puedes adivinar, es Docker.

Así que podemos iniciar un nuevo contenedor de Docker, podemos ejecutar nuestro código, y el código generado por DLLM, y podemos obtener los resultados. Así que eso es exactamente lo que vamos a hacer ahora mismo. La intuición es que el código que DLLM escribe se envía al servidor MCP, y el servidor MCP se encarga de iniciar el contenedor de Docker con la imagen de Node.js. Luego el código se copia en el contenedor y se ejecuta. Así que la imagen que vamos a usar, va a tener Node.js preinstalado. Y luego la salida del código se envía de vuelta a DLLM.

Por supuesto, escribir este tipo de cosas es relativamente fácil, es súper fácil, gracias a los SDKs oficiales. Actualmente tenemos SDKs oficiales para muchas tecnologías diferentes. Pero si, por ejemplo, estás usando algo como, no sé, C++ o lo que sea, y no hay una implementación oficial de MCP para tu propia tecnología, puedes simplemente echar un vistazo a las de la comunidad, hay bastantes de ellas. O si quieres ir más allá, aún puedes reimplementar la especificación, lo cual es relativamente fácil de reimplementar. Así que puedes intentarlo.

Veamos cómo funciona con el SDK de TypeScript en este caso. Así que como podemos ver, en 20 líneas de código o algo así, podemos crear nuestro primer servidor MCP, y podemos exponer nuestra primera herramienta MCP. Nuevamente, no profundicé demasiado en los detalles de qué son los MCPs y cómo funcionan, pero la idea es que a través de MCP, podemos exponer algunas cosas como herramientas, recursos, prompts, y así sucesivamente. Así que hay algunas cosas que podemos exponer. En este caso, voy a mantenerlo simple, y voy a exponer solo una herramienta.

Así que como podemos ver, voy a crear el servidor MCP. Voy a darle un nombre, una versión y una descripción. Y nuevamente, voy a usar el SDK de TypeScript de MCP para esto. Y cuando estoy creando la herramienta, las únicas cosas que tengo que describir son el nombre de la herramienta, la descripción de la herramienta y los parámetros como un esquema JSON.

Así que en este caso, estoy usando XOD, para que podamos hacer la validación también. Y luego puedo simplemente llamar a mi función. Así que cuando el LLM va a invocar esta herramienta, el cliente MCP va a llamar al servidor, que luego va a llamar a la función.

Y como podemos ver aquí en la función, solo tengo una función simple que es runJS ephemeral, y luego paso el código generado por el LLM a esta función, que veremos en un momento. Estoy tomando la salida, y estoy devolviendo la salida como un objeto, que contiene contenido, que es básicamente un array. Ahora, este array es como MCP espera el retorno. Así que estoy pasando, por ejemplo, el tipo, que es un texto en este caso, y luego estoy pasando el texto en sí. Así que en este caso, solo estoy pasando la salida del proceso de node.js de vuelta al LLM. Y luego, por último pero no menos importante, estoy conectando el servidor al transporte SDDO.

Bien, veamos ahora cómo podemos ejecutar el código de forma segura en Docker. Así que como podemos ver, la función es relativamente simple. Así que lo primero que podemos hacer es, primero, generamos un ID de contenedor, como uno aleatorio. Luego creamos, ahora ejecutamos el contenedor, y lo ejecutamos con la imagen node.lts.lim, pero por supuesto podemos personalizar la imagen. Y luego usamos un truco simple, que es el tail, menos f, slash dev, slash null, para decirle al sistema, está bien, no puedes, no tienes que detenerte. Así que por favor mantente inactivo y espérame. Luego lo que voy a hacer es, voy a copiar el código en el archivo index.js, que voy a crear en una plantilla aquí. Y luego voy a copiar este archivo en el Docker. Y luego voy a ejecutar esto, voy a ejecutar con node index.js este código, y voy a obtener la salida del contenedor Docker. Por último pero no menos importante, como puedes adivinar, solo estoy haciendo algo de limpieza. Así que podré matar el contenedor Docker y eliminar el directorio temporal. Y eso es todo, esa es la esencia de la solución.

Lo genial de esta solución es que, como puedes adivinar, expandirla es relativamente simple. De hecho, veremos que expandir esta solución, este tiempo de ejecución, a Python, requiere cambiar al menos tres líneas de código. Y vamos a verlo. Así que lo primero que voy a cambiar es, por supuesto, el nombre de la función, que ya no es como run.js, sino run Python ephemeral. Luego voy a cambiar cómo estructuramos la cadena de ID del contenedor, pero eso realmente no es necesario. Ahora, los tres cambios que se necesitan son, bueno, primero que nada, en lugar de usar Node.js, la imagen de node, voy a usar una imagen con Python preinstalado, así que es el Python 3.11 sling. Luego, cuando escribo el archivo, no va a ser index.js, sino script.pi. Y luego, en lugar de lanzar el script con node index.js, solo voy a lanzar Python script.pi, y eso es todo. Así que como podemos ver, este tipo de solución es muy expandible a otras tecnologías manteniendo la misma idea central. Por supuesto, tengamos en cuenta algo súper importante, que es que la precisión del uso de la herramienta no es perfecta. Así que la llamada de función es una de las capacidades de los LLMs, como la resumización, reescritura, y así sucesivamente.

Es una de sus capacidades, pero no es algo que sea perfecto. Por supuesto, hay algunos benchmarks, y especialmente con modelos que no son de última generación, o especialmente con modelos más pequeños, podemos esperar que el modelo vaya a alucinar bastante. No va a llamar a la herramienta correcta, o especialmente si tenemos muchas herramientas, va a tener dificultades para definir qué herramienta debe ser llamada y con qué parámetros. Así que hay algo que podemos hacer, que es que debemos tener en cuenta que los principios de ingeniería de prompts siguen siendo válidos cuando estamos escribiendo algún servidor MCP.

Así que la idea es que el nombre, la descripción de la herramienta, los parámetros, y la descripción de los parámetros se van a pasar al LLM. Así que mientras escribimos la descripción, por ejemplo, debemos tener en cuenta que el LLM va a leer eso, y debemos guiar al LLM para que escriba el código de la manera correcta, ¿verdad? Así que, por ejemplo, aquí estoy dando alguna información sobre la carpeta de archivos para montar archivos y demás, pero debemos tener en cuenta dar tanta información como podamos, el contexto adecuado al LLM para llamar a las funciones de la manera correcta. Por supuesto, tengamos en cuenta que los servidores MCP son más suaves, como el software habitual, por lo que necesitamos probarlos, y necesitamos probarlos de la manera más correcta posible.

¿Y adivina quién es realmente bueno escribiendo pruebas? Sí, lo adivinaste, los LLMs. Así que podemos aprovechar los LLMs para escribir las pruebas para este tipo de software. Funciona relativamente bien. De hecho, la gran mayoría de las pruebas que escribí para este proyecto están escritas por un LLM, por supuesto, han sido revisadas y demás.

Añadamos algunas características más ahora mismo. Así que la primera característica que quiero añadir es la instalación de dependencias. Así que estamos usando ahora Node.js, pero quiero que el LLM pueda instalar sus propias dependencias y usarlas. Así que la forma en que funciona es que el LLM define no solo el código como parámetros, sino también las dependencias como un array. Y luego el package.json se escribe en el sistema de archivos y luego se copia, y luego yo simplemente hago un paso más, que es npm install.

Por supuesto, el principal problema con esto es que tengo un compromiso aquí en términos de latencia, porque tengo que instalar las dependencias, y esto puede llevar un poco de tiempo. Pero si no estoy instalando demasiadas dependencias, no es un gran problema, generalmente. Y luego, por supuesto, ejecuto mi código en Docker y va a ejecutarse sin problemas. La siguiente característica que es súper útil es tener un directorio de trabajo montado en Docker para que mi proceso de Node.js pueda tanto leer archivos como escribir archivos. Y luego vamos a notificar al LLM a través de MCP qué archivo ha sido actualizado.

Por supuesto, este es un ejemplo. Así que en este caso, tuve que crear un código QR, que no suele ser compatible por defecto desde el escritorio en la nube. Él creó el código QR con la biblioteca y lo muestra aquí en la interfaz de usuario.

Así que, en primer lugar, tenemos este directorio de trabajo. Tomamos una instantánea del directorio de trabajo, luego se ejecuta el script. El script podría actualizar algunos archivos, crear algunos archivos, y así sucesivamente. Luego obtengo otra instantánea del directorio. Comparo las dos instantáneas y luego simplemente le digo al LLM, está bien, estos son los archivos que cuando vi la diferencia entre las dos instantáneas han cambiado. Esta es la salida del LLM que podemos ver.

Así que, por ejemplo, aquí ejecuto la herramienta efímera JS y simplemente dijo, está bien, el script de Node.js se ejecutó con éxito. Estos son los archivos que se han creado y así sucesivamente. Y esto es lo que sucede en la capa MCP. Si recuerdas, tenemos este array de contenidos, que contiene el tipo de texto. Así que con la salida del proceso de Node.js pero puede contener más cosas, ¿verdad? Como la lista de archivos cambiados, la lista de recursos, así que puedo tener las URLs a los archivos.

Y luego también puedo pasar las imágenes formateadas como base64. Por supuesto, también podemos permitir que la IA genere algunos gráficos. Esto va a requerir algunas más dependencias. Por lo tanto, también creé algunas imágenes Docker personalizadas para ello. Bien, el siguiente punto respecto a la seguridad, que es súper importante. Tengamos en cuenta que MCP no es seguro por defecto, y todo lo que entra en el servidor MCP debe ser tratado como código no confiable. Así que la idea aquí es que queremos verificar todo, sanitizar todo. De hecho, también tuve un CVA relativamente alto en mi repositorio porque había una fuga de sandbox a través de inyección de comandos.

Así que la idea aquí es que queremos asegurarnos de que todo sea completamente seguro. De hecho, si quieres aprender un poco más sobre seguridad en MCP, puedes simplemente buscar en Google historias de terror de MCP. De hecho, hay muchas brechas y problemas que se han reportado hasta ahora con MCP en términos de seguridad, aislamiento de datos, y así sucesivamente. Así que te recomiendo encarecidamente que si estás buscando escribir tu propio servidor MCP, te tomes un tiempo y estudies un poco cuáles son los ataques más comunes para MCP para que puedas estudiar e implementar tu servidor MCP de manera segura. Dicho esto, muchas gracias por tu tiempo.