Giorgio Módulo 1 / 5
Agent loop, estado tipado e event sourcing
Um agente útil alterna observar, decidir, agir e verificar. Estado deve separar objetivo, contexto, plano, ferramentas, artefatos e resultados. Sem essa separação, o histórico vira um prompt monolítico difícil de corrigir.
Cada ação deve produzir um evento observável e um estado novo. Isso permite resumir longas execuções, retomar de checkpoint e auditar por que um passo ocorreu sem expor raciocínio privado.
Exemplo resolvido · cenário didático
Estado antes da próxima ação
Um agente registra pedido recebido, ferramenta iniciada e resultado confirmado. Se o processo cai após iniciar, o estado não pode ser tratado como sucesso. Na retomada, reconcilie o identificador da operação antes de agir outra vez.
Teste sua compreensão
Qual evidência permite marcar a tarefa como concluída?
Conferir o raciocínio
Um resultado verificado contra os critérios da tarefa, não apenas a emissão de uma chamada de ferramenta.
Leitura de referência: Yao et al. — ReAct
Próximo módulo →Módulo 2 / 5
Planejamento adaptativo, DAGs e acceptance criteria
Planos são úteis quando há dependências, risco ou custo alto de erro. Para tarefas triviais, planejar demais só acrescenta latência. Um controller pode decidir entre execução direta, plano curto ou decomposição em subtarefas.
Cada subtarefa precisa de critério de aceitação. 'Melhorar frontend' é ruim; 'reproduzir layout X, manter rotas Y e passar checks Z' é verificável.
Exemplo resolvido · cenário didático
Dependências definem o paralelismo
Para gerar um relatório, A coleta dados, B calcula indicadores usando A e C revisa o texto usando B. A→B→C é sequencial. Uma tarefa D que verifica o formato solicitado pode rodar enquanto A acontece.
Teste sua compreensão
Executar B ao mesmo tempo que A reduz a duração de forma válida?
Conferir o raciocínio
Não se B depende dos dados de A. Paralelize apenas etapas cujas entradas já estejam disponíveis.
Leitura de referência: Yao et al. — ReAct
Próximo módulo →Módulo 3 / 5
Delegação, handoffs e erros correlacionados
Subagentes funcionam melhor quando escopo e interface são estreitos. Um pesquisador pode devolver evidências; um implementador, patch; um reviewer, findings. Duplicar o mesmo prompt em cinco agentes sem diversidade de função só multiplica custo.
O coordenador precisa resolver conflitos, verificar saídas e controlar budget. Consenso não garante verdade se todos compartilham o mesmo erro.
Exemplo resolvido · cenário didático
Votos podem compartilhar o mesmo erro
Três agentes consultando a mesma fonte incorreta podem concordar por uma causa comum. Diversidade de nomes não cria evidência independente. Compare fontes e verifique fatos por mecanismos distintos.
Teste sua compreensão
Três votos iguais equivalem a três verificações independentes?
Conferir o raciocínio
Não. É preciso examinar dependências de dados, modelos e procedimentos entre as verificações.
Leitura de referência: Yao et al. — ReAct
Próximo módulo →Módulo 4 / 5
Failure recovery, idempotência e durable execution
Agentes longos falham por rede, quota, ferramenta, estado stale ou erro lógico. Retry deve considerar classe de falha e backoff. Um erro determinístico de schema não melhora repetindo a mesma chamada; um 429 pode melhorar esperando.
Persistência de checkpoint deve ser atômica: salve o que foi concluído e o próximo passo, evitando repetir ações externas após reinício.
Exemplo resolvido · cenário didático
Timeout não significa ausência de efeito
Uma transferência simulada é registrada, mas a resposta não chega ao cliente. Antes de repetir, consulte o status pelo identificador estável. Diferencie falha de transporte, rejeição da operação e resultado desconhecido.
Teste sua compreensão
Quando repetir com uma nova identidade é arriscado?
Conferir o raciocínio
Quando a primeira operação pode ter sido efetivada; a segunda identidade permite duplicar o efeito.
Leitura de referência: Yao et al. — ReAct
Próximo módulo →Módulo 5 / 5
Verificação, stop conditions e budgeted reasoning
Confidence do mesmo modelo é fraca como única regra de parada. Use checks externos quando existem: testes, schemas, invariants, fontes, compilação e outcomes. Em tarefas abertas, combine progresso, cobertura de requisitos e budget.
Overthinking é real: continuar depois de uma solução suficiente pode introduzir regressões. Stop conditions precisam detectar tanto insuficiência quanto deterioração.
Exemplo resolvido · cenário didático
Parar com evidência e limite
Defina no início: no máximo três tentativas, 30 segundos e teste de aceitação X. Se X falhar após o limite, encerre com falha explicada e resultado parcial identificado. Uma quarta tentativa invisível quebra o orçamento.
Teste sua compreensão
Um texto convincente deve substituir o teste X?
Conferir o raciocínio
Não. A conclusão deve refletir a verificação observável acordada.
Leitura de referência: Yao et al. — ReAct
Ir para o projeto →Projeto aplicado
Agente de triagem com ferramentas simuladas
- Modele estados de recebido, planejado, executando, verificado e encerrado.
- Injete timeout antes e depois do efeito de uma ferramenta; demonstre ausência de duplicação.
- Compare execução simples e delegada com os mesmos casos e orçamento total.
Critérios para revisar sua entrega
- A execução pode ser reproduzida a partir das instruções e dos arquivos entregues.
- O baseline, as condições e as métricas permitem conferir a comparação.
- O relatório distingue resultado medido, simulação, hipótese e limitação.
Esta rubrica orienta a autoavaliação do projeto; a conclusão e a credencial seguem a avaliação do curso.
Continue com evidências.
Os exemplos numéricos são didáticos. Compare o raciocínio com a referência e registre o que você observou no seu próprio experimento.
Yao et al. — ReAct ↗Progresso e avaliação
A leitura e o roteiro de exercícios são abertos. Para registrar progresso e realizar a avaliação final do curso, entre na área de estudo.
Abrir minha área de estudo ↗