Conteúdo detalhado
🔄 A virada de paradigma
Quase todo mundo usa IA no modo sob demanda: você abre o chat, pergunta, lê a resposta e fecha. A IA só "existe" enquanto você está ali, digitando. O local destrava um segundo modo, muito mais poderoso e quase desconhecido de quem só usou nuvem: o agente que nunca fecha — o sempre-on.
A lógica é simples. Sua máquina já está ligada. O modelo local não cobra por uso. Então não há motivo para a IA ficar parada esperando você. Ela pode trabalhar no fundo o tempo todo: varrendo um repositório atrás de falhas, vigiando fontes na web, resumindo o que chegou na sua caixa, organizando arquivos. Tarefas que rodam continuamente, sem ninguém perguntar nada.
🆕 Novo aqui?
"Sempre-on" (always-on) é a IA rodando de forma contínua, no fundo, mesmo quando você não está olhando. "Worker" é cada processo dedicado a uma tarefa repetitiva — pense num funcionário que faz uma coisa, sem parar. Um agente sempre-on normalmente é montado como um (ou vários) workers.
🔑 A ideia central
Local = ilimitado + sempre ligado. Essa combinação habilita uma classe inteira de usos que a nuvem torna inviável por custo:
- •Uso ambiente: a IA fica no ambiente, trabalhando de fundo, em vez de só responder quando chamada.
- •Contínuo, não pontual: milhares de execuções por dia deixam de ser um problema de fatura.
- •Sem medo do medidor: você experimenta, deixa rodando, esquece — só a energia conta.
📊 Dois modos, lado a lado
- Sob demanda: você inicia, a IA responde, encerra. Ótimo para uma pergunta pontual.
- Sempre-on: um gatilho inicia a IA sozinho, ela age, registra e volta a dormir — para sempre. Ótimo para vigiar, varrer, manter algo em dia.
- Não é "um ou outro": o sempre-on é uma camada nova que você ganha por rodar local.
💸 Por que só dá em local
O sempre-on não é uma escolha de gosto — é economia. Na nuvem, cada chamada ao modelo tem um pedágio. Pra uma pergunta por dia, ninguém sente. Para um agente que dispara a cada poucos minutos, dia e noite, a conta explode. No local, a mesma carga custa só a eletricidade que a máquina já gastaria ligada.
🧮 A conta que muda tudo
Um worker que dispara a cada 5 minutos roda:
Na nuvem, multiplique isso pelo preço por chamada — e por quantos workers você tem. No local, o número de chamadas é irrelevante pra fatura: ela não existe.
Compare os dois modelos de custo lado a lado:
✓ Local (sempre-on)
- ✓Custo marginal por chamada ≈ zero
- ✓Rodar 24/7 não muda a fatura — só a energia
- ✓Sem rate limit: dispare quantas vezes quiser
- ✓Dados ficam na máquina — nada vaza por padrão
✗ Nuvem (pedágio por chamada)
- ✗Cada chamada custa — 24/7 multiplica rápido
- ✗Vários workers = a fatura soma todos eles
- ✗Rate limits e cotas te freiam no pior momento
- ✗Cada execução manda seus dados pra fora
💡 Dica prática
A energia não é zero, mas é pequena e previsível. Um modelo pequeno (3–8B) num PC modesto gasta pouco quando está só esperando o próximo gatilho — a GPU/CPU só "acende" no instante da inferência. O custo real do sempre-on é tempo de máquina ociosa, que você já paga de qualquer jeito.
🧬 Anatomia de um worker contínuo
Todo worker sempre-on, por mais sofisticado que pareça, tem a mesma anatomia de quatro peças. Depois que você enxerga o esqueleto, montar qualquer um deles (e os passo a passo das próximas aulas) vira encaixar peças conhecidas.
Leia o ciclo no sentido horário: o timer (em âmbar) dispara o agente, que pensa, executa a ação e grava um log. A seta em ciano fecha o laço: tudo volta ao início e repete, sem parar, 24/7.
As quatro peças, na prática:
Agendador (o gatilho)
O que decide quando rodar: um cron por horário, um loop que dorme entre execuções, um "watch" que reage a um arquivo novo. É o despertador do worker.
A tarefa
O trabalho concreto e bem definido: coletar dados, varrer um repo, ler uma pasta. Geralmente uma parte determinística (sem IA) que prepara o material.
O modelo local
A inteligência: o agente chama a API local (a do módulo 3.5) para triar, classificar, resumir ou decidir. É onde o LLM agrega valor sobre o que a tarefa coletou.
A saída
O resultado que sobrevive ao ciclo: um arquivo (relatorio.md), uma notificação, uma linha no log. Sem saída persistente, o trabalho some.
⏰ Disparadores: cron, watch, fila
A peça que transforma um script comum em um worker sempre-on é o disparador. Existem três sabores, e você escolhe pelo que dispara a tarefa: o relógio, um evento, ou um trabalho na fila.
🆕 Novo aqui?
- Cron: agendador de tarefas por tempo, embutido no Linux/macOS. Você descreve "a cada X" e o sistema dispara sozinho — mesmo se você não estiver logado.
- Watch: em vez de horário, dispara por evento — tipicamente "apareceu/mudou um arquivo nesta pasta". Reage na hora.
- Fila (queue): uma lista de trabalhos a fazer; o worker pega um por vez e processa. Útil quando chega mais trabalho do que dá pra fazer de imediato.
⏱ Cron / loop
Dispara por tempo. "A cada 20 min", "todo dia às 3h". O cavalo de batalha do sempre-on.
👁 Watch
Dispara por evento. Arquivo novo numa pasta, mudança detectada. Reativo, sem ficar checando à toa.
📥 Fila
Dispara por demanda. Trabalhos entram numa lista; o worker consome um a um, sem perder nenhum.
⌨️ Exemplo prático: uma tarefa a cada 20 minutos
Objetivo: disparar uma chamada ao seu modelo local a cada 20 min. Mostramos dois caminhos — o cron (oficial) e um loop em bash (mais simples de testar agora).
Como verificar: rode tail -f worker.log em outro terminal — a cada 20 min deve aparecer uma resposta nova do modelo e a linha "ciclo concluído". Se nada surge, confira se a API local responde (curl http://localhost:11434/api/tags).
💡 Dica prática
O loop em bash some quando você fecha o terminal. Para o sempre-on de verdade, prefira o cron ou um serviço (systemd no Linux, launchd no macOS): eles sobrevivem a logout e reinício. Comece testando com o loop, promova para cron quando funcionar.
🛡️ Confiabilidade do worker
Um agente sempre-on roda sem ninguém olhando — por isso ele não pode te dar dor de cabeça. A diferença entre um worker útil e um que vira um problema está em quatro hábitos: registrar tudo, ser idempotente, ter limites e saber retomar de uma falha.
🆕 Novo aqui?
"Idempotência" é a propriedade de poder rodar a mesma coisa várias vezes sem causar dano extra. Um worker idempotente que processa o mesmo item duas vezes não duplica o trabalho nem manda dois alertas iguais — ele detecta "isso já foi feito" e segue. Crucial para algo que repete o tempo todo.
✓ Worker confiável
- ✓Logs: grava o que fez, quando e o resultado — dá pra auditar depois
- ✓Idempotente: rodar de novo no mesmo item não duplica nada
- ✓Limites: timeout por execução e teto de itens por ciclo
- ✓Retoma: guarda onde parou e continua após queda/reinício
✗ Worker que dá dor de cabeça
- ✗Roda em silêncio — quando falha, você nem sabe
- ✗Reprocessa tudo e dispara o mesmo alerta 50 vezes
- ✗Trava num item pesado e segura a fila inteira
- ✗Cai e recomeça do zero, perdendo o progresso
✅ Checklist de confiabilidade
- ▸Cada ciclo escreve uma linha de log com data/hora e o que aconteceu.
- ▸Antes de agir num item, checar "já processei este?" (hash, ID, marcador).
- ▸Timeout por chamada ao modelo e limite de quantos itens por execução.
- ▸Estado salvo em disco (último item visto) para retomar de onde parou.
- ▸Alertar só no que é novo — silêncio quando não há novidade.
💡 Dica prática
A forma mais barata de idempotência: guarde um arquivo com os IDs (ou hashes) já processados e cheque contra ele no começo de cada ciclo. Pulou o que já viu, processou só o novo, anexou o ID novo. Simples, em disco, e resolve 90% das duplicações.
👥 A frota de funcionários
Um worker é um funcionário. Vários workers, cada um numa tarefa, são uma frota — e é aqui que o orquestrador do módulo 4.1 reaparece: ele carrega os modelos, roteia entre máquinas e coordena quem faz o quê. Você deixa de ter "uma IA" e passa a ter um time silencioso trabalhando por você, de graça, sem parar.
🎯 Sua frota nas próximas aulas
- •4.3 — Scanner de segurança: um worker que varre seu codebase atrás de segredos e falhas, 24/7.
- •4.4 — Vigia da web: um worker que monitora fontes e extrai oportunidades, rankeadas.
- •4.5 — Buddy pessoal: um assistente sempre disponível, com nome, cara e voz.
Repare: os três têm a mesma anatomia deste módulo — agendador, tarefa, modelo local e saída. Você já tem o esqueleto; as próximas aulas só preenchem a carne.
🧭 Como pensar a frota
- Um worker = uma tarefa bem definida. Não tente fazer um worker fazer tudo.
- Workers compartilham a mesma API local e a mesma tailnet (módulos 3.5 e 2.4).
- O orquestrador (4.1) é opcional no começo: cron + scripts já montam uma frota pequena.
Auto-checagem (opcional): por que rodar um agente 24/7 normalmente só fecha a conta em IA local?
📌 Resumo do módulo
Próximo módulo:
4.3 — Scanner de segurança 24/7 no seu codebase