Agent loop
Um chatbot pode responder em um turno; um agente precisa decidir se já possui informação suficiente ou se deve agir sobre o ambiente. Imagine uma equipe de suporte que recebe a pergunta: o pedido P7 pode ser entregue amanhã? A resposta exige consultar o pedido, verificar estoque, consultar a regra de transporte e montar uma recomendação. O modelo pode escolher a próxima consulta, mas a aplicação continua responsável por validar argumentos, controlar permissões e encerrar o trabalho. Nesta aula, o objetivo é transformar essa sequência em um mecanismo observável, sem confundir autonomia com execução ilimitada.
Vamos estudar o ciclo objetivo, decisão, ferramenta, observação e continuação usando um simulador local. Ele não acessa modelos nem serviços externos: sua política de decisão é explícita, justamente para permitir que você enxergue cada transição. Depois, a política pode ser substituída por um modelo sem alterar as regras de segurança. ReAct, planejamento, decomposição de tarefas e reflexão serão apresentados como estratégias distintas, com problemas que cada uma resolve e limites que precisam ser medidos.
JavaScriptAgentesAo terminar esta aula
- Um agente precisa de condições de sucesso e de parada que a aplicação consiga verificar.
- Planejamento organiza dependências; observações podem exigir revisar o plano.
- Ações e evidências públicas permitem avaliar o ciclo sem exigir raciocínio privado.
Antes de continuar: Laboratório: Memory
A decisão depende do que foi observado
FundamentosO objetivo deve ter uma condição de sucesso verificável. “Ajudar o cliente” é vago; “produzir uma recomendação que cite estoque e prazo, sem prometer uma entrega não confirmada” permite testar a conclusão. O estado contém o que já foi observado, não apenas uma conversa. Uma decisão válida escolhe uma ferramenta ainda necessária ou encerra com os dados disponíveis. A observação devolvida pela ferramenta modifica o estado e pode invalidar o plano inicial. Se o estoque retornar zero, consultar transporte deixa de ser prioridade e procurar alternativas passa a ser útil.
O trabalho ReAct descreve a combinação de raciocínio e ações em tarefas interativas. Para engenharia, a parte reproduzível é a sequência de ações, argumentos, observações e decisões públicas. Não precisamos obter ou armazenar o raciocínio privado de um modelo para avaliar essa sequência. Registre uma justificativa curta, como “preciso do estoque antes de estimar disponibilidade”, e conserve a origem do dado. Uma explicação convincente não compensa uma observação ausente. Um agente que afirma ter consultado estoque, mas não apresenta o evento correspondente, falhou na rastreabilidade.
↗ ReAct: Synergizing Reasoning and Acting in Language Models
Planejar não congela o mundo
FundamentosPlanejamento organiza dependências antes da execução. No pedido P7, a identidade do item deve ser conhecida antes da consulta de estoque; já estoque e regra de transporte podem ser consultados independentemente depois disso. Decompor a tarefa significa criar unidades com entradas, saídas e critérios de conclusão. “Resolver logística” não é uma unidade adequada. “Consultar prazo para CEP autorizado e devolver data e fonte” é. Uma decomposição muito fina acrescenta chamadas e coordenação; uma divisão muito ampla entrega decisões demais a uma ferramenta opaca.
O plano deve ser tratado como hipótese operacional. Depois de cada observação, compare a próxima etapa com o objetivo e com as restrições. Se uma ferramenta retornar informação incompleta, é melhor marcar uma lacuna do que preencher o campo por imaginação. Reflexão limitada acrescenta uma revisão após uma tentativa: identifica uma falha, propõe uma mudança pequena e executa novamente com orçamento definido. O trabalho Reflexion investiga feedback verbal entre tentativas; ele não oferece uma garantia geral de correção. Repetir a mesma resposta com linguagem diferente não é uma melhora demonstrável.
↗ Reflexion: Language Agents with Verbal Reinforcement Learning
Quatro ferramentas e uma saída defensável
FundamentosO simulador usa lerPedido, lerEstoque, lerPrazo e redigir como quatro ferramentas com papéis distintos. As três primeiras retornam dados; a última combina dados já disponíveis, sem inventar uma consulta adicional. A política escolhe a primeira observação ausente, e o runtime limita o número de passos. Essa separação mostra um detalhe central: uma ferramenta de síntese deve receber fatos identificados, e a aplicação deve validar sua saída antes de apresentá-la. Uma futura versão com modelo continua sujeita aos mesmos contratos.
Execute mentalmente o caso nominal: pedido conhecido, estoque positivo e prazo de dois dias. O resultado informa disponibilidade e prazo, mas não equivale a uma reserva real. No caso de falha, um pedido desconhecido devolve erro e a execução termina com status de falha. Não há tentativa infinita para adivinhar um identificador. O teto de passos protege a aplicação caso uma política defeituosa continue solicitando ferramentas. Tempo máximo e custo máximo também são necessários em um runtime real, pois uma única chamada pode consumir todo o orçamento.
function executar(id) {
const estado = {}, eventos = [];
const tools = {
lerPedido: () => { if (id !== 'P7') throw new Error('pedido desconhecido'); return {item:'I2', destino:'Cuiaba'}; },
lerEstoque: () => ({item:estado.lerPedido.item, quantidade:3}),
lerPrazo: () => ({dias:2, fonte:'tabela local'}),
redigir: () => ({disponivel:estado.lerEstoque.quantidade > 0, prazoDias:estado.lerPrazo.dias})
};
for (let passo=0; passo<8; passo++) {
const nome = Object.keys(tools).find(k => !(k in estado));
if (!nome) return {status:'sucesso', resultado:estado.redigir, eventos};
try { estado[nome]=tools[nome](); eventos.push({passo,nome,observacao:estado[nome]}); }
catch (erro) { return {status:'falha',erro:erro.message,eventos}; }
}
return {status:'orcamento',eventos};
}
console.log(JSON.stringify([executar('P7'),executar('P404')],null,2));Reflexão, parada e avaliação
AvaliaçãoUm critério de parada tem precedência sobre a vontade de continuar. Existem paradas de sucesso, falha, orçamento e necessidade de intervenção. Diferencie-as no resultado: “não foi possível consultar” não é a mesma coisa que “não há estoque”. Um erro comum consiste em capturar qualquer exceção e devolver texto vazio, tornando impossível distinguir falta de dados de ausência real. Outro é permitir que conteúdo de uma ferramenta altere instruções de execução. Observações são dados do ambiente; não concedem autorização para novas ações nem ampliam o objetivo aprovado.
Para avaliar, prepare pedidos com estoque, sem estoque, inexistentes e com prazo indisponível. Conte conclusão correta, afirmações sem fonte, número de chamadas e passos desperdiçados. Compare o ciclo com uma sequência fixa: se os caminhos nunca variam, um workflow determinístico pode resolver o problema com menos complexidade. Um agente é útil quando a escolha do próximo passo depende do contexto; ele não é uma obrigação arquitetural. A reflexão só merece permanecer se reduzir falhas em casos novos, sem aumentar de forma desproporcional custo e latência.
↗ Reflexion: Language Agents with Verbal Reinforcement Learning
Exercício aplicado
Uma equipe de suporte precisa recomendar o próximo passo para P7 consultando pedido, estoque e prazo antes de redigir a resposta. Demonstre também o comportamento para P404 e para uma política que repete a mesma consulta.
- Salve o exemplo, execute P7 e associe cada evento a uma mudança do estado.
- Execute P404 e confirme que nenhuma recomendação logística foi fabricada.
- Injete uma política repetitiva, capture o encerramento por orçamento e restaure a seleção correta.
- Descreva uma decomposição alternativa e justifique se ela reduz dependências ou apenas acrescenta coordenação.
Abrir resolução comentada
A resolução começa pela dependência entre pedido e item. Consultar estoque antes de conhecer o item seria uma chamada sem argumento válido. O simulador guarda cada observação pelo nome da ferramenta e escolhe apenas a próxima lacuna, o que torna a sequência legível. Quando redigir aparece no estado, o trabalho já possui uma saída e o runtime encerra. O limite de oito passos é uma decisão didática, não uma recomendação universal para produção.
Para o pedido inexistente, a exceção é convertida em um resultado de falha com histórico preservado. A correção não consiste em pedir ao modelo que seja mais cuidadoso: o contrato da ferramenta precisa indicar o erro e o runtime deve parar. Se você acrescentar uma alternativa de produto, inclua uma nova condição de sucesso e teste novamente se a política continua respeitando seu orçamento.
function executar(id) {
const estado = {}, eventos = [];
const tools = {
lerPedido: () => { if (id !== 'P7') throw new Error('pedido desconhecido'); return {item:'I2', destino:'Cuiaba'}; },
lerEstoque: () => ({item:estado.lerPedido.item, quantidade:3}),
lerPrazo: () => ({dias:2, fonte:'tabela local'}),
redigir: () => ({disponivel:estado.lerEstoque.quantidade > 0, prazoDias:estado.lerPrazo.dias})
};
for (let passo=0; passo<8; passo++) {
const nome = Object.keys(tools).find(k => !(k in estado));
if (!nome) return {status:'sucesso', resultado:estado.redigir, eventos};
try { estado[nome]=tools[nome](); eventos.push({passo,nome,observacao:estado[nome]}); }
catch (erro) { return {status:'falha',erro:erro.message,eventos}; }
}
return {status:'orcamento',eventos};
}
console.log(JSON.stringify([executar('P7'),executar('P404')],null,2));Como conferir seu resultado
- A execução nominal utiliza quatro ferramentas e termina com sucesso.
- O pedido desconhecido termina com falha e histórico consultável.
- A política repetitiva termina pelo limite de passos.
Aplique em um problema novo
Primeiro resolva sem consultar a resposta. Explique suas decisões e guarde a evidência. A conclusão de leitura é independente desta autoavaliação.
Confira seus pré-requisitos
- Relacionar observações e próxima ação.
- Definir orçamento de passos.
Uma recomendação de reparo exige garantia válida; consultar garantia requer serial. O serial não foi informado e há limite de quatro passos. Qual sequência e estado final são adequados?
Conferir raciocínio e critérios de domínio
A primeira ação útil é solicitar/obter o serial, seguida de consulta de garantia e recomendação sustentada pelo resultado, caso o identificador seja fornecido.
Como o serial está ausente, a decisão atual é pendência por informação faltante, sem afirmar elegibilidade nem recomendar reparo como coberto.
O orçamento limita novas ações; repetir consultas sem serial não produz evidência. O critério de sucesso é garantia observada e recomendação compatível, não simplesmente chegar ao quarto passo.
Evidências para autoavaliação ou revisão por pares
- Dependência: A primeira ação útil é solicitar/obter o serial, seguida de consulta de garantia e recomendação sustentada pelo resultado, caso o identificador seja fornecido.
- Parada: Como o serial está ausente, a decisão atual é pendência por informação faltante, sem afirmar elegibilidade nem recomendar reparo como coberto.
- Falha: O orçamento limita novas ações; repetir consultas sem serial não produz evidência. O critério de sucesso é garantia observada e recomendação compatível, não simplesmente chegar ao quarto passo.
Um erro frequente
Planejamento elimina necessidade de observar.
Um plano é revisado à luz de observações.
Teste sua compreensão
Responda com suas palavras antes de abrir o comentário. Saber explicar uma decisão é parte do domínio.
1. O que muda o plano durante a execução?
Uma observação que altera as premissas ou revela uma lacuna.
O plano é uma hipótese; dados novos podem invalidar uma etapa prevista.
↗ ReAct: Synergizing Reasoning and Acting in Language Models
2. Reflexão garante uma resposta correta?
Não. É uma estratégia de revisão que exige orçamento e avaliação.
Uma nova tentativa precisa mostrar melhora em casos observáveis.
↗ Reflexion: Language Agents with Verbal Reinforcement Learning
3. Por que limitar passos fora do prompt?
Porque a aplicação deve interromper mesmo uma política que não obedece às instruções.
A parada é uma propriedade do runtime, não uma promessa textual.
Seu progresso fica salvo neste navegador. Concluir a leitura não substitui demonstrar o domínio nos exercícios.
Referências e aprofundamento
Documentação oficial e trabalhos originais. As referências registram o escopo e as limitações para você conferir o que sustentam.
- Running agents
OpenAI • consulta: 2026-10-06
OpenAIAgentesLoop do SDK, tool calls, critérios de término, streaming e continuação.
Limites: Controle de duração e ferramentas exige configuração; SDK não fornece automaticamente infraestrutura durável.
- ReAct: Synergizing Reasoning and Acting in Language Models
Yao et al. / arXiv • consulta: 2026-10-06
FundamentosIntercala raciocínio, ações e observações; decomposição, planejamento e ajuste de planos.
Limites: Paper histórico; resultados dependem de tarefas e modelos. Traços de raciocínio do paper não equivalem a acesso ao raciocínio privado de modelos atuais.
- Thinking in LangGraph
LangChain • consulta: 2026-10-06
LangGraphAgentesDecompor passos, representar estado, roteamento, recuperação e escolhas entre loops e grafos.
Limites: Tutorial de desenho; ajustar o exemplo ao caso de uso e à versão instalada.
- Reflexion: Language Agents with Verbal Reinforcement Learning
Shinn et al. / arXiv • consulta: 2026-10-06
AgentesFeedback verbal e memória episódica para melhorar tentativas posteriores.
Limites: Reflexão não garante acerto; limitar tentativas e medir benefício e custo.