Agent Orchestration Patterns: ReAct vs. Plan-and-Execute

1. ReAct: O Padrão de Raciocínio e Ação Iterativa

O padrão ReAct, que significa Reasoning and Acting, é talvez o mais intuitivo. Ele imita a maneira como um ser humano aborda um problema desconhecido: um passo de cada vez.

O ciclo do ReAct é contínuo e iterativo:

1. Thought (Pensamento): O LLM analisa o objetivo e o estado atual e pensa sobre qual deve ser o próximo passo.
2. Action (Ação): Com base no pensamento, o LLM decide qual ferramenta chamar e com quais argumentos.
3. Observation (Observação): A ferramenta é executada e seu resultado (a "observação") é retornado.
4. Repeat: O ciclo recomeça, com a nova observação alimentando o próximo "pensamento".

Para entender melhor o ReAct e suas implicações, assista a este trecho.

Em resumo, as características do ReAct são:

• Força: Altamente adaptável. Se uma ação falha ou retorna um resultado inesperado, o agente pode raciocinar sobre essa nova informação e mudar de curso imediatamente. É ideal para tarefas exploratórias ou ambientes imprevisíveis (por exemplo, um chatbot de atendimento ao cliente).
• Fraqueza: Ineficiente e caro. Cada passo do ciclo requer uma chamada ao LLM, que é a operação mais lenta e cara do processo. Para uma tarefa de 10 passos, são necessárias pelo menos 10 chamadas ao LLM, consumindo muitos tokens com o histórico de pensamento (o agent_scratchpad que você pode ver nos templates de prompt).

2. Plan-and-Execute: O Padrão do Estrategista

Como uma alternativa ao ReAct, surgiu o padrão Plan-and-Execute. A ideia é simples: em vez de pensar a cada passo, o agente faz todo o trabalho de raciocínio no início.

O fluxo é dividido em fases distintas:

1. Planning (Planejamento): O LLM recebe o objetivo final e cria um plano detalhado e sequencial de todas as etapas necessárias para alcançá-lo. Esta é, tipicamente, a primeira e única grande fase de raciocínio.
2. Execution (Execução): Um executor, que pode ser um loop de código simples sem a necessidade de um LLM, percorre o plano passo a passo, chamando as ferramentas especificadas.
3. (Opcional) Synthesis (Síntese): Após a conclusão de todos os passos, os resultados coletados podem ser enviados a um LLM uma última vez para gerar uma resposta final consolidada.

O artigo a seguir oferece uma excelente decomposição visual e arquitetônica deste padrão.

Para ver uma implementação prática usando uma estrutura de grafos, que pode ser familiar à sua experiência com sistemas e redes, o vídeo a seguir é bastante elucidativo.

As características do Plan-and-Execute são:

• Força: Eficiente e rápido. Minimiza as chamadas ao LLM (geralmente apenas duas: uma para planejar, outra para sintetizar), o que reduz drasticamente a latência e o custo. É ideal para tarefas previsíveis com um fluxo de trabalho bem definido.
• Fraqueza: Rígido e frágil. Se um passo no meio da execução falhar, ou se o plano inicial for falho, o agente não pode se adaptar dinamicamente sem uma lógica de "replanejamento" explícita, como a que foi mostrada no vídeo com a aresta condicional.

3. Comparação Direta e Quando Usar Cada Padrão

Agora que entendemos os dois padrões, vamos colocá-los lado a lado. A escolha correta depende inteiramente da natureza da tarefa.

O artigo da GenMind que você leu anteriormente contém uma seção de benchmark que quantifica as diferenças de forma impressionante.

Aqui está um resumo consolidado para referência rápida:

4. A Evolução do Planejamento: Superando a Rigidez

A principal desvantagem do Plan-and-Execute é sua rigidez. E se um passo depende do resultado de um passo anterior? A comunidade de pesquisa de IA tem trabalhado em evoluções desse padrão. Dado seu background em engenharia, esses conceitos mais avançados serão particularmente interessantes.

5. Conectando ao Seu Objetivo

Para o seu projeto de agente de código, qual padrão faz mais sentido?

Sua tarefa de "implementar uma funcionalidade descrita no Jira" é complexa, mas em grande parte previsível. O fluxo de trabalho geral é conhecido:

1. Analisar o ticket.
2. Consultar fontes de conhecimento (Drive, repositórios).
3. Formular um plano de ataque (quais arquivos modificar, etc.).
4. Aprovação humana (um passo crucial de segurança!)
5. Executar as modificações de código e banco de dados.
6. Criar pull requests.
7. Atualizar o status no Jira.

Este fluxo se encaixa perfeitamente no padrão Plan-and-Execute. Usar ReAct seria extremamente lento e caro, com o agente parando para "pensar" antes de cada leitura de arquivo ou chamada de API.

Você pode, inclusive, projetar um sistema híbrido: usar Plan-and-Execute para a orquestração de alto nível e, talvez, um sub-agente estilo ReAct para uma tarefa específica e mais exploratória dentro do plano, como "tentar refatorar esta função complexa até que os testes de unidade passem".

Conclusão

Nesta lição, você comparou os dois principais padrões de orquestração de agentes. Agora você entende as trocas fundamentais entre adaptabilidade e eficiência.

Principais Pontos:

• ReAct é um ciclo iterativo de Pensamento-Ação-Observação. É flexível e adaptável, mas lento e caro, ideal para tarefas imprevisíveis.
• Plan-and-Execute separa o raciocínio da ação. Um plano é criado no início e depois executado. É eficiente e barato, ideal para fluxos de trabalho previsíveis.
• A escolha do padrão é uma decisão de arquitetura crítica que depende da natureza da tarefa e das restrições de custo e velocidade.
• Para seu objetivo de criar um agente de código, Plan-and-Execute é o padrão de orquestração mais adequado para o fluxo de trabalho principal.

Na Próxima Lição:

Discutimos que a principal fraqueza do Plan-and-Execute é sua fragilidade: o que acontece se a chamada à API do GitHub falhar no meio da execução? Como o agente se recupera? A próxima lição, "Descrever estratégias para tratamento de erros e fallbacks dentro do loop operacional de um agente", abordará exatamente este problema, fornecendo as ferramentas para construir um agente não apenas inteligente, mas também robusto.