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.
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.
Resumo
- Ideia Central: Um único agente é um loop decidir-agir-observar sobre uma única janela de contexto; um sistema multi-agente são múltiplos loops coordenados por código que você escreve.
- Por que Importa: Escolher multi-agente por padrão adiciona latência, complexidade de coordenação e custo a tarefas que um único loop teria lidado igualmente bem.
- Conceitos-Chave: o loop de chamada de ferramenta, janela de contexto, decomposição de tarefa, paralelismo, isolamento de contexto, orquestrador/trabalhador.
- Quando Usar: Opte por múltiplos agentes quando uma tarefa se decompõe em sub-tarefas genuinamente independentes, quando diferentes partes precisam de acesso a ferramentas diferentes, ou quando uma parte inundaria de outra forma um contexto compartilhado com exploração irrelevante.
- Limitações / Trade-offs: Sistemas multi-agente são mais difíceis de depurar, mais lentos de ponta a ponta quando as sub-tarefas são sequenciais e custam mais tokens, pois cada limite de agente inicia um novo contexto.
- Tópicos Relacionados: padrões orquestrador/trabalhador, delegação de subagentes, encadeamento de prompts vs. roteamento, salvaguardas para sistemas multi-agente.
Fundamentos
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.
Mecânicas e Interações
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.
Considerações Avançadas e Aplicações
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.
Equívocos Comuns
- "Sistemas multi-agente são sempre mais capazes." Um sistema multi-agente só pode fazer o que seus agentes individuais podem fazer; ele não adiciona capacidade de raciocínio, apenas paralelismo e isolamento de contexto. Um único agente com as ferramentas certas resolve a mesma classe de problemas.
- "Mais agentes significa mais minúcia." Dividir uma tarefa entre agentes muda como o trabalho é organizado, não quão cuidadosamente ele é feito. Um subagente mal escopado não é mais minucioso do que uma chamada de ferramenta mal escopada.
- "Agentes devem delegar por padrão, pois é mais escalável." A delegação é uma escolha arquitetural deliberada feita quando a forma da tarefa a justifica, não uma postura padrão; a maioria das tarefas é mais barata e confiável como um único loop.
- "Um subagente vê tudo o que o orquestrador vê." Um subagente normalmente começa com um contexto novo; o orquestrador tem que passar o que o subagente realmente precisa, não é herdado automaticamente.
- "Subagentes paralelos são gratuitos apenas porque rodam concorrentemente." Concorrência economiza tempo de relógio, não custo de token; cada trabalhador paralelo ainda paga por seu próprio contexto e seu próprio raciocínio.
FAQs
Qual é a definição mais simples de um loop de agente único?
- Um modelo, uma janela de contexto, decidindo repetidamente uma ação, executando-a (geralmente uma chamada de ferramenta) e observando o resultado até que a tarefa seja concluída.
Qual é a definição mais simples de um sistema multi-agente?
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.
Como sei se minha tarefa deve ser dividida entre agentes?
- Pergunte se as sub-tarefas são independentes: alguma sub-tarefa precisa ver o raciocínio intermediário de outra, não apenas seu resultado final?
- Se sim, mantenha-a em um único agente. Se não, e houver sub-tarefas suficientes para tornar o paralelismo vantajoso, dividir é razoável.
Dividir uma tarefa entre agentes a torna mais rápida?
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.
Dividir uma tarefa entre agentes a torna mais barata?
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.
O que é isolamento de contexto e por que ele é importante?
- Significa que o raciocínio exploratório de um trabalhador, tentativas falhas e chamadas de ferramentas intermediárias permanecem dentro do contexto desse trabalhador e nunca aparecem no contexto do orquestrador.
- Importa porque mantém o raciocínio do orquestrador sobre o resultado combinado livre de ruído de como cada parte foi resolvida.
Um orquestrador é ele mesmo um agente?
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.
Qual é a diferença entre adicionar uma ferramenta e adicionar um subagente?
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).
Um único agente pode usar muitas ferramentas em vez de delegar?
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.
Existe um custo para ir multi-agente desnecessariamente?
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).
Devo usar uma arquitetura multi-agente por padrão para novos projetos "para garantir"?
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.
Relacionados
- Noções Básicas de Orquestração de Agentes - um orquestrador mínimo passando uma tarefa para um subagente
- Padrões Orquestrador/Trabalhador com o Claude Agent SDK - o padrão para o qual este modelo mental leva
- Salvaguardas para Sistemas Multi-Agente: Limitando Custo e Escopo - controlando a sobrecarga descrita nesta página
- O Modelo Mental do Claude Agent SDK - como funciona o loop de chamada de ferramenta subjacente
- Delegando Trabalho para Subagentes no Claude Agent SDK - as mecânicas do SDK de um limite de subagente
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.