padrões-multi-agente

Padrões de Arquitetura Multi-Agente

Arquiteturas multi-agente distribuem o trabalho entre múltiplas instâncias de modelo de linguagem, cada uma com sua própria janela de contexto. Quando bem projetadas, essa distribuição possibilita capacidades além dos limites de um único agente. Quando mal projetadas, introduz uma sobrecarga de coordenação que anula os benefícios. A percepção crítica é que os subagentes existem principalmente para isolar o contexto, não para antropomorfizar a divisão de papéis.

Quando Ativar

Ative esta habilidade quando:

• Os limites de contexto de um único agente restringem a complexidade da tarefa
• As tarefas se decompõem naturalmente em subtarefas paralelas
• Diferentes subtarefas exigem diferentes conjuntos de ferramentas ou prompts de sistema
• Construir sistemas que precisam lidar com múltiplos domínios simultaneamente
• Escalar capacidades de agente além dos limites de um único contexto
• Projetar sistemas de agente de produção com múltiplos componentes especializados

Não ative esta habilidade para trabalhos adjacentes de outras habilidades:

• Decidir a adequação tarefa-modelo, formato do pipeline ou custo em nível de projeto antes que a topologia seja conhecida: project-development.
• Projetar sandboxes hospedadas, pools quentes, sessões remotas ou infraestrutura de runtime em segundo plano: hosted-agents.
• Compartilhar estado do orquestrador através de compactação de cache KV em runtimes controlados: latent-briefing.
• Projetar as ferramentas que cada agente expõe: tool-design.

Conceitos Centrais

Use padrões multi-agente quando a janela de contexto de um único agente não consegue conter todas as informações relevantes para a tarefa. O isolamento de contexto é o principal benefício — cada agente opera em um contexto limpo, sem ruído acumulado de outras subtarefas, prevenindo o problema do jogo do telefone onde a informação se degrada através de sumarizações repetidas.

Escolha entre três padrões dominantes com base nas necessidades de coordenação, não na metáfora organizacional:

• Supervisor/orquestrador — Use para controle centralizado quando as tarefas têm decomposição clara e a supervisão humana é importante. Um único coordenador delega para especialistas e sintetiza os resultados.
• Peer-to-peer/swarm — Use para exploração flexível quando o planejamento rígido é contraproducente. Qualquer agente pode transferir o controle para qualquer outro através de mecanismos explícitos de transferência.
• Hierárquico — Use para projetos de grande escala com abstração em camadas (estratégia, planejamento, execução). Cada camada opera em um nível diferente de detalhe com sua própria estrutura de contexto.

Projete todo sistema multi-agente em torno de protocolos explícitos de coordenação, mecanismos de consenso que resistam à sicofância e tratamento de falhas que evite cascatas de propagação de erros.

Tópicos Detalhados

Por que Arquiteturas Multi-Agente

O Gargalo do Contexto Recorra a arquiteturas multi-agente quando o contexto de um único agente se enche de histórico acumulado, documentos recuperados e saídas de ferramentas a ponto de degradar o desempenho. Reconheça três sinais de degradação: o efeito perdido-no-meio (a atenção enfraquece para conteúdo no meio do contexto), escassez de atenção (muitos itens competindo) e envenenamento de contexto (conteúdo irrelevante desloca conteúdo útil).

Particione o trabalho em múltiplas janelas de contexto para que cada agente opere em um contexto limpo focado em sua subtarefa. Agregue os resultados em uma camada de coordenação sem que nenhum contexto único suporte a carga total.

A Realidade da Economia de Tokens Prepare-se para custos de token substancialmente mais altos. Dados de produção mostram que sistemas multi-agente podem custar muito mais tokens do que uma conversa com um único agente (claim-multi-agent-token-multiplier):

Arquitetura	Multiplicador de Token	Caso de Uso
Chat com agente único	Linha de base	Consultas simples
Agente único com ferramentas	Maior que a linha de base	Tarefas que usam ferramentas
Sistema multi-agente	Muito maior que a linha de base	Pesquisa/coordenação complexa

Pesquisas de avaliação de agentes de navegação sugerem que o uso de tokens, chamadas de ferramentas e a escolha do modelo dominam a variância de desempenho (claim-evaluation-browsecomp-variance). Isso apoia a medição de configurações multi-agente em relação a linhas de base de agente único, em vez de assumir que mais agentes ajudam.

Priorize a seleção de modelo juntamente com o design da arquitetura — atualizar para modelos melhores frequentemente fornece ganhos de desempenho maiores do que dobrar os orçamentos de token. Dados do BrowseComp mostram que melhorias na qualidade do modelo superam com frequência aumentos brutos de token. Trate a seleção de modelo e a arquitetura multi-agente como estratégias complementares.

O Argumento da Paralelização Atribua subtarefas paralelizáveis a agentes dedicados com contextos novos, em vez de processá-las sequencialmente em um único agente. Uma tarefa de pesquisa que exige buscas em múltiplas fontes independentes, análise de diferentes documentos ou comparação de abordagens concorrentes se beneficia da execução paralela. O tempo real total se aproxima da duração da subtarefa mais longa, em vez da soma de todas as subtarefas.

O Argumento da Especialização Configure cada agente apenas com o prompt de sistema, ferramentas e contexto de que precisa para sua subtarefa específica. Um agente de uso geral deve carregar todas as configurações possíveis no contexto, diluindo a atenção. Agentes especializados carregam apenas o que precisam, operando com contexto enxuto otimizado para seu domínio. Roteie de um coordenador para agentes especializados para alcançar especialização sem explosão combinatória.

Padrões Arquiteturais

Padrão 1: Supervisor/Orquestrador Implante um agente central que mantém o estado global e a trajetória, decompõe os objetivos do usuário em subtarefas e roteia para trabalhadores apropriados.

Consulta do Usuário -> Supervisor -> [Especialista, Especialista, Especialista] -> Agregação -> Saída Final

Escolha este padrão quando: as tarefas têm decomposição clara, a coordenação entre domínios é necessária ou a supervisão humana é importante.

Espere estas compensações: controle de fluxo de trabalho rigoroso e intervenções humano-no-loop mais fáceis, mas o contexto do supervisor se torna um gargalo, falhas do supervisor se propagam para todos os trabalhadores e o problema do "jogo do telefone" surge quando os supervisores parafraseiam incorretamente as respostas dos subagentes.

O Problema do Jogo do Telefone e sua Solução Antecipe que arquiteturas de supervisor inicialmente tenham desempenho aproximadamente 50% pior do que versões otimizadas devido ao problema do jogo do telefone (benchmarks LangGraph). Supervisores parafraseiam as respostas dos subagentes, perdendo fidelidade a cada passagem.

Resolva isso implementando uma ferramenta forward_message que permite que os subagentes passem respostas diretamente aos usuários:

def forward_message(message: str, to_user: bool = True):
    """
    Encaminha a resposta do subagente diretamente ao usuário, sem síntese do supervisor.

    Use quando:
    - A resposta do subagente é final e completa
    - A síntese do supervisor perderia detalhes importantes
    - O formato da resposta deve ser preservado exatamente
    """
    if to_user:
        return {"type": "direct_response", "content": message}
    return {"type": "supervisor_input", "content": message}

Prefira arquiteturas swarm em vez de supervisores quando os subagentes puderem responder diretamente aos usuários, pois isso elimina completamente os erros de tradução.

Padrão 2: Peer-to-Peer/Swarm Remova o controle central e permita que os agentes se comuniquem diretamente com base em protocolos predefinidos. Qualquer agente transfere o controle para qualquer outro através de mecanismos explícitos de transferência.

def transfer_to_agent_b():
    return agent_b  # Transferência via retorno de função

agent_a = Agent(
    name="Agent A",
    functions=[transfer_to_agent_b]
)

Escolha este padrão quando: as tarefas exigem exploração flexível, o planejamento rígido é contraproducente ou os requisitos surgem dinamicamente e desafiam a decomposição inicial.

Espere estas compensações: nenhum ponto único de falha e escalabilidade breadth-first eficaz, mas a complexidade de coordenação aumenta com o número de agentes, o risco de divergência aumenta sem um mantenedor de estado central e restrições robustas de convergência se tornam essenciais.

Defina protocolos explícitos de transferência com passagem de estado. Garanta que os agentes comuniquem suas necessidades de contexto aos agentes receptores.

Padrão 3: Hierárquico Organize os agentes em camadas de abstração: estratégia (definição de objetivos), planejamento (decomposição de tarefas) e execução (tarefas atômicas).

Camada de Estratégia (Definição de Objetivos) -> Camada de Planejamento (Decomposição de Tarefas) -> Camada de Execução (Tarefas Atômicas)

Escolha este padrão quando: os projetos têm estrutura hierárquica clara, os fluxos de trabalho envolvem camadas de gerenciamento ou as tarefas exigem planejamento de alto nível e execução detalhada.

Espere estas compensações: separação clara de responsabilidades e suporte para diferentes estruturas de contexto em diferentes níveis, mas sobrecarga de coordenação entre camadas, potencial desalinhamento estratégia-execução e caminhos complexos de propagação de erros.

Isolamento de Contexto como Princípio de Design

Trate o isolamento de contexto como o objetivo principal das arquiteturas multi-agente. Cada subagente deve operar em uma janela de contexto limpa focada em sua subtarefa, sem carregar contexto acumulado de outras subtarefas.

Mecanismos de Isolamento Selecione o mecanismo de isolamento correto para cada subtarefa:

• Delegação total de contexto — Compartilhe o contexto completo do planejador com o subagente. Use para tarefas complexas onde o subagente precisa de compreensão completa. O subagente tem suas próprias ferramentas e instruções, mas recebe o contexto completo para suas decisões. Nota: isso anula parcialmente o propósito do isolamento de contexto.
• Passagem de instruções — Crie instruções via chamada de função; o subagente recebe apenas o que precisa. Use para subtarefas simples e bem definidas. Mantém o isolamento, mas limita a flexibilidade do subagente.
• Memória do sistema de arquivos — Agentes leem e escrevem em armazenamento persistente. Use para tarefas complexas que exigem estado compartilhado. O sistema de arquivos serve como mecanismo de coordenação, evitando o inchaço do contexto devido à passagem de estado compartilhado. Introduz latência e desafios de consistência, mas escala melhor do que a passagem de mensagens.

Escolha com base na complexidade da tarefa, nas necessidades de coordenação e na latência aceitável. Padrão: passagem de instruções e escale para memória do sistema de arquivos quando o estado compartilhado for necessário. Evite a delegação total de contexto, a menos que a subtarefa realmente exija.

Consenso e Coordenação

O Problema da Votação Evite a votação por maioria simples — ela trata alucinações de modelos fracos como iguais ao raciocínio de modelos fortes. Sem intervenção, discussões multi-agente degeneram em consenso sobre premissas falsas devido ao viés inerente para concordância.

Votação Ponderada Pondere os votos dos agentes por confiança ou especialização. Agentes com maior confiança ou especialização no domínio devem ter mais peso nas decisões finais.

Protocolos de Debate Estruture os agentes para criticar as saídas uns dos outros ao longo de várias rodadas. A crítica adversarial frequentemente produz maior precisão em raciocínios complexos do que o consenso colaborativo. Proteja-se contra a convergência sicofante, onde os agentes concordam para serem agradáveis em vez de corretos.

Intervenção Baseada em Gatilho Monitore as interações multi-agente em busca de marcadores comportamentais. Ative gatilhos de paralisação quando as discussões não progredirem. Detecte gatilhos de sicofância quando os agentes imitam as respostas uns dos outros sem raciocínio único.

Considerações sobre Frameworks

Diferentes frameworks implementam esses padrões com filosofias diferentes. LangGraph usa máquinas de estado baseadas em grafos com nós e arestas explícitos. AutoGen usa padrões conversacionais/event-driven com GroupChat. CrewAI usa fluxos de processo baseados em papéis com estruturas de equipe hierárquicas.

Orientação Prática

Modos de Falha e Mitigações

Falha: Gargalo do Supervisor O supervisor acumula contexto de todos os trabalhadores, tornando-se suscetível a saturação e degradação.

Mitigue restringindo os esquemas de saída dos trabalhadores para que retornem apenas resumos destilados. Use checkpointing para persistir o estado do supervisor sem carregar o histórico completo no contexto.

Falha: Sobrecarga de Coordenação A comunicação entre agentes consome tokens e introduz latência. A coordenação complexa pode anular os benefícios da paralelização.

Mitigue minimizando a comunicação através de protocolos claros de transferência. Agrupe resultados quando possível. Use padrões de comunicação assíncrona. Meça se a coordenação multi-agente realmente economiza tempo em comparação com um único agente com um contexto mais longo.

Falha: Divergência Agentes perseguindo objetivos diferentes sem coordenação central se desviam dos objetivos pretendidos.

Mitigue definindo limites claros de objetivo para cada agente. Implemente verificações de convergência que verifiquem o progresso em direção a objetivos compartilhados. Defina limites de time-to-live na execução do agente para evitar exploração ilimitada.

Falha: Propagação de Erros Erros na saída de um agente se propagam para agentes downstream que consomem essa saída, compondo resultados cada vez mais incorretos.

Mitigue validando as saídas dos agentes antes de passá-las aos consumidores. Implemente lógica de repetição com circuit breakers. Use operações idempotentes quando possível. Considere adicionar um agente de verificação que cruze as saídas críticas antes de entrarem no pipeline.

Exemplos

Exemplo 1: Arquitetura de Equipe de Pesquisa

Supervisor
├── Pesquisador (busca na web, recuperação de documentos)
├── Analista (análise de dados, estatísticas)
├── Verificador de Fatos (verificação, validação)
└── Redator (geração de relatórios, formatação)

Exemplo 2: Protocolo de Transferência

def handle_customer_request(request):
    if request.type == "billing":
        return transfer_to(billing_agent)
    elif request.type == "technical":
        return transfer_to(technical_agent)
    elif request.type == "sales":
        return transfer_to(sales_agent)
    else:
        return handle_general(request)

Diretrizes

1. Projete para o isolamento de contexto como o principal benefício dos sistemas multi-agente
2. Escolha o padrão de arquitetura com base nas necessidades de coordenação, não na metáfora organizacional
3. Implemente protocolos explícitos de transferência com passagem de estado
4. Use votação ponderada ou protocolos de debate para consenso
5. Monitore gargalos do supervisor e implemente checkpointing
6. Valide as saídas antes de passá-las entre agentes
7. Defina limites de time-to-live para evitar loops infinitos
8. Teste cenários de falha explicitamente

Armadilhas

1. Gargalo do supervisor — O contexto do supervisor se torna o gargalo em sistemas grandes; combata com saídas de trabalhadores enxutas e checkpointing.
2. Superioridade imaginada do multi-agente — Meça em relação a uma linha de base realista de agente único; a orquestração custa tokens.
3. Sicofância — Agentes em debate convergem para concordância; implemente votação ponderada e protocolos de debate adversarial.
4. Alucinação em cascata — Erros iniciais se amplificam através do sistema; implemente validação em cada borda.
5. Complexidade de implementação — Sistemas multi-agente são mais complexos de construir e depurar que sistemas de agente único; comece simples e adicione agentes apenas quando necessário.

Referências

• claim-multi-agent-token-multiplier — Documentação sobre custos incrementais de tokens em sistemas multi-agente
• claim-evaluation-browsecomp-variance — Pesquisa sobre fatores que dominam a variância de desempenho em agentes de navegação
• Documentação da OpenAI sobre transferências de agente