Die Kunst der langen Aufgabenläufe

Der technische Bericht zu Kimi K3 beschreibt nicht nur ein größeres Kontextfenster, sondern ein Training für lange Aktionsketten mit überprüfbaren Ergebnissen. Aber was bedeutet „Long Horizon“ in der Praxis tatsächlich? Die Länge einer Agentenaufgabe lässt sich nicht sinnvoll in Minuten allein messen. Aussagekräftiger sind abhängige Entscheidungen, Tool-Aufrufe und Zustandsänderungen. Ein Agent kann zwei Stunden lang immer denselben Fehler wiederholen oder in zehn Minuten zwanzig zielgerichtete Schritte abschließen. Das ist ein sehr großer Unterschied. Long Horizon Coding verlangt deshalb vier Fähigkeiten: Relevante Zustände über viele Schritte bewahren, Zwischenresultate prüfen, aus Rückmeldungen neue Pläne ableiten und rechtzeitig mit einem nachweisbaren Ergebnis stoppen.

Moonshot trainierte K3 auf einer allgemeinen Schleife aus Denken, Handeln, Beobachten, Verifizieren und Anpassen. Die Umgebungen umfassen Software Engineering, Webentwicklung, GPU-Kernel, multimodale Aufgaben und autonome Ausführung. Einzelne Aufgabenläufe, also vollständige Abfolgen aus Modellschritten, Tool-Aufrufen, Beobachtungen und Zustandsänderungen, enthalten laut Bericht Hunderte oder Tausende Tool-Aufrufe und umfassen insgesamt Millionen Token [Kimi Team]. „Eine Million Token Kontext“ bedeutet dabei nicht, dass die gesamte Historie unverändert in eine einzelne Anfrage passt: Ein langer Aufgabenlauf verteilt sich auf mehrere Modellaufrufe, deren Zustände erhalten und deren bisherige Inhalte bei Bedarf verdichtet werden.

Training mit echten Konsequenzen

Beim Supervised Fine-Tuning (SFT), dem überwachten Feintuning, lernt K3 zunächst aus vorgegebenen Beispielen für erwünschtes Verhalten. Moonshot ließ spezialisierte Vorgängermodelle dafür vollständige Aufgabenläufe erzeugen und prüfte sowie annotierte diese anschließend in mehreren Schritten unter menschlicher Beteiligung. So erhält das Modell eine belastbare Ausgangsbasis für Schlussfolgerungen, Tool-Aufrufe und längere Arbeitsabläufe.

Darauf baut Reinforcement Learning (RL) auf. Statt weitere Musterlösungen lediglich nachzuahmen, erzeugt das Modell eigene Lösungswege und erhält Rückmeldungen zu deren Qualität. Das Training teilt sich in drei Domänen:

• allgemeine Aufgaben wie Wissensarbeit, Suche und visuelles Schlussfolgern,
• allgemeine Agentenaufgaben wie Recherche und länger laufende Assistenz sowie
• Coding-Aufgaben aus Softwareentwicklung, Webentwicklung und GPU-Kernel-Optimierung.

Für jede Domäne entstehen drei spezialisierte Modellvarianten mit niedrigem, hohem und maximalem Denkbudget. Das Budget begrenzt, wie viele Token das Modell für seine Herleitung und bei Agentenaufgaben zusätzlich für Tool-Aufrufe verbrauchen darf. Aus drei Domänen und drei Budgetstufen ergeben sich neun Varianten.

Die Multi-Teacher On-Policy Distillation (MOPD) bündelt deren Fähigkeiten anschließend in einem gemeinsamen Modell. „Multi-Teacher“ bedeutet, dass alle neun spezialisierten Varianten als Lehrermodelle dienen. „On-Policy“ bezeichnet das Training mit Antworten, die das gemeinsame Modell selbst erzeugt: Passend zur jeweiligen Domäne und Budgetstufe bewertet das zuständige Lehrermodell dessen Token-Entscheidungen und liefert so fortlaufende Lernsignale. Das fertige Modell soll dadurch alle Spezialisierungen vereinen und über das API zwischen niedrigem, hohem und maximalem Denkbudget umschalten können.

Bei sehr langen Aufgabenläufen können einzelne Ausführungen erheblich länger dauern als andere. Moonshot setzt deshalb sogenannte partielle Roll-outs ein. Ein Roll-out bezeichnet im Reinforcement Learning einen Aufgabenlauf, bei dem das Modell schrittweise Aktionen ausführt und Rückmeldungen aus seiner Umgebung erhält. Sobald ein festgelegter Anteil dieser Aufgabenläufe abgeschlossen ist, pausiert das System die übrigen Ausführungen. Das Training kann die fertigen Ergebnisse bereits auswerten und das Modell aktualisieren, ohne auf den langsamsten Nachzügler warten zu müssen. Die pausierten Aufgabenläufe landen in einer Warteschlange und laufen in einer späteren Trainings-Iteration weiter.

Dafür muss die Infrastruktur zwei Arten von Zustand erhalten. Auf der Modellseite speichert ein externer Cache den bereits verarbeiteten Anfang des Kontexts, den sogenannten Präfix. Gemeint sind nicht nur die ursprünglichen Token, sondern auch die daraus berechneten Zwischenzustände. Das System lagert derzeit nicht benötigte Zustände aus dem GPU-Speicher in den Arbeitsspeicher der CPU aus und lädt sie vor der Fortsetzung erneut. Dadurch muss das Modell eine möglicherweise sehr lange bisherige Historie nicht vollständig neu berechnen.

Auf der Umgebungsseite führt AgentENV jede Aufgabe in einer isolierten MicroVM aus. Eine MicroVM ist eine schlanke virtuelle Maschine, die eine stärkere Trennung als ein gewöhnlicher Container bietet, aber deutlich schneller startet als eine klassische VM. AgentENV kann den Zustand einer solchen Umgebung schrittweise sichern, pausieren und später wiederherstellen. Dabei speichert es nur die seit dem letzten Sicherungspunkt veränderten Speicherseiten. Dateisystem, laufende Prozesse und weitere Bestandteile der Arbeitsumgebung bleiben dadurch über Trainingsiterationen hinweg erhalten. Die Isolation verhindert zugleich, dass aggressive oder fehlerhafte Aktionen eines Agenten andere Aufgabenläufe oder die Trainingsinfrastruktur beeinträchtigen. Zusammen bewahren Cache und Sandbox somit sowohl den Modellkontext als auch den Zustand der bearbeiteten Umgebung.

Einen besonderen Trainingsbereich bilden die Autonomous Execution Tasks, also Aufgaben zur autonomen Ausführung. Der Agent erhält einen Ausgangszustand, ein klar begrenztes Ziel, verfügbare Werkzeuge, ein Ausführungsbudget und eine unabhängige Prüfschnittstelle. Einen vorgegebenen Lösungsweg oder einen beispielhaften Aufgabenlauf bekommt er nicht. Er muss die Aufgabe selbst zerlegen, Werkzeuge auswählen, sein Vorgehen planen, Fehler beheben und entscheiden, wann die Arbeit abgeschlossen ist.

Über den Erfolg entscheidet nicht die Behauptung des Agenten, er habe die Aufgabe erledigt, sondern der messbare Endzustand der Umgebung. Ein unabhängiger Prüfmechanismus bewertet diesen Zustand und erzeugt daraus die Belohnung, also das Lernsignal für das Reinforcement Learning. Sichtbare Prüfungen liefern dem Agenten Diagnosehinweise, mit denen er seine Lösung verbessern kann. Zusätzliche verborgene Prüfungen kontrollieren zurückgehaltene Fälle, auf die sich der Agent nicht gezielt einstellen kann. Begrenzte Einreichungsbudgets und Strafen für Fehlversuche ergänzen diese Kontrolle.

Dieses Verfahren erschwert Reward Hacking. Damit ist ein Verhalten gemeint, bei dem ein Modell eine Schwachstelle im Bewertungssystem ausnutzt und eine hohe Belohnung erzielt, ohne die eigentlich beabsichtigte Aufgabe korrekt zu lösen. Das Prinzip ähnelt einer sauber aufgebauten CI-Pipeline: Nicht der Selbstbericht des Agenten zählt, sondern das Ergebnis unabhängiger und reproduzierbarer Prüfungen.

Benchmarks richtig lesen

K3 erreicht im Bericht 77,8 Prozent auf ProgramBench, 88,3 Prozent auf Terminal-Bench 2.1, 81,2 Prozent auf FrontierSWE und 42,0 Prozent auf SWE-Marathon. Damit führt es dort ProgramBench und SWE-Marathon an, liegt bei Terminal-Bench knapp hinter GPT-5.6 Sol und bei FrontierSWE hinter Claude Fable 5. DeepSWE zeigt die Grenze: 67,5 Prozent reichen nicht an GPT-5.6 Sol mit 73,0 oder Claude Fable 5 mit 70,0 heran [Hugging Face].

Diese Zahlen bilden keinen universellen Rang ab. Moonshot nutzte maximale Reasoning-Stufe und eine Temperatur-Einstellung von 1,0. Verschiedene Modelle liefen zudem in Kimi Code, Claude Code oder Codex. Harness, Systemprompt, Toolset und Abbruchregeln beeinflussen das Resultat erheblich. Für SWE-Marathon diente eine auf Nvidia H20 kalibrierte Vorabversion der Aufgaben vom 9. Juli 2026. Zudem griffen 35 Prozent der Läufe von Claude Fable 5 auf Fallbacks zurück. Seriöse Vergleiche nennen solche Bedingungen und vermeiden Aussagen wie „K3 löst 81,2 Prozent aller Softwarefehler“. Denn das ist faktisch schlicht falsch.

Auswertungen Dritter im Bericht relativieren und stützen das Bild. Artificial Analysis führte K3 am 23. Juli 2026 auf Rang vier seines Intelligence Index, Vals AI auf Rang zwei. In der WebDev Arena belegte K3 Rang eins, in der Text Arena Rang acht und in der Agent Arena Rang vier. Die besondere Stärke liegt damit in Webentwicklung und agentischer Arbeit [Kimi Team].

Vom Issue zur überprüfbaren .NET-Aufgabe

Ein geeigneter Praxistest braucht mehr als den Prompt „Optimiere das Projekt“. Nehmen wir als Beispiel eine ASP.NET-Core-Anwendung. Hier kann eine Aufgabenbeschreibung so aussehen:

Ziel: Beseitige die doppelten Datenbankabfragen im Endpunkt GET /api/orders/{id}.
Grenzen:
- Öffentliche API und Datenbankschema bleiben unverändert.
- Keine neuen NuGet-Pakete.
- Änderungen nur in src/Orders und tests/Orders.Tests.
Abnahme:
- Alle vorhandenen Tests bestehen.
- Ein neuer Integrationstest weist genau eine SQL-Abfrage nach.
- dotnet test --configuration Release ist erfolgreich.
- Abschlussbericht nennt geänderte Dateien, Messung und Restrisiken.

Diese Form erzwingt einen überprüfbaren Endzustand. Ein isolierter Arbeitszweig, eine reproduzierbare Datenbank, ein Laufzeitbudget und eine Messdatei vor und nach der Änderung ergänzen den Versuch.

Kimi Codes Zielmodus bildet dieses Muster direkt ab. /goal speichert einen gewünschten Endzustand und prüft nach jedem Turn, ob er erreicht, blockiert oder noch aktiv ist. Die Dokumentation empfiehlt ausdrücklich Ziele mit Finish Line und Belegen. Ein passender Aufruf lautet etwa:

/goal Erfülle die Abnahmekriterien in issue-142.md, führe den Release-Testlauf aus und stoppe nur bei grünem Testprotokoll oder einem präzisen dokumentierten Blocker.

Die Qualität hängt an der Prüfumgebung, denn Tests können Anforderungen unvollständig abbilden. Ein Agent kann lokalen Erfolg mit globaler Korrektheit verwechseln. Diff-Review, Sicherheitsanalyse und fachliche Abnahme gehören deshalb in die Definition of Done.

Fallstudien als Machbarkeitsnachweis

Moonshot dokumentiert mehrere Extremfälle. K3 optimierte in isolierten Sandboxes bis zu 24 Stunden lang GPU-Kernel und senkte die AttnRes-Latenz, also die Rechenzeit für den gezielten Zugriff auf Ergebnisse früherer Modellschichten, von 283,6 auf 114,4 Millisekunden. In einem 48-stündigen Lauf entwickelte es mit Kimi Code einen kleinen Inferenzchip-Prototyp, erzeugte RTL, nutzte Open-Source-EDA-Werkzeuge und prüfte Timing sowie Simulation. Ein weiteres Projekt, MiniTriton, umfasst DSL-Frontend, Optimierungsschicht, PTX-Codeerzeugung, Autograd und verteiltes Training.

Die Eigenversuche belegen lange zusammenhängende Arbeit, ersetzen aber keine unabhängige Replikation: Moonshot wählte Aufgaben, Umgebung und Erfolgsmetriken. Im Alltag zählt, ob ein Team den Erfolg objektiv prüfen, den Diff verstehen und einen fehlerhaften Lauf gefahrlos abbrechen kann. Es gilt also, einen kontrollierten Repository-Workflow aufzubauen, um mit K3 weiter in Richtung Agenten-Entwicklung zu gehen.