idea_world_labDEV JOURNAL
quarta-feira, 17 de junho de 2026

2026-06-17 SWE-agent trajectory palavra‑chave memo

Conclusão principal

É muito provável que, ao criar um modelo de codificação Godot 4, um pequeno conjunto de dados de perguntas e respostas seja insuficiente. O problema que está sendo considerado agora não é simplesmente um conjunto de instruções, mas sim um problema de aprendizado de agente de engenharia de software que envolve ler um contexto longo em nível de repositório, navegar pelos arquivos, tomar decisões, fazer modificações, validar e gerar patches.

Resumindo, o nome da direção atual se aproxima do seguinte.

Long-context repository-level software engineering agent training

Ou, de forma mais curta, pode ser visto como a seguinte palavra‑chave.

SWE-agent trajectory training

Se substituirmos por Godot, o objetivo não é um modelo simples de perguntas e respostas sobre Godot, mas algo mais próximo do seguinte.

# Criando conjunto de dados de trajetória SWE-agent para Godot

Por que apenas perguntas e respostas curtas não são suficientes

A preocupação anterior era a seguinte.

"Crie o mapa"
-> Ler o projeto
-> Encontrar arquivos relacionados
-> Verificar assets
-> Determinar sintaxe/API do Godot 4
-> Modificar o código
-> Executar/Testar/Validar
-> Criar patch

Esse fluxo não termina apenas com pergunta -> resposta. O agente de codificação real precisa explorar vários arquivos, fazer julgamentos intermediários, modificar e até validar. Portanto, em vez de um conjunto de dados que mantém apenas o código da resposta final, pode ser mais adequado criar dados de treinamento a partir da trajetória e dos patches deixados pelo agente ao resolver o problema.

Prioridade de Busca

1. SWE-smith
2. nebius/SWE-agent-trajectories
3. CoderForge-Preview
4. ACC
5. aiXcoder CoLT
6. RepoBench / CrossCodeEval / RepoCoder
7. godot-dodo / wallstoneai dataset

Caso de Memória

Trajetórias do agente SWE

SWE-agent-trajectories é um conjunto de dados de registro de comportamento de agente que, ao observar um issue do GitHub, explora arquivos do repositório, abre os arquivos necessários, os modifica, testa e cria o patch final.

Palavras‑chave principais:

  • trajetória do agente
  • resolução de issue do GitHub
  • exploração de arquivos
  • geração de patch
  • treinamento de agente de engenharia de software

Correspondência no Godot:

"Crie o mapa"
-> Verificar scene/script/resource relacionados
-> Modificar
-> Executar ou validar captura de tela
-> Criar patch

SWE-smith

SWE-smith é um kit de ferramentas que transforma repositórios do GitHub em ambientes de aprendizado para agentes de engenharia de software. Em termos de descrição, ele converte um repositório arbitrário do GitHub para o formato SWE-gym, permitindo a localização de arquivos, reparo de programas e a criação de tarefas no estilo SWE-bench.

Correspondência para Godot:

Godot repo
-> Criar tarefa de modificação de mapa/cena/script
-> Criar trajetória do agente Godot
-> Treinar modelo de patch Godot

SWE-Gym

SWE-Gym é um caso que agrupa codebase, ambiente de execução executável, testes unitários e tarefa de linguagem natural para treinar o agente SWE e o verificador.

Correspondência para Godot:

Godot project
+ versão do Godot executável
+ verificação de cena/teste/captura de tela
+ tarefa de linguagem natural
+ trajetória de correção
+ patch

Importante notar que não se trata apenas de treinar código ou apenas perguntas em linguagem natural, mas de combinar isso com o ambiente de execução e a validação.

CoderForge-Preview

CoderForge-Preview é um exemplo de criação de dados SFT de longo contexto baseado na trajetória do agente. É importante que tenha sido usada uma trajetória de longo contexto de até 128 K tokens.

Este caso serve de base para a seguinte questão.

Não seria necessário um grande contexto para trabalhos em nível de repositório?

Realmente há um fluxo de aprendizado de agentes de codificação que utiliza trajetórias de contexto longo.

ACC

ACC: Compiling Agent Trajectories for Long-Context Training é uma abordagem que compila trajetórias de agentes no formato de perguntas e respostas de contexto longo. O ponto central é transformar chamadas de ferramentas, observações, conteúdo de arquivos e resultados de buscas que ocorrem em múltiplas interações em dados de treinamento de contexto extenso.

Esse caso está ligado à seguinte questão.

É suficiente treinar apenas o código da resposta final?  
Ou devemos deixar também a exploração de arquivos e o processo de julgamento como dados de treinamento?

RepoBench / CrossCodeEval / RepoCoder

Esta série trata de compreensão e conclusão de código em nível de repositório.

Questões centrais:

  • Um benchmark de arquivo único não captura a complexidade de projetos reais.
  • Informações úteis estão espalhadas em vários arquivos.
  • É necessário avaliar a conclusão de código que requer contexto entre arquivos.
  • É preciso um pipeline de recuperação‑geração.

Resposta para Godot:

É difícil modificar o mapa apenas olhando um arquivo.  
É necessário ver a cena, o script, as configurações de recurso e projeto, e o caminho dos assets juntos.

aiXcoder CoLT

aiXcoder-7B-v2 e CoLT tratam do problema de que, mesmo com um contexto longo, o modelo pode ignorar informações úteis.

Questão importante:

Devo inserir um contexto grande?  
-> Não.  
Mesmo que seja grande, é necessário treinar/validar se o modelo realmente lê e utiliza.

Godot tem informações sobre o Godot 4 mesmo em contextos longos, mas o modelo ainda pode responder usando padrões estilo Python ou a API do Godot 3. Portanto, pode ser necessário treinar o uso de long‑context ou projetar os dados de forma a fixar mais fortemente o contexto do Godot 4.

Conjunto de dados godot-dodo / wallstoneai

Um exemplo direto do Godot são os repositórios godot-dodo e wallstoneai/godot-gdscript-dataset.

Ambos se aproximam de um conjunto de dados de código GDScript bruto ou de texto de repositório. Eles são úteis como ponto de partida para aprendizado especializado em Godot, mas estão distantes do objetivo final, que é um conjunto de dados de trajetórias de agentes.

Comparando com o objetivo atual, pode‑se resumir da seguinte forma.

Conjunto de dados Godot existente:
GDScript raw code / repo text

Conjunto de dados Godot necessário:
Godot repo context
+ tarefa do usuário
+ exploração de arquivos
+ correção
+ verificação
+ trajetória de longo contexto

Palavras‑chave relacionadas à preocupação atual

Se conectarmos com as dúvidas organizadas na retrospectiva de 14 de junho, temos o seguinte.

Será que podemos colocar todo o contexto do projeto e os trechos de documentação oficial encontrados de uma só vez no contexto de entrada do modelo?  
-> problema de codificação em nível de repositório com contexto longo
## Deve-se deixar o processo de exploração e julgamento como dados?
-> problema de treinamento de trajetória
Mesmo fornecendo um contexto longo, o modelo usará corretamente o contexto do Godot 4?  
-> utilização de longo contexto / problema CoLT