Contenido detallado
🔄 El cambio de paradigma
Casi todo el mundo usa la IA en modo bajo demanda: abres el chat, preguntas, lees la respuesta y lo cierras. La IA solo "existe" mientras estás ahí, escribiendo. El entorno local desbloquea un segundo modo, mucho más poderoso y casi desconocido para quienes solo han usado la nube: el agente que nunca se cierra — el siempre activo.
La lógica es simple. Tu máquina ya está encendida. El modelo local no cobra por uso. Entonces, no hay motivo para que la IA se quede parada esperándote. Puede trabajar en segundo plano todo el tiempo: recorrer un repositorio en busca de fallas, vigilar fuentes en la web, resumir lo que llegó a tu bandeja de entrada, organizar archivos. Tareas que se ejecutan continuamente, sin que nadie pregunte nada.
🆕 ¿Eres nuevo por aquí?
"Siempre activo" (always-on) es la IA que funciona de forma continua, en segundo plano, incluso cuando no la estás mirando. "Worker" es cada proceso dedicado a una tarea repetitiva; piensa en un empleado que hace una cosa, sin parar. Un agente siempre activo normalmente se configura como uno o varios workers.
🔑 La idea central
Local = ilimitado + siempre encendido. Esta combinación habilita toda una categoría de usos que la nube vuelve inviables por su costo:
- •Entorno de uso: la IA permanece en el entorno, trabajando en segundo plano, en vez de responder solo cuando la llamas.
- •Continuo, no puntual: miles de ejecuciones al día dejan de ser un problema de facturación.
- •Sin miedo al medidor: pruebas, lo dejas funcionando, te olvidas — solo cuenta la energía.
📊 Dos modos, lado a lado
- A demanda: inicias, la IA responde, terminas. Ideal para una pregunta puntual.
- Siempre activo: un disparador inicia la IA por sí sola, actúa, registra y vuelve a dormir — para siempre. Ideal para vigilar, revisar y mantener algo al día.
- No es «una cosa o la otra»: el funcionamiento siempre activo es una nueva capa que obtienes al ejecutar el modelo localmente.
💸 Por qué solo funciona en local
El paradigma siempre activo no es una cuestión de gustos: es ahorro. En la nube, cada llamada al modelo tiene un costo. Para una pregunta al día, nadie lo nota. Para un agente que se activa cada pocos minutos, día y noche, la cuenta se dispara. En local, la misma carga solo cuesta la electricidad que la máquina ya consumiría encendida.
🧮 La cuenta que lo cambia todo
Un worker que activa cada 5 minutos ejecuta:
En la nube, multiplica esto por el precio por llamada y por la cantidad de workers que tengas. En local, el número de llamadas es irrelevante para la factura: no existe.
Compara los dos modelos de costo lado a lado:
✓ Local (siempre activo)
- ✓Costo marginal por llamada ≈ cero
- ✓Ejecutarlo 24/7 no cambia la factura: solo el consumo de energía
- ✓Sin límite de solicitudes: ejecuta tantas veces como quieras
- ✓Los datos se quedan en la máquina: nada se filtra de forma predeterminada
✗ Nube (peaje por llamada)
- ✗Cada llamada cuesta — 24/7 se multiplica rápido
- ✗Varios workers = la factura suma el costo de todos
- ✗Los límites de solicitudes y las cuotas te frenan en el peor momento
- ✗Cada ejecución envía tus datos al exterior
💡 Consejo práctico
La energía no es cero, pero es poca y predecible. Un modelo pequeño (3–8B) en una PC modesta consume poco mientras espera el próximo disparador: la GPU/CPU solo «se enciende» en el momento de la inferencia. El costo real de estar siempre encendido es tiempo de máquina inactiva, que de todos modos ya pagas.
🧬 Anatomía de un worker continuo
Todo worker siempre activo, por sofisticado que parezca, tiene la misma anatomía de cuatro piezas. Cuando ves el esqueleto, montar cualquiera de ellos (y los paso a paso de las próximas clases) se convierte en encajar piezas conocidas.
Lee el ciclo en sentido horario: el timer (en ámbar) activa el agente, que piensa, ejecuta la acción y guarda un log. La flecha cian cierra el ciclo: todo vuelve al inicio y se repite sin parar, 24/7.
Las cuatro piezas, en la práctica:
Programador (el disparador)
Qué decide cuando ejecutar: un cron por horario, un loop que duerme entre ejecuciones, un "watch" que reacciona ante un archivo nuevo. Es el despertador del worker.
La tarea
El trabajo concreto y bien definido: recopilar datos, recorrer un repo, leer una carpeta. Por lo general, una parte determinista (sin IA) que prepara el material.
El modelo local
La inteligencia: el agente llama a la API local (la del módulo 3.5) para filtrar, clasificar, resumir o decidir. Es donde el LLM agrega valor a lo que recopiló la tarea.
La salida
El resultado que sobrevive al ciclo: un archivo (relatorio.md), una notificación, una línea en el registro. Sin una salida persistente, el trabajo desaparece.
⏰ Disparadores: cron, watch, cola
La pieza que transforma un script común en un worker siempre activo es el disparador. Hay tres modalidades y eliges según lo que active la tarea: el reloj, un evento o un trabajo en la cola.
🆕 ¿Eres nuevo por aquí?
- Cron: planificador de tareas por tiempo, integrado en Linux/macOS. Describes "cada X" y el sistema se activa solo, incluso si no has iniciado sesión.
- Watch: en lugar de por horario, se activa por evento — normalmente, «apareció/cambió un archivo en esta carpeta». Reacciona al instante.
- Cola (queue): una lista de tareas pendientes; el worker toma una a la vez y la procesa. Es útil cuando llega más trabajo del que se puede hacer de inmediato.
⏱ Cron / loop
Se activa por tiempo. "Cada 20 min", "todos los días a las 3 h". El caballo de batalla del funcionamiento continuo.
👁 Watch
Se activa por evento. Archivo nuevo en una carpeta, cambio detectado. Reactivo, sin estar revisando innecesariamente.
📥 Cola
Se activa por demanda. Los trabajos entran en una lista; el worker los procesa uno por uno, sin perder ninguno.
⌨️ Ejemplo práctico: una tarea cada 20 minutos
Objetivo: disparar una llamada a tu modelo local cada 20 min. Mostramos dos opciones — cron (oficial) y un bucle en bash (más sencillo de probar ahora).
Cómo verificar: ejecuta tail -f worker.log en otra terminal — cada 20 min debería aparecer una respuesta nueva del modelo y la línea "ciclo concluído". Si no aparece nada, comprueba si la API local responde (curl http://localhost:11434/api/tags).
💡 Consejo práctico
El ciclo en bash desaparece cuando cierras la terminal. Para que esté realmente siempre activo, prefiere el cron o un servicio (systemd en Linux, launchd en macOS): sobreviven al cierre de sesión y al reinicio. Empieza probando con el loop y pásalo a cron cuando funcione.
🛡️ Confiabilidad del worker
Un agente siempre activo se ejecuta sin que nadie lo supervise; por eso no debería darte dolores de cabeza. La diferencia entre un worker útil y uno que se convierte en un problema está en cuatro hábitos: registrarlo todo, ser idempotente, tener límites y saber recuperarse de un fallo.
🆕 ¿Eres nuevo por aquí?
"Idempotencia" es la propiedad de poder ejecutar lo mismo varias veces sin causar daños adicionales. Un worker idempotente que procesa el mismo elemento dos veces no duplica el trabajo ni envía dos alertas iguales: detecta «esto ya se hizo» y sigue. Es crucial para algo que se repite todo el tiempo.
✓ Worker confiable
- ✓Registros: registra lo que hiciste, cuándo y el resultado — así se puede auditar después
- ✓Idempotente: volver a ejecutar el mismo elemento no duplica nada
- ✓Límites: timeout por ejecución y límite de elementos por ciclo
- ✓Retoma: guarda dónde se quedó y continúa después de una caída o reinicio
✗ Worker que da dolores de cabeza
- ✗Se ejecuta en silencio: cuando falla, ni te enteras
- ✗Vuelve a procesarlo todo y activa la misma alerta 50 veces
- ✗Se atasca en un elemento pesado y retiene toda la cola
- ✗Se cae y vuelve a empezar desde cero, perdiendo el progreso
✅ Lista de verificación de confiabilidad
- ▸Cada ciclo escribe una línea de registro con fecha/hora y lo que ocurrió.
- ▸Antes de actuar sobre un elemento, verifica «¿ya procesé este?» (hash, ID, marcador).
- ▸Timeout por llamada al modelo y límite de elementos por ejecución.
- ▸Estado guardado en disco (último elemento visto) para retomar donde lo dejaste.
- ▸Alertar solo sobre lo que es nuevo — silencio cuando no hay novedades.
💡 Consejo práctico
La forma más barata de lograr idempotencia: guarda un archivo con los IDs (o hashes) ya procesados y compáralos al comienzo de cada ciclo. Omite lo que ya viste, procesa solo lo nuevo y agrega el nuevo ID. Es simple, queda en disco y resuelve el 90% de los duplicados.
👥 La flota de empleados
Un worker es un empleado. Varios workers, cada uno con una tarea, forman una flota — y aquí reaparece el orquestador del módulo 4.1: carga los modelos, enruta entre máquinas y coordina quién hace qué. Dejas de tener "una IA" y pasas a tener un equipo silencioso trabajando para ti, gratis y sin parar.
🎯 Tu flota en las próximas clases
- •4.3 — Escáner de seguridad: un worker que revisa tu codebase en busca de secretos y fallas, 24/7.
- •4.4 — Vigilante de la web: un worker que monitorea fuentes y extrae oportunidades clasificadas.
- •4.5 — Buddy personal: un asistente siempre disponible, con nombre, cara y voz.
Fíjate: los tres tienen la misma anatomía de este módulo — planificador, tarea, modelo local y salida. Ya tienes el esqueleto; las próximas clases solo le pondrán la carne.
🧭 Cómo pensar la flota
- Un worker = una tarea bien definida. No intentes hacer que un worker lo haga todo.
- Los workers comparten la misma API local y la misma tailnet (módulos 3.5 y 2.4).
- El orquestador (4.1) es opcional al principio: cron + scripts ya forman una pequeña flota.
Autoevaluación (opcional): ¿por qué ejecutar un agente 24/7 normalmente solo resulta viable en IA local?
📌 Resumen del módulo
Siguiente módulo:
4.3 — Escáner de seguridad 24/7 en tu codebase