Start/Forschung/Papers/Oracle-SWE: Welche Kontext-Signale einen SWE-Agenten wirklich besser machen
9. April 2026

Wer einen Coding-Agenten ernsthaft baut, steht vor einer unangenehmen Frage: Welche Informationen aus dem Repository soll der Agent zur Aufgabe bekommen, und welche sind nur Rauschen? Die Literatur der letzten zwei Jahre hat dazu eine Reihe von Kandidaten etabliert -- Reproduktionstests, Regressionstests, die korrekte Edit-Location, den Execution Context, die API-Nutzung. Geprueft wurden diese Signale bisher vor allem gebuendelt als Teil komplexer Harnesses. Was fehlt, ist eine saubere Zerlegung: Welches Signal bringt wie viel, und lohnt sich welche Investition? Kenan Li, Qirui Jin, Liao Zhu und Kollegen von Microsoft Research beantworten mit Oracle-SWE genau diese Frage.

Kernaussagen

Das Paper fuehrt eine einheitliche Methode ein, um aus SWE-Benchmarks fuenf klar definierte Oracle-Signale zu extrahieren und deren individuellen Beitrag zur Agent-Performance zu isolieren. Die Autoren betrachten den Reproduction Test (ein Test, der den Bug in der alten Version zuverlaessig ausloest), den Regression Test (die Menge an Tests, die nach dem Fix gruen bleiben muessen), die Edit Location (die konkreten Dateien und Zeilen, an denen geaendert werden soll), den Execution Context (der Laufzeit-Zustand, den der Fehler produziert -- Stacktrace, Variablenbelegungen, Pfade) sowie die API Usage (welche internen Schnittstellen der Codebase fuer den Fix relevant sind).

Die Pointe ist die Zweiteilung der Evaluation. Im Oracle-Szenario bekommt der Agent das jeweilige Signal perfekt -- direkt aus dem Benchmark extrahiert, ohne Extraktionsfehler. Das liefert die theoretische Obergrenze: "Wenn wir dieses Signal perfekt haetten, wie viel waere drin?" Im zweiten, realistischeren Szenario extrahiert ein starkes LLM das Signal eigenstaendig aus dem Repository und uebergibt es einem Base-Agent. Die Luecke zwischen beiden Werten zeigt, wie viel vom Upper Bound in der Praxis tatsaechlich erreichbar ist -- und welche Signale besonders schwer zu extrahieren sind.

Die Autoren adressieren damit eine Luecke, die in der Debatte um Agent-Harnesses oft uebersehen wird: Es genuegt nicht zu wissen, dass ein Signal theoretisch hilft. Es muss auch zuverlaessig beschaffbar sein, sonst ist es praktisch wertlos.

Methodik

Oracle-SWE ist eine Ablation auf etablierten SWE-Benchmarks. Fuer jede Aufgabe wird der Grundwahrheits-Fix aus dem Benchmark analysiert und die fuenf Signale werden daraus deterministisch abgeleitet. Dieser Schritt liefert das Oracle -- perfekte, benchmark-gesicherte Information. Der Base-Agent wird dann mit allen Kombinationen der Signale ausgefuehrt: ohne Signal als Baseline, mit einzelnen Signalen zur Isolation des Beitrags, mit Signal-Kombinationen zur Messung von Interaktionseffekten.

Im zweiten Teil tritt ein Extractor-Modell dazwischen. Ein starker LM liest das Repository und den Issue-Report und versucht, jedes Signal selbststaendig zu rekonstruieren. Das Ergebnis wird dem Base-Agent als Kontext gegeben. Die Differenz zum Oracle-Lauf quantifiziert den Informationsverlust durch Extraktion. Das Paper umfasst 37 Seiten, 10 Figures und 5 Tables, ist bei cs.MA/cs.SE unter arXiv-Nummer 2604.07789 eingereicht und befindet sich im Peer Review.

Die methodische Staerke liegt darin, dass die Ablation nicht nur einzelne Signale, sondern auch ihre Kombination misst. Damit lassen sich Substitutions- und Komplementaritaetseffekte sichtbar machen: Manche Signale ueberlappen sich -- wer die Edit Location kennt, braucht den Execution Context vielleicht weniger -- andere wirken multiplikativ.

Relevanz fuer die Praxis

Fuer Teams, die einen Agent-Harness betreiben, ist das Paper ungewoehnlich konkret. Es verschiebt die Diskussion weg von "wir haengen alles an den Prompt" hin zu einer priorisierten Einkaufsliste fuer Kontext-Zutaten. Das passt nahtlos zu den vier Grundbewegungen aus Context Engineering: Die eigentliche Disziplin hinter funktionierenden AI-Agenten -- Offloading, Retrieval, Isolation und Reduction werden erst dann steuerbar, wenn man die erwartete Rendite einzelner Informationsbausteine kennt. Oracle-SWE liefert diese Rendite empirisch.

Besonders interessant ist die Verbindung zum Agentic-TDD-Muster aus Agentic TDD: Warum Test-Driven Development der natuerliche Partner von Coding-Agenten ist. Die Tatsache, dass Reproduction Test und Regression Test zwei der fuenf untersuchten Signale sind, ist kein Zufall: Sie sind genau das, was eine TDD-Suite von Natur aus liefert. Wer die Tests vorab schreibt, produziert die wertvollsten Oracle-Signale als Nebenprodukt des normalen Entwicklungsprozesses -- der Agent bekommt Upper-Bound-Kontext, ohne dass ein teures Extractor-Modell ihn rekonstruieren muss.

Die Ergebnisse aus SWE-CI und ProdCodeBench ergaenzen sich damit zu einem konsistenten Bild: Einmal-Korrektheit ist nicht genug, Produktionscode stellt hoehere Anspruechen, und die entscheidende Stellschraube liegt im Kontext, den der Agent vor dem ersten Token bekommt.

Ganz praktisch laesst sich das in bestehenden Tools verankern. Ein Claude-Code-Slash-Command, der bei jedem Issue zuerst einen Reproduction-Test schreibt und die Edit Location ueber die LSP-API bestimmt, bevor der Implementation-Agent gestartet wird, bildet die Oracle-SWE-Pipeline im Kleinen nach. Das ist deutlich effektiver, als den Agenten mit dem gesamten Repository zu fluten und zu hoffen, dass er die richtigen Stellen findet.

Was bringt das konkret fuer meine Agent-Harness? Ressourcen zuerst in Reproduction Test und Edit Location investieren -- das sind die Signale mit dem hoechsten erwarteten Hebel und gleichzeitig die, die sich am besten deterministisch beschaffen lassen. Execution Context und API Usage sind Fuellmaterial, wenn noch Token-Budget uebrig ist. Regression Test ist Pflicht, aber ohnehin schon Teil jedes ernsthaften CI-Setups. Und: Wer einen Extractor-Schritt vor den Base-Agent schaltet, sollte ihn an der Qualitaet der extrahierten Signale messen, nicht an der End-to-End-Erfolgsrate des Agenten.

Quellen

Nach oben