Enxame Autónomo de IA

Você pede a um agente de IA para construir uma funcionalidade durante a noite. Parece boa ideia em teoria. Na prática, você acorda com metade de uma migração, dois ficheiros partidos e uma mensagem alegre a dizer que a tarefa está completa.

Esse padrão de falha é comum. O agente não falhou porque o modelo é fraco. Falhou porque um único agente de longa duração tem de fazer demasiados trabalhos ao mesmo tempo: escolher a tarefa, manter o plano, editar o código, verificar o resultado e decidir se é seguro lançar.

É isso que este post resolve. Abaixo está um Enxame Autónomo de IA. Dito de forma mais simples, é orquestração automática de IA. Um gatilho dispara a cada 30 minutos. Um orquestrador lê o estado do projeto, encaminha um ou vários especialistas e verifica cinco portas antes de qualquer coisa contar como feita.

As cinco formas como as execuções noturnas de agentes falham

A maioria das demos "autónomas" esconde a parte difícil. Fazer um agente escrever código é fácil. Fazer com que continue a tomar decisões corretas durante horas é a parte difícil.

Estes são os cinco modos de falha que aparecem primeiro.

1. Sem gatilho

Nada acorda o sistema na hora certa.

Você ainda tem de estar lá e escrever o prompt. Ou inicia uma grande execução antes de dormir e espera que sobreviva à noite. Se a execução parar após 20 minutos, tudo morre ali.

A correção é simples. Um gatilho temporizado. A cada 30 minutos, o sistema acorda, verifica o que aconteceu e decide o que fazer a seguir.

2. Sem encaminhamento

Um agente é forçado a ser gestor de projeto, arquiteto, engenheiro de frontend, engenheiro de backend, testador e revisor.

Parece eficiente. Não é. A mesma janela de contexto tem agora planeamento, implementação e verificação a competir por espaço. A execução deriva. O agente perde o controlo do que está feito, o que está bloqueado e o que ainda precisa de prova.

A correção é a separação de papéis. Um orquestrador encaminha. Agentes especialistas executam. O cérebro de encaminhamento e o cérebro de trabalho deixam de se atrapalhar mutuamente.

3. Sem guardrails

O agente escreve código e depois marca a tarefa como completa porque o ficheiro existe.

Isso não é o mesmo que lançar. Um ficheiro pode existir e ainda falhar verificações de tipos, falhar no lint, quebrar a build, vazar um segredo, ou não ter testes.

A correção é uma pilha de portas. A execução não conta a menos que passe as verificações que importam.

4. Sem prova

O agente diz que a funcionalidade está feita, mas nada no sistema o prova.

Este é o mesmo problema que aparece também na segurança de IA. Uma descoberta sem prova é ruído. Uma funcionalidade sem prova é pensamento positivo.

A correção é verificação que corre em cada ciclo. O sistema precisa de uma razão para confiar no resultado que seja mais forte do que a confiança do próprio agente.

5. Sem memória entre execuções

Uma execução longa para. Você reinicia. O próximo agente não sabe o que o último estava a fazer.

Agora você tem trabalho duplicado, edições conflituosas e resumos vagos em vez de progresso real. O sistema continua a mover-se, mas está a andar em círculos.

A correção é estado externo. O orquestrador lê a condição atual do projeto antes de cada ciclo e encaminha a partir daí, não a partir do que um agente se lembra.

Por que um único agente não chega

A resposta habitual é "deixa o agente continuar até os testes passarem."

É melhor do que um prompt único. Ainda não é suficiente.

Um único agente ajuda com persistência. Não resolve o encaminhamento. Não resolve a especialização. Não resolve o problema de um agente avaliar o seu próprio trabalho. Não resolve o problema de decidir se deve planear, construir, corrigir ou parar.

Esta é a diferença entre um trabalhador e um enxame.

Um único trabalhador continua a repetir uma tarefa.

Um enxame é um pequeno sistema que acorda, lê o estado, escolhe um papel, executa o trabalhador certo, verifica o resultado e ou avança ou dorme.

É por isso que este enxame não é um cluster distribuído, um plano de controlo Kubernetes ou alguma "malha de agentes" abstrata. É muito mais simples do que isso. Uma máquina. Um repositório. Um gatilho temporizado. Um orquestrador. Um ou vários especialistas. Worktrees separadas são o modo paralelo quando o trabalho se divide de forma limpa.

A forma do enxame

Um enxame de orquestração de IA como este tem cinco partes móveis:

1. Gatilho: uma ativação a cada 30 minutos.
2. Orquestrador: uma sessão principal lê o contexto e escolhe o próximo movimento.
3. Especialistas: planeador, construtor, designer, testador e guarda. O orquestrador pode encaminhar um ou vários deles.
4. Portas: lint, tipos, build limpa, guarda de commit, suite de testes.
5. Resultado: se todas as verificações passarem, a funcionalidade está pronta. Se não, o enxame continua a trabalhar ou dorme.

Essa é a forma completa:

gatilho a cada 30 minutos
      ↓
orquestrador lê o estado
      ↓
escolhe a próxima tarefa
      ↓
despacha um especialista ou vários
      ↓
executa portas de qualidade
      ↓
lança, continua, ou dorme

A parte importante não é "mais agentes." A parte importante é que cada ciclo tem um trabalho.

Os orquestradores separados importam aqui porque são o modo paralelo. Use-os quando o trabalho se divide em dois ou três recursos independentes com fronteiras claras.

Passo 1: o gatilho

O gatilho é um ping a cada 30 minutos.

Você pode implementar isso com um cron job real do sistema. Pode implementá-lo com tarefas agendadas do Claude Code Desktop. O ponto não é a marca do agendador. O ponto é a cadência.

A cadência faz duas coisas.

Primeiro, dá ao sistema mais do que uma oportunidade de recuperar. Se uma execução morre às 2:07 da manhã, o próximo ciclo acorda às 2:30 e continua.

Segundo, mantém o sistema barato e legível. Você não precisa de um agente sempre ativo a queimar tokens a cada segundo. Você precisa de um padrão de automação que acorda, decide, age e para.

Numa configuração como esta, o passo do gatilho resume-se a uma linha:

Um cron job. Agenda todo o enxame.

Esse é o modelo mental correto. Um agendador. Não uma plataforma cloud.

Passo 2: o orquestrador

O orquestrador é o cérebro.

Não tenta fazer toda a funcionalidade por si mesmo. Essa é a primeira regra.

O seu trabalho é ler o estado atual e responder a uma questão: qual é o próximo movimento?

Essa questão é mais estreita do que parece. O orquestrador não está a inventar estratégia de produto. Está a ler contexto que já existe:

• que tarefa foi tentada por último
• que ficheiros mudaram
• que verificações passaram
• que verificações falharam
• o que está bloqueado
• que funcionalidade está mais perto de estar pronta

Uma vez que tem esse estado, encaminha o trabalho para o especialista certo, ou para vários especialistas se o trabalho se dividir de forma limpa.

É por isso que a legenda diz:

Escolhe o próximo movimento.

Essa frase importa porque define o orquestrador corretamente. Não é "o trabalhador principal." É o despachante.

Passo 3: os especialistas

Este enxame usa cinco papéis especializados.

Pode renomeá-los. Os nomes não são a parte importante.

A parte importante é que cada agente tem um trabalho mais estreito do que "construir a funcionalidade." Isso reduz a deriva e mantém o resultado mais consistente de ciclo para ciclo.

É também aqui que a maioria das configurações de equipas de agentes corre mal. As pessoas criam cinco agentes e depois dão a todos os cinco o mesmo prompt. Isso não é uma equipa. É duplicação.

Um verdadeiro especialista só precisa do contexto necessário para o seu trabalho.

O planeador precisa da tarefa e da forma do projeto.

O construtor precisa dos ficheiros alvo e dos critérios de aceitação.

O designer precisa dos requisitos de UI e das restrições dos componentes.

O testador precisa das condições de falha e das verificações.

O guarda precisa da política.

O orquestrador não tem de acordar todos os cinco sempre.

Às vezes um especialista é suficiente. Às vezes o trabalho divide-se e o orquestrador distribui a vários especialistas em paralelo.

A versão limpa disso usa sessões isoladas ou Git worktrees separadas. Cada especialista recebe a sua própria cópia do repositório, faz a sua parte e evita pisar nos ficheiros de outro especialista. É assim que se mantém o trabalho paralelo real em vez de confuso. Mesmo detalhes básicos do repositório como .gitignore, .gitkeep, migrações, testes e ficheiros de UI ficam mais fáceis de raciocinar quando cada trabalhador tem a sua própria faixa.

É isso que "Um orquestrador. Um ou vários especialistas." significa na prática.

Como o trabalho paralelo se funde novamente

O trabalho paralelo é útil até dois especialistas tocarem nos mesmos ficheiros.

É por isso que cada especialista trabalha na sua própria Git worktree. O branch principal fica limpo enquanto os especialistas constroem em paralelo.

Quando um especialista termina, o seu branch não funde diretamente. No modo separado, passa por um ajudante de merge limitado. Um branch de cada vez. Um branch alvo. Regras de fallback simples.

Se o merge for limpo, aterra.

Se houver um conflito, o sistema tenta três passos. Primeiro, um git merge limpo. Segundo, resolução automática determinística para os casos fáceis. Terceiro, uma resolução LLM por ficheiro com rejeição rígida para saída em prosa. Isso mantém o caminho de merge apertado e previsível.

Se nada disso funcionar, o merge para e o branch é marcado como falhado.

Isso importa. Um enxame não é "fundir tudo e esperar pelo melhor." É trabalho paralelo com regras.

Passo 4: o caminho de execução full-stack

A fase de construção é onde o sistema mostra o seu valor.

Muitas demos de agentes param em "o agente escreveu um ficheiro." Nós quisemos o oposto. Quisemos um caminho da base de dados para a saída ao vivo.

É por isso que a fase de construção no enxame não é descrita como "escrever código." É descrita como:

Os agentes executam a stack completa.

Num sistema como este, isso significa que o orquestrador pode encaminhar pelas camadas reais que uma funcionalidade real toca:

• trabalho de base de dados
• lógica de backend
• páginas e ligação de UI
• polimento de design
• testes

É por isso que o slide 4 termina com:

Base de dados para ao vivo. Uma funcionalidade, zero passos manuais.

Este é também o lugar certo para definir full stack em termos simples. Neste sistema, não significa "todas as tecnologias do mundo." Significa as camadas necessárias para tornar uma funcionalidade real desde o armazenamento até ao ecrã.

Se a base de dados muda mas a página não, a funcionalidade não está feita.

Se a página muda mas os testes falham, a funcionalidade não está feita.

Se tudo constrói localmente mas o guarda de commit sinaliza um segredo, a funcionalidade não está feita.

O enxame continua a mover-se através dessas camadas até a cadeia fechar.

Passo 5: as cinco portas

A fase do guarda é a parte que torna o sistema confiável.

Sem ela, o enxame é apenas uma forma rápida de gerar trabalho partido.

A nossa pilha de portas tem cinco verificações:

Isto é o oposto exato de "deixa o agente lançar e espera pelo melhor."

A legenda aqui é direta por uma razão:

Nada lança sem passar.

Isso não é um slogan. É a regra.

As cinco portas fazem dois trabalhos.

Primeiro, impedem código mau de chegar ao main.

Segundo, dão ao orquestrador um sinal fiável sobre o que fazer a seguir. Se a verificação de tipos falha, o próximo movimento não é "celebrar." O próximo movimento é "encaminhar uma correção."

Isso significa que as portas não são apenas verificações de segurança. São sinais de encaminhamento.

Como é o resultado

O objetivo não é "o agente correu durante quatro horas."

O objetivo é: você regressa e a funcionalidade está realmente feita.

É por isso que a última fase no enxame não se chama "resumo" ou "reporting." Chama-se resultado.

Uma execução noturna pode ler-se assim:

• 2:00 da manhã: planeou o sistema de autenticação
• 2:30 da manhã: construiu três endpoints de API
• 3:00 da manhã: correu 47 testes
• 3:30 da manhã: implementou para produção

Essa sequência importa porque prova que o sistema está a fazer trabalho ordenado, não trabalho aleatório.

Um exemplo simples é:

4 horas. A autenticação foi construída, testada e lançada.

Este é exatamente o formato de prova certo para um sistema de construção autónomo. Curto. Concreto. Verificável.

Não "o modelo raciocinou muito bem." Não "o sistema parecia promissor." Uma funcionalidade cruzou a linha.

Como a automação realmente corre

Esta parte importa porque "autónomo" significa muito pouco se o gatilho for vago.

A automação não é mágica. Começa com uma ativação agendada.

A versão mais simples é uma entrada de cron do sistema que inicia uma nova execução a cada 30 minutos. Conceitualmente parece-se com isto:

*/30 * * * * cd /path/to/repo && claude -p "run the swarm orchestrator for the next task"

Isso é suficiente para criar a cadência.

Você também pode executar o mesmo padrão com tarefas agendadas do Claude Code Desktop. Nesse modelo, a aplicação Desktop mantém o agendamento e inicia uma nova sessão no intervalo escolhido. O trabalho ainda funciona da mesma forma após o ativamento:

1. uma execução agendada inicia
2. o orquestrador lê o estado atual do projeto
3. um especialista ou vários especialistas recebem a próxima tarefa
4. o resultado passa pelas portas de qualidade
5. o sistema lança, tenta novamente, ou dorme

A escolha entre cron e tarefas agendadas do Desktop é operacional, não arquitetural.

Use cron se quer o gatilho mais simples ao nível da máquina.

Use tarefas agendadas do Desktop se quer um agendamento visível, histórico integrado, e uma nova sessão de Claude a cada vez sem ter de ligar shell scripts manualmente.

O que importa é que cada execução começa de novo e cada execução consegue ver o estado atual. É isso que torna o enxame durável em vez de frágil.

O que acontece quando nada está pronto

Um bom enxame automatizado precisa de um estado de sono.

Isto parece pequeno. Não é.

Se nada mudou, nenhuma porta falhou, e nenhuma funcionalidade está suficientemente perto para avançar, o orquestrador devia registar o estado e parar. Não devia forçar trabalho só porque o agendador disparou.

É assim que se mantém o sistema limpo.

O gatilho cria oportunidade. Não cria urgência falsa.

Por que isto funciona melhor do que um framework de agentes genérico

A maioria dos frameworks de agentes genéricos dá-lhe as partes móveis mas não as regras de operação.

Você recebe ferramentas para criar agentes. Ferramentas para passar mensagens. A sensação de estrutura. Depois ainda tem de decidir:

• quando o sistema acorda
• que estado lê
• como escolhe a próxima tarefa
• como evita trabalho duplicado
• o que torna um passo completo
• o que bloqueia um lançamento

Essas são as perguntas reais.

O enxame funciona porque as responde antecipadamente.

Gatilho dá-lhe cadência.

Orquestrador dá-lhe encaminhamento.

Especialistas dão-lhe foco.

Portas dão-lhe prova.

Resultado dá-lhe uma linha de chegada.

Um framework genérico pode hospedar essa forma. Não pode substituí-la.

Como construir a sua própria versão

Você não precisa de uma stack enorme para copiar isto.

Comece com esta forma mínima:

um agendador
um orquestrador
um ou vários especialistas
três a cinco portas de qualidade
um ficheiro de estado ou diretório de relatórios

Depois siga estas regras.

1. Mantenha o gatilho barato

Não execute um agente sempre acordado se um ativamento temporizado funciona.

Um ping a cada 30 minutos é suficiente para a maioria dos sistemas de construção noturna. Dá-lhe comportamento de retry sem pagar por atividade constante.

2. Separe encaminhamento de execução

Não faça o orquestrador fazer o trabalho de implementação.

Se o cérebro também é o trabalhador, a qualidade do encaminhamento cai e o contexto fica confuso rapidamente.

3. Dê a cada especialista um trabalho estreito

Um agente não devia planear, programar, projetar e verificar na mesma passagem.

Prompts estreitos são mais fáceis de avaliar, mais fáceis de tentar novamente e mais fáceis de substituir.

Se vários especialistas correrem em paralelo, dê a cada um uma fronteira clara. Worktrees separadas são a versão mais limpa porque cada especialista edita o seu próprio checkout em vez de lutar pelos mesmos ficheiros.

4. Faça as portas bloquear, não avisar

Uma porta de qualidade que só escreve um aviso não é uma porta.

Se a build está partida, o sistema tem de encaminhar uma correção em vez de fingir que a funcionalidade está completa.

5. Mantenha a prova fora do auto-relato do agente

O agente dizer "feito" não é prova.

A prova vem de verificações, testes, logs e builds bem-sucedidas. Sinais externos batem sempre na confiança interna.

6. Durma de propósito

Se nada está pronto, registe o estado e durma.

Isto é mais importante do que parece. Os sistemas ficam caros e confusos quando não conseguem decidir parar.

O que este sistema realmente é

Esta é a resposta direta à sua pergunta: é um crontab?

Ao nível do gatilho, sim, tem forma de cron.

Há um agendador que acorda o sistema a cada 30 minutos. Esse agendador pode ser:

• uma entrada real de crontab na sua máquina
• uma tarefa agendada do Claude Code Desktop

O enxame não é só o agendador, no entanto.

O fluxo completo é:

1. o agendador dispara
2. nova sessão acorda
3. o orquestrador lê o estado
4. o orquestrador escolhe o próximo movimento
5. um especialista ou vários especialistas correm
6. as portas verificam o resultado
7. o sistema lança, tenta novamente, ou dorme

É por isso que a resposta certa não é "é um crontab" nem "é um framework de IA."

É um enxame autónomo de IA.

Uma forma válida é:

sessão principal -> encaminha trabalho -> sub-agentes -> portas -> dorme

Outra forma válida é:

sessão principal -> particiona 2-3 funcionalidades independentes -> cria sessões de worktree isoladas -> funde de volta com segurança

Ambas são a mesma ideia. Orquestração automática de IA com papéis claros, regras de merge limitadas e uma linha de chegada.

Onde mais este padrão se aplica

Uma vez que você vê a forma, pode usá-la fora das construções de funcionalidades.

O mesmo padrão de enxame funciona para:

• revisão de segurança
• auditorias de dependências
• produção de conteúdo
• triagem de analítica
• babysitting de PRs

O agendador acorda o sistema. O orquestrador verifica o estado. Um ou vários especialistas fazem o trabalho estreito. As portas decidem se o resultado é bom o suficiente. Depois o enxame dorme novamente.

Esse é o modelo completo.

Um ping. Um cérebro. Um ou vários especialistas. Cinco portas. Funcionalidades feitas quando você acorda.