Loops de Agente Único vs. Sistemas Multi-Agente: Um Modelo Mental
Antes de adotar uma arquitetura multi-agente, um líder técnico precisa de um teste claro para quando ela é realmente justificada.
//
Busque em todas as páginas da documentação
Antes de adotar uma arquitetura multi-agente, um líder técnico precisa de um teste claro para quando ela é realmente justificada.
A resposta honesta para a maioria das tarefas é que um único agente, iterando sobre ferramentas até que a tarefa seja concluída, é mais simples de construir, mais barato de executar e mais fácil de depurar do que qualquer projeto multi-agente.
Esta página oferece o modelo mental para distinguir os dois: o que é um loop de agente único, o que um sistema multi-agente adiciona a ele e os sinais específicos que indicam que uma tarefa superou um único loop.
Um único agente é um loop: o modelo decide o que fazer a seguir, uma ação é executada (geralmente uma chamada de ferramenta), o resultado retorna como uma observação, e o modelo decide novamente.
Este loop continua, tudo dentro de uma única janela de contexto, até que o modelo determine que a tarefa está concluída ou atinja uma condição de parada.
Tudo o que o agente viu, todos os arquivos que leu, todos os comandos que executou, todos os erros que cometeu e corrigiu, vive nesse único contexto crescente.
Esta é a forma padrão de um agente, e é suficiente para a grande maioria das tarefas: responder a uma pergunta, escrever um arquivo, corrigir um bug, executar um script e interpretar a saída.
Um sistema multi-agente substitui esse loop único por dois ou mais loops, cada um com sua própria janela de contexto, coordenados por código de aplicação que fica fora de qualquer um dos agentes.
A versão mais simples é um orquestrador e um trabalhador: o agente orquestrador (ou código simples) decide passar uma sub-tarefa para um agente trabalhador, espera pelo resultado do trabalhador e continua seu próprio loop com esse resultado incorporado.
Nada em um agente trabalhador é arquiteturalmente diferente de um agente único por si só. O que é diferente é que ele opera em um contexto que o orquestrador não pode ver, e seu resultado cruza uma fronteira de volta para o pai.
A decisão de dividir uma tarefa entre agentes se resume a uma pergunta: essa tarefa se decompõe em partes que não precisam ver os passos intermediários umas das outras?
Se a resposta for não, um único loop com mais ferramentas é quase sempre a escolha certa. Adicionar um limite de agente a uma tarefa que é fundamentalmente uma linha contínua de raciocínio apenas adiciona um ponto de serialização sem benefício.
Se a resposta for sim, um limite de agente lhe concede duas coisas específicas: paralelismo, pois trabalhadores independentes podem ser executados simultaneamente em vez de um após o outro, e isolamento de contexto, pois as tentativas falhas e as chamadas exploratórias de ferramentas de um trabalhador permanecem dentro de seu próprio contexto em vez de se acumularem no do pai.
O isolamento importa mais do que parece inicialmente. Um único agente auditando cinco arquivos não relacionados acumula o raciocínio, os becos sem saída e a saída da ferramenta de todos os cinco em um contexto, e esse ruído ainda está lá quando o modelo raciocina sobre o arquivo três, mesmo que nada sobre o arquivo três dependesse dele.
Cinco subagentes isolados, um por arquivo, cada um começa limpo, e apenas seus resultados finais cruzam de volta para o orquestrador, que vê cinco resumos limpos em vez de uma transcrição longa e barulhenta.
# A forma da decisão, não uma implementação completa.
# is_independent(a, b) pergunta se a sub-tarefa b precisa de algo
# que a sub-tarefa a descobre no meio do voo, não apenas o resultado final de a.
if task_decomposes_into(subtasks) and all(
is_independent(a, b) for a, b in pairs(subtasks)
):
use_multi_agent(subtasks) # orquestrador + um trabalhador por sub-tarefa
else:
use_single_agent(task) # um loop, mais ferramentas se necessárioCoordenação não é gratuita. Cada limite de agente significa: um novo contexto precisa ser reconstruído (mais tokens gastos restabelecendo o estado relevante), o orquestrador tem que esperar por um trabalhador síncrono ou gerenciar os concorrentes, e uma falha dentro de um trabalhador se torna outra categoria de erro que o próprio loop do orquestrador tem que interpretar e recuperar, em vez de uma chamada de ferramenta falhando inline.
O teste de decomposição escala para uma regra prática: se você não consegue descrever as sub-tarefas como pontos de bala paralelos sem setas entre eles, elas não são independentes, e dividi-las entre agentes apenas forçará você a reinventar a sequenciação com passos extras.
Especialização é a outra razão legítima para dividir, separada do paralelismo. Uma sub-tarefa que necessita de um escopo de ferramenta mais estreito ou diferente do resto da tarefa, por exemplo, uma parte que só deveria ler arquivos e nunca escrevê-los, é candidata a seu próprio agente, mesmo que não seja executada simultaneamente com qualquer outra coisa, porque o acesso a ferramentas no Claude Agent SDK é escopo por agente, não compartilhado globalmente.
O custo se acumula com a profundidade. Uma única camada extra de delegação, um orquestrador passando para um punhado de trabalhadores, geralmente é uma sobrecarga modesta. Trabalhadores que delegam a sub-trabalhadores multiplicam essa sobrecarga e tornam as falhas muito mais difíceis de rastrear até uma causa raiz, razão pela qual a maioria dos sistemas de produção limita a delegação a um ou dois níveis.
| Abordagem | Força | Fraqueza | Melhor Ajuste |
|---|---|---|---|
| Agente único, mais ferramentas | Mais simples de construir, depurar e raciocinar sobre | Sem paralelismo; um contexto longo acumula todo o raciocínio | Tarefas sequenciais, ou tarefas que precisam de mais uma capacidade |
| Orquestrador + trabalhadores (um nível) | Execução paralela; contexto limpo por sub-tarefa | Código de coordenação, latência por trabalhador e custo de token | Tarefa se decompõe em sub-tarefas independentes e de formato semelhante |
| Delegação multi-nível profunda | Lida com decomposição genuinamente aninhada | Difícil de depurar, custo e latência se acumulam com a profundidade | Raro; apenas quando as sub-tarefas precisam delegar |
A latência não é automaticamente melhor com múltiplos agentes. Trabalhadores independentes executando simultaneamente podem terminar mais rápido do que um único agente fazendo o mesmo trabalho serialmente, mas se o orquestrador tiver que esperar pelos trabalhadores um por um, ou se a tarefa era sequencial para começar, um projeto multi-agente é estritamente mais lento do que um único loop, pois adiciona a sobrecarga de iniciar e encerrar o contexto de cada trabalhador além do trabalho real.
Dois ou mais desses loops, cada um com seu próprio contexto, coordenados por código (um orquestrador) que decide quando delegar trabalho e como combinar resultados.
Apenas se as sub-tarefas puderem realmente ser executadas concorrentemente. Sub-tarefas sequenciais divididas entre agentes geralmente rodam mais devagar do que um único agente lidando com elas em ordem, pois cada passagem adiciona sua própria sobrecarga de configuração e passagem de resultados.
Geralmente não. O contexto de cada agente começa do zero, então qualquer background compartilhado precisa ser restabelecido por agente, e essa repetição custa tokens que um único contexto compartilhado não gastaria.
Pode ser um agente completo tomando suas próprias decisões de chamada de ferramenta (incluindo quando invocar um trabalhador) ou código de aplicação simples que chama trabalhadores em uma sequência fixa; ambos os padrões são comuns.
Uma ferramenta adiciona mais uma capacidade a um loop existente sem um novo limite de contexto. Um subagente adiciona um segundo loop completo com seu próprio contexto e seu próprio escopo de ferramentas, cruzado apenas no início (o prompt) e no final (o resultado).
Sim. Empilhar muitas ferramentas e responsabilidades não relacionadas no contexto de um agente torna seu raciocínio mais barulhento em uma tarefa longa, mesmo sem um problema de decomposição; em algum ponto, a especialização em agentes separados se torna o design mais legível, não apenas o mais paralelo.
Sim, em três eixos: custo de token (contexto novo por agente), latência (sobrecarga de configuração e passagem) e depurabilidade (uma falha pode originar-se na lógica do orquestrador ou em qualquer um dos trabalhadores, o que é mais difícil de rastrear do que uma única chamada de ferramenta falha).
Não. Comece com um único agente e o menor conjunto de ferramentas que resolva a tarefa. Mova para um projeto multi-agente apenas quando uma necessidade específica e concreta de decomposição ou especialização surgir, não preventivamente.
Versões de Stack: Escrito contra a linha de modelos Claude atual por volta de junho de 2026 - Claude Fable 5, Claude Opus 4.8, Claude Sonnet 5 (o padrão), e Claude Haiku 4.5 - e o Claude Agent SDK (última versão). Nomes de modelos, versões de SDK e preços mudam rapidamente - verifique os detalhes atuais em platform.claude.com/docs antes de confiar neles.
Revisado por Chris St. John·Última atualização: 16 de jul. de 2026