idea_world_labDEV JOURNAL
mercredi 17 juin 2026

2026-06-17 SWE-agent trajectory mots‑clés mémo

Conclusion principale

Il est très probable que créer un modèle de codage Godot 4 avec un petit jeu de données Q&A ne soit pas suffisant. Le problème que nous réfléchissons actuellement n’est pas simplement un problème de jeu de données d’instructions, mais il se rapproche davantage d’un problème d’apprentissage d’un agent d’ingénierie logicielle qui doit lire un contexte long au niveau du dépôt, puis explorer les fichiers, juger, modifier, vérifier et générer des correctifs.

En résumé, le nom de la direction actuelle se rapproche de ce qui suit.

Long-context repository-level software engineering agent training

Ou, de façon plus concise, cela peut être vu comme les mots-clés suivants.

SWE-agent trajectory training

Si on se tourne vers Godot, l'objectif n'est pas simplement un modèle de questions‑réponses Godot, mais il se rapproche de ce qui suit.

Créer un jeu de données de trajectoires SWE-agent pour Godot

Pourquoi les petites questions‑réponses ne suffisent pas

Les préoccupations initiales étaient les suivantes.

"Créer une carte"
-> Lire le projet
-> Trouver les fichiers associés
-> Vérifier les assets
-> Déterminer la syntaxe/API de Godot 4
-> Modifier le code
-> Exécuter/Tester/Valider
-> Générer le patch

Cette séquence ne se termine pas simplement par question -> réponse. Un véritable agent de codage doit explorer plusieurs fichiers, prendre des décisions intermédiaires, apporter des modifications et même les valider. Ainsi, au lieu d’un jeu de données ne conservant que le code de la réponse finale, il peut être plus approprié de créer des données d’apprentissage à partir de la trajectoire et des correctifs que l’agent laisse en résolvant le problème.

Priorité de recherche

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

Mémo d'exemple

Trajectoires d'agent SWE

SWE-agent-trajectories est un jeu de données d'enregistrements d'actions d'agent qui consiste à consulter un problème GitHub, explorer les fichiers du dépôt, ouvrir les fichiers nécessaires, les modifier, les tester et créer le patch final.

Mots‑clés principaux :

  • trajectoire d'agent
  • résolution de problème GitHub
  • exploration de fichiers
  • génération de patch
  • formation d'agent en génie logiciel

Correspondance côté Godot :

"Créer une carte"
-> Explorer la structure du projet Godot
-> Vérifier les scènes/scripts/ressources associés
-> Modifier
-> Exécuter ou vérifier les captures d'écran
-> Créer un patch

SWE-smith

SWE-smith est un kit d'outils qui transforme un dépôt GitHub en un environnement d'apprentissage pour les agents d'ingénierie logicielle. En théorie, il peut convertir n'importe quel dépôt GitHub en forme SWE-gym, et permettre la localisation de fichiers, la réparation de programmes, ainsi que la création de tâches de type SWE-bench.

Réponse côté Godot :

Godot repo
-> Créer une tâche de modification de carte/scene/script
-> Créer une trajectoire d'agent Godot
-> Entraîner le modèle de correctif Godot

SWE-Gym

SWE-Gym est un exemple qui regroupe le code source, l'environnement d'exécution, les tests unitaires et les tâches en langage naturel afin d'entraîner un agent SWE et un vérificateur.

Réponse côté Godot :

Godot project
+ Version Godot exécutable
+ Vérification de la scène/test/capture d'écran
+ Tâche de langage naturel
+ Modifier la trajectoire
+ patch

Le point important est que l'on n'apprend pas seulement le code ou uniquement les questions en langage naturel, mais que l'on regroupe également l'environnement d'exécution et la validation.

CoderForge-Preview

CoderForge-Preview est un exemple de création de données SFT à long contexte basé sur la trajectoire d'un agent. Il est important de noter qu'il utilise une trajectoire à long contexte de jusqu'à 128 K tokens.

Cet exemple constitue une base pour la question suivante.

Est-ce que les travaux au niveau du dépôt ne nécessitent pas un grand contexte ?

Le flux d’apprentissage des agents de codage utilise également des trajectoires de contexte long.

ACC

ACC : Compilation des trajectoires d’agent pour un entraînement à long contexte vise à compiler les trajectoires d’agent sous forme de QA à long contexte. L’idée principale est de transformer les appels d’outil, les observations, le contenu de fichiers et les résultats de recherche s’étalant sur plusieurs tours en données d’apprentissage à contexte étendu.

Ce cas soulève les questions suivantes.

## Question

**Est‑ce suffisant d’apprendre uniquement le code de la réponse finale ?**  
**Ou faut‑il également conserver les processus d’exploration de fichiers et de prise de décision comme données d’apprentissage ?**

RepoBench / CrossCodeEval / RepoCoder

Cette série traite de la compréhension et de la complétion de code au niveau du dépôt.

Idée principale :

  • Un benchmark à fichier unique ne permet pas de saisir la complexité réelle d’un projet.
  • Des informations utiles sont dispersées sur plusieurs fichiers.
  • Il faut évaluer la complétion de code nécessitant un contexte inter‑fichiers.
  • Un pipeline de récupération‑génération est nécessaire.

Réponse côté Godot :

Il est difficile de modifier la carte en ne regardant qu'un seul fichier.  
Il faut examiner ensemble la scène, le script, les ressources, les paramètres du projet et le chemin des assets.

aiXcoder CoLT

aiXcoder-7B-v2 et CoLT traitent le problème selon lequel le modèle peut ignorer les informations utiles même lorsqu’on lui fournit un long contexte.

Question importante :

## Doit‑on insérer un grand contexte ?  
→ Non.  
Même si vous insérez beaucoup, il faut former/vérifier si le modèle le lit réellement et l’utilise.

Godot côté, même si les informations sur Godot 4 se trouvent dans un contexte long, le modèle peut répondre avec des motifs de type Python ou l’API Godot 3. Ainsi, il peut être nécessaire d’entraîner l’utilisation du long‑context ou de concevoir des données qui fixent plus fortement le contexte de Godot 4.

jeu de données godot-dodo / wallstoneai

Un exemple direct de Godot est godot-dodo et wallstoneai/godot-gdscript-dataset.

Ces deux jeux de données se rapprochent du code brut GDScript ou du texte du dépôt. Ils ont du sens comme point de départ pour un apprentissage spécialisé sur Godot, mais ils sont éloignés de l’objectif final qui est le jeu de données de trajectoires d’agents.

Comparé à l’objectif actuel, on peut le résumer comme suit.

Jeu de données Godot existant:
GDScript raw code / repo text

Jeu de données Godot requis:
Godot repo context
+ user task
+ file exploration
+ patch
+ verification
+ long-context trajectory

Mots-clés liés aux préoccupations actuelles

En reliant les questions résumées lors de la rétrospective du 14 juin, on obtient ce qui suit.

Peut‑on inclure le contexte complet du projet et les extraits de documentation officielle recherchés dans le contexte d’entrée du modèle en une seule fois ?
-> problème de codage au niveau du dépôt avec contexte long
## Faut‑il conserver les processus d’exploration et de jugement sous forme de données ?
→ problème d’entraînement de trajectoire
Même avec un long contexte, le modèle utilisera-t-il correctement le contexte de Godot 4 ?
-> long-context utilization / CoLT problem

Liens de référence