Kuaishous KwaiKAT-Team hat KAT-Coder-V2.5 vorgestellt, ein Coding-Modell, das dafür entwickelt wurde, in realen, ausführbaren Software-Repositories zu arbeiten, statt Code-Snippets in einzelnen Interaktionsschritten zu erzeugen. Das bereitgestellte Modell ist über StreamLake verfügbar. Eine separate Open-Weight-Variante, KAT-Coder-V2.5-Dev, wurde auf Hugging Face unter der Apache-2.0-Lizenz veröffentlicht.

Die Veröffentlichung konzentriert sich auf agentische Coding-Workflows, bei denen ein Modell ein Repository prüfen, eine Aufgabe verstehen, Dateien bearbeiten, Tests ausführen und verifizieren muss, ob ein Patch korrekt ist. Dieser Schwerpunkt spiegelt eine breitere Verschiebung in der Bewertung von Coding-Modellen wider: weg von isolierten Programmieraufgaben und hin zur Softwarewartung auf Repository-Ebene, bei der reproduzierbare Umgebungen und verlässliches Testfeedback ebenso wichtig sein können wie die Qualität der Codegenerierung. Das Projekt betont Repository-Umgebungen, Datenkonstruktion, Sandbox-Zuverlässigkeit, Infrastruktur für Reinforcement Learning und Benchmark-Evaluierung.

AutoBuilder erstellt Umgebungen, die die vorgesehenen Tests ausführen

Die Forschung definiert eine verifizierbare Coding-Aufgabe als Tripel: eine präzise Aufgabenbeschreibung, eine ausführbare Repository-Umgebung und eine Reihe von Validierungstests. Ein Patch gilt nur dann als korrekt, wenn er den vollständigen Validierungssatz besteht.

Die Aufgaben werden aus realen Pull Requests und Commits gewonnen und folgen der SWE-bench-Linie. Die zusammengeführte Codeänderung liefert einen Golden Patch, während die zugehörige Teständerung einen Test-Patch bereitstellt. Das System verwendet den ursprünglichen Issue-Text nicht als Spezifikation. Stattdessen werden Aufgabenbeschreibungen in drei Komponenten neu generiert: eine auf dem Golden Patch basierende Problembeschreibung, aus dem Test-Patch abgeleitete Anforderungen und aus beiden Quellen abgeleitete Schnittstellenbeschränkungen. Eine Klarheitsprüfung entfernt Aufgaben, die mehrdeutig, unvollständig, unterspezifiziert oder intern inkonsistent sind.

AutoBuilder ist für den Aufbau der Umgebung verantwortlich. Ein Build-Agent untersucht das Repository und schreibt ein Konfigurationsskript, das Abhängigkeiten installiert und Tests aus einem sauberen Checkout heraus ausführt. Ein Verifizierungsagent führt das Skript anschließend in einer isolierten Sandbox aus.

Der Akzeptanzprozess stützt sich nicht auf Exit-Codes oder Log-Pattern-Matching. Stattdessen parst die Verifizierung strukturierte Ausgaben von Test-Frameworks. Eine Umgebung wird nur akzeptiert, wenn mehr als 90% der erwarteten Tests erfasst werden und die Pass/Fail-Ergebnisse über mehrere Läufe hinweg reproduzierbar sind. Fehler werden als strukturierte Informationen für iterative Reparaturen zurückgegeben.

Durch die Kombination einer vorkonfigurierten Basisumgebung, Build-System-Templates und einer abrufbaren Bibliothek destillierter Build-Rezepte erhöhte das Team die Erfolgsquote beim Aufbau von Umgebungen von 16.5% auf 57.2%. Der daraus resultierende Datensatz umfasst mehr als 100,000 verifizierbare Umgebungen in 12 Programmiersprachen. Git-Historie, Commit-Metadaten und andere ausnutzbare Spuren werden entfernt, damit Agenten die Referenzlösung nicht direkt aus dem Repository beziehen können.

Data Scaling Flywheel filtert nach Prozessqualität

Das Projekt argumentiert, dass eine Filterung von Trajektorien ausschließlich nach endgültigem Testerfolg irreführend sein kann. Manche erfolgreiche Läufe können auf Hard-Coding, dem Umgehen vorgesehener Mechanismen oder testorientierten Abkürzungen beruhen. Gleichzeitig können manche fehlgeschlagenen Läufe dennoch nützliches Such-, Lokalisierungs- und Reparaturverhalten enthalten.

KwaiKAT adressiert beide Fälle. Bei knapp gescheiterten Versuchen zeigen gezielte Hinweise auf Prozessebene, was geprüft oder verifiziert werden sollte, ohne die Lösung offenzulegen. Dadurch steigt die Erfolgsquote zuvor vollständig erfolgloser Aufgaben auf ungefähr 20%. Da Trajektorien mit Hinweisen Informationen enthalten, die zur Inferenzzeit nicht verfügbar wären, wird der verifizierte Patch anschließend fixiert und aus dem ursprünglichen Aufgabenkontext eine hinweisfreie Trajektorie neu generiert. Beibehalten werden nur Samples, die die Verifizierung bestehen, keine Hinweis-Leckage enthalten und mit dem Patch konsistent bleiben.

Für Trajektorien, die bereits erfolgreich sind, entfernen regelbasierte Gates ungültige, instabile oder ausnutzende Beispiele. Eine Scoring-Stufe bewertet anschließend Exploration, Lokalisierung, Vorab-Reasoning vor Änderungen, Spezifikationstreue, Einhaltung von Repository-Konventionen, Patch-Minimalität, Verifizierungsqualität, Wiederherstellungsverhalten und Ehrlichkeit.

Ein dritter Mechanismus zielt darauf ab, Overfitting auf das Harness zu reduzieren. Toolnamen, Argumentkonventionen, Ausgabeformate und Prompt-Templates werden randomisiert, während die Funktionalität unverändert bleibt. Da die Verifizierung an Testergebnisse statt an Harness-Spuren gebunden ist, kann dieselbe Aufgabe unter mehreren Harness-Konfigurationen präsentiert werden. Das System injiziert außerdem realistische Störungen, darunter fehlende Abhängigkeiten, vorübergehende Befehlsfehler, gekürzte Ausgaben und verrauschte Logs.

Sandbox-Fehler beeinflussten Rewards vor algorithmischen Grenzen

Während des Trainings von KAT-Coder-V2 wurden langsame Reward-Kurven zunächst dem Reinforcement-Learning-Algorithmus zugeschrieben. Eine spätere Prüfung ergab jedoch, dass etwa 16% der Trajektorien wegen Problemen in der Sandbox-Infrastruktur scheiterten und nicht aufgrund der Modell-Policy. Grenzfehlanpassungen leerten Beobachtungen mitunter für etwa 40 Schritte und verfälschten Rewards.

Das Team implementierte drei Infrastrukturkorrekturen. Erstens senkte eine Image-Eviction-Policy mit früher Freigabe die Festplattennutzung von 95% auf 60%, wodurch zeitüberschreitungsbedingte ungültige Rollouts von 6–7% auf unter 1% zurückgingen. Zweitens verhinderte die Korrektur von Umgebungsvariablen bei der Initialisierung entfernter Sandboxes System-Overrides, die bei 6–7% der Samples Rewards umgekehrt hatten, und reduzierte diese Fehler auf unter 1%. Drittens umging der Gateway Server gängige Chat-Endpunkte, die durch erneutes Anwenden von apply_chat_template und erneutes Tokenisieren bei einer Größenordnung von ungefähr 200 Turns eine Token-Abweichung von 40% verursacht hatten. Stattdessen rief das System direkt /generate auf, um die Token-Ausrichtung der Rollouts aufrechtzuerhalten.

Zusammen senkten diese Änderungen die Fehlerquote des Sandbox-Feedbacks von etwa 16% auf unter 2% und reduzierten Trainingseinbrüche um eine Größenordnung. Der Befund verdeutlicht außerdem eine praktische Einschränkung beim Training agentischer Coding-Systeme: Die Reward-Qualität hängt vom umgebenden Ausführungssystem ab, nicht nur von Modellarchitektur oder Optimierungsmethode.

Asymmetrisches PPO und dreistufige Rewards

Die Forschenden entschieden sich für PPO mit GAE anstelle von kritikfreien Trajektorienmethoden, weil Produktions-Harnesses Sitzungen in strukturell unterschiedliche Samples aufteilen, was Gruppen-Baselines erschwert.

Das Trainingssetup nutzt ein asymmetrisches Actor–Critic-Design. Der Critic erhält privilegierten Trainingskontext, darunter Rewards, Tests, Coverage, Patches, Metadaten und zukünftige Turns. Der Actor sieht nur den Rollout-Zustand. Der Critic und der zusätzliche Kontext werden bei der Inferenz verworfen.

Rewards sind in drei Stufen organisiert. Core Task Scores verlangen, dass alle fail_to_pass- und pass_to_pass-Tests bestanden werden. Standard Behavior Constraints bestrafen Duplikation, ungültige Tool-Aufrufe und Debug-Überreste. Failed Trajectory Incentives bewerten den Dateiaufruf über F2 und vergeben Teilpunkte für Tests.

Fünf Experten werden durch Multi-Teacher On-Policy Distillation kombiniert, unter Verwendung von reverse KL, einem Off-Policy-Start und driftbewusster Trunkierung aus Prune-OPD.

Benchmark-Ergebnisse

Unter einem einheitlichen Claude Code Harness führte KAT-Coder-V2.5 sein Vergleichsfeld auf PinchBench mit einem Wert von 94.9 an, vor Opus 4.8 mit 93.5. Auf SWE-Bench Pro belegte es mit 65.2 gegenüber 69.2 den zweiten Platz, ebenso auf dem internen KAT Code Bench mit 53.1 gegenüber 57.3.

Auf Terminal-Bench 2.1 schnitt das Modell schwächer ab und landete mit 60.7 auf dem letzten Platz, hinter GLM-5.1 mit 61.8 und Opus 4.8 mit 84.6. Auf SciCode erzielte es 50.3 und lag damit gleichauf mit GLM-5.2. Die gemischten Ergebnisse machen Harness und Benchmark-Umfang für die Interpretation wichtig, da Repository-Patching, Terminal-Bedienung und wissenschaftliche Coding-Tests unterschiedliche Teile eines agentischen Coding-Systems messen.

KAT-Coder-V2.5-Dev, die Open-Weight-Variante, ist ein separates 35B-total / 3B-active MoE-Modell, das auf Qwen3.6-35B-A3B mit 127K SFT-Beispielen nachtrainiert und anschließend per Reinforcement Learning weiter trainiert wurde. Es wurde nach einem separaten internen Protokoll evaluiert, sodass seine Ergebnisse nicht mit der wichtigsten Benchmark-Tabelle des Flaggschiffmodells vergleichbar sind.

Zu den zentralen Materialien des Projekts gehören das Paper, die StreamLake-Produktseite und die KAT-Coder-V2.5-Dev-Modellgewichte auf Hugging Face.