Selbstoptimierende KI-Agenten gelten als nächster Schritt nach dem klassischen Prompting: Systeme, die ihre eigenen Anweisungen, Abläufe oder Werkzeuge iterativ anpassen, um bei einer Aufgabe besser zu werden. In Benchmarks – also standardisierten Testsammlungen, an denen Modelle verglichen werden – sehen die Ergebnisse oft beeindruckend aus. Eine Untersuchung von Google-Forschern legt nun nahe, dass ein Teil dieser Verbesserung weniger mit echtem Können zu tun hat als mit Auswendiglernen.

Die Forscher beschreiben mit RRSI einen Ansatz, der genau diesen Effekt sichtbar macht und gezielt bremst. Der Befund: Agenten, die sich über viele Runden selbst verbessern dürfen, passen sich stark an die konkreten Testaufgaben an. Auf Aufgaben, die sie zuvor nicht gesehen haben, fallen sie dagegen zurück.

Memorieren statt Generalisieren

Der Unterschied zwischen Memorieren und Generalisieren ist für den Praxiseinsatz zentral. Memorieren heißt: Das System findet eine Lösung, die exakt für die vorliegenden Testfälle funktioniert – etwa eine sehr spezifische Prompt-Formulierung oder eine fest verdrahtete Abfolge von Schritten. Generalisieren heißt: Das System entwickelt ein Vorgehen, das auch bei abweichenden, neuen Aufgaben trägt.

Der Selbstverbesserungsprozess belohnt zunächst das Erste. Wer ausschließlich am Ergebnis einer festen Aufgabensammlung optimiert, erhält einen Agenten, der auf dieser Sammlung glänzt. Die Kennzahl steigt – die tatsächliche Einsatzfähigkeit nicht zwingend mit.

Laut der Untersuchung verbessert RRSI die Leistung auf ungesehenen Benchmarks um bis zu 4,7 Punkte. Gleichzeitig sinkt der Token-Verbrauch um rund 30 Prozent. Tokens sind die Texteinheiten, nach denen Sprachmodelle abgerechnet werden – weniger Tokens bedeuten in der Regel direkt geringere Betriebskosten und kürzere Laufzeiten.

Warum das für Coding-Agenten relevant ist

Coding-Agenten sind derzeit einer der häufigsten produktiven Anwendungsfälle: Systeme, die Tickets abarbeiten, Tests schreiben, Abhängigkeiten aktualisieren oder Refactorings vorbereiten. Gerade hier ist die Lücke zwischen Testergebnis und Alltag groß.

Ein Agent, der auf einem bekannten Beispiel-Repository hervorragende Werte erzielt, trifft im realen Projekt auf eine andere Welt: gewachsene Codebasis, firmeneigene Konventionen, unvollständige Dokumentation, Altlasten. Wenn die Stärke des Agenten im Wesentlichen aus der Anpassung an bekannte Aufgaben stammt, bricht die Leistung genau dort ein, wo sie gebraucht wird.

Das Muster lässt sich auf andere Agenten-Einsätze übertragen: Rechnungsprüfung, Textklassifikation, Datenmigration, Supportvorqualifizierung. Überall dort, wo Sie einen Agenten anhand einer überschaubaren Menge von Beispielfällen justieren, besteht das Risiko, dass das System die Beispiele lernt und nicht die Aufgabe.

Was Unternehmen daraus ableiten können

Die Konsequenz ist weniger technisch als organisatorisch. Es geht um die Art, wie Sie Agenten bewerten, bevor Sie ihnen Verantwortung übertragen.

  • Testdaten trennen. Die Fälle, an denen ein Agent optimiert wird, dürfen nicht dieselben sein, an denen er abgenommen wird. Halten Sie einen Satz an Aufgaben zurück, den weder Entwicklungsteam noch Agent während der Optimierung sehen.
  • Auf ungesehenen Fällen messen. Eine Erfolgsquote ist nur dann aussagekräftig, wenn sie auf neuen Aufgaben erhoben wurde. Werte aus dem Optimierungslauf selbst taugen nicht als Abnahmekriterium.
  • Kosten mitmessen. Token-Verbrauch, Laufzeit und Anzahl der Agentenschritte gehören in dieselbe Tabelle wie die Trefferquote. Ein Agent, der ein Prozent besser ist und doppelt so teuer, ist keine Verbesserung.
  • Aufgabenvielfalt erhöhen. Je breiter und unterschiedlicher die Fälle in der Optimierungsphase, desto schwerer lässt sich das Problem durch Auswendiglernen umgehen.
  • Nachmessen statt einmal abnehmen. Codebasen, Datenstrukturen und Geschäftsregeln ändern sich. Ein einmal erhobener Benchmarkwert altert.

Effizienz ist Teil der Qualität

Bemerkenswert an den berichteten Ergebnissen ist die Kombination: bessere Übertragbarkeit und geringerer Verbrauch. Das widerspricht der verbreiteten Annahme, dass mehr Qualität bei Agenten automatisch mehr Rechenschritte und damit höhere Kosten bedeutet.

Eine plausible Lesart: Agenten, die sich an Testaufgaben festhalten, produzieren viel Umweg – zusätzliche Versuche, redundante Zwischenschritte, immer längere Anweisungen. Ein Vorgehen, das stärker auf Übertragbarkeit zielt, kommt mit weniger Aufwand zum Ziel. Für die Budgetplanung ist das ein wichtiger Hinweis: Token-Kosten sind nicht nur eine Preisfrage, sondern auch ein Indikator dafür, wie sauber ein Agent arbeitet.

Einordnung mit Augenmaß

Es handelt sich um ein Forschungsergebnis, nicht um ein fertiges Produkt. Die genannten Werte stammen aus einem kontrollierten Setting und lassen sich nicht ungeprüft auf beliebige Unternehmensszenarien übertragen. Der methodische Kern ist aber unabhängig davon brauchbar: Trennen Sie das, woran optimiert wird, von dem, woran gemessen wird.

Für Web- und Softwareprojekte heißt das vor allem, Agenten nicht nach Demo-Eindruck einzuführen, sondern nach Ergebnissen auf Fällen, die das System vorher nicht kannte – idealerweise aus dem eigenen Projektalltag. Wer schon beim Pilotprojekt eine kleine, zurückgehaltene Testmenge aufbaut und Kosten pro Aufgabe mitprotokolliert, erkennt frühzeitig, ob ein Agent wirklich trägt oder nur gut aussieht. Das ist weniger aufwendig, als es klingt, und erspart teure Korrekturen, wenn der Agent später auf echte Tickets losgelassen wird.

Quellen