Resumo Técnico: Symphony-Coord

Declaração do Problema

Sistemas de modelos de linguagem de grande escala (LLM) multi-agente visam resolver tarefas complexas e de múltiplas etapas decompondo o trabalho e coordenando comportamentos especializados. No entanto, os mecanismos de coordenação existentes normalmente dependem de papéis atribuídos estaticamente e controladores centralizados. À medida que os pools de agentes crescem e as distribuições de tarefas evoluem, essas escolhas de design introduzem limitações significativas:

1. Roteamento Ineficiente: Rótulos de papéis estáticos são frequentemente genéricos demais para distinguir diferenças sutis nas capacidades específicas dos modelos, levando a uma seleção de agentes suboptimal.
2. Baixa Adaptabilidade: Mapeamentos fixos de tarefa-para-papel, estabelecidos durante a fase de design, têm dificuldade em mudar para agentes mais adequados quando as distribuições de tarefas sofrem deslocamentos.
3. Recuperação de Falhas Frágil: Quando um agente altamente capaz degrada ou torna-se indisponível, a alocação estática carece de um mecanismo de substituição rápido, causando um declínio contínuo de desempenho.

Embora alguns frameworks tentem suavizar a rigidez de papéis via "role playing" baseado em prompts (ex: CAMEL), essas abordagens muitas vezes carecem de um mecanismo de decisão principista para aprender com a experiência qual agente é mais adequado para uma sub-tarefa sob o contexto atual e estados do sistema.

Metodologia: Symphony-Coord

Os autores propõem o Symphony-Coord, um framework de coordenação local à tarefa com execução descentralizada. Ele reformula a seleção de agentes não como um problema de correspondência estática, mas como um problema de bandit contextual online. O sistema trata cada agente como um "braço" (arm) e seleciona executores baseados em contexto observável, atualizando as políticas de roteamento via feedback.

O framework emprega um protocolo de roteamento Beacon de dois estágios dinâmicos:

Estágio 1: Triagem de Candidatos Leve

Para gerenciar o overhead de comunicação e computação, o sistema não consulta todo o pool de agentes para cada sub-tarefa. Em vez disso, ele calcula uma pontuação composta leve ($s_{j,t}$) para cada agente disponível $j$, incorporando:

• Pontuação de Correspondência (Match Score): Similaridade de cosseno (ou fallback léxico) entre o texto de capacidade do agente e os requisitos da sub-tarefa.
• Sucesso Prévio: Uma estimativa suavizada de sucesso histórico.
• Confiabilidade: Estabilidade operacional de curto horizonte (ex: latência recente, status de erro, disponibilidade).

O sistema seleciona os Top-L agentes para formar um conjunto de candidatos $C_t$, reduzindo significativamente o espaço de decisão.

Estágio 2: Seleção LinUCB Adaptativa

Dentro do conjunto de candidatos pré-selecionados $C_t$, o Symphony-Coord aplica um seletor online do tipo LinUCB. Para cada candidato, um vetor de contexto $x_{j,t}$ é construído, fundindo:

• Características de requisitos da tarefa.
• Representação estática de capacidade do agente.
• Sinais dinâmicos de tempo de execução (carga, latência, reputação, disponibilidade).

O seletor maximiza um limite superior de confiança (Upper Confidence Bound - UCB):
$$UCB_{j,t} = x_{j,t}^\top \hat{\theta}_{t-1} + \beta_{t-1} \sqrt{x_{j,t}^\top A_{t-1}^{-1} x_{j,t}}$$
Isso equilibra explotação (seleção de agentes com altas recompensas estimadas) e exploração (testar candidatos incertos para reduzir a incerteza).

Mecanismo de Feedback e Atualização

O sistema utiliza um loop de feedback pós-execução atrasado. As recompensas são moldadas com base em:

1. Validade base (conclusão sem erros).
2. Um "bônus de vencedor" se uma execução concorda com a saída final votada (proxy baseado em concordância).
3. Termos de correção opcionais (quando rótulos de ouro estão disponíveis).
4. Penalidades de eficiência (latência).

As atualizações para as estatísticas do LinUCB ($A_t, b_t, \hat{\theta}_t$) ocorrem após a resolução do voto ao nível da tarefa. Isso introduz um efeito de "atualização diferida", onde os parâmetros são atualizados com um pequeno atraso, mas a decisão de roteamento em si depende apenas do contexto e estado atuais.

Principais Contribuições

1. Formulação do Problema: Formaliza o roteamento sub-tarefa–agente como um problema de bandit contextual online, integrando requisitos de tarefa e estados de agentes em características de contexto.
2. Roteamento Beacon Dinâmico de Dois Estágios: Propõe um pipeline prático combinando filtragem de candidatos Top-L (para controlar o overhead) com seleção adaptativa baseada em LinUCB (para lidar com não-estacionariedade).
3. Loop Fechado de Aprendizado Online: Desenha um mecanismo de feedback-para-atualização que melhora continuamente as decisões de roteamento de ponta a ponta, alinhando-se com visões de tomada de decisão sequencial.
4. Escopo Teórico: Prova um limite de regret sublinear de alta probabilidade para o seletor sob suposições padrão de bandit linear condicional de candidato. A análise separa explicitamente os efeitos da filtragem Top-L e do feedback pós-voto atrasado.
5. Validação Empírica: Valida o framework através de simulação, benchmarks de LLM do mundo real (GSM8K, BBH, MedicalQA) e extensos estudos de ablação.

Resultados Experimentais

• Ganhos de Desempenho: O Symphony-Coord supera consistentemente os baselines de agente único (ganhos de 8,5–22,0% no GSM8K, 16,5–23,5% no BBH e 27,0–33,0% no MedicalQA) e atinge o melhor desempenho médio contra baselines multi-agentes (MetaGPT, AFLOW, GPTSwarm) através de vários backbones.
• Heterogeneidade: O sistema beneficia-se significativamente de pools de agentes heterogêneos. Nos experimentos de MedicalQA, a heterogeneidade de habilidades em equipes de 5 agentes rendeu a maior precisão, sugerindo que a especialização de capacidade é uma fonte chave de complementaridade.
• Escalabilidade: O framework mantém a estabilidade conforme o pool de agentes cresce de $N=5$ para $N=100$. Diferente dos baselines centralizados (AutoGen, MetaGPT) que sofrem quedas de desempenho e aumento de latência com pools maiores, o Symphony-Coord mantém o overhead de roteamento abaixo de 100ms ao restringir a seleção online a uma lista curta fixa de Top-L=3.
• Eficiência de Custo: O Symphony-Coord atinge uma fronteira de Pareto favorável, oferecendo maior precisão que baselines de agente único com orçamentos moderados e precisão comparável ou superior a baselines multi-agentes com menor consumo de tokens e latência.
• Robustez: Em experimentos de recuperação semi-reais envolvendo degradação de agentes, o Symphony-Coord conseguiu realocar tarefas para agentes saudáveis, enquanto as variantes estáticas e de UCB congelado falharam na recuperação.

Significância e Alegações

O artigo afirma que o Symphony-Coord demonstra que a coordenação escalável de multi-agentes de LLM não precisa depender de atribuição de papéis estáticos. Em vez disso, a coordenação eficaz pode ser realizada através de roteamento adaptativo impulsionado pelo contexto de execução e feedback.

Distinções principais em relação ao trabalho anterior incluem:

• Especialização Emergente: Em vez de atribuir manualmente identidades de planejador/solucionador/verificador, a especialização de roteamento emerge gradualmente conforme o sistema se adapta às características das tarefas e ao feedback.
• Coordenação Local à Tarefa: O sistema opera com um modelo de execução descentralizado onde os trabalhadores são independentes, mas um plano de roteamento leve e limitado gerencia a seleção de candidatos e as atualizações de feedback para cada instância de tarefa.
• Integração Prática: A novidade não reside em um novo algoritmo de bandit, mas na integração de filtragem consciente de capacidade, seleção contextual e especialização de roteamento impulsionada por feedback especificamente para pools de agentes de LLM heterogêneos.

Os autores observam que o framework foi projetado para ser robusto sob deslocamentos de distribuição de tarefas e falhas de agentes, abordando desafios abertos em sistemas multi-agentes baseados em LLM relativos a overhead de comunicação, complexidade de coordenação e robustez. Sugere-se que trabalhos futuros estendam o framework para pools de agentes abertos maiores, fluxos de trabalho de uso de ferramentas mais ricos e fluxos de tarefas de horizonte mais longo.