Padrão ReAct (Raciocínio + Ação)

1. Visão geral da concepção e o problema sistêmico

Antes do surgimento da concepção ReAct (publicada por pesquisadores da Universidade de Princeton e Google Research em 2022), existia uma divisão na comunidade entre duas abordagens para a automação de LLMs:

1. Chain-of-Thought (Apenas raciocínio): O modelo escreve longas cadeias de raciocínio, mas não tem acesso ao mundo externo. Como resultado, a lógica do raciocínio parece convincente, porém baseia-se em fatos inventados e dados desatualizados.
2. Act-Only (Apenas ação): O modelo chama APIs ou executa comandos bash sem autoanálise intermediário. Isso leva a repetições caóticas, tentativa cega de parâmetros e incapacidade de resolver até mesmo tarefas simples com múltiplos passos.

O Padrão ReAct (Reasoning + Acting) uniu essas duas forças em um único ciclo iterativo: o modelo primeiro verbaliza seus pensamentos e planeja o próximo passo, depois executa a ação alvo, analisa o resultado real do ambiente (Observation) e somente então toma a próxima decisão.

2. Taxonomia arquitetural e modelo mental

Um passo clássico do ciclo ReAct consiste em três estados sequenciais:

• 1. Thought (Raciocínio interno): O agente analisa o estado atual da tarefa, levanta uma hipótese e formula uma intenção concreta: "Preciso verificar se o serviço Redis está rodando na porta 6379 antes de iniciar os testes". Esta etapa reduz criticamente a probabilidade de erros nos argumentos das ferramentas.
• 2. Action (Chamada de ação / ferramenta): O agente forma uma ação específica com parâmetros rigorosos: nome da função e um objeto JSON válido (por exemplo, execute_bash(command="systemctl status redis")).
• 3. Observation (Observação do ambiente): O runtime externo intercepta a ação, executa-a no servidor ou banco de dados e retorna a saída bruta em texto ou código de erro de volta ao contexto do agente.
• 4. Finish / Final Answer (Estado final): Quando o agente vê na última Observation que a meta foi atingida, ele interrompe o ciclo e formula a resposta final para o usuário.

3. Pipeline técnico e mecânica interna

O ciclo de vida do trabalho de um agente ReAct em um ambiente programático:

1. Context & Scratchpad Injection (Preparação do prompt): As regras de interação, descrições das ferramentas disponíveis e o histórico das iterações anteriores da sessão atual (Scratchpad) são incorporados ao prompt do sistema.
2. Inference with Tool Delimiter (Geração de raciocínio e intenção): A LLM gera os tokens da seção Thought. Assim que o modelo chega à chamada de ferramenta, a geração é pausada pelo cliente e os argumentos da chamada são validados.
3. Execution & Observation Feedback (Execução no ambiente): O orquestrador passa o comando para o subsistema correspondente (terminal local, banco de dados ou navegador), lê a saída, limita seu tamanho para economizar tokens e adiciona a mensagem Observation: ... ao contexto.
4. Loop Progression & Termination Check (Verificação de saída): Se o agente atingiu a meta ou o contador max_iterations = 10, o ciclo é interrompido. Caso contrário, inicia-se a próxima iteração com um novo bloco Thought.

4. Cenários práticos de engenharia em produção

01. Diagnóstico interativo e reparo da infraestrutura do servidor

• Thought: O serviço retorna um erro 502. Primeiro, vou verificar os logs do Nginx dos últimos 5 minutos.
• Action: read_logs(service="nginx", lines=20)
• Observation: connect() failed (111: Connection refused) while connecting to upstream 127.0.0.1:3000
• Thought: O upstream na porta 3000 caiu. Preciso verificar o status do processo Node.js via PM2.
• Action: execute_cmd(command="pm2 status")
• Observation: app-server: errored (out of memory)
• Thought: O serviço caiu devido à falta de memória. Vou reiniciá-lo com um limite maior de heap.

02. Busca iterativa em documentação e API

O agente tenta chamar um serviço externo Stripe. No primeiro passo, recebe um erro invalid_api_key. Por meio do bloco Thought, o agente lembra que o modo de teste requer o prefixo sk_test_, puxa a variável de ambiente correta e, na segunda tentativa, cria com sucesso a intenção de pagamento.

03. Depuração passo a passo de testes unitários

O agente de código vê a falha do teste devido a uma divergência no valor esperado. Ele levanta uma hipótese, faz uma edição mínima em uma linha, reinicia o teste, vê o resultado verde e só então reporta a conclusão da tarefa.

5. Armadilhas, erros comuns e segurança

• Looping em hipótese falsa (Self-Reinforcing Delusion): Se no primeiro passo o modelo fez uma conclusão errônea, ele tende a interpretar todas as Observations subsequentes a favor de seu erro. Solução: adição obrigatória de um passo de crítica (Reflection) após 3 ações malsucedidas consecutivas.
• Inflação do contexto por observações brutas: O comando cat huge_file.json retorna 50.000 tokens de lixo, deslocando o prompt do sistema. Sempre limite o tamanho do retorno da Observation no runtime (por exemplo, não mais que 2000 caracteres).
• Chamada de ferramentas inexistentes (Action Hallucination): O modelo tenta chamar uma ferramenta que não está na lista. Solução: uso da API nativa de Tool Calling em vez de parsing bruto de texto.