Lição 4: Padrões de colaboração: pipeline, revisão, votação

Objetivos de aprendizado:

• Diferenciar como pipeline, produtor-revisor e votação multiperspectiva realmente funcionam
• Avaliar qual padrão se encaixa em uma tarefa e nomear o perfil de custo de cada um
• Entender a diferença central de quem detém o controle entre a colaboração no estilo handoff e a colaboração orquestrador-subagente

Pré-requisitos: concluiu a Lição 3, à vontade para escrever prompts de delegação autocontidos e com escopo bem definido | Anterior: Lição 3 << | Próxima: Lição 5 >>

A estrutura orquestrador-subagente das duas últimas lições é uma forma: um nó central divide a tarefa, vários subagentes trabalham em paralelo e os resultados deles são mesclados de volta. Mas essa não é a única maneira de conectar vários agentes. Esta lição cobre três padrões de colaboração mais específicos — pipeline, produtor-revisor e votação multiperspectiva —, onde cada um se encaixa e para onde vai seu custo, e depois uma quarta forma de colaborar que funciona a partir de uma ideia completamente diferente do orquestrador-subagente: passar o controle adiante por completo.

Pipeline: uma etapa após a outra, cada uma se alimentando da anterior

Pipeline (encadeamento de prompts): "Prompt chaining decomposes a task into a sequence of steps, where each LLM call processes the output of the previous one."¹ A maior diferença entre um pipeline e o orquestrador-subagente é esta: o orquestrador-subagente é uma estrutura paralela — "a central LLM dynamically breaks down tasks, delegates them to worker LLMs, and synthesizes their results."¹ Um pipeline é estritamente uma etapa após a outra — a próxima etapa não pode começar até a anterior terminar, e toma a saída dessa etapa anterior diretamente como sua própria entrada.

Tome um post de blog de lançamento de produto. Você pode dividi-lo em três etapas: rascunhar uma primeira versão, traduzir o rascunho para outro idioma e depois verificar a versão traduzida em busca de terminologia inconsistente. A entrada da etapa dois é a saída da etapa um; a entrada da etapa três é a saída da etapa dois; nenhuma delas pode pular à frente e começar por conta própria. Essa forma se encaixa em tarefas que carregam uma ordem natural, em que a próxima etapa genuinamente não consegue prosseguir sem o resultado da etapa anterior. Diferentemente de pesquisar os preços de três empresas, que de fato se divide em blocos independentes, cada etapa de um pipeline depende da que vem antes dela.

Produtor-revisor: um escreve, o outro disseca, repete

Produtor-revisor (avaliador-otimizador): "one LLM call generates a response while another provides evaluation and feedback in a loop."¹ A diferença central em relação a um pipeline é esse loop. Um pipeline percorre um conjunto fixo de etapas e para; o produtor-revisor vai do rascunho, o revisor dá feedback, revisa-se de acordo com o feedback, revisa de novo, e não para até o revisor ficar satisfeito (ou até atingir um número máximo de rodadas pré-definido). Quantas rodadas serão necessárias normalmente não se sabe de antemão.

Por exemplo, coloque um agente para escrever código que lida com a lógica de pagamento e outro agente cujo único trabalho é verificar se esse código deixa passar casos extremos — um valor negativo, um envio duplicado sob concorrência. Se o agente revisor encontrar um problema, o código volta ao agente produtor para mais uma passada e depois retorna ao revisor, até o revisor não ver problemas óbvios. Essa forma se encaixa em tarefas em que “ele fez um bom trabalho” não pode ser julgado com precisão de uma só vez e precisa de polimento repetido para convergir. A primeira versão raramente é a final; a etapa de revisão existe para pegar problemas óbvios antes da entrega e empurrar o produtor a revisar mais uma vez.

Votação multiperspectiva: vários julgamentos independentes sobre uma mesma coisa

Votação multiperspectiva: vários agentes julgam o mesmo conteúdo de forma independente, em vez de processá-lo passo a passo em um revezamento. O exemplo oficial é uma revisão de segurança de código: "Reviewing a piece of code for vulnerabilities, where several different prompts review and flag the code if they find a problem."¹ Aqui, os “vários prompts diferentes” olham cada um para o mesmo código de forma independente, nenhum dependendo do julgamento de outro; basta um prompt sinalizar um problema para o código ser sinalizado e valer uma análise mais atenta.

Esse padrão difere do produtor-revisor. A votação não é um loop de rascunhar-e-revisar; os agentes julgam um conteúdo já existente em paralelo e de forma independente. O objetivo é reduzir as chances de um deslize verificando de vários ângulos diferentes, não tornar o conteúdo melhor por meio de edições repetidas. Ele se encaixa em situações em que você prefere gastar algumas chamadas a mais a deixar um problema escapar — em revisões de segurança e verificações de conformidade, deixar passar um problema real costuma custar muito mais do que alguns tokens a mais.

Escolhendo entre os três e para onde vai o custo

Os três padrões têm estruturas de custo diferentes, então escolha fazendo as contas em relação à sua situação real:

• Pipeline: o custo total é aproximadamente a soma das chamadas ao longo das etapas. A contagem de etapas é fixa e previsível, mas, como a execução é estritamente sequencial, a latência total é o tempo de cada etapa somado, então não será rápido. Bom para tarefas com dependências claras de etapa a etapa, em que o escopo de cada etapa é bem pequeno.
• Produtor-revisor: o custo depende de quantas rodadas leva para convergir, e a contagem de rodadas é incerta. Quando o produtor e o revisor entram em um vai e vem, o custo pode ir muito além do que você esperava — por isso esse padrão normalmente precisa de um limite máximo de rodadas no loop, para não ficar girando para sempre. Bom para tarefas em que a primeira versão provavelmente não é boa o suficiente e precisa de polimento repetido.
• Votação multiperspectiva: o custo é aproximadamente o custo de uma única revisão vezes o número de agentes votando — uma multiplicação direta, então N agentes significam N vezes o custo. Bom para tarefas em que um deslize é caro e você prefere pagar mais por uma cobertura mais ampla; uma má escolha para situações sensíveis a custo em que o conteúdo em si não é muito arriscado.

Para escolher, volte à forma da própria tarefa. Ela tem uma ordem natural de etapas? Se sim, considere um pipeline. A qualidade da saída precisa de polimento repetido para ser boa o suficiente? Se sim, considere o produtor-revisor. Deixar passar um problema é caro o bastante para valer verificar de vários ângulos? Se sim, considere a votação multiperspectiva. Os três também não são mutuamente exclusivos — um fluxo de trabalho completo pode percorrer um pipeline fixo e aninhar um loop produtor-revisor dentro de uma de suas etapas. A Lição 6 constrói exatamente esse tipo de combinação na prática.

Outra maneira de colaborar: passar o controle adiante por completo

Os padrões vistos até aqui compartilham uma coisa: o orquestrador (ou o nó de ligação em um pipeline) permanece no comando de tudo, e os subagentes devolvem resultados quando terminam, em vez de manter o volante e dirigir o que vem a seguir. Mas há uma ideia completamente diferente de colaboração — handoff: "Handoffs: Peer agents hand off control to a specialized agent that takes over the conversation. This is decentralized."²

A diferença central entre handoff e orquestrador-subagente não é apenas quem detém o controle — é também que o agente que assume vê uma quantidade de informação completamente diferente. A documentação é explícita: "When a handoff occurs, it's as though the new agent takes over the conversation, and gets to see the entire previous conversation history."³ Esse é o comportamento padrão, e há opções de configuração como filtros de entrada para mudar quanto do histórico o novo agente vê. Isso é o exato oposto do mecanismo de subagente das Lições 2 e 3: subagentes partem de um contexto novo e isolado e não veem a conversa anterior⁴, enquanto o agente que recebe um handoff vê o histórico completo por padrão, porque ele não é despachado para fazer uma tarefa isolada e devolver um resultado — ele genuinamente assume a conversa e segue dali com o usuário ou com a próxima etapa.

Essa diferença decide quais situações cada estilo atende. O orquestrador-subagente se encaixa em separar um lote de subtarefas independentes em que cada uma devolve uma conclusão e o nó central permanece no comando de tudo. O handoff se encaixa no caso em que, à medida que a conversa avança, você percebe que um agente mais especializado deveria assumir dali, e você entrega a conversa inteira intacta — digamos, no suporte ao cliente, um agente de suporte geral julga que o problema do usuário envolve um reembolso e entrega a conversa inteira a um agente especializado em reembolsos, para que o usuário não precise descrever o problema tudo de novo. Essa transferência de controle ainda acontece dentro de uma única execução, porém: "Handoffs stay within a single run."³

Recapitulação

• Pipeline divide uma tarefa em uma cadeia de etapas fixas dependentes de ordem, cada uma processando a saída da etapa anterior¹; bom para tarefas com uma ordem natural que não precisam de trabalho devolvido.
• Produtor-revisor é um loop de escrever um rascunho, obter feedback, revisar, revisar de novo, que roda até convergir¹; bom para tarefas cuja qualidade de saída precisa de polimento repetido, com o custo determinado pela contagem de rodadas, então normalmente precisa de um limite máximo de rodadas.
• Votação multiperspectiva tem vários agentes julgando o mesmo conteúdo em paralelo e de forma independente, sinalizando-o assim que qualquer ângulo encontra um problema¹; bom para situações em que um deslize é caro e você pagará várias vezes o custo por uma cobertura mais ampla, com o custo sendo aproximadamente o custo de uma única execução vezes o número de agentes julgando.
• Para escolher entre os três, olhe a forma da tarefa: ela tem uma ordem natural de etapas, precisa de polimento repetido e um deslize é caro — as três perguntas apontam respectivamente para pipeline, produtor-revisor e votação multiperspectiva.
• Handoff é uma ideia de colaboração diferente: os agentes passam o controle adiante por completo uns aos outros, o agente que recebe assume a conversa e por padrão vê todo o histórico anterior da conversa³, o oposto do mecanismo do orquestrador-subagente em que os subagentes partem de um contexto novo e isolado e só devolvem uma conclusão⁴ — um handoff permanece dentro de uma única execução e se encaixa no caso em que um agente mais especializado deveria assumir a conversa dali².

>> Lição 5: Falha e coordenação