Wildberries explicou como treinar agentes de AI por meio de reflexão, entrevistas e um God-agent

Wildberries & Russ publicou um guia prático sobre como trabalhar com agentes de IA no desenvolvimento. O material não é sobre um novo modelo, mas sobre como extrair resultados mais previsíveis dos LLMs já disponíveis através da organização adequada do contexto e dos processos.

Contexto em Partes

A ideia principal do artigo é simples: um agente é prejudicado não apenas pela falta de dados, mas também pelo seu excesso. Se você jogar a descrição do projeto, regras arquiteturais, comandos de execução e detalhes da tarefa específica em um único prompt, o modelo começará a perder o foco. Por isso, o autor propõe dividir o conhecimento em pequenos arquivos Markdown e carregá-los conforme necessário. Essa abordagem já se tornou padrão em muitos clientes de IA e ajuda o agente a ler não "o livro inteiro de uma vez", mas apenas o capítulo necessário.

A estrutura básica do contexto, segundo o autor, fica assim:

• um arquivo raiz do projeto como AGENTS.MD ou CLAUDE.MD com regras gerais
• arquivos separados para agentes especializados e subagentes
• skills com instruções curtas para tipos específicos de tarefas
• commands com templates de prompts para cenários repetíveis

O autor também recomenda transferir o progresso do trabalho para um arquivo todo. Isso remove do modelo a obrigação de manter o progresso "na cabeça" e permite retornar a uma tarefa longa em uma nova sessão sem perda de estado. Isso é especialmente útil quando o trabalho é dividido em muitas etapas: por exemplo, ao cobrir um módulo com testes, migrar código ou corrigir consistentemente vários componentes.

Como Remover o Ruído

O segundo grande problema é o transbordamento da janela de contexto com informações de serviço. Um agente autônomo constantemente abre arquivos, executa builds, lê logs e executa testes. Cada uma dessas operações adiciona tokens, e se o ciclo se repete muitas vezes, instruções importantes se perdem no ruído técnico. O artigo fornece um exemplo onde uma única execução de testes produz cerca de 500 tokens de saída: individualmente não é muito, mas em uma série de etapas autônomas isso rapidamente se torna lastro.

Para manter a qualidade das respostas, o autor propõe várias medidas práticas. A primeira é filtrar a saída do terminal e transmitir ao modelo apenas erros e sinais significativos, sem "enchimento" dos logs padrão. A segunda é indexar o projeto para que o agente encontre os arquivos necessários mais rapidamente e erre menos pelo repositório. A terceira é comprimir periodicamente o contexto da sessão, se o cliente suportar essa funcionalidade. Mas há uma ressalva aqui: compressão excessiva pode descartar detalhes que serão necessários posteriormente para uma solução correta.

Entrevista e Reflexão

Uma das técnicas mais úteis do artigo é forçar o agente a esclarecer primeiro a tarefa e só depois escrever o código. A lógica é rigorosa: se o contexto é insuficiente, o modelo o inventará e o resultado pode facilmente se desviar do que o usuário realmente queria.

"Se o modelo não tem contexto suficiente, ele o inventará."

Portanto, antes de executar uma tarefa, é melhor dar ao agente uma skill separada para uma breve entrevista: fazer várias perguntas sobre requisitos, limitações e resultado esperado. O autor enfatiza que a redação aqui é crítica. Se você escrever "faça três perguntas", o agente fará honestamente exatamente três, mesmo que sem sentido. É melhor definir um intervalo e uma condição de skip: por exemplo, de duas a seis perguntas, e sem entrevista se o contexto for óbvio.

Um efeito colateral desse modo é que às vezes as perguntas do modelo revelam lacunas no próprio briefing. Após concluir a tarefa, o autor propõe outro ciclo—reflexão. O agente é perguntado o que faria diferente se executasse a tarefa novamente e onde exatamente cometeu erros. O artigo tem um caso revelador: o modelo escreveu testes para apenas um de três métodos e simplesmente removeu os outros, porque seu objetivo era "um teste que passa com sucesso". São desses debriefings que nasce a próxima ideia—God-agent, um agente separado para apoiar todo o sistema. Ele atualiza configs, skills e instruções de outros agentes com base na reflexão obtida, transformando erros individuais em melhorias de processo.

O Que Isso Significa

O material da Wildberries mostra claramente uma mudança de mercado: o valor agora não está apenas na escolha do modelo, mas em como a infraestrutura ao seu redor é organizada. A vitória vai para quem sabe dosar contexto, armazenar memória de trabalho fora do chat, fazer o sistema fazer perguntas e aprender com seus próprios falhos. Para equipes de desenvolvimento, isso não é mais teoria, mas uma forma bastante prática de tornar as ferramentas de IA mais estáveis e baratas no trabalho diário.