Das Vorhersagen von Befehlsausgaben hilft beim späteren Training des Agenten
Ein Agent, der im Terminal arbeitet, versucht, ein Programm auszuführen. Er sendet einen Befehl, liest eine Fehlermeldung und wählt die nächste Aktion. Dabei muss er die Ausgabe mit dem vorherigen Befehl verknüpfen: erkennen, ob eine Datei, Speicher oder das richtige Argument fehlte. Davon hängt ab, ob der nächste Versuch die Situation verbessert.
Ein solcher Agent lässt sich anhand von Aufzeichnungen der Arbeit eines leistungsfähigeren Modells trainieren. Die Aufzeichnung enthält sowohl Befehle als auch Antworten des Terminals, doch das Training bewertet gewöhnlich nur die Vorhersage des vom Agenten geschriebenen Textes. Werkzeugantworten stehen als Kontext für spätere Entscheidungen zur Verfügung. Das Modell muss jedoch nicht selbst vorhersagen, welche Antwort auf einen bestimmten Befehl folgen wird.
Nachdem der Agent Demonstrationen nachgeahmt hat, kann er durch eigene Versuche weiterlernen. Zwei Modelle, die erfolgreiche Aktionen gleich gut reproduzieren, können jedoch unterschiedlich auf neue Situationen reagieren. Eine Bewertung unmittelbar nach dem Lernen aus Demonstrationen zeigt deshalb möglicherweise nicht, welches Modell der bessere Ausgangspunkt für weiteres Training ist.
Diesen Zusammenhang untersucht Don't Mask the Environment: Observation Supervision Changes How Agents Explore Under RL. Der Preprint vom 17. September 2026 behandelt das Training von Agenten auf Basis von Sprachmodellen. Juzheng Zhang, Disha Makhija, Manoj Ghuhan Arivazhagan, Vinayshekhar Bannihatti Kumar und Rashmi Gangadharaiah schlagen ActObs vor: Beim Lernen aus Demonstrationen sagt das Modell auch die Antworten der Umgebung voraus, im Folgenden Beobachtungen genannt. Der spätere Algorithmus zum Lernen durch Belohnungen bleibt derselbe.
Eine Terminalantwort kann Kontext oder Trainingsziel sein
Das Lernen aus vorhandenen Demonstrationen ist hier eine Variante des überwachten Fine-Tunings, kurz SFT: Die Aufzeichnung zeigt dem Modell den gewünschten Ablauf, und das Training passt seine Parameter an. Der Text wird in Tokens zerlegt, also in Einheiten, die das Modell verarbeitet. An jeder bewerteten Position muss das Modell anhand des vorherigen Textes das nächste Token vorhersagen.
Loss Masking legt fest, welche Positionen die Verlustfunktion beeinflussen, also die numerische Bewertung des Fehlers, mit der die Parameter verändert werden. In der Variante ActionSFT werden die Tokens des Agenten bewertet, einschließlich seiner Überlegungen und Befehle. Die Tokens der Terminalantworten bleiben in der Sequenz, sind aber keine Vorhersageziele. Ihr Ausschluss vom Verlust entfernt sie nicht aus dem Kontext.
ActObs bezieht beide Gruppen in den Verlust ein. Das Modell lernt, einen Befehl vorherzusagen und anschließend den Text der Werkzeugantwort auf diesen Befehl. Die anfängliche Aufgabenanweisung bleibt von der Bewertung ausgeschlossen. Im tatsächlichen Betrieb stammt die Antwort weiterhin vom Werkzeug; ActObs ersetzt die Ausführung des Befehls nicht durch einen vom Modell erfundenen Text.
Zur Bewertung der Vorhersage dient die Kreuzentropie: Je geringer die Wahrscheinlichkeit ist, die das Modell dem in der Demonstration enthaltenen Token zugewiesen hat, desto höher ist die Strafe. In der grundlegenden ActObs-Variante hat jedes Aktions- und Beobachtungstoken dasselbe Gewicht. Der Mittelwert wird über alle bewerteten Tokens berechnet, nicht über gleich gewichtete Gruppen von „Befehlen“ und „Antworten“. Eine längere Terminalantwort trägt daher mehr Terme zum Verlust bei. Diese Normalisierung ist in Gleichung 1 der Arbeit festgelegt.
Dieselben zwei Befehle ergeben drei oder fünf Vorhersageziele
Das folgende Beispiel wurde zur Erklärung der Methode erstellt und stammt nicht aus dem Experiment. Der Nutzer bittet darum, eine in einer Datei gespeicherte Zahl auszulesen. Ein kleines Werkzeug unterstützt zwei Befehle: list liefert den Dateinamen, und read liest die angegebene Datei. Die Demonstration enthält:
Agent: list
Werkzeug: report.csv
Agent: read report.csv
Werkzeug: 42
Für die Berechnung nehmen wir eine hypothetische Aufteilung des Textes in Tokens an (einen Tokenizer), bei der list, read, report.csv und 42 jeweils ein einzelnes Token sind. Wir lassen die Rollenmarkierungen weg. Die Sequenz enthält fünf Positionen: drei gehören zum Agenten, zwei zum Werkzeug. report.csv kommt zweimal vor und belegt jedes Mal eine eigene Position.
ActionSFT bewertet die Vorhersage von list und später von read sowie dem Argument report.csv. Jede dieser drei Positionen trägt 1/3 zum mittleren Verlust bei. Beide Werkzeugantworten haben das Gewicht null. Das Modell sieht das erste report.csv, bevor es den Befehl read vorhersagt, wird aber nicht dafür bewertet, diesen Namen als Ergebnis von list vorherzusagen.
ActObs verarbeitet genau dieselbe Aufzeichnung, bewertet jedoch alle fünf Positionen, jede mit einem Anteil von 1/5. Der erste Unterschied entsteht bei der Antwort auf list: Das Modell erhält nun ein Trainingssignal für die Vorhersage von report.csv. Der zweite entsteht bei 42, das es nach read report.csv vorhersagen soll. In beiden Fällen sieht es nur den vorherigen Teil der Aufzeichnung, und während des Trainings erhalten die nachfolgenden Positionen den tatsächlichen vorherigen Text der Demonstration.
Die Befehle entsprechen der Menge der Aktionstokens im Algorithmus, die Werkzeugausgaben der Menge der Beobachtungstokens. Ihr Anteil am Verlust verändert sich; kein Teil der Demonstration wird erneut gezogen oder entfernt. Das Signal an der Ausgabe von read verlangt, die Vorhersage an die Wirkung des vorherigen Befehls anzupassen. Das bedeutet nicht, dass das Modell beliebige Inhalte einer ungelesenen Datei kennen kann: Unvorhersehbare Informationen können weiterhin zu Fehlern führen.
Fünf Tokens und zwei Aufrufe sind lediglich eine didaktische Vereinfachung. In der Studie enthalten die Sequenzen Überlegungen, vollständige Befehle und lange Terminalantworten. ActObs fügt keine gesonderten Demonstrationen oder Modelldurchläufe hinzu, weil Werkzeugantworten bereits als Kontext verarbeitet wurden. Das gesamte Training umfasst weiterhin das Sammeln von Demonstrationen und die spätere Ausführung von Aufgaben durch den Agenten; das Budget ist unten angegeben.
Der Vorteil zeigte sich nach demselben GRPO-Training
Nach dem SFT setzten die Autoren GRPO ein, einen Algorithmus des verstärkenden Lernens (RL), der die Belohnungen einer Gruppe von Versuchen zur Lösung derselben Aufgabe vergleicht. Ein Versuch umfasst hier die gesamte Interaktion mit dem Terminal, also einen Rollout. Ein automatischer Prüfer vergibt eine Belohnung für die Erledigung der Aufgabe. In dieser Phase haben beide Modelle denselben Algorithmus, dieselben Daten und dasselbe Budget; ActObs fügt keinen Verlust für die Vorhersage von Umgebungsantworten mehr hinzu.
pass@k bezeichnet die Wahrscheinlichkeit, unter einer vorgegebenen Anzahl von Versuchen mindestens eine korrekte Ausführung zu erhalten; ein höherer Wert ist besser. pass@1 bezieht sich auf einen einzelnen Versuch, obwohl sich dessen Erfolgsquote anhand vieler Durchläufe schätzen lässt.
Das deutlichste Transferergebnis betrifft Qwen3-4B auf aider-polyglot, einem Satz von Aufgaben zur Codebearbeitung in mehreren Programmiersprachen, die durch Unit-Tests geprüft werden. Nach demselben GRPO-Zeitplan erreichte das endgültige Modell mit ActionSFT als Ausgangspunkt 9,7% pass@1, das Modell mit ActObs als Ausgangspunkt 13,9%. Der Unterschied betrug 4,2 Prozentpunkte. Die Aufgaben dieser Evaluation kamen weder in den SFT-Demonstrationen noch im GRPO-Training vor. Vor GRPO hatte die Variante ActionSFT in dieser Evaluation den höheren Wert. pass@1 wurde anhand von vier Versuchen pro Aufgabe geschätzt; es wurde nicht die beste der vier Antworten ausgewählt.
Ein separates Experiment mit dem größeren Qwen3-8B auf Terminalaufgaben zeigte einen Zielkonflikt: ActObs verschlechterte das Ergebnis eines einzelnen Versuchs, erhöhte aber die Erfolgswahrscheinlichkeit bei mehreren Versuchen. Es war somit nicht bei jedem Budget durchgehend die bessere Initialisierung. Das ist ein wichtiger Unterschied zwischen einem System, das eine Aufgabe einmal ausführen muss, und einem System, das Versuche wiederholen und ihre Ergebnisse prüfen kann.
Einzelheiten zum Experiment
Quelle der Konfiguration und Ergebnisse: §3.1, Tabelle 1 und Anhänge A–B des Preprints v1. Die Hauptvergleiche beziehen sich auf die endgültigen Checkpoints, also gespeicherte Parameterversionen nach demselben Trainingszeitplan. Die Autoren beschreiben sie als endgültige Policies und vergleichen den Zustand nach Abschluss des Trainings; die folgenden Zahlen sind keine von einer Trainingskurve abgelesenen Höchstwerte.
SFT. Qwen3-4B und Qwen3-8B wurden auf 50 Tausend Aufzeichnungen mehrstufiger Terminalarbeit aus dem synthetischen Teil des Nemotron-Terminal-Corpus trainiert. Die Demonstrationen wurden von DeepSeek-V3.2 erzeugt. Der Korpus enthielt 0,71 Milliarden Tokens, von denen etwa 45% Beobachtungen waren. Das Training dauerte eine Epoche, 781 Schritte, mit 64 Beispielen pro Batch (Batch Size) und einem maximalen Koeffizienten für die Schrittweite der Parameteraktualisierung (Learning Rate) von 0,00001, der nach einem Kosinus-Zeitplan verringert wurde. Die grundlegende ActObs-Variante verwendete ein Beobachtungsgewicht von 1, ActionSFT eines von 0. Die Normalisierung umfasste die Anzahl der Aktionstokens und die gewichtete Anzahl der Beobachtungstokens.
GRPO. Es folgten 135 Schritte auf 2392 Aufgaben von Endless Terminals, die sich nicht mit dem SFT-Korpus überschnitten. Verwendet wurden 16 Rollouts pro Aufgabe, eine Batch Size von 32, eine Learning Rate von 0,000001 und binäre Prüfer. Die Evaluationssätze überschnitten sich mit keiner der beiden Trainingsphasen. Diese Rollouts sind nicht mit den zwei Aufrufen des kleinen Werkzeugs im Beispiel zu verwechseln.
Terminalevaluation. Terminal-Bench 2.0 enthielt 89 Aufgaben. Jeder Hauptcheckpoint wurde in 16 Versuchen pro Aufgabe bewertet, gesammelt in vier separat gestarteten Paketen mit jeweils vier Versuchen. Verwendet wurden der Agent terminus-2, die offiziellen Zeitlimits und eine gemeinsame Konfiguration zur Bereitstellung der Modelle: eine vLLM-Engine auf acht A100-GPUs, 12 parallele Versuche, ein Kontext von 40 960 Tokens und eine GPU-Speichernutzung von 0,90. Die Temperatur, ein Parameter, der die Zufälligkeit der Tokenauswahl beeinflusst, betrug 0,6. Top-p beschränkte die Auswahlmenge auf Tokens mit einer Gesamtwahrscheinlichkeit von mindestens 0,95, Top-k auf die 20 wahrscheinlichsten Tokens. Modellfehler erhielten null; bei Infrastrukturfehlern wurde der Versuch einmal wiederholt. Die Konfiguration zur Bereitstellung der Modelle wurde nach dem Vergleich von neun Einstellungen festgelegt und anschließend für alle Methoden verwendet.
Evaluation der Codebearbeitung. Aider-polyglot umfasste 225 Aufgaben in sechs Programmiersprachen mit jeweils vier Versuchen pro Aufgabe. Die oben genannte Konfiguration zur Bereitstellung der Modelle betrifft Terminal-Bench 2.0; sie sollte nicht automatisch der aider-Evaluation zugeschrieben werden.
Jede folgende Zeile vergleicht ActionSFT→GRPO mit ActObs→GRPO unter derselben Einstellung. Die Tabelle enthält die Hauptergebnisse des gewöhnlichen GRPO, ohne die Variante ECHO, die auch während RL die Vorhersage von Beobachtungen hinzufügt.
| Modell und Evaluation | Metrik | ActionSFT→GRPO | ActObs→GRPO |
|---|---|---|---|
| Qwen3-4B, aider-polyglot, 4 Versuche pro Aufgabe | pass@1 | 9,7 ± 0,6% | 13,9 ± 0,7% |
| Qwen3-4B, aider-polyglot, 4 Versuche pro Aufgabe | pass@4 | 20,4 ± 0,9% | 25,3 ± 1,0% |
| Qwen3-4B, Terminal-Bench 2.0, 16 Versuche pro Aufgabe | pass@1 | 5,6 ± 0,4% | 7,2 ± 0,4% |
| Qwen3-4B, Terminal-Bench 2.0, 16 Versuche pro Aufgabe | pass@16 | 18,0 ± 1,4% | 19,1 ± 1,4% |
| Qwen3-8B, Terminal-Bench 2.0, 16 Versuche pro Aufgabe | pass@1 | 12,3 ± 0,5% | 11,0 ± 0,5% |
| Qwen3-8B, Terminal-Bench 2.0, 16 Versuche pro Aufgabe | pass@16 | 23,6 ± 1,2% | 27,0 ± 1,3% |
Für Qwen3-4B auf aider-polyglot lag pass@1 vor RL bei 1,4 ± 0,3% nach ActionSFT und bei 1,0 ± 0,3% nach ActObs. Der spätere Vorteil von ActObs war also nicht einfach die Bewahrung eines besseren Ausgangsergebnisses.
Die Werte nach dem Zeichen ± bezeichnen einen Standardfehler, geschätzt durch Bootstrapping: 20 Tausend erneute Ziehungen von Versuchen bei unverändertem Aufgabensatz. Sie messen die Unsicherheit aufgrund der begrenzten Anzahl von Agentendurchläufen. Sie messen nicht die Unterschiede zwischen unabhängigen Trainingsläufen oder zwischen verschiedenen Aufgabensätzen. pass@k wurde mit einem Schätzer berechnet, der die Anzahl der Erfolge in den verfügbaren Versuchen berücksichtigt.
Kontrollen und Diagnostik. Die Variante Obs→Act lernte zunächst nur die Vorhersage von Beobachtungen und danach nur Aktionen; sie benötigte zwei Epochen und reproduzierte den Vorteil des gemeinsamen Lernens bei größeren Versuchsbudgets nicht. Das Vertauschen der Antworten zwischen Demonstrationen verschlechterte die Ergebnisse nach SFT. Dies sind separate Kontrollen und keine weiteren Hauptergebnisse von GRPO. Die Gradientenanalyse verwendete 256 zurückgehaltene Demonstrationen, die Bewertung der Beobachtungsvorhersage 300 Aufzeichnungen aus dem Validierungsteil des Korpus. Die Messungen der Entropie, einem Maß für die Streuung der Wahrscheinlichkeiten des nächsten Tokens, an den endgültigen Modellen umfassten jeweils 200 Evaluationsaufzeichnungen. In der Kontrolle zur Angleichung der Entropie wurde die Temperatur von ActionSFT→GRPO von 0,6 auf 0,64 erhöht; das beseitigte den Unterschied bei pass@16 auf Qwen3-8B nicht.
ActObs bewahrt die Vorhersage von Auswirkungen und mehr Befehlsvarianten
Die Autoren prüften, wie die Modelle nach SFT Terminalantworten in zurückgehaltenen Demonstrationen vorhersagten. ActionSFT verschlechterte diese Fähigkeit gegenüber dem Modell vor SFT, während ActObs sie bewahrte und verbesserte. Der Effekt umfasste den tatsächlichen Inhalt der Ausgaben, einschließlich Fehlern und Shell-Meldungen, und nicht nur die sich wiederholende Kopfzeile einer Werkzeugantwort.
Die Gradientendiagnostik, also die Untersuchung der aus dem Verlust folgenden Richtungen der Parameteränderungen, hilft zu erklären, warum das Lernen von Befehlen allein dies nicht sicherstellte. Während SFT stimmte die Richtung, die die Aktionsvorhersage verbesserte, schnell nicht mehr mit der Richtung überein, die die Beobachtungsvorhersage verbesserte. ActionSFT ließ das zweite Signal aus. ActObs berücksichtigte es während des gesamten Trainings, obwohl die direkten Ergebnisse bei der Aufgabenausführung nach SFT ähnlich blieben.
Nach GRPO bewahrte ActObs eine höhere Entropie, also eine größere Streuung der Wahrscheinlichkeiten des nächsten Tokens. Der Unterschied war besonders an späteren Positionen im Befehl sichtbar, wo Argumente, Optionen und Pfade vorkommen. Mehr solcher Varianten blieben bei der zufälligen Auswahl des nächsten Versuchs verfügbar. Das bedeutet nicht, dass der Agent mehr vollständig unterschiedliche Strategien entdeckte: Die Analyse erfolgreicher Ausführungen zeigte hauptsächlich Unterschiede in der Umsetzung ähnlicher Abläufe.
Diese Messungen stützen eine Erklärung, die mit der Bewahrung nützlicher Alternativen zusammenhängt, beweisen aber nicht, dass die Entropie allein für die Verbesserung verantwortlich ist. Die Erhöhung der Zufälligkeit des ActionSFT-Modells auf ein ähnliches Niveau reproduzierte das Ergebnis von ActObs nicht. Die kontrollierte Änderung der Maske zeigt den Einfluss des SFT-Ziels auf spätere Ergebnisse; die vollständige Kette von der Beobachtungsvorhersage bis zu einer konkreten erfolgreichen Aktion bleibt eine durch die Diagnostik gestützte Interpretation.
Bewerte die Initialisierung nach dem weiteren Training und mit dem vorgesehenen Versuchsbudget
Die Studie betrifft eine Modellfamilie in zwei Größen, Demonstrationen eines einzigen Modells und das Training im Terminal. Der Transfer zur Codebearbeitung erweitert den Umfang der Evaluation, bestätigt aber nicht, dass die Methode in einem Browser, einer grafischen Oberfläche oder der Robotik funktioniert. Die Autoren legen auch Unterschiede zwischen den Umgebungen der Phasen offen: Während RL wurden Befehle in einer frischen, nicht interaktiven Shell ausgeführt, während die Terminalevaluation eine dauerhafte tmux-Sitzung verwendete. Die Methodenvergleiche innerhalb der jeweiligen Phase waren kontrolliert, doch solche Unterschiede können die absoluten Ergebnisse verändern. Die Autoren kündigen an, Code und detaillierte Artefakte nach Annahme der Arbeit zu veröffentlichen.
Die Bewertung von SFT sollte die Wirkung des späteren RL berücksichtigen, weil ein ähnliches Ergebnis nach den Demonstrationen keine ähnliche Wirkung des weiteren Trainings garantiert. Ein eigener Test von ActObs sollte dieselben Daten und dasselbe Budget beibehalten und die Modelle anschließend nach dem gesamten geplanten Training vergleichen. Da das größere untersuchte Modell bei mehreren Versuchen auf Kosten des einzelnen Versuchs gewann, müssen beide Ergebnisse und die Kosten der Wiederholungen gemessen werden; pass@k löst nicht das Problem, zu erkennen, welcher Versuch korrekt endete.
Quelle: Juzheng Zhang und Mitautoren, Don't Mask the Environment: Observation Supervision Changes How Agents Explore Under RL, arXiv:2609.20715v1, 2026. Polnische Besprechung auf Grundlage des vollständigen Textes, der unter der Lizenz CC BY 4.0 veröffentlicht wurde.
Ich nutze KI-generierte Inhalte als Teil meines täglichen Lernprozesses.