Lição 1: Por que múltiplos agentes: os limites de um único contexto
Objetivos de aprendizado:
- Nomear dois limites específicos que um único agente encontra em tarefas longas: poluição de contexto e diluição de atenção
- Usar os números de custo de tokens reportados pela Anthropic para julgar se vale a pena dividir uma tarefa entre múltiplos agentes
- Reconhecer quando a sobrecarga de coordenação supera o retorno, e dizer em que tipos de tarefa os sistemas multiagente não são bons hoje
Pré-requisitos: os cinco primeiros cursos desta série (você sabe escrever prompts, entende o protocolo de chamada de ferramentas, conhece memória e estado de agentes, e sabe ler JS básico) | Próxima: Lição 2 >>
O que um único agente enfrenta quando faz tudo sozinho
Suponha que você entregue a um único agente esta tarefa: “Pesquise como três provedores de nuvem mudaram seus preços ao longo do último ano, compare-os lado a lado e escreva uma recomendação de 2000 palavras sobre qual escolher.”
Veja como um único agente trabalha nisso: ele pesquisa a página de preços do primeiro provedor e lê um longo bloco de HTML e tabelas de preços; pesquisa o segundo, outro bloco longo; pesquisa o histórico de mudanças do terceiro provedor, talvez percorrendo várias páginas; pelo caminho, encontra alguns resultados irrelevantes ou desatualizados e também os lê; por fim, trabalhando a partir dessa única conversa que não para de crescer, escreve a recomendação de 2000 palavras.
Nada disso está errado por si só. Os cursos anteriores já mostraram que é assim que um agente funciona: ler o contexto, decidir o próximo passo, chamar uma ferramenta, colocar o resultado de volta no contexto e repetir. O problema aparece quando a tarefa fica mais longa e mais complexa. Esse contexto único, sempre crescente, silenciosamente puxa o resultado final para baixo em dois pontos.
Poluição de contexto: uma virada errada no início da qual você não se livra
No meio da pesquisa, o agente encontra um resultado enganoso — talvez um post de blog desatualizado citando um preço que não está mais em vigor. Ele não percebe que algo está errado, trata como dado real, raciocina a partir dali e chega a escrever isso em um julgamento inicial sobre um dos provedores.
Uma vez que esse julgamento errado existe, ele não desaparece. Permanece no histórico da conversa e passa a fazer parte do pano de fundo de cada etapa posterior de raciocínio. Quando o agente finalmente encontra a página de preços autoritativa e atual, os dois fatos contraditórios ficam na mesma janela de contexto, e o modelo pode não distinguir com clareza em qual confiar — especialmente quando o errado apareceu antes e foi referenciado pelo caminho.
Isso é a poluição de contexto: um erro ou fragmento irrelevante de uma etapa inicial se mistura ao único contexto do qual todo o raciocínio posterior depende, e é difícil que informações posteriores e corretas o lavem por completo. Como a Anthropic coloca, "as the number of tokens in the context window increases, the model's ability to accurately recall information from that context decreases" (à medida que o número de tokens na janela de contexto aumenta, a capacidade do modelo de recuperar com precisão as informações desse contexto diminui)1. Quanto mais longa a tarefa e mais etapas intermediárias, mais chances esse tipo de poluição tem de se acumular.
Diluição de atenção: quanto mais lê, mais embaçada fica a visão
O segundo problema é diferente do primeiro. Não é que a informação esteja errada, é que ter informação demais já é, por si só, um custo. As páginas de preços e os históricos de mudanças de três provedores podem somar dezenas de milhares de palavras de conteúdo bruto, todas empilhadas em uma única janela de contexto. Quando o modelo escreve a recomendação final, em princípio ele precisa manter cada detalhe ao longo dessas dezenas de milhares de palavras ao mesmo tempo, mas sua atenção a qualquer um deles se espalha mais fina à medida que o contexto cresce.
Isso é a diluição de atenção. A Anthropic enquadra como um orçamento de atenção: "LLMs have an 'attention budget' that they draw on when parsing large volumes of context" (os LLMs têm um “orçamento de atenção” do qual lançam mão ao analisar grandes volumes de contexto) e "Every new token introduced depletes this budget by some amount" (cada novo token introduzido esgota esse orçamento em alguma medida)1. Quanto mais você comprime em uma única janela de contexto, menos desse orçamento sobra para qualquer detalhe isolado, e mais fácil é errar ou deixar coisas de fora em tarefas — resumos, comparações — que exigem manter muitos detalhes com precisão ao mesmo tempo.
Junte a poluição de contexto e a diluição de atenção e você tem o teto do caminho de contexto único: uma vez que a tarefa fica longa o suficiente, a qualidade se degrada de forma constante se um único agente a carrega do começo ao fim. A Anthropic descreve esse declínio como "a performance gradient rather than a hard cliff" (um gradiente de desempenho em vez de um penhasco abrupto)1, e um prompt mais longo, sozinho, raramente o recupera.
Sistemas multiagente: dividir uma tarefa longa entre vários contextos
A resposta multiagente é quebrar uma tarefa grande em pedaços e entregar cada um a um agente separado e independente, em vez de enfiar tudo no mesmo contexto sempre crescente. A definição da Anthropic: "A multi-agent system consists of multiple agents (LLMs autonomously using tools in a loop) working together." (um sistema multiagente consiste em múltiplos agentes — LLMs usando ferramentas de forma autônoma em um loop — trabalhando em conjunto)2
De volta ao exemplo de pesquisa em nuvem: em vez de um agente ler todo o material das três empresas do começo ao fim, ponha três agentes, cada um focado em uma empresa, cada um com sua própria janela de contexto separada, fora do caminho um do outro2. O post de blog desatualizado, recolhido enquanto se pesquisava a primeira empresa, só polui o contexto daquele agente; nunca se mistura ao raciocínio sobre as outras duas. A Anthropic chama isso de "separation of concerns" (separação de responsabilidades) — ferramentas, prompts e caminhos de exploração distintos que reduzem a dependência de caminho2. E o conteúdo bruto que cada agente precisa administrar cai de "o material das três empresas" para "o material de uma empresa", o que também alivia o problema da diluição de atenção. Exatamente como essa estrutura funciona — um agente central divide a tarefa, vários agentes trabalham em paralelo e depois os resultados são agregados — é o que a próxima lição aborda.
O custo: multiagente é mais caro
Dividir entre agentes não é de graça. Cada subagente precisa reler o contexto da tarefa e organizar o próprio raciocínio, e isso queima tokens; depois uma etapa final agrega os resultados dos vários agentes, e isso também queima tokens. Os números medidos pela Anthropic: "In our data, agents typically use about 4× more tokens than chat interactions, and multi-agent systems use about 15× more tokens than chats." (em nossos dados, os agentes normalmente usam cerca de 4× mais tokens do que interações de chat, e os sistemas multiagente usam cerca de 15× mais tokens do que os chats)2
15× não é um número pequeno. Significa que trazer um sistema multiagente só compensa quando a própria tarefa é valiosa o suficiente para justificar esse custo extra de tokens — como a Anthropic coloca, "For economic viability, multi-agent systems require tasks where the value of the task is high enough to pay for the increased performance." (para viabilidade econômica, os sistemas multiagente exigem tarefas em que o valor da tarefa seja alto o bastante para pagar pelo desempenho adicional)2
Quantos subagentes executar também não é uma decisão do tipo "quanto mais, melhor". A Anthropic ofereceu uma regra prática de escala: uma busca simples de fatos vai bem com 1 agente e 3 a 10 chamadas de ferramenta; uma comparação direta pode exigir de 2 a 4 subagentes com 10 a 15 chamadas cada; e apenas pesquisas complexas o bastante para terem responsabilidades claramente divididas justificam mais de 10 subagentes.2 No início, a equipe esbarrou nos contraexemplos — agentes que geravam 50 subagentes para uma consulta simples, ou vasculhavam a web sem fim por uma fonte que não existia, com agentes distraindo uns aos outros ao enviar uma pilha de atualizações desnecessárias.2
A atitude por trás dessa regra combina com o conselho que a Anthropic dá em outro texto sobre arquitetura de agentes: "you should consider adding complexity only when it demonstrably improves outcomes." (você deveria considerar adicionar complexidade apenas quando isso comprovadamente melhorar os resultados)3 Faça a tarefa funcionar primeiro com um único agente, observe onde ela realmente trava — poluição de contexto ou diluição de atenção — e só então decida se, e em qual etapa, trazer múltiplos agentes. Isso é melhor do que montar um sistema multiagente complexo desde o começo.
Quando não usar multiagente: a sobrecarga de coordenação supera o retorno
O valor de um sistema multiagente repousa sobre uma premissa: a tarefa pode ser quebrada em pedaços tratados de forma independente. Uma vez que essa premissa falha, a própria divisão vira peso extra. Isso é a sobrecarga de coordenação: o tempo e os tokens adicionais gastos para fazer vários agentes dividirem o trabalho e colaborarem, incluindo dividir a tarefa, agregar resultados e reconciliar saídas contraditórias dos agentes. Quando uma tarefa não tem muito que possa ser genuinamente paralelizado, a sobrecarga de coordenação facilmente ultrapassa o que a divisão traz.
A Anthropic nomeia um tipo de tarefa que é um mau encaixe: "most coding tasks involve fewer truly parallelizable tasks than research, and LLM agents are not yet great at coordinating and delegating to other agents in real time." (a maioria das tarefas de programação envolve menos tarefas verdadeiramente paralelizáveis do que a pesquisa, e os agentes LLM ainda não são ótimos em coordenar e delegar a outros agentes em tempo real)2 Corrigir um bug geralmente significa entender vários trechos de lógica interligados no código, fortemente acoplados de ponta a ponta, difíceis de recortar em blocos limpos para agentes diferentes sem que pisem uns nos outros. Isso está mais perto de uma tarefa em profundidade: a resposta vive em uma cadeia de raciocínio que você tem de percorrer passo a passo, não espalhada por várias direções não relacionadas. Em contraste, o que a Anthropic considera que os sistemas multiagente realmente fazem bem é o trabalho de alto valor — "multi-agent systems excel at valuable tasks that involve heavy parallelization, information that exceeds single context windows, and interfacing with numerous complex tools" (os sistemas multiagente se destacam em tarefas valiosas que envolvem forte paralelização, informação que excede janelas de contexto individuais e a interface com numerosas ferramentas complexas)2 — e pesquisar preços de nuvem ou comparar vários documentos lado a lado é uma tarefa em largura: a resposta se espalha por algumas direções relativamente independentes que você pode ir buscar separadamente, sem depender dos resultados intermediários umas das outras.
Para decidir se uma tarefa deve virar multiagente, comece com três perguntas: a tarefa pode ser dividida em subtarefas independentes umas das outras? Uma vez dividida, a informação total excede o que uma única janela de contexto consegue conter? A tarefa é valiosa o suficiente para cobrir esse custo extra de tokens? Se ao menos uma resposta pender para "não" ou "não vale a pena", concluir a tarefa honestamente com um sistema de agente único costuma ser um negócio melhor do que forçá-la em múltiplos agentes.
Recapitulação
- Um único agente fazendo tudo do começo ao fim encontra dois limites específicos em tarefas longas: poluição de contexto (um erro inicial ou fragmento irrelevante se mistura ao raciocínio posterior e é difícil de lavar) e diluição de atenção (quanto mais você empacota em um único contexto, menos o modelo atende a qualquer detalhe isolado).
- Um sistema multiagente é vários agentes que cada um usa ferramentas de forma independente trabalhando em conjunto2, aliviando poluição e diluição ao dar a cada agente sua própria janela de contexto.
- Multiagente não é de graça: os dados da Anthropic mostram que ele usa em média cerca de 15× os tokens de uma interação de chat, então só compensa quando o valor da tarefa é alto o bastante2; quantos subagentes executar também tem uma regra de escala da Anthropic para se apoiar, em vez de "quanto mais, melhor"2.
- A postura mais segura é fazer a tarefa funcionar primeiro com um único agente, e só considerar adicionar complexidade quando isso comprovadamente melhorar os resultados3.
- Para decidir se dividir entre agentes, pergunte: a tarefa pode ser quebrada em subtarefas independentes? A informação excede um único contexto? O valor compensa o custo extra de tokens? A Anthropic afirma com clareza que tarefas do tipo programação, em profundidade e fortemente acopladas paralelizam mal e não são o forte do multiagente2; tarefas de pesquisa em largura que você pode ir buscar separadamente, sim.
Lição 2: Orquestrador e subagentes: distribuir e agregar >>