Pipeline, fan-out, orquestrador e painel de críticos: qual padrão multiagente serve para qual tarefa

O que é

O guia de engenharia da Anthropic sobre a construção de agentes distingue workflows, nos quais o código fixa a sequência de chamadas ao modelo, de agents, nos quais é o próprio modelo que dirige os seus passos, e nomeia cinco padrões de workflow; quatro combinam várias chamadas (o quinto, o routing, encaminha uma entrada por um único caminho especializado). Prompt chaining: um pipeline em que cada chamada processa o resultado da anterior, com verificações programáticas entre as etapas. Parallelization, em duas variantes: sectioning, em que subtarefas independentes correm ao mesmo tempo, e voting, em que a mesma tarefa corre várias vezes para obter resultados diversos. Orchestrator-workers: um modelo central decompõe a tarefa em tempo de execução, delega e sintetiza. Evaluator-optimizer: uma chamada gera, outra avalia, em ciclo. Um outro artigo de engenharia da Anthropic sobre o seu sistema de pesquisa descreve um padrão orchestrator-worker com um agente principal a coordenar subagentes que operam em paralelo, cada um com a sua própria janela de contexto, e afirma que esses sistemas se destacam em consultas breadth-first (exploração em amplitude) que perseguem várias direções independentes ao mesmo tempo. A documentação dos Managed Agents lista três padrões que funcionam bem: parallelization, specialisation (encaminhar para agentes com prompts e ferramentas focados num domínio) e escalation (consultar um modelo mais capaz para subtarefas difíceis).

Por que importa

Cada padrão multiplica chamadas e tokens e acrescenta uma camada (o orquestrador, o agregador, quem preside ao painel) que pode estar errada de formas que nenhum worker isolado consegue estar. Escolher a forma pela estrutura da tarefa mantém essa multiplicação onde ela compensa.

Como aplicar

• Pipeline: os passos são conhecidos de antemão e cada um tem um resultado intermédio verificável (extrair, validar, traduzir). Coloque as verificações em código, entre os passos.
• Fan-out por sectioning: as subperguntas são independentes e as suas respostas juntam-se por concatenação ou por uma regra simples (um ficheiro ou uma fonte por worker). Fixe primeiro o formato de saída, para que juntar as respostas seja mecânico.
• Fan-out por voting: a correção é difícil de verificar, mas fácil de comparar (classificação, sinalização); use um número ímpar de execuções e registe o desacordo como um sinal, não como ruído.
• Orchestrator-workers: a decomposição depende do que é encontrado (investigação, depuração num código-base desconhecido). Invista no briefing de delegação; o artigo de investigação citado atribui trabalho duplicado e lacunas a descrições de tarefa demasiado ligeiras.
• Painel de críticos: o resultado tem de satisfazer vários critérios distintos (segurança, estilo, correção); dê a cada crítico um único critério e uma grelha fixa, e deixe o código agregar.
• Comece com um único agente e um bom prompt; só acrescente um padrão quando uma falha medida (estouro de contexto, cobertura em falta, revisão tendenciosa) apontar para isso.

Armadilhas

Workers que partilham um contexto e por isso partilham um erro. Uma agregação feita por uma chamada ao modelo que descarta silenciosamente o resultado de um worker. Orquestradores que refazem o trabalho dos workers. Uma contabilização de custo que só conta a chamada final.