arXiv:2605.22794: MOSS zeigt Agenten, die sich durch Umschreiben ihres eigenen Quellcodes verbessern

Das arXiv-Preprint MOSS vom 21. Mai 2026 stellt ein Framework für autonome Agenten vor, die sich durch Umschreiben ihres eigenen Quellcodes verbessern — nicht nur durch Prompt- oder Fine-Tuning-Anpassungen. Die Autoren dokumentieren, dass ein MOSS-Agent Produktionsfehler identifiziert, die Behebung an einen Coding-Agenten delegiert, die Änderung in einer ephemeren Test-Sandbox verifiziert und erst nach Validierung mit Rollback-Mechanismus deployt. In einem autonomen Zyklus auf dem OpenClaw-Benchmark steigt der Score von 0,25 auf 0,61, verglichen mit einer Prompt-only-Baseline, die bei 0,28 verbleibt.

Wie unterscheidet MOSS strukturelle von oberflächlichen Korrekturen?

MOSS unterscheidet zwei Fehlerkategorien. Oberflächliche Fehler: falsche Prompts, schlechte Few-Shot-Beispiele oder eine zu rigide Persona — alles durch Prompt-Engineering behebbar. Strukturelle Fehler: falsche Routing-Regeln in Multi-Agent-Dispatch, fehlende Hooks für Error-Handling, unsicherer State-Zugriff in parallelen Subagenten und Logikfehler in Tool-Integrationen.

Konkret: Wenn MOSS auf einem OpenClaw-Task erkennt, dass ein Subagent halbvalide JSONs zurückgibt, öffnet er dispatch.py, fügt einen JSON-Schema-Validator mit Rollback-Semantik ein, deployt die Änderung in der Sandbox und verifiziert, dass die fehlschlagenden Szenarien nun durchlaufen.

Was ist der OpenClaw-Benchmark und warum ist 0,61 bedeutsam?

OpenClaw umfasst 240 Multi-Step-Produktionsaufgaben, die Kombinationen aus Retrieve-and-Summarize, Code-Modify und Deploy-Verify verlangen. Die Baseline von 0,25 ist für State-of-the-Art-LLM-Agenten ohne Self-Improvement-Loop erwartet. Ein Score von 0,61 nach einem MOSS-Zyklus bedeutet, dass 87 zusätzliche Aufgaben von 240 nun erfolgreich gelöst werden.

Die Autoren betonen: MOSS hat keinen „magischen Trick” gefunden — Korrekturen sind konkret und auditierbar. Eine typische Korrektur umfasst 15–40 Zeilen Python-Code, dauert 2–8 Minuten Wall-Clock-Zeit und hinterlässt eine für menschliche Reviewer lesbare Git-Commit-Geschichte.

Welche Sicherheitsrisiken gibt es und wie begegnet MOSS ihnen?

Jede Änderung durchläuft eine ephemere Test-Sandbox ohne Zugriff auf echte Daten. Ein Pre-Deploy-Regressionstest muss bestanden werden — er wächst automatisch mit jedem von MOSS gelösten Szenario. Post-Deploy aktiviert Rollback bei neuen Regressionen. Alle Änderungen werden mit detaillierten Commit-Nachrichten in Git eingecheckt.

Die Autoren erkennen ein offenes Problem: Wenn ein Agent seinen Code ändern kann, kann kein Reviewer jede Iteration in Echtzeit verfolgen. Sie empfehlen ein wöchentliches Oversight-Gate, bei dem kumulierte Änderungen menschlich geprüft werden, bevor sie in den stabilen Branch einfließen.