Sistemas Multiagentes

O que é um Sistema Multiagente?

Um Sistema Multiagente (Multi-Agent System, MAS) é um sistema no qual múltiplos agentes autônomos (autonomous agents) interagem em um ambiente compartilhado para atingir objetivos. Os agentes podem ser processos de software, robôs, serviços ou agentes de modelo de linguagem grande (LLM agents) capazes de raciocinar, comunicar-se e agir (frequentemente via ferramentas). A principal diferença em relação a sistemas de agente único é que o comportamento emerge das interações: os agentes podem cooperar, competir ou fazer ambos, dependendo de incentivos e restrições.

No contexto de fluxos de trabalho agênticos baseados em modelos de linguagem grandes (LLM-based agentic workflows), “multiagente (multi-agent)” normalmente significa múltiplas instâncias (ou papéis) especializadas de modelos de linguagem grandes coordenando-se por meio de mensagens e estado compartilhado (shared state) para resolver tarefas amplas demais, incertas demais ou de horizonte longo demais para um único agente.

Características centrais:

Autonomia: cada agente pode decidir ações sem controle direto passo a passo.
Visões locais: os agentes frequentemente têm informações parciais (contexto limitado, observabilidade parcial).
Interação: agentes afetam uns aos outros por meio de comunicação e ações no ambiente.
Descentralização: nenhum agente único tem controle completo (embora o padrão de supervisor (supervisor pattern) seja comum na prática).

Por que usar múltiplos agentes?

Múltiplos agentes são úteis quando:

A tarefa se decompõe em subcompetências especializadas (pesquisa, codificação, testes, escrita).
O ambiente é distribuído (robôs em locais diferentes, serviços em redes diferentes).
Você quer robustez (a falha de um agente não deveria colapsar o sistema inteiro).
Você quer confiabilidade melhorada via redundância (verificação independente, crítica).
Você precisa de paralelismo (velocidade) ou cobertura (explorar hipóteses diversas).

Compensações (trade-offs) a considerar:

A sobrecarga de coordenação pode anular ganhos de velocidade.
A comunicação adiciona complexidade e novos modos de falha.
Agentes podem “concordar” em respostas erradas (erros correlacionados) sem verificações fortes.

Fundamentos teóricos (o que a pesquisa em MAS formaliza)

Sistemas multiagentes têm uma longa história em IA distribuída, controle, economia e teoria dos jogos. Alguns dos formalismos mais relevantes:

Processos de decisão multiagentes

Processo de Decisão de Markov (Markov Decision Process, MDP): tomada de decisão sequencial de agente único.
Jogos estocásticos / jogos de Markov (stochastic games / Markov games): generalização multiagente de MDPs; as recompensas dos agentes dependem de ações conjuntas.
MDP parcialmente observável descentralizado (Decentralized Partially Observable MDP, Dec-POMDP): múltiplos agentes com observações parciais e objetivos potencialmente compartilhados — expressivo, porém computacionalmente difícil.
Não estacionariedade (non-stationarity): da perspectiva de qualquer agente, o ambiente muda conforme outros agentes aprendem ou se adaptam, complicando as dinâmicas de aprendizado em Aprendizado por Reforço (Reinforcement Learning) e em aprendizado por reforço multiagente (multi-agent RL).

Teoria dos jogos e desenho de mecanismos

Quando os incentivos não estão totalmente alinhados, o comportamento de MAS é melhor compreendido por meio de:

Equilíbrio de Nash (Nash equilibrium) (perfis de estratégia estáveis)
Teoria dos jogos cooperativos (cooperative game theory) (coalizões, utilidade conjunta)
Desenho de mecanismos (mechanism design) (projetar regras/mercados para que agentes racionais produzam resultados desejados)

Relevância prática: quando agentes têm objetivos diferentes (por exemplo, “agente de vendas” vs “agente de conformidade”), você deve projetar explicitamente incentivos, restrições e arbitragem.

Coordenação e resolução distribuída de problemas

Métodos clássicos de coordenação em MAS incluem:

Protocolo Contract Net (Contract Net Protocol, CNP): agentes fazem lances por tarefas; um gerente atribui o trabalho.
Sistemas de quadro-negro (blackboard systems): agentes publicam resultados parciais em um espaço de trabalho compartilhado.
Otimização distribuída de restrições (Distributed Constraint Optimization, DCOP): agentes resolvem restrições globais via troca local de mensagens.
Algoritmos de consenso (consensus algorithms): garantem que um grupo converja para um valor/estado compartilhado (mais comum em sistemas distribuídos, mas conceitualmente semelhante à coordenação por crença compartilhada).

Essas ideias se encaixam bem em padrões modernos de orquestração de agentes de modelos de linguagem grandes.

Papéis: como estruturar “múltiplos agentes coordenados”

Um MAS prático geralmente começa definindo papéis: pelo que cada agente é responsável, a que ele pode acessar e como se comunica.

Padrões comuns de papéis (amigáveis a agentes de modelos de linguagem grandes) (LLM-agent-friendly)

Supervisor–Executor
- O Supervisor decompõe tarefas, atribui trabalho e integra resultados.
- Os Executores são especialistas (busca/recuperação, codificação, análise, garantia de qualidade).
- Prós: controle simples, depuração mais fácil.
- Contras: o supervisor é um gargalo e um ponto único de falha.
Comitê / Votação
- Vários agentes pares propõem soluções; um juiz agrega.
- Prós: reduz fragilidade de um único modelo; pode revelar raciocínios diversos.
- Contras: pode amplificar vieses compartilhados; pode “tirar uma média” medíocre sem um critério de pontuação forte.
Debate / Crítica
- Um agente propõe, outro critica; iterações refinam a saída.
- Prós: efetivo para encontrar erros e justificar decisões.
- Contras: pode degenerar em ciclos retóricos, a menos que você imponha evidências e regras de parada.
Pipeline / Linha de montagem
- Agentes organizados em etapas: planejar → pesquisar → rascunhar → verificar → formatar.
- Prós: interfaces claras; bom para fluxos operacionais.
- Contras: erros a montante se propagam, a menos que etapas posteriores possam contestar premissas.
Baseado em mercado / Lances
- Agentes fazem lances por tarefas com base em custo/confiança; a alocação otimiza um objetivo global.
- Prós: escalável; alocação de tarefas flexível.
- Contras: exige cuidado no design de “lances” e veracidade; pode ser manipulado.

Checklist de definição de papéis

Para cada papel, defina:

Objetivo: o que significa “pronto”.
Entradas/saídas: esquema (schema) esperado de mensagens e artefatos.
Permissões: ferramentas, fontes de dados, acesso externo.
Restrições: orçamento, tempo, regras de segurança.
Portas de qualidade (quality gates): testes, validações, citações/logs obrigatórios.
Regras de escalonamento: quando pedir ajuda ou repassar para outro agente.

Clareza de papéis é um dos maiores determinantes de se a coordenação multiagente de fato melhora os resultados.

Comunicação: mensagens, protocolos e estado compartilhado

A comunicação é onde sistemas multiagentes se tornam poderosos — ou caóticos.

Canais de comunicação

Mensagens diretas: chat agente-a-agente; rápido, mas pode ser ruidoso.
Espaço de trabalho compartilhado: um quadro-negro, sistema de tickets ou documento compartilhado.
Barramento de eventos (event bus): publicar/assinar (publish/subscribe); agentes reagem a eventos (tarefa criada, teste falhou).
Mediada pelo ambiente: agentes agem no mundo; outros inferem intenção a partir das ações.

Sistemas modernos com modelos de linguagem grandes frequentemente combinam mensagens diretas com um repositório de estado compartilhado (shared state store). Veja também: Memória e Estado.

Conteúdo das mensagens: linguagem natural vs formatos estruturados

Linguagem natural é flexível, mas ambígua e mais difícil de validar.
Mensagens estruturadas (structured messages) (JSON, esquemas) são robustas para orquestração e ferramental.

Um compromisso prático é “LN + esquema”: uma justificativa curta em linguagem natural mais campos verificáveis por máquina.

Exemplo de esquema:

{
  "type": "task_result",
  "task_id": "T-1042",
  "agent_role": "researcher",
  "status": "success",
  "claims": [
    {"claim": "X reduces latency", "evidence": "benchmark_link_or_log"}
  ],
  "artifacts": ["notes.md", "sources.json"],
  "uncertainties": ["Result may not hold for ARM CPUs"]
}

Protocolos: quem fala quando?

Sem regras de alternância de turno, MAS pode entrar em espirais de conversa. Elementos úteis de protocolo:

Estados do ciclo de vida da tarefa (task lifecycle states): created → assigned → in_progress → blocked → done → verified.
Limitação de tempo (time boxing): máximo de turnos por agente; escalonamento após N ciclos.
Regras de roteamento (routing rules): apenas o supervisor pode reatribuir tarefas; executores falam via supervisor (ou não).
Resolução de conflitos: o que acontece se agentes discordarem?
Requisitos de fundamentação (grounding requirements): alegações devem citar logs, saídas de ferramentas ou resultados de testes.

Estado compartilhado e “base comum”

Muitas falhas de coordenação vêm de contexto compartilhado ausente ou inconsistente:

Agentes referenciam versões diferentes de requisitos.
Agentes assumem que outros fizeram verificações que nunca aconteceram.
Agentes sobrescrevem os artefatos intermediários uns dos outros.

Padrões de design para reduzir isso:

Uma única fonte de verdade (source of truth) (quadro de tarefas + repositório de artefatos).
Artefatos imutáveis com versionamento (logs somente de acréscimo (append-only logs)).
Campos explícitos de “premissas” e “perguntas em aberto” nas mensagens.
Resumos periódicos de sincronização (“Aqui está o que concordamos”).

Isso se sobrepõe fortemente a Uso de Ferramentas e Orquestração: ferramentas devem atualizar o estado compartilhado de forma determinística, e a orquestração deve impor esquemas e transições do ciclo de vida.

Estratégias de coordenação: da alocação de tarefas ao planejamento conjunto

Decomposição e alocação de tarefas

Abordagens comuns:

Decomposição estática: pipeline predefinido; bom para fluxos rotineiros.
Decomposição dinâmica: o supervisor divide tarefas com base em progresso e incerteza.
Roteamento por habilidade: combina tarefas com especialistas (por exemplo, “agente de SQL”, “agente de segurança”).
Alocação por lances/mercado: agentes submetem custo/confiança; escolhe-se a melhor utilidade esperada.

Heurística prática: aloque com base em vantagem comparativa (comparative advantage) (no que um agente é singularmente bom), não apenas em “mais agentes = mais rápido”.

Planejamento conjunto vs trabalho independente

Trabalho independente + integração funciona bem quando subproblemas são separáveis.
Planejamento conjunto (joint planning) é necessário quando ações são fortemente acopladas (equipes de robôs, restrições compartilhadas).

Para agentes de modelos de linguagem grandes, planejamento conjunto frequentemente se parece com:

Esqueleto de plano compartilhado (marcos, interfaces)
Exploração paralela de alternativas
Integração central com verificação/testes

Consenso e tratamento de discordâncias

Discordância nem sempre é ruim — pode sinalizar incerteza. Mecanismos úteis:

Voto da maioria (majority vote) (rápido, mas podem errar juntos)
Voto ponderado (weighted voting) (pondera por acurácia passada ou confiança apoiada por ferramentas)
Revisão adversarial (adversarial review) (o trabalho de um agente é encontrar falhas)
Verificação formal / testes (formal verification / tests) como árbitro final quando possível

Um princípio-chave: resolva discordâncias transformando-as em perguntas testáveis.

Modos de falha (e por que MAS frequentemente falha na prática)

Sistemas multiagentes não apenas herdam problemas de agente único (alucinações (hallucinations), fragilidade (brittleness)); eles introduzem novas falhas em nível de sistema.

1) Falhas de coordenação

Impasse (deadlock): agentes aguardam uns aos outros (“Preciso das especificações” / “Preciso de detalhes de implementação”).
Livelock (livelock): muita atividade, mas nenhum progresso (debate sem fim, replanejamento repetido).
Duplicação de tarefa: múltiplos agentes fazem o mesmo trabalho por atribuições pouco claras.
Colapso de integração: componentes não se encaixam (incompatibilidade de API, premissas inconsistentes).

Mitigações:

Propriedade clara por tarefa/artefato.
Contratos de interface compartilhados (esquemas, testes).
Timeouts + regras de escalonamento.

2) Falhas de comunicação

Ambiguidade: instruções vagas geram saídas incompatíveis.
Deriva de contexto: agentes divergem conforme mensagens resumem e comprimem detalhes.
Perda de informação: restrições cruciais não chegam a todos os agentes.
Comunicação excessiva: ruído supera o sinal; custos explodem.

Mitigações:

Mensagens estruturadas para compromissos (“Entregarei X até Y”).
Resumos compartilhados periódicos (base comum).
Limitar broadcast; usar roteamento direcionado.

3) Falhas epistêmicas (problemas de crença e verdade)

Cascatas de erro: uma premissa incorreta se espalha e vira “aceita”.
Falso consenso: múltiplos agentes convergem para uma resposta errada por viés compartilhado.
Lavagem de especulação: um palpite é repetido até soar como fato.
Névoa de citação: fontes faltam, são circulares ou irrelevantes.

Mitigações:

Exigir evidência apoiada por ferramentas para alegações-chave (testes, recuperação, logs).
Atribuir um papel verificador dedicado.
Rastrear confiança e incerteza explicitamente.

4) Falhas de incentivos e alinhamento

Quando agentes têm objetivos diferentes ou metas implícitas:

Desalinhamento de objetivos: um agente de “velocidade” corta caminhos; um agente de “qualidade” bloqueia o progresso.
Manipulação de recompensa (reward hacking): agentes otimizam métricas medidas em vez de objetivos reais.
Conluio: agentes reforçam as escolhas uns dos outros para minimizar trabalho (ou para “parecer consistente”).
Captura de autoridade: um agente domina decisões independentemente de correção.

Mitigações:

Prioridades e arbitragem explícitas (o que vence: segurança vs velocidade?).
Verificações e auditorias independentes.
Alternar papéis de “juiz”; manter checagens finais baseadas em ferramentas.

5) Falhas de segurança e proteção

Injeção de prompt (prompt injection) entre agentes: um agente repassa instruções maliciosas a outro.
Exfiltração de dados (data exfiltration) via mensagens: informações sensíveis vazam por canais compartilhados.
Uso indevido de ferramentas (tool misuse): um agente usa permissões para ações não intencionais.

Mitigações:

Princípio do menor privilégio (principle of least privilege) para ferramentas.
Filtragem de conteúdo e checagens de política nas fronteiras.
Tratar mensagens entre agentes como entrada não confiável; validar esquemas e sanitizar.

6) Falhas de engenharia de sistemas

Não determinismo (non-determinism) e irreplicabilidade (irreproducibility): difícil depurar comportamento emergente.
Explosões de custo: “conversa” multiagente aumenta custos de tokens/ferramentas.
Explosões de latência: dependências sequenciais anulam paralelismo.

Mitigações:

Logging com IDs de correlação (correlation IDs) e ferramentas de replay (replay tools).
Orçamento por papel; limites rígidos de turnos/chamadas.
Preferir trabalho paralelo apenas quando a integração estiver clara.

Exemplos práticos

Exemplo 1: Mudança de software com agentes revisor e testador

Objetivo: implementar uma funcionalidade com segurança.

Papéis:

Planejador: decompõe a mudança, identifica riscos.
Implementador: edita o código.
Testador: escreve/atualiza testes, executa a suíte de testes.
Revisor: verifica estilo, segurança e casos de borda.

Fluxo:

O Planejador cria tarefas com critérios de aceitação (acceptance criteria).
O Implementador cria um artefato do tipo PR (pull request).
O Testador executa testes e adiciona cobertura ausente.
O Revisor bloqueia o merge a menos que os testes passem e os riscos sejam endereçados.

O que isso ganha sobre um único agente:

Separação de responsabilidades (codificação vs revisão adversarial).
Portas de controle mais fortes (testes como evidência).

Falha típica:

Implementador e Revisor “concordam” sem executar testes. Correção: exigir logs de teste produzidos por ferramenta.

Exemplo 2: Triagem de suporte ao cliente com escalonamento

Papéis:

Agente classificador: categoriza o problema e extrai campos estruturados.
Agente respondedor: redige a resposta ao cliente.
Agente de políticas: garante conformidade e restrições de segurança.
Agente de escalonamento: direciona para humano ou engenharia com um template de relatório de bug.

Modo de falha:

O classificador rotula mal a urgência → caminho errado de SLA (service level agreement). Mitigação: incluir confiança e escalonamento humano baseado em limiar.

Exemplo 3: Separação de pedidos em armazém com múltiplos robôs (MAS clássico)

Papéis:

Cada robô é um agente que planeja seu próprio caminho.
Uma camada de coordenação lida com prevenção de colisões e atribuição de tarefas.

Desafios:

Observabilidade parcial (corredores bloqueados).
Obstáculos dinâmicos (humanos, empilhadeiras).
Necessidade de coordenação distribuída e garantias de segurança.

Esse domínio ilustra por que a teoria de MAS enfatiza planejamento descentralizado, consenso e restrições de segurança.

Padrões de implementação para MAS com modelos de linguagem grandes

Abaixo há um esboço simplificado de orquestração mostrando mensagens estruturadas, roteamento e portas de verificação (verification gates).

from dataclasses import dataclass
from typing import Literal, Optional

Status = Literal["created", "assigned", "done", "blocked"]

@dataclass
class Task:
    id: str
    owner_role: str
    status: Status
    spec: str
    artifact_uri: Optional[str] = None
    evidence_uri: Optional[str] = None

def route(task: Task) -> str:
    # Simple router: send to role that owns it; could be skill-based.
    return task.owner_role

def verify(task: Task) -> bool:
    # In real systems: run tests, validate JSON schema, check citations, etc.
    return task.evidence_uri is not None and task.artifact_uri is not None

def orchestrate(tasks, agents):
    while True:
        pending = [t for t in tasks if t.status in ("created", "assigned", "blocked")]
        if not pending:
            break

        for task in pending:
            role = route(task)
            result = agents[role].run(task.spec)  # returns structured result

            task.status = result["status"]
            task.artifact_uri = result.get("artifact_uri")
            task.evidence_uri = result.get("evidence_uri")

            if task.status == "done" and not verify(task):
                task.status = "blocked"
                task.spec = "Add evidence (tests/logs) and resubmit."

    return tasks

Notas de design:

O orquestrador impõe interfaces e portas de qualidade.
Agentes produzem artefatos e evidências, não apenas texto.
A verificação é explícita e idealmente baseada em ferramentas.

Esse padrão se alinha com Uso de Ferramentas e Orquestração robusto e depende de Memória e Estado compartilhados confiáveis.

Avaliação e depuração de sistemas multiagentes

Avaliar MAS é mais difícil do que avaliar um único modelo porque os resultados dependem da dinâmica de interação.

Ângulos úteis de avaliação:

Taxa de sucesso da tarefa e tempo até a conclusão
Custo (tokens, chamadas de ferramentas, latência de relógio de parede)
Robustez (desempenho sob entradas ruidosas, falhas parciais)
Ablações (ablations) (remover um agente/papel; o desempenho cai?)
Métricas de interação (interaction metrics) (mensagens por tarefa, frequência de discordância)
Taxa de aprovação na verificação (verification pass rate) (com que frequência alegações são apoiadas por testes/evidência)

Práticas de depuração:

Logs correlacionados com IDs por tarefa.
Salvar trilhas completas de mensagens (com redação para dados sensíveis).
Reexecutar execuções com sementes/configurações fixas onde possível.
Testes unitários de “conformidade de protocolo” (esquemas, transições do ciclo de vida).

Uma surpresa comum: um sistema pode parecer melhor com mais agentes, enquanto fica menos confiável se a verificação for fraca.

Aplicações de sistemas multiagentes

MAS aparece em diversas áreas de IA e engenharia:

Robótica: enxames de drones, mapeamento com múltiplos robôs, automação de armazéns
Tráfego e cidades inteligentes: semáforos adaptativos, roteamento coordenado
Cibersegurança: agentes de monitoramento distribuído + coordenação de resposta a incidentes
Jogos e simulações: sociedades de NPCs, comportamentos emergentes (emergent behaviors), treinamento via autojogo (self-play)
Fluxos corporativos (agentes de modelos de linguagem grandes): pipelines de pesquisa, revisão de conformidade, geração de código + testes, assistentes de analytics
Ciência e engenharia: geração de hipóteses + revisão de literatura + planejamento de experimentos

Em produtos guiados por modelos de linguagem grandes, MAS costuma ser usado menos para “autonomia verdadeira” e mais para colaboração estruturada: decompor, verificar e integrar trabalho com checagens explícitas.

Principais conclusões

Um sistema multiagente não é apenas “mais modelos”: é um problema de design de interação (interaction design problem) (papéis, protocolos, estado e verificação).
Defina papéis com responsabilidades, interfaces e restrições bem delimitadas.
Prefira comunicação estruturada e estado compartilhado para reduzir deriva e ambiguidade.
Espere modos de falha em nível de sistema: impasses, erros em cascata, falso consenso e riscos de segurança.
Torne discordâncias testáveis; fundamente alegações-chave em ferramentas, logs e validações.
Orquestração e design de memória são de primeira classe: veja Uso de Ferramentas e Orquestração e Memória e Estado.