Qué es Nod

Por: Artiko
nodn8nagentes-iaarquitecturaasistente-personal

Qué es Nod

Objetivos

  • Entender qué hace Nod y en qué se diferencia de un chat con un modelo.
  • Conocer las piezas del sistema: conversación, workspace, navegador, apps y proveedor de modelos.
  • Elegir entre las tres formas de ejecutarlo.
  • Tener una idea de la arquitectura interna para interpretar los capítulos siguientes.

Un asistente con su propio ordenador

Según su documentación, Nod es un asistente personal con el que hablas en un solo chat. Tiene un workspace Linux y un navegador propios, de modo que puede hacer trabajo real y no solo responder preguntas.

Cuatro ideas lo describen:

  • Su propio ordenador. Nod ejecuta comandos y guarda archivos en un workspace Linux privado. Navega en su propio navegador, que puedes tomar cuando un sitio te necesita.
  • Tus apps. Conectas Gmail, Calendar, Slack, Notion, Linear y otras, y Nod puede leerlas y actuar en ellas.
  • Trabajo que corre solo. Nod ejecuta tareas programadas. Cuando se lo pides, también detecta correo y actividad nuevos que te necesitan.
  • Tu alojamiento, tu modelo. Nod corre en tu equipo o en un servidor tuyo. Sus peticiones de modelo van al proveedor que elijas o a un servidor compatible con OpenAI que ejecutes tú, como Ollama.

Cómo encajan las piezas

Hay una sola conversación continua. La app de escritorio, el navegador web, Telegram y WhatsApp muestran la misma conversación, así que puedes empezar una tarea en el portátil y revisarla desde el teléfono.

flowchart LR
    Tu(["Tú"]) --> Chat["Una conversación<br/>app · web · Telegram · WhatsApp"]
    Timers["Programaciones y<br/>comprobaciones en segundo plano"] --> Chat
    Chat --> Nod["Nod planifica el trabajo"]
    Nod <--> Modelo["Proveedor de modelos<br/>que tú eliges"]
    Nod --> WS["Workspace Linux<br/>archivos y comandos"]
    Nod --> BR["Navegador"]
    Nod --> Apps["Apps conectadas"]

Qué se le puede pedir

La documentación propone estos ejemplos por área:

ÁreaMensaje de ejemplo
Investigación”Compare three project tools for a team of five. Put the prices in a table.”
Archivos”Turn the attached CSV into a chart and a one-page PDF summary.”
Correo y apps”Find client emails from this week that still need a reply and draft answers.”
Sitios web”Download last month’s invoice from billing.example.com with my saved login.”
Programaciones”Every Friday at 5 pm, send me a recap of what we finished this week.”
Fuera del escritorioPor Telegram: “Did the supplier reply yet?”

Nod sigue el idioma de tu último mensaje, así que los mismos pedidos funcionan en español.

Nod está diseñado para consultarte antes de enviar, publicar o borrar algo que no pediste. El servidor ejecuta esa comprobación antes de cada acción de ese tipo. La decisión la toma un modelo de IA, por lo que puede equivocarse. El trabajo en segundo plano que Nod inicia solo se limita a leer y redactar borradores, salvo que le hayas dicho qué hacer por su cuenta. El capítulo 12 lo explica.


Dónde corre Nod

Asistente local de escritorioInstalación local desde códigoServidor propio
Para qué sirveUsar Nod en tu equipoEjecutarlo en Linux o modificar su códigoLlegar a un mismo asistente desde varios dispositivos
Corre enMac (Apple silicon o Intel), Windows 11macOS o Linux con DockerUna máquina con Docker Compose
Qué necesitasNada más instaladoNode.js, pnpm, Docker y GitConfigurar el servidor y HTTPS para acceso por red
ActualizacionesAutomáticasgit pull y reiniciarActualizar el servidor
Capítulo020304

La app de escritorio también puede conectarse a un servidor. En ese caso el chat, los archivos, las conexiones de modelos y las apps conectadas vienen del servidor, y cerrar el cliente no detiene al asistente.

flowchart TD
    P{"¿Desde dónde quieres usar Nod?"}
    P -- "Solo desde mi Mac o PC" --> D["App de escritorio<br/>capítulo 2"]
    P -- "Desde Linux, o quiero tocar el código" --> S["Código fuente<br/>capítulo 3"]
    P -- "Desde varios dispositivos,<br/>o con el portátil cerrado" --> H["Servidor propio<br/>capítulo 4"]
    H --> C["La app de escritorio se conecta<br/>al servidor como cliente"]

Cada asistente necesita una conexión de modelo: credenciales de un servicio soportado, un plan de ChatGPT que admita inicio de sesión o un servidor de modelos. Las apps se conectan iniciando sesión en cada una y revisando sus permisos.


Lo que Nod no es

  • No ejecuta modelos por sí mismo. Se conecta a un proveedor, que te factura el uso, o a un servidor de modelos local que ejecutas tú.
  • Necesita un equipo encendido. Un asistente local corre solo mientras Nod está abierto y el equipo despierto. Un servidor sigue trabajando con los clientes cerrados.
  • Pertenece a una persona. Varios dispositivos pueden llegar al mismo servidor y asistente. Las instalaciones separadas no sincronizan datos.
  • El acceso por red requiere configuración. Las instalaciones desde código escuchan en loopback por defecto. Un servidor propio usa un token de acceso y HTTPS.
  • No está terminado. Es una vista previa: las funciones y los formatos de datos pueden cambiar.

Arquitectura interna

Nod es un proceso de Node.js más unos pocos contenedores Docker, todos en el equipo que ejecuta tu asistente.

flowchart TD
    Web["Cliente web o de escritorio"] --> API["API y funciones del servidor"]
    Canales["Telegram · WhatsApp"] --> API
    API --> PG["PostgreSQL y trabajos pg-boss"]
    PG --> Worker["Worker thread-drain"]
    Worker --> Runtime["Runtime del agente"]
    Runtime --> Pi["Sesión de agente Pi"]
    Runtime --> BRC["Contenedor del navegador"]
    Runtime --> WSC["Contenedor del workspace"]
  • Un proceso de Node sirve el cliente React y ejecuta la API (Fastify), el runtime del agente, el worker que drena los hilos y los programadores.
  • Los contenedores son PostgreSQL, el workspace y el navegador.
  • Un proceso auxiliar separado habla con la app de 1Password, de modo que el servidor nunca carga el código de 1Password.

El flujo de un mensaje es este: cada mensaje o disparo de una programación se convierte en un turno guardado en PostgreSQL, con un trabajo en cola. El worker toma el trabajo y pide al runtime que ejecute el turno. El runtime abre una sesión del agente, que llama a herramientas que actúan en el workspace, el navegador y las apps conectadas.

Cuatro decisiones de diseño aparecen a lo largo de la documentación:

IdeaQué implica
Un hilo por propietarioWeb, Telegram y WhatsApp comparten una conversación. Las sesiones en segundo plano tienen navegador y transcripción propios
Todo es un turnoMensajes, programaciones, despertares por evento y reanudaciones. Los turnos nunca se reintentan
La política vive en el servidorEl servidor revisa las acciones en apps, el uso de Vault y los pagos. Las instrucciones del modelo se suman a esas comprobaciones, no las sustituyen
Equipo aisladoLos comandos corren en un contenedor restringido. Las claves de los proveedores nunca entran en el workspace ni en el navegador

El stack declarado en el README es TypeScript sobre Node.js 24, Fastify, React, PostgreSQL con pg-boss, el runtime de agente Pi, agent-browser, Composio, MCP y Electron.

Qué ve el modelo y qué no

flowchart LR
    subgraph Servidor["Servidor de Nod"]
        Claves["Claves de proveedores"]
        VaultK["Vault: logins y tarjetas"]
        Politica["Trust check"]
    end
    subgraph Aislado["Ordenador privado de Nod"]
        WS["Workspace"]
        BR["Navegador"]
    end
    Modelo["Modelo"] -- "planifica acciones" --> Politica
    Politica -- "acciones permitidas" --> WS
    Politica -- "acciones permitidas" --> BR
    Claves -. "nunca entran" .-> Aislado
    VaultK -. "el servidor escribe el secreto<br/>el modelo no lo recibe" .-> BR

Los resultados de apps, páginas web y navegador llegan al modelo marcados como datos, no como instrucciones. Solo tus mensajes, tus aprobaciones y las instrucciones que defines dan permiso.


Cifras que publica el proyecto

La página principal y el README publican resultados de sus propias pruebas. Son cifras declaradas por el proyecto; el detalle de los métodos está en la sección Benchmarks and methods de la documentación.

Métrica declaradaValor
Tareas completadas98 %
Acciones no seguras0
Recuerdo de memoria93,2 %
Recuerdos falsos0 de 216

El proyecto también advierte sobre la elección del modelo para la comprobación de acciones: en 240 decisiones de prueba, GPT-6.1 Sol y Claude Opus 5.5 acertaron todas, mientras que Claude Haiku 5.5 dejó pasar 8 acciones no seguras. Esto importa al elegir modelo en el capítulo 6.


Actividad

  1. Escribe tres tareas tuyas que hoy haces a mano en sitios web o en el correo.
  2. Para cada una, anota qué necesitaría Nod: una app conectada, un login guardado o solo el navegador.
  3. Decide con el diagrama de este capítulo qué forma de instalación te corresponde.

Autoevaluación

1. ¿Qué diferencia a Nod de un chat con un modelo?

Tiene un workspace Linux y un navegador propios, y puede actuar en apps conectadas. Con eso ejecuta comandos, guarda archivos y usa sitios web, además de responder.

2. ¿Cuántas conversaciones tiene un asistente?

Una sola. La app, la web, Telegram y WhatsApp muestran y alimentan la misma conversación.

3. ¿Qué pasa con las tareas programadas si cierras el portátil en una instalación local de escritorio?

No se ejecutan mientras el equipo está dormido o Nod cerrado. Para que sigan corriendo hace falta un servidor propio o un equipo siempre encendido.

4. ¿Dónde se decide si una acción puede ejecutarse?

En el servidor de Nod, mediante la comprobación de acciones (trust check). Las instrucciones del modelo se suman a esa comprobación, no la sustituyen.

5. ¿Qué contenedores acompañan al proceso de Node?

PostgreSQL, el workspace y el navegador.


Lista de control

  • Puedo explicar qué son el workspace y el navegador de Nod.
  • Sé que hay una sola conversación compartida entre app, web y canales.
  • Elegí una de las tres formas de instalación.
  • Sé que las claves de proveedores no entran en el workspace ni en el navegador.
  • Sé que Nod es una vista previa y que sus formatos pueden cambiar.

Anterior: Índice · Siguiente: Instalar la app de escritorio