Phase 16 - Lesson 09

Arquiteturas Paralelas / de Enxame / em Rede

Contraste com supervisor: sem tomador de decisão central. Os agentes leem um barramento de eventos compartilhado, coletam o trabalho de forma assíncrona e gravam os resultados de volta. O LangGraph suporta explicitamente "Swarm Architecture" para ambientes descentralizados e dinâmicos. O Matrix (arXiv:2511.21686) representa tanto o fluxo de controle quanto o de dados como mensagens serializadas passadas por filas distribuídas para eliminar o gargalo do orquestrador. O tradeoff é explícito: determinismo e rastreabilidade por escalabilidade. O Swarm se adapta a tarefas com muitos subproblemas independentes; ele não se adapta a tarefas que precisam de um único plano coerente.

Tipo: Learn + Build Linguagens: Python (stdlib, threading, queue) Pré-requisitos: Fase 16 · 05 (Padrão Supervisor), Fase 16 · 04 (Modelo Primitivo) Tempo: ~75 minutos

O Problema

O supervisor escala para alguns trabalhadores. E quanto a centenas? O próprio supervisor se torna o gargalo: cada decisão sobre quem faz o quê passa por um único agente. Um passo lento no planejamento paralisa todo o sistema.

As arquiteturas de enxame (swarm) invertem o design. Em vez de um planejador central despachar o trabalho, os trabalhadores coletam o trabalho de uma fila compartilhada. A "coordenação" é embutida nas semânticas do barramento de eventos. Sem orquestrador; o sistema escala até que a fila o faça.

Conceito

O formato

                ┌──── shared queue ────┐
                │                      │
       ┌────────┼────────┐  ◄──────┬───┘
       ▼        ▼        ▼         │
     Worker  Worker  Worker   Worker
      A       B       C        D
       │        │        │         │
       └────────┴────────┴─────────┘
                 │
                 ▼
            results pool

Sem orquestrador. Cada trabalhador repete: obter uma tarefa, processar, gravar o resultado (e, opcionalmente, enfileirar as etapas seguintes).

Quando o enxame se adapta

• Muitas tarefas independentes. Coleta de dados (scraping), transformação, classificação. As tarefas não dependem umas das outras.
• Trabalho com duração variável. Se algumas tarefas levam 100ms e outras levam 10s, um enxame equilibra a carga automaticamente — trabalhadores rápidos coletam as próximas tarefas. Um supervisor precisa antecipar a duração.
• Vazão (throughput) em vez de determinismo. Você se importa com o tempo total de conclusão, não com a ordenação estrita.

Quando o enxame falha

• Fluxos de trabalho ordenados. Se a etapa 3 precisa da saída da etapa 2, um enxame corre o risco de iniciar a etapa 3 antes que a etapa 2 seja concluída.
• Tarefas com plano global. Perguntas de pesquisa complexas se beneficiam de um planejador. Um enxame de pesquisadores produz fatos independentes, não um relatório coerente.
• Depuração (debugging). Sem um log central e com trabalho assíncrono, reproduzir um bug é caro.

Matrix (arXiv:2511.21686)

Matrix é o artigo de 2025 que leva o enxame à sua conclusão natural: tanto o fluxo de controle quanto o de dados são mensagens serializadas em filas distribuídas. Sem coordenador central. A tolerância a falhas vem da durabilidade das mensagens. A escalabilidade é um problema do message broker (intermediário de mensagens), não do sistema.

Contribuição: um modelo de programação onde a coordenação de múltiplos agentes é "a qual tópico de mensagem este agente se inscreve?" em vez de "qual agente o supervisor escolhe a seguir?". Isso faz com que o sistema pareça uma malha de eventos pub/sub.

Arquitetura de Enxame do LangGraph

A documentação de 2025 do LangGraph descreve explicitamente a "Swarm Architecture" como um dos padrões de múltiplos agentes: os agentes são nós, mas as arestas formam um grafo direcionado com ciclos e qualquer nó pode ser ativado a partir do pool. Um trabalhador escolhe o trabalho disponível por condição, não por atribuição do supervisor.

Modo de falha: inanição (starvation) e gargalos de processamento (hot-spotting)

Se todos os trabalhadores coletarem a tarefa mais rápida disponível, as tarefas de longa duração nunca serão escolhidas até que sejam as únicas restantes. Inanição clássica de fila.

Mitigações:

• Filas de prioridade com envelhecimento (aging) explícito (aumentar a prioridade com o tempo de espera).
• Especialização de trabalhadores: alguns trabalhadores apenas aceitam tarefas "longas".
• Pressão de retorno (back-pressure): limitar quantas tarefas rápidas entram na fila.

O link do roteamento baseado em conteúdo

O enxame combina naturalmente com o roteamento baseado em conteúdo (Lição 22). Em vez de uma fila genérica, tenha uma fila por tipo de mensagem. Trabalhadores especialistas se inscrevem apenas em seu tipo. Essa é a base para arquiteturas de barramento de mensagens que escalam para milhares de agentes.

Construa

O code/main.py implementa um enxame de 4 threads de trabalhadores (workers) coletando de uma queue.Queue compartilhada. As tarefas têm durações variáveis (algumas rápidas, outras lentas). A demonstração contrasta:

• Linha de base sequencial: um trabalhador processa todas as tarefas em série.
• Atribuição fixa: cada tarefa é pré-atribuída a um trabalhador específico (estilo supervisor).
• Enxame (Swarm): os trabalhadores coletam de uma fila compartilhada.

O enxame equilibra a carga automaticamente; a atribuição fixa deixa trabalhadores rápidos ociosos quando a tarefa atribuída a eles é lenta.

Execute:

python3 code/main.py

A saída mostra a contagem de tarefas por trabalhador (o enxame distribui de forma desigual, mas ideal) e os tempos de relógio de parede (wall-clock times).

Use

O outputs/skill-swarm-fit.md avalia se uma tarefa deve usar enxame vs supervisor. Entradas: independência das tarefas, variação de duração, requisitos de ordenação e necessidades de depuração.

Coloque em Produção

Checklist:

• Fila de prioridade com envelhecimento (aging). Evite a inanição de tarefas longas.
• Idempotência do trabalhador. Uma tarefa pode ser coletada mais de uma vez se um trabalhador falhar no meio da execução. Os trabalhadores devem ser idempotentes.
• Fila durável. Use Kafka, Redis Streams ou uma fila baseada em banco de dados para produção. A queue.Queue é apenas em memória.
• Observabilidade por tarefa. Cada tarefa tem um ID de rastreamento (trace ID); cada trabalhador registra o início/fim com ele.
• Pressão de retorno (back-pressure). Se a fila crescer mais rápido do que os trabalhadores a esvaziam, desacelere o produtor.

Exercícios

1. Execute code/main.py. Quanto mais rápido é o enxame em comparação ao sequencial na carga de trabalho com duração variável? Quanto mais rápido em comparação à atribuição fixa?
2. Adicione uma variante de fila de prioridade (use queue.PriorityQueue). Atribua prioridade pelo campo "importance" da tarefa. Observe se as tarefas de baixa prioridade chegam a sofrer inanição (starve) sob carga contínua.
3. Implemente um detector de gargalo (hot-spot): registre quando qualquer trabalhador processar 3 vezes mais tarefas do que o trabalhador mais lento. O que isso indica sobre a distribuição de duração das tarefas?
4. Leia o resumo e a Seção 3 do artigo do Matrix (arXiv:2511.21686). Identifique um tradeoff específico que o Matrix aceita (ganho de escalabilidade) e um que ele abre mão (rastreabilidade, determinismo).
5. Converta a demonstração de enxame para usar uma queue.Queue de tuplas (task_type, payload), com os trabalhadores se inscrevendo apenas em tipos específicos. Quais regras de roteamento fazem sentido quando as tarefas são heterogêneas?

Termos-Chave

Leitura Adicional

• LangGraph workflows and agents — Swarm Architecture — suporte explícito a enxame
• Matrix — A Decentralized Framework for Multi-Agent Systems — enxame completo de passagem de mensagens
• Anthropic engineering — why supervisor not swarm in Research — por que um sistema de produção específico escolheu explicitamente supervisor em vez de enxame
• AutoGen v0.4 actor-model docs — a reescrita do modelo de ator orientada a eventos, mais próxima de enxame do que o GroupChat do v0.2.