idea_world_labDEV JOURNAL
Mittwoch, 17. Juni 2026

2026-06-17 SWE-agent trajectory Schlüsselwort‑Notiz

Kernschlussfolgerung

Beim Erstellen eines Godot‑4‑Coding‑Modells ist es sehr wahrscheinlich, dass ein kleiner Q&A‑Datensatz nicht ausreicht. Das aktuelle Problem, das ich überlege, ist nicht einfach ein Problem mit einem Instruction‑Datensatz, sondern eher ein Lernproblem für einen Software‑Engineering‑Agent, der ein ganzes Repository‑Kontext liest, Dateien durchsucht, Entscheidungen trifft, Änderungen vornimmt, verifiziert und schließlich Patches erzeugt.

Zusammengefasst ist der Name der aktuellen Richtung dem Folgenden am nächsten.

Long-context repository-level software engineering agent training

Oder kürzer gesagt kann man es mit den folgenden Schlüsselwörtern betrachten.

SWE-agent trajectory training

Wenn man es auf Godot überträgt, ist das Ziel nicht ein einfaches Godot‑Q&A‑Modell, sondern kommt dem Folgenden nahe.

Erstellung eines SWE‑Agent‑Trajektoriensatzes für Godot → Erstellung eines SWE‑Agent‑Trajektoriensatzes für Godot

Warum kleine Q&A nicht ausreichen

Das ursprüngliche Problem war wie folgt.

"Karte erstellen"

-> Projekt lesen
-> zugehörige Dateien finden
-> Assets prüfen
-> Godot 4 Syntax/API beurteilen
-> Code ändern
-> Ausführen/Testen/Validieren
-> Patch erstellen

Dieser Ablauf endet nicht mit nur einer Frage -> Antwort. Der eigentliche Coding‑Agent muss mehrere Dateien durchsuchen, Zwischenergebnisse beurteilen, Änderungen vornehmen und schließlich verifizieren. Daher könnte es geeigneter sein, anstelle eines Datensatzes, der nur den endgültigen Antwortcode enthält, die vom Agenten während der Problemlösung hinterlassenen Trajektorien und Patches als Trainingsdaten zu verwenden.

Priorität beim Durchsuchen

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

Fallbeispiel Notizen

SWE-Agent Trajektorien

SWE-agent-trajectories ist ein Datensatz von Agentenaktionsprotokollen, der das Durchsuchen von Repository‑Dateien, das Öffnen, Ändern, Testen und Erstellen des endgültigen Patches nach dem Betrachten eines GitHub‑Issues aufzeichnet.

Kernschlagwörter:

  • Agenten‑Trajektorie
  • Lösung von GitHub‑Issues
  • Dateiexploration
  • Patch‑Generierung
  • Training von Software‑Engineering‑Agenten

Godot‑seitige Gegenmaßnahme:

"Karte erstellen"
-> Godot-Projektstruktur durchsuchen
-> Zugehörige Szene/Script/Resource prüfen
-> Bearbeiten
-> Ausführen oder Screenshot prüfen
-> Patch erstellen

SWE-smith

SWE-smith ist ein Toolkit, das ein GitHub‑Repository in eine Lernumgebung für Software‑Engineering‑Agenten umwandelt. Es beschreibt, wie ein beliebiges GitHub‑Repository in das SWE‑gym‑Format konvertiert werden kann und ermöglicht die Erstellung von File‑Localization, Program‑Repair und SWE‑bench‑ähnlichen Aufgaben.

Godot‑seitige Unterstützung:

Godot repo
-> Erstellung einer Aufgabe zum Ändern von Karte/Szene/Skript
-> Erstellung einer Godot-Agent-Trajektorie
-> Training des Godot-Patch-Modells

SWE-Gym

SWE-Gym ist ein Beispiel, das den Code‑Base, die ausführbare Laufzeitumgebung, Unit‑Tests und Aufgaben in natürlicher Sprache kombiniert, um einen SWE‑Agenten und einen Verifizierer zu trainieren.

Godot‑seitige Unterstützung:

Godot-Projekt
+ ausführbare Godot-Version
+ Scene/Test/Screenshot-Validierung
+ Natürliche Sprachaufgabe
+ Trajektorie korrigieren
+ Patch

Wichtig ist, dass nicht nur Code oder nur natürliche Sprachfragen gelernt werden, sondern dass die Ausführungsumgebung und die Validierung ebenfalls zusammengefasst werden.

CoderForge-Preview

CoderForge-Preview ist ein Beispiel dafür, wie anhand von Agent‑Trajektorien Long‑Context‑SFT‑Daten erstellt werden. Dabei ist es bedeutsam, dass Trajektorien mit einem Long‑Context von bis zu 128 K Token verwendet wurden.

Dieses Beispiel liefert die Grundlage für die folgende Frage.

Braucht man für Aufgaben auf Repository‑Ebene nicht einen großen Kontext?

Tatsächliche Codierungs‑Agent‑Lern‑Ansätze verwenden ebenfalls lange Kontext‑Trajektorien.

ACC

ACC: Compiling Agent Trajectories for Long-Context Training ist ein Ansatz, bei dem Agent‑Trajektorien in ein Long‑Context‑QA‑Format kompiliert werden. Der Kern besteht darin, Tool‑Aufrufe, Beobachtungen, Dateiinhalte und Suchergebnisse, die sich über mehrere Runden erstrecken, in lange Kontext‑Lern‑Daten zu verwandeln.

Dieses Beispiel steht in Verbindung mit der folgenden Frage.

Reicht es aus, nur den endgültigen Antwortcode zu lernen?  
Oder muss man den Datei‑Durchsuchungs‑ und Entscheidungsprozess ebenfalls als Trainingsdaten behalten?

RepoBench / CrossCodeEval / RepoCoder

Diese Reihe behandelt das Verständnis und die Vervollständigung von Code auf Repository‑Ebene.

Kernproblematik:

  • Ein Single‑File‑Benchmark reicht nicht aus, um die Komplexität realer Projekte abzubilden.
  • Nützliche Informationen sind über mehrere Dateien verteilt.
  • Es muss die Code‑Vervollständigung bewertet werden, die Kontext über Dateien hinweg erfordert.
  • Ein Retrieval‑Generation‑Pipeline ist erforderlich.

Godot‑seitige Umsetzung:

Eine einzelne Datei zu betrachten, macht die Kartenbearbeitung schwierig.  
Szene, Skript, Ressourceneinstellungen, Projektkonfiguration und Asset‑Pfade müssen gemeinsam betrachtet werden.

aiXcoder CoLT

aiXcoder-7B-v2 und CoLT behandeln das Problem, dass das Modell nützliche Informationen ignorieren kann, selbst wenn ein langer Kontext bereitgestellt wird.

Wichtige Frage:

Kann man den Kontext groß einfügen?  
-> Nein.  
Auch wenn man ihn groß einfügt, muss man prüfen, ob das Modell ihn tatsächlich liest und nutzt.

Godot‑Seite enthält Informationen zu Godot 4, die selbst in einem langen Kontext vorhanden sind, sodass das Modell mit Python‑ähnlichen Mustern oder der Godot 3‑API antworten kann. Daher kann es nötig sein, das Training so zu gestalten, dass die Nutzung von Long‑Context gelernt wird, oder die Daten so zu entwerfen, dass der Godot 4‑Kontext stärker verankert wird.

godot‑dodo / wallstoneai‑Datensatz

Ein direktes Beispiel von der Godot‑Seite sind godot-dodo und wallstoneai/godot-gdscript-dataset.

Beide nähern sich einem GDScript‑Rohcode‑ bzw. Repository‑Text‑Datensatz. Sie haben zwar einen Sinn als Ausgangspunkt für ein Godot‑spezifisches Training, liegen jedoch vom eigentlichen Ziel, einem Agent‑Trajectory‑Datensatz, entfernt.

Im Vergleich zum aktuellen Ziel lässt sich das Folgende zusammenfassen.

Vorhandener Godot‑Datensatz:
GDScript raw code / repo text

Erforderlicher Godot‑Datensatz:
Godot repo context
+ user task
+ file exploration
+ patch
+ verification
+ long-context trajectory

Aktuelle Überlegungen und zugehörige Schlüsselwörter

Wenn man es mit den Fragen verbindet, die im Rückblick vom 14. Juni zusammengestellt wurden, ergibt sich Folgendes.

Können wir den gesamten Kontext des Projekts und die gefundenen offiziellen Dokumentationsausschnitte gleichzeitig in den Modelleingabekontext einbinden?
-> long-context repo-level coding problem
Soll der Such- und Entscheidungsprozess als Daten hinterlassen werden?  
-> Trajektorien‑Trainingsproblem
Kann das Modell selbst bei langen Kontexten Godot 4‑Zusammenhänge korrekt nutzen?  
→ Langzeit‑Kontextnutzung / CoLT‑Problem