Treinar agentes de vários turnos e decidir quem recebe o crédito

Um agente que monta link de campanha não resolve numa tacada: lê o pedido, chama a ferramenta, recebe um erro, corrige e entrega. Quando a URL final sai certa, a pergunta de treino é quais desses turnos merecem o crédito. Ao fim desta aula você desenha ambiente, verificador e recompensa de uma tarefa com ferramenta. Também escolhe entre nota final e nota por passo e reconhece quando treinar pesos não compensa.

Em tarefa de um turno, a trajetória é uma resposta, e a vantagem da aula anterior cai sobre ela inteira. Em tarefa de vários turnos, o agente alterna ação e observação: cada chamada de ferramenta devolve algo do ambiente, que entra no contexto do turno seguinte. A recompensa costuma chegar só no fim. Daí nasce o problema de atribuição de crédito: descobrir qual decisão, entre dez ou cem, fez o resultado sair bom ou ruim.

Há duas famílias de juiz para esse problema. O modelo de recompensa de resultado, ORM na sigla em inglês, olha só a resposta final. O modelo de recompensa de processo, PRM, dá nota a cada passo intermediário. No estudo Let's Verify Step by Step (OpenAI, maio de 2023), a supervisão por processo superou de forma significativa a supervisão por resultado. O teste usou o MATH, conjunto de problemas de matemática de competição, e o modelo resolveu 78% de um subconjunto representativo.

O preço desse ganho foi o rótulo. Os autores liberaram o PRM800K, com 800.000 rótulos humanos por passo. Mostraram também que o aprendizado ativo (escolher o que mandar para rotulagem em vez de sortear) aumenta a eficácia da supervisão por processo. Para uma empresa, a pergunta prática é quem rotula o passo intermediário do seu agente e quanto isso custa por mil passos. Sem resposta, a nota por passo vira a opinião de outro modelo, com os vieses dele.

Três trabalhos de 2025 mostram o desenho do sinal decidindo o resultado. O SWE-RL (Meta, fevereiro de 2025) treinou o Llama 3 com uma recompensa leve baseada em regra: a similaridade entre o patch gerado (o conjunto de mudanças no código) e o patch real de projetos abertos. Com 70 bilhões de parâmetros, chegou a 41,0% no SWE-bench Verified, conjunto de issues reais do GitHub conferidas por pessoas. Os autores relatam ganho em cinco tarefas fora do domínio, enquanto o ajuste supervisionado de base piorou na média.

O RAGEN (abril de 2025) treinou agentes em quatro ambientes, três deles de vários turnos. Descreveu a Echo Trap, armadilha em que a variância da recompensa despenca e o gradiente dá saltos. A versão estabilizada filtra trajetórias, reintroduz um crítico e controla o gradiente; sem sinal fino e atento ao raciocínio, concluem os autores, o agente aprende estratégias rasas. O ToolRL (abril de 2025) estudou só o desenho da recompensa para uso de ferramenta. Treinou com GRPO e mediu 17% sobre o modelo base e 15% sobre o ajuste supervisionado.

De 2025 para 2026 o gargalo saiu do algoritmo e foi para o ambiente. O SkyRL-Agent (Berkeley, novembro de 2025) treinou um agente de código só com RL até 39,4% de acerto na primeira tentativa no SWE-Bench Verified. O custo ficou mais de duas vezes menor que o de modelos de desempenho parecido. O Agent World Model (Snowflake, fevereiro de 2026) gerou 1.000 ambientes sintéticos baseados em código e banco de dados. O ProRL Agent (NVIDIA, março de 2026) oferece rollouts como serviço, separados do laço de treino.

Antes de escolher algoritmo, três peças precisam existir. O ambiente é o mundo em que o agente age: ferramentas expostas, estado inicial, limite de turnos e o que fica fora de alcance. O verificador é o programa que decide a nota sem perguntar ao agente o que ele fez. O orçamento de rollouts, execuções completas do agente sobre uma tarefa, fixa quantas tentativas cabem no dinheiro, e ele cresce rápido quando cada episódio tem vários turnos.

Num primeiro projeto com verificador programático, o RL só compensa quando esse verificador é barato, rápido e confiável. Se a nota exige uma pessoa lendo, se o verificador erra muito ou se o rollout custa mais que o ganho, comece pelo prompt, pela memória e pelos exemplos. Essas alavancas mudam o comportamento sem tocar nos pesos, custam horas em vez de semanas e voltam atrás com um commit. RLHF com modelo de recompensa é outro projeto, com outro orçamento. O curso de RLM detalha essa escolha em quando treinar pesos e quando ficar na memória.

A tarefa de UTM do guia de Claude contra OpenAI é um bom primeiro ambiente. O verificador cabe em 35 linhas e não depende de opinião. As regras já estão no AGENTS.md daquele guia: três parâmetros obrigatórios, minúsculas sem acento, meio numa lista fechada e “&” quando a URL já tem “?”. Para comparar, use o GEPA como linha de base barata: ele evolui o prompt por reflexão e superou o GRPO com até 35 vezes menos rollouts (2025).

Rode as quatro chamadas do fim: a URL certa vale 1,0, a que perdeu o “#topo” e a que trocou o domínio valem zero, e a recusa ao meio “newsletter” vale 0,9. A penalidade da chamada inválida vale em todo caminho, inclusive na recusa. Depois tente quebrar o verificador como um agente faria: repita o utm_source, troque a ordem dos parâmetros, mande “Google” com maiúscula. Cada caso que passar sem merecer, ou falhar sem motivo, vira linha nova no conjunto de borda, e a regra que faltava entra no AGENTS.md.

Escreva o ambiente da sua primeira tarefa com ferramenta no mesmo formato: estado inicial, ferramentas, seis casos de borda, verificador e conta do orçamento. Considere pronto quando o verificador acertar a nota em todos os casos de borda. Você também precisa dizer, em tokens e em dólares, quanto custa uma passada. Se algum caso precisar de uma pessoa para decidir, a tarefa fica no prompt e na memória até caber rótulo humano no orçamento.