Microsoft Research hat am 7. Oktober 2026 Agent Lightning v1.0 vorgestellt. Das Open-Source-System trainiert Sprachmodelle per Reinforcement Learning, während der Coding-Agent mit seinem bisherigen Harness arbeitet. In einem veröffentlichten Experiment stieg die Erfolgsquote von Qwen3.5-9B auf SWE-bench Verified von 41,8 auf 56,4 Prozent. Das sind 14,6 Prozentpunkte bei ungefähr 6.000 Trainingsbeispielen. Die Zahlen stammen aus Microsofts eigener Evaluation.
Der Agent behält seine Tool- und Kontextlogik
Klassische Agent-RL-Frameworks steuern die gesamte Interaktionsschleife selbst: Modellaufruf, Tool-Aktion, Rückgabe und nächste Entscheidung. Wer einen bestehenden Coding-Agenten trainieren wollte, musste dessen Ablauf häufig im Trainingssystem nachbauen. Damit konnten sich Training und späterer Einsatz in Details unterscheiden.
Agent Lightning setzt einen OpenAI-kompatiblen LLM-Proxy zwischen Harness und Modell. Der Harness führt weiter seine gewohnten Tools aus, verwaltet Kontext und startet gegebenenfalls Subagenten. Das Trainingssystem beobachtet die Modellaufrufe und ordnet sie einem Rollout zu. Die neue Version umfasst nach Microsofts Angaben etwa 3.500 Zeilen Kerncode.
Drei Komponenten teilen die Arbeit: Ein API-Gateway verwaltet Rollouts und Modellaufrufe. Ein Rollout-Controller startet Agenten als lokale Prozesse oder Kubernetes-Jobs. Ein auf verl aufbauender Trainer verarbeitet die aufgezeichneten Samples und aktualisiert das Modell.
Kontextkompression verändert die Statistik des Trainings
Der Ansatz erzeugt ein Problem, das in einem einfachen Chat-Trainingsloop kaum sichtbar wird. Ein Agent kann denselben Auftrag in viele Modellaufrufe zerlegen, den Kontext zwischendurch zusammenfassen oder Subagenten einsetzen. Die Anzahl der Trainingssamples hängt damit auch vom Harness ab.
Microsoft beschreibt vier Folgen: Token-Grenzen können sich beim erneuten Tokenisieren verschieben; Rollouts mit vielen Teilaufrufen können bei der Advantage-Berechnung übergewichtet werden; dasselbe gilt für die Loss-Normalisierung; außerdem ist die tatsächliche Sample-Länge vor Ende des Agentenlaufs unbekannt.
Die Implementierung berechnet deshalb Vorteile und Normalisierung auf Rollout-Ebene. Microsoft berichtet, dass diese Kombination in den eigenen Experimenten stabilere Policy-Entropie und höhere Validierungswerte erzielte als eine reine Sample-Betrachtung.
Rollouts und Modellupdates teilen GPUs
Mit „Collocated Async RL“ lässt Agent Lightning mehrere Agentenläufe asynchron arbeiten, nutzt für Training und Inferenz aber denselben GPU-Pool. Sobald genügend Rollouts vorliegen, nimmt das Gateway vorübergehend keine neuen Requests an, lässt laufende Requests auslaufen und startet das Modellupdate. Microsoft misst dafür in seinen Tests ungefähr die doppelte End-to-End-Geschwindigkeit gegenüber synchronem RL.
Die Architektur ist öffentlich dokumentiert und der Code verfügbar. Eine unabhängige Reproduktion der 14,6 Punkte oder des zweifachen Geschwindigkeitsgewinns liegt bislang nicht vor. Für Teams mit eigenen Agent-Harnesses ist vor allem die Trennung zwischen Ausführungsumgebung und Trainer prüfbar: Sie müssen den Agenten nicht ein zweites Mal als Trainingssimulation implementieren. Kubernetes-Jobs ersetzen dabei keine Sicherheitsprüfung der Agentenberechtigungen.
Quellen: Microsoft Research, 7. Oktober 2026, https://www.microsoft.com/en-us/research/blog/agent-lightning-v1-0-a-3500-line-lightweight-agentic-rl-framework-for-training-agents-with-real-harnesses/ ; Quellcode: https://github.com/microsoft/agent-lightning