# Infrastruktur für RSI-Forschung: selbstverbessernde Agenten ausführen und bewerten

Wie Beeuni wiederholte Agentenexperimente unterstützt: Code und Anweisungen ändern, Tests ausführen, Fehler untersuchen und Versionen vergleichen.

Canonical page: https://beeuni.ai/blog/de/infrastructure-for-rsi-research

Ein Forschungsagent ändert ein Suchwerkzeug in seinem eigenen Code. Er löst eine Aufgabe, an der er zuvor gescheitert ist. Gelingt das nun auch bei anderen Aufgaben? Kann die verbesserte Version erneut eine nützliche Änderung finden? Dafür musst du Programme wiederholt bearbeiten, Experimente ausführen und Ergebnisse vergleichen. Beeuni stellt einen Computer bereit, auf dem Agenten diese Arbeit mit deinem Code, deinen Werkzeugen und Auswertungsskripten erledigen.

Rekursive Selbstverbesserung, kurz RSI, untersucht, ob ein System sich selbst verbessern kann, einschließlich der Methode für weitere Verbesserungen. In Agentenexperimenten kann es seinen Code, seine Anweisungen oder Werkzeuge ändern, die Änderung testen und mit einer erfolgreichen Version weiterarbeiten. Ein Suchwerkzeug dient hier als konkretes Beispiel dafür, wie Beeuni diesen Prozess unterstützt.

## Gib Beeuni den Code und eine konkrete Frage

Verbinde das Repository mit deinem Agenten und seinen Tests. Erkläre Beeuni die Installation, den Befehl für die Auswertung und welche Teile es ändern darf. Die erste Frage kann eng gefasst sein: Kann das Suchwerkzeug die relevante Funktion zurückgeben, ohne die ganze Datei an das Modell zu senden?

Die Forschungsfrage bestimmt, was der Agent ändern darf. Du kannst untersuchen, ob andere Anweisungen die Planung verbessern, eine neue Suche unnötiges Lesen verringert oder ein anderer Umgang mit Erinnerungen bei späteren Aufgaben hilft. Halte diese Experimente auseinander. Änderungen an Modellgewichten brauchen einen anderen Versuchsaufbau mit eigener Trainingsmethode und Rechenleistung.

```
Inspect the file-search tool in this repository.
Run the existing coding-task tests before changing it.
Try returning matching functions with their file paths and line numbers.
Keep the model and test settings unchanged.
Run the same tests again. Save the patch, raw logs, and a comparison report.
Do not change the tests or merge the code.
```

Beeuni kann die Implementierung lesen, Installationsbefehle ausführen und deine Tests im Terminal starten. Fehlt eine Abhängigkeit oder stürzt ein Test ab, kann es den Fehler untersuchen. Du kannst die Arbeit in der Session verfolgen und die erzeugten Dateien öffnen.

## Führe erst das ursprüngliche Werkzeug aus

Lass Beeuni zunächst den unveränderten Agenten ausführen. Speichere, welche Aufgaben bestanden wurden, welche fehlschlugen und welche Fehler auftraten. Falls dein Testprogramm Modellnutzung, Tool-Aufrufe oder Laufzeit erfasst, nimm diese Angaben dazu. Damit hast du konkrete Ergebnisse zum Vergleichen.

Lass den Agenten danach das Suchwerkzeug ändern und denselben Befehl erneut ausführen. Behalte Modell, Aufgabenliste und Limits bei. Lass ihn jede Ergebnisänderung anhand des passenden Logs erklären. Weniger Tokens sind interessant. Untersuche aber auch neu fehlgeschlagene Aufgaben, bei denen das kürzere Suchergebnis wichtigen Code ausgelassen hat.

| Anzufordernde Datei | Was du prüfen kannst |
| --- | --- |
| Code-Patch | Was sich am Suchwerkzeug genau geändert hat |
| Ergebnisse vor und nach der Änderung | Welche Aufgaben besser, schlechter oder unverändert sind |
| Unveränderte Testlogs | Den tatsächlichen Fehler hinter einem Fehlschlag |
| Befehle und Einstellungen | Wie du das Experiment wiederholen kannst |

Du stellst die Aufgaben und Bewertungsskripte bereit. Der Agent führt sie aus und erstellt die Dateien für deinen Vergleich. Was als Verbesserung zählt, legst du mit deinem Experiment fest; Beeuni liefert dafür keinen eigenen Forschungsbenchmark.

## Nutze Fehlschläge für die nächste Änderung

Angenommen, das neue Werkzeug verarbeitet kleine Dateien gut, scheitert aber bei einer Funktion, die eine Hilfsfunktion aus einer anderen Datei aufruft. Bitte Beeuni, diesen Fall zu untersuchen, den fehlenden Kontext zu finden und eine gezielte Änderung vorzuschlagen. Vielleicht reichen die Namen verwandter Funktionen im Suchergebnis, statt wieder sämtliche Dateien vollständig zurückzugeben.

Prüfe Patch und Bericht, bevor du die Änderung übernimmst. Teste sie danach mit anderen Aufgaben. Der ursprüngliche Problemfall allein sagt weniger aus als Aufgaben, an denen der Agent seinen Code nicht wiederholt angepasst hat. Halte die Tests für die abschließende Bewertung außerhalb der Dateien, die der Agent bearbeiten darf.

Das geht auch mit einem Browser-Agenten. Gib Beeuni eine Testanwendung und die Aufgabe, eine Bestellung zu finden und deren Lieferhinweis zu ändern. Es kann den Browser bedienen, das Ergebnis prüfen und einen Fehler dokumentieren. Setze vor dem Vergleich mit einer anderen Version die Testdaten zurück, damit beide mit derselben Bestellung beginnen.

## Organisiere wiederholte Experimente mit deinem Programm

Ein Controller ist das Programm, das die Versuchsrunden organisiert. Es wählt eine Agentenversion, fordert eine Änderung an, startet Tests und entscheidet über den nächsten Versuch. Als Kandidat gilt die geänderte Version, die gerade getestet wird. Dein Controller kann Beeuni-Sessions über die [API oder das TypeScript SDK](/docs/de/sdk/sessions) starten und prüfen. Die Auswahlregeln bleiben in deinem Forschungscode.

Jede Session hat ihre eigene Ausführungsumgebung. Zwei Werkzeugimplementierungen können getestet werden, ohne dieselben Arbeitsdateien oder Abhängigkeiten zu überschreiben. Das Programm muss mit dem vorgesehenen Codestand starten. Lädt ein Skript seinen Code nur beim Start, starte es nach einer Änderung neu. Sonst testest du möglicherweise noch die alte Implementierung.

Beginne mit einer kleinen Warteschlange von Experimenten. Begrenze im Controller Versuche, gleichzeitige Sessions, Laufzeit und Modellnutzung. Beim Erreichen eines Limits soll er die zugehörige Arbeit stoppen und prüfen, ob die Prozesse beendet wurden. Diese Regeln bestimmen, wie viel Suche nach Verbesserungen vor der Versionswahl zulässig ist.

## Teste jede Version unter vergleichbaren Bedingungen

Ein Agent, der die Musterlösung lesen oder die Tests ändern kann, erzielt möglicherweise mehr Punkte, ohne die Aufgabe besser zu lösen. Führe die abschließende Bewertung getrennt aus. Bewahre geheime Antworten außerhalb der Dateien auf, auf die der Agent zugreifen kann, und verhindere Änderungen am Bewertungscode. Beeuni kann Entwicklungstests ausführen und Ausgaben sammeln. Dein Auswertungsprogramm bewertet diese getrennt. Setze bei Browserexperimenten die gemeinsamen Anwendungsdaten zwischen Versionen zurück. Auch ein neuer Computer sieht die zurückgelassenen Datensätze in derselben externen Anwendung.

Vergleiche erfolgreiche Aufgaben, Fehler, Dauer sowie erfasste Tool-Aufrufe und Modellnutzung. Halte Aufgabensatz, Modelleinstellungen und Ausführungslimits vergleichbar. Wiederhole unsichere Ergebnisse. Eine Änderung kann weniger Tokens lesen, dabei aber eine Hilfsfunktion übersehen. Oder sie löst mehr Aufgaben mit erheblich mehr Modellaufrufen. Der Bericht sollte diesen Aufwand zeigen.

Erfasse auch die Kosten für das Finden der Änderung. Trenne die Versuche zum Vorschlagen und Testen von Versionen von den Ausführungskosten der ausgewählten Version. Der fertige Agent kann pro Aufgabe günstiger sein, obwohl seine Entdeckung eine teure Suche erforderte. Für die Beurteilung zählen beide Messungen.

## Bewahre genug auf, um einen gescheiterten Versuch zu erklären

Eine falsch gelöste Aufgabe und eine nicht erreichbare Modell-API verlangen unterschiedliche Reaktionen. Lass Beeuni ursprüngliche Fehler und Logs vor der Zusammenfassung sichern. Unterscheide falsche Antworten, fehlende Abhängigkeiten, gescheiterte Modellanfragen und Zeitlimits. Entscheide ausdrücklich, welche Fehler einen weiteren Versuch erhalten, statt jeden Fehlschlag still bis zum Erfolg zu wiederholen.

Speichere ursprüngliche und geänderte Codestände, Anweisungen, Startbefehle, Abhängigkeiten, Versionen von Aufgabensatz und Bewertungscode sowie Einzelergebnisse. Halte fest, von welcher früheren Version eine Änderung stammt. Beeuni kann diesen Versuchsbericht neben Patch und Logs erstellen. So kannst du nachvollziehen, warum eine Version gewählt oder verworfen wurde.

Speichere nützliche Patches und Berichte im gewählten Repository oder Speicher, bevor du den Versuchscomputer entfernst. So kannst du ein Ergebnis auf den Code und Befehl zurückführen, der es erzeugt hat. Das gilt auch für verworfene Versuche.

## Prüfe, ob auch der nächste Verbesserungsversuch besser wird

Bewerte die ausgewählte Version mit Aufgaben, die nicht zur Anpassung dienten. Lass sie anschließend weitere Verbesserungen versuchen und vergleiche diese mit denen des ursprünglichen Agenten. Findet sie unter demselben Budget häufiger nützliche Änderungen, benötigt weniger Versuche oder verursacht weniger Rückschritte? Mehr Aufgaben zu lösen ist ein Ergebnis. Ob auch das Verfahren für spätere Verbesserungen besser wird, ist die zusätzliche Frage der RSI-Forschung.

Die [Veröffentlichung zur Darwin Gödel Machine](https://arxiv.org/abs/2505.22954) untersucht Agenten, die ihren Code ändern und die Änderungen testen. [Self-Refine](https://arxiv.org/abs/2303.17651) untersucht das Überarbeiten einer Antwort anhand von Feedback, ohne zusätzliches Training. Das hilft bei der Forschungsfrage: Verbesserst du eine Antwort, die Arbeitsweise des Agenten oder seine Fähigkeit, die nächste Verbesserung zu finden? Beeuni hilft bei Codeänderungen, Befehlsausführung und Ergebnisprüfung. Du entwirfst die Forschungsmethode. Für Modelltraining lies [Fine-Tuning mit Beeuni](/blog/de/run-model-fine-tuning-with-beeuni).

Für den Versuch mit dem Suchwerkzeug reichen zunächst ein Repository und ein funktionierender Testbefehl. Der [Computer-Leitfaden](/docs/de/work/runtime) erklärt, wie du die Umgebung und Prozessausgaben während der Arbeit prüfst.