TL;DR
Os enxames de agentes de IA dividem um objetivo entre três papéis: um planejador que divide o trabalho em tarefas, workers que desenvolvem essas tarefas em paralelo dentro de workspaces isolados e verificadores que testam cada alteração antes de aprová-la. O planejador e o verificador utilizam o modelo mais potente; os workers ficam com modelos mais baratos e rápidos. O padrão falha quando os workers compartilham arquivos, os verificadores apenas aprovam por cima sem checar, ou ninguém define um teto de gastos.
Por que os enxames de agentes de IA voltaram às manchetes
O Google disponibilizou o Gemini 4 Carbon para o público geral e apresentou uma prévia do /swarm no Google Antigravity, recurso que transforma um único prompt em uma equipe coordenada de agentes. Nas palavras do Google, o Carbon assume o “design arquitetural, coordenação e auditoria”, em conjunto com “modelos mais rápidos e leves operando em workspaces isolados paralelos e verificadores adversariais que testam cada alteração”.
Essa frase resume um padrão que você já pode implementar com os modelos que tem à disposição. Este guia aborda os três papéis, o motivo de investir mais no planejamento e na verificação, onde os enxames costumam falhar e como gerenciar um enxame em um quadro compartilhado. Se você já utiliza vários agentes de código, o Sharkly atribui a cada um uma Task, um registro de execução e uma etapa de revisão — praticamente tudo o que um enxame precisa.
O que é um enxame de agentes de IA?
Um enxame de agentes de IA é um grupo de agentes que divide um único objetivo em tarefas independentes e trabalha nelas simultaneamente. Um agente planeja e distribui o trabalho, vários agentes o executam em paralelo e um ou mais agentes validam cada resultado antes do merge. Cada papel possui um escopo delimitado e um fluxo de entrega bem definido.
A Anthropic descreveu essa mesma estrutura em 2024 como o padrão orquestrador-workers: um modelo central decompõe uma tarefa, delega as partes e consolida os resultados. O verificador é a adição mais recente — e o papel que a maioria das equipes costuma ignorar.
Um enxame não se resume a “vários agentes fazendo o mesmo trabalho”. Cinco agentes executando o mesmo prompt no mesmo repositório geram uma condição de corrida, não uma equipe. São os papéis especializados que definem um enxame. Para ter uma visão mais ampla sobre coordenação de agentes, confira o que é orquestração de agentes de IA.
Os três papéis: planejador, workers e verificadores
Cada papel responde a uma pergunta diferente e exige um contexto específico.
| Papel | Pergunta que responde | Modelo típico | Lê | Escreve |
|---|---|---|---|---|
| Planejador | Quais são as partes e quem faz cada uma? | O mais avançado disponível | O objetivo, o mapeamento da base de código | Lista de tarefas, critérios de aceitação |
| Worker | Como implementar esta parte específica? | Mais rápido e econômico | Uma tarefa, seus respectivos arquivos | Um diff em seu próprio workspace |
| Verificador | Esta alteração cumpre o que a tarefa pedia? | O mais avançado disponível | A tarefa, o diff, o output dos testes | Aprovação ou rejeição fundamentada |
O que faz o planejador?
O planejador transforma um objetivo genérico em tarefas sem sobreposição. Um plano bem estruturado especifica quais arquivos cada tarefa pode alterar, o teste que comprova sua conclusão e a sequência de execução quando houver dependências. Se duas tarefas precisarem modificar o mesmo arquivo, o planejador as unifica ou define uma execução sequencial.
O que fazem os workers?
Os workers desenvolvem uma única tarefa cada, em paralelo, sem desvios de escopo. Cada worker recebe seu próprio workspace, geralmente um git worktree: um checkout isolado do mesmo repositório em sua própria branch. Esse isolamento é o que permite a três workers editarem código simultaneamente sem sobrescrever o trabalho alheio. Saiba mais em agentes paralelos em worktrees isoladas.
O que fazem os verificadores?
Os verificadores tentam encontrar falhas nas alterações. O termo do Google, “adversarial”, resume bem essa dinâmica: o verificador executa os testes, analisa o diff em relação aos requisitos da tarefa e procura atalhos indevidos que o worker possa ter tomado. Um verificador que apenas questiona “os testes passaram?” não detectará um worker que alterou os próprios testes para fazê-los passar.
Por que o modelo mais caro cuida do planejamento e da auditoria
Planejar e verificar envolvem contextos menores de leitura, mas com um impacto crítico. Já a implementação gera grandes volumes de código com baixo impacto por linha. Essa assimetria determina a alocação de cada modelo.
O planejador escreve poucas centenas de linhas detalhando as tarefas. O verificador emite um veredito direto. Nenhum dos dois gera uma saída massiva de tokens, portanto, o custo adicional de um modelo premium é mínimo no valor final. Já os workers geram a maior parte dos tokens; logo, usar modelos mais acessíveis nessa etapa gera a maior economia.
A escala dos erros também é desproporcional. Um planejamento incorreto desorienta todos os workers, e um verificador relapso aprova qualquer alteração problemática. Por outro lado, um worker mais simples produz apenas um diff incorreto, que é prontamente barrado pelo verificador. Concentre o poder de julgamento onde o erro se multiplica.
O próprio posicionamento do Google reforça essa divisão. A empresa afirma que o Gemini 4 Argon “permanece a escolha ideal para a maior parte da engenharia de software e trabalho intelectual”, enquanto o Carbon consome mais tokens “para explorar a fundo, raciocinar de forma detalhada e executar ciclos extensos de verificação”. O Carbon custa US$ 2 por milhão de tokens de entrada e US$ 10 por milhão de tokens de saída até 30 de novembro de 2026, passando depois para US$ 4 e US$ 20. Para conferir os detalhes técnicos de cada modelo, leia Gemini 4 Carbon para agentes de código e Gemini 4 Argon para agentes de código. Essa mesma lógica se aplica a qualquer combinação de modelos; confira Crews de modelos mistos com workers econômicos e revisor premium.
Onde os enxames de agentes de IA falham
A maioria das falhas em enxames se resume a três fatores: estado compartilhado, validações frágeis e ausência de limites de orçamento.
Por que os agentes sobrescrevem o trabalho uns dos outros?
Dois workers editam o mesmo arquivo porque o planejamento não delimitou a restrição. Sem workspaces isolados, a última gravação prevalece e a alteração do primeiro worker é perdida. Com isolamento, ambas as alterações persistem até o momento do merge, gerando conflitos. A solução começa no planejamento: defina a posse dos arquivos por tarefa e serialize as tarefas que dependem dos mesmos arquivos.
Por que os verificadores aprovam alterações sem critério?
Um verificador que avalia o resumo fornecido pelo worker em vez do diff real está julgando uma promessa, não a entrega. Ele lê “todos os testes passaram” e simplesmente aprova. Entregue ao verificador o diff bruto e o output dos testes, nunca o autorrelato do worker. Além disso, execute o verificador em um modelo diferente dos workers para não herdar os mesmos pontos cegos. O artigo agentes de revisão de código por IA explica em detalhes o que um agente revisor pode e não pode validar.
Como os custos do enxame saem do controle?
Cada rejeição dispara um novo ciclo de implementação e uma nova rodada de revisão; logo, uma tarefa que falha três vezes custa quatro ciclos de cada etapa. Dez workers presos em um loop de rejeição durante a noite podem esgotar o orçamento de uma semana inteira. Defina limites de tentativas por tarefa (duas tentativas é um padrão razoável), limite a quantidade de workers simultâneos e encaminhe a tarefa para um humano caso a última tentativa falhe.
Existe uma quarta falha oculta sob as outras: se o plano, as execuções e os vereditos ficarem restritos a uma única janela de contexto, ninguém conseguirá auditar o resultado. É indispensável que alguém fora do enxame continue monitorando o processo.
Como gerenciar um enxame de agentes de IA em um quadro compartilhado
Você não precisa de uma ferramenta exclusiva de enxames para implementar esse fluxo. Você só precisa de tarefas, workspaces isolados e um gate de controle. Um quadro compartilhado fornece esses três elementos e mantém o histórico acessível para a equipe.
- Crie uma tarefa-pai para o objetivo geral. O planejador analisa o escopo e detalha o plano em subtarefas, cada uma com seus respectivos arquivos e testes de aceitação.
- Atribua exatamente uma tarefa para cada worker. Uma tarefa, um agente, uma branch. Se duas subtarefas precisarem do mesmo arquivo, faça o merge do escopo antes de iniciar o trabalho.
- Execute cada tarefa em seu próprio diretório. Utilizar uma worktree por execução mantém as edições paralelas devidamente isoladas.
- Adicione o status Revisão antes de Concluído. Nenhuma tarefa deve avançar para Concluído baseando-se apenas na palavra do worker.
- Atribua a revisão a um agente verificador em um modelo mais avançado. Ele analisa o diff e o log dos testes para então aprovar a tarefa ou devolvê-la acompanhada do motivo da recusa.
- Mantenha uma pessoa na etapa final. O verificador filtra o volume de trabalho; o humano valida e aceita o resultado final.
Veja como essa estrutura funciona no Sharkly. Uma Crew é um grupo reutilizável de Pessoas e Agentes coordenado por um Agente líder. Ao atribuir a Task principal à Crew, o líder assume primeiro: ele analisa a Task, aciona os Agentes membros para demandas específicas e consolida os resultados. Essa ordem estruturada garante que nenhum worker inicie o desenvolvimento antes da definição do plano.
Agentes no modo de diretório de trabalho temporário recebem um diretório isolado por Task, e execuções integradas a repositórios podem preparar uma nova worktree, impedindo que workers simultâneos compartilhem arquivos. Cada Agente opera no Runtime que você configurar, permitindo alocar o líder e o revisor em modelos superiores aos dos workers.
O gate de validação funciona como um status no fluxo de trabalho das suas Tasks. Um Agente pode marcar uma Task como pendente de revisão humana, e essa transição é exibida no módulo Task Chats da barra lateral principal, conforme detalhado na documentação de execução de tarefas por agentes. Execuções com falha ou bloqueadas continuam sendo direcionadas para a Inbox. Os agentes pesquisam, executam, testam e reportam. As pessoas definem o direcionamento, concedem acessos e aprovam o resultado. O Sharkly é gratuito para começar: conecte um Computer, configure dois Agentes e delegue uma demanda inicial para uma Crew. Para entender melhor a dinâmica da supervisão humana, leia projetando revisões para agentes paralelos.
Quando você não precisa de um enxame de agentes de IA
Evite o uso de enxames quando o escopo não puder ser dividido. A correção de um único bug, a refatoração de um único arquivo ou um fluxo extenso de raciocínio sequencial funcionam melhor com um agente avançado e um revisor. Em demandas com menos de três tarefas independentes, o overhead de coordenação costuma superar os ganhos do paralelismo.
Adote um enxame quando o objetivo final puder ser decomposto em partes que tocam arquivos distintos: migrações de múltiplos pacotes, cobertura retroativa de testes em vários módulos ou uma mudança de API propagada em dez microsserviços. O Google cita “migrações de múltiplos pacotes” e “investigações de causa raiz entre subsistemas” como os cenários ideais para o Carbon em arquiteturas multiagente.
Conclusão
Um enxame de agentes de IA envolve três etapas essenciais, e não apenas um prompt gigantesco: planejar, construir e verificar. Reserve seu melhor modelo para o planejamento e para o veredito, use modelos econômicos para a execução do código e mantenha cada entrega acessível para validação humana. Comece com uma tarefa principal, três workers e um verificador. Para estruturar esse modelo com os agentes que você já utiliza, conecte um Computer ao Sharkly e configure sua primeira Crew.
Perguntas frequentes
Qual é a diferença entre um enxame de agentes e a orquestração multiagente?
A orquestração é o conceito abrangente de coordenar múltiplos agentes. O enxame é um padrão específico de orquestração com papéis definidos: um planejador, workers paralelos e verificadores. Todo enxame é orquestrado, mas nem toda orquestração forma um enxame.
Quantos agentes um enxame de IA deve ter?
Comece com um planejador, três workers e um verificador. Só adicione mais workers se as tarefas permanecerem totalmente independentes e a fila de validação der conta do volume. Escalar workers sem capacidade de revisão apenas transfere o gargalo para o verificador.
O planejador e o verificador podem ser o mesmo agente?
Eles podem compartilhar o mesmo modelo de base, mas devem operar em execuções distintas com contextos separados. Um planejador revisando o resultado do próprio plano tende a aprová-lo sem rigor. Já um verificador em uma sessão limpa avalia o diff sem as premissas prévias do planejador.
É necessário ter o Google Antigravity para rodar um enxame de agentes?
Não. O comando /swarm é apenas uma prévia dentro do Antigravity, mas o padrão exige apenas divisão de tarefas, workspaces isolados e uma etapa de validação. Você pode estruturar esse fluxo usando git worktrees e um quadro de tarefas com os agentes de código que já utiliza.
O que impede os workers de um enxame de editarem o mesmo arquivo?
O planejamento distribui a responsabilidade dos arquivos para que não haja sobreposição de tarefas, enquanto os workspaces isolados mantêm as alterações de cada worker em sua respectiva branch até o momento do merge. Além disso, regras de CODEOWNERS acrescentam uma verificação adicional durante o processo de revisão.
