Lição 2: Orquestrador e subagentes: distribuir e agregar
Objetivos de aprendizado:
- Dizer de que o orquestrador e os subagentes são responsáveis cada um em uma arquitetura orquestrador-subagente
- Explicar o que o "isolamento de contexto" de fato isola, e por que ele alivia a poluição de contexto e a diluição de atenção da lição anterior
- Explicar por que um subagente deveria devolver apenas sua conclusão ao orquestrador, em vez de empurrar de volta todo o seu fluxo de raciocínio acumulado
Pré-requisitos: Concluir a Lição 1 e entender a definição de "sistema multiagente" e onde ele se encaixa | Anterior: Lição 1 << | Próxima: Lição 3 >>
O orquestrador: dividir a tarefa, distribuí-la, esperar os resultados
Na lição passada decidimos que uma tarefa como "pesquisar os preços de três provedores de nuvem" é um bom encaixe para dividir entre múltiplos agentes, mas nunca detalhamos como essa divisão de fato funciona. Uma estrutura comum para isso é a arquitetura orquestrador-subagente. A definição oficial é "a central LLM dynamically breaks down tasks, delegates them to worker LLMs, and synthesizes their results." (um LLM central quebra tarefas dinamicamente, delega-as a LLMs trabalhadores e sintetiza seus resultados)1
Essa definição nomeia três ações, e elas mapeiam nas três coisas que o orquestrador faz: quebrar — olhar uma tarefa grande e descobrir em quais pedaços ela se divide; delegar — entregar cada pedaço, junto com o contexto de que ele precisa, a um subagente para executar; sintetizar — uma vez que os subagentes tenham devolvido seus resultados, combiná-los na resposta final. O próprio orquestrador nunca desce e lê a página de preços de um provedor. Seu trabalho é decidir como dividir o trabalho, quem recebe o quê e como costurar vários resultados em uma resposta que se sustente como um todo.
O subagente: pegar uma tarefa, terminá-la dentro do seu próprio contexto
Do lado do subagente, as coisas funcionam de forma bem diferente. A documentação é explícita: "Each subagent starts with a fresh, isolated context window. It doesn't see your conversation history, the skills you've already invoked, or the files Claude has already read. Claude composes a delegation message that summarizes the task, and the subagent works from there." (cada subagente começa com uma janela de contexto nova e isolada. Ele não vê seu histórico de conversa, as skills que você já invocou, nem os arquivos que o Claude já leu. O Claude compõe uma mensagem de delegação que resume a tarefa, e o subagente trabalha a partir daí)2 Em outras palavras, um subagente não tem ideia do que você disse primeiro ao orquestrador, nem de como o orquestrador ponderou internamente "devemos dividir isto" e "em quantos pedaços". Tudo o que ele consegue ver é o único resumo de tarefa que o orquestrador lhe entregou.
Isso parece uma limitação, mas na verdade é a cura para os dois problemas da lição passada. O contexto do subagente não carrega o histórico completo de conversa do orquestrador, então também não carrega os becos sem saída que o orquestrador enfrentou em outros pontos nem o material irrelevante que ele viu. Isso é o isolamento de contexto: confinar o escopo de trabalho de cada agente à sua própria janela de contexto, de modo que a poluição de contexto dentro de um agente não se espalhe para outro. O subagente mantém apenas o material da sua própria fatia da tarefa, e não precisa administrar todo o conteúdo de três empresas ao mesmo tempo, então a pressão da diluição de atenção também cai. Quanto a escrever um resumo de tarefa claro o bastante para que um subagente faça um bom trabalho por conta própria sem nunca ver o histórico de conversa, isso é a próxima lição.
Distribuição: dividir a tarefa e entregá-la a vários subagentes de uma vez
De volta ao exemplo de preços dos três provedores. Uma vez que o orquestrador quebrou o trabalho em "verificar o primeiro", "verificar o segundo", "verificar o terceiro", ele não os enfileira um de cada vez. Ele distribui os três ao mesmo tempo — que é exatamente o que o sistema em produção faz: o agente líder aciona de 3 a 5 subagentes em paralelo, em vez de em série3. Essa jogada de "distribuir tudo ao mesmo tempo" é a distribuição (fan-out): o orquestrador reparte as subtarefas divididas em paralelo para um número equivalente de subagentes, deixando cada um começar a trabalhar de forma independente e simultânea, em vez de esperar o primeiro subagente terminar para despachar o segundo.
O retorno da distribuição é direto: três subagentes trabalhando em paralelo significa que o tempo total fica perto de fazer uma única pesquisa, não a soma de três. Depois que o sistema em produção introduziu esse tipo de paralelização, o tempo de pesquisa em consultas complexas caiu em até 90%3. Mas a distribuição não é só picar a tarefa em pedaços e dar por encerrado — como você recorta importa. Três empresas são naturalmente independentes, então recortar em três é um encaixe limpo. Troque para "revisar um contrato de 20 páginas" e as cláusulas podem se referenciar e se restringir mutuamente; um recorte ruim deixa cada subagente sem contexto-chave e chegando a conclusões que se contradizem. Decidir como e com que granularidade recortar remete ao teste da lição passada: cada pedaço que você recorta é de fato algo que pode ser tratado por conta própria, sem depender dos resultados intermediários de outro pedaço?
Agregar: puxar os resultados juntos, não apenas colá-los
Depois que os três subagentes terminam cada um de verificar o preço da sua própria empresa e devolvem os resultados, o que o orquestrador faz não é colar três blocos de texto em sequência. O que os subagentes devolvem são conclusões de pesquisa a partir de seus próprios pontos de vista, e o trabalho do orquestrador é agregar: pôr vários resultados produzidos de forma independente lado a lado, compará-los, resolver qualquer duplicação ou contradição que apareça e reorganizá-los no formato do entregável final — escrevendo um documento que se lê como um todo, não como três pedaços obviamente costurados.
A documentação, ao descrever subagentes que se sucedem em sequência, nota que "Each subagent completes its task and returns results to Claude, which then passes relevant context to the next subagent." (cada subagente conclui sua tarefa e devolve resultados ao Claude, que então passa o contexto relevante para o próximo subagente)2 Então a agregação não é necessariamente tão simples quanto "esperar cada subagente entregar seu trabalho, e então o orquestrador recolhe tudo de uma vez e processa". Em alguns casos, o resultado do subagente anterior é ele próprio parte do resumo de tarefa do próximo subagente, e o orquestrador vai e volta entre distribuir e agregar até que cada subtarefa tenha um resultado.
O caminho que um resultado percorre também nem sempre precisa passar pelo orquestrador. Quando o conteúdo que um subagente produz é grande e precisa ser mantido intacto, a documentação menciona uma abordagem: "Subagent output to a filesystem to minimize the 'game of telephone.' Direct subagent outputs can bypass the main coordinator for certain types of results, improving both fidelity and performance." (saída do subagente para um sistema de arquivos para minimizar o “telefone sem fio”. Saídas diretas de subagente podem contornar o coordenador principal para certos tipos de resultado, melhorando tanto a fidelidade quanto o desempenho)3 Escrever direto no sistema de arquivos é, no fundo, uma forma de evitar que um resultado seja parafraseado, comprimido e perca detalhe ao longo da cadeia "subagente → orquestrador → saída final".
Devolver apenas a conclusão, não todo o fluxo de raciocínio do subagente
Para concluir sua tarefa, um subagente pode ler muitas páginas de material irrelevante pelo caminho, tentar alguns caminhos que não levam a lugar nenhum, até cometer pequenos erros e se corrigir. Esse processo não precisa — e não deveria — ser enfiado de volta no contexto do orquestrador do jeito que está. O que o orquestrador precisa é da conclusão final e defensável do subagente e da evidência-chave por trás dela, não de toda a trilha de raciocínio com seus desvios.
A razão remete ao ponto da Lição 1: o orquestrador tem uma janela de contexto própria, e ele também passa por poluição de contexto e diluição de atenção. A documentação é direta sobre isso: quando os subagentes concluem, seus resultados retornam à conversa principal, e rodar muitos subagentes que cada um devolve resultados detalhados pode consumir contexto significativo2. Se três subagentes empurram de volta, cada um, vários milhares de palavras de raciocínio completo do jeito que está, o orquestrador acaba encontrando, na sua própria camada, o exato problema que múltiplos agentes deveriam aliviar. A devolução deve carregar apenas a conclusão em si, e deixar o detalhe do "como cheguei aqui" no próprio contexto do subagente, que ele já gastou e está prestes a descartar.
Isso não significa que toda delegação começa do zero. A documentação menciona um tipo especial de subagente — um fork: "A fork is a subagent that inherits the entire conversation so far instead of starting fresh... The fork's own tool calls still stay out of your conversation and only its final result comes back, so your main context window stays clean." (um fork é um subagente que herda toda a conversa até então em vez de começar do zero... As próprias chamadas de ferramenta do fork continuam fora da sua conversa e só seu resultado final volta, então sua janela de contexto principal permanece limpa)2 Então, mesmo quando um subagente de fato raramente precisa ver o histórico completo (digamos, ele tem de produzir um resumo profundo fundamentado em toda a discussão anterior), seu pensamento intermediário ainda assim não entra no contexto do orquestrador do jeito que está. O princípio "devolver apenas a conclusão" é estável; o que muda é apenas se o subagente começa com o histórico em mãos.
Em outras palavras: a mesma divisão de trabalho aparece em outros frameworks
"Orquestrador-subagente" não é a formulação privada de um único fornecedor. A documentação do Agents SDK da OpenAI chama a mesma estrutura de padrão Manager: "A central manager/orchestrator invokes specialized sub‑agents as tools and retains control of the conversation." (um gerente/orquestrador central invoca subagentes especializados como ferramentas e mantém o controle da conversa)4 Troque as palavras — gerente por orquestrador, agentes-como-ferramentas por subagentes — e está descrevendo a mesma coisa: um nó central quebra a tarefa, distribui o trabalho e mantém o controle do todo, enquanto a execução de fato vai para subordinados especializados que devolvem seus resultados, e o nó central segue conduzindo o que vem a seguir. Reconhecer o formato dessa divisão de trabalho importa mais do que decorar a terminologia de um framework — você verá alguma variante dessa lógica na documentação de quase todo framework multiagente.
Recapitulação
- Na arquitetura orquestrador-subagente, um LLM central quebra a tarefa, delega subtarefas a múltiplos LLMs trabalhadores e sintetiza seus resultados1; o próprio orquestrador não desce e trata o conteúdo detalhado de uma subtarefa.
- Cada subagente parte por padrão de uma janela de contexto nova e isolada e não consegue ver o histórico de conversa do orquestrador2 — isto é o isolamento de contexto, o mecanismo-chave para aliviar a poluição de contexto e a diluição de atenção da lição passada.
- A distribuição reparte as subtarefas divididas em paralelo para múltiplos subagentes trabalharem ao mesmo tempo; agregar não é uma simples colagem das respostas dos subagentes, mas uma etapa de comparar, resolver contradições e reorganizar em um único formato; e a passagem de resultados também pode contornar o orquestrador e escrever direto no sistema de arquivos, para reduzir informação perdida na paráfrase3.
- Depois que um subagente termina, seu resultado retorna ao orquestrador2; o que se devolve deve ser apenas a conclusão, não os desvios que ele enfrentou nem todo o seu fluxo de raciocínio — a documentação é explícita ao dizer que muitos subagentes devolvendo cada um resultados detalhados podem consumir contexto significativo2, e o orquestrador voltaria a encontrar poluição de contexto e diluição de atenção na sua própria camada.
- "Orquestrador-subagente" não é a formulação privada de um framework — o Agents SDK da OpenAI chama a mesma estrutura de padrão Manager, um gerente central invocando subagentes como ferramentas enquanto mantém o controle da conversa4. Reconhecer a lógica compartilhada por trás dessa divisão de trabalho importa mais do que decorar qualquer termo isolado.
>> Lição 3: Escrevendo prompts para delegação