Google erklärt die Bewertungsschleife von Agents CLI und warnt vor Gesamtwerten
Der Entwicklerblog von Google hat am 28. Oktober 2026 eine Anleitung zu den Bewertungsbefehlen von Agents CLI veröffentlicht, einem Werkzeug zum Bauen von KI-Agenten. Der Beitrag nutzt einen kleinen Demo-Agenten, um eine Schleife zu zeigen: Testfälle ausführen, Ergebnisse bewerten, Läufe vergleichen und aus dem Unterschied handeln. Die zentrale Warnung lautet, dass ein Gesamtwert täuschen kann und Teams deshalb die Ergebnisse je Fall lesen sollten.
Der Entwicklerblog von Google hat am 28. Oktober 2026 eine Anleitung zu den Bewertungsbefehlen von Agents CLI veröffentlicht, einem Werkzeug zum Bauen von KI-Agenten. Der Beitrag nutzt einen kleinen Demo-Agenten, um eine Schleife zu zeigen: Testfälle ausführen, Ergebnisse bewerten, Läufe vergleichen und aus dem Unterschied handeln. Die zentrale Warnung lautet, dass ein Gesamtwert täuschen kann und Teams deshalb die Ergebnisse je Fall lesen sollten. Die verglichenen Bewertungen stammen aus einer Demo mit vier Fällen, nicht aus einem Benchmark echter Produkte; daneben zitiert der Beitrag eine Studie von Google.
Der Namensraum eval hat fünf Befehle mit jeweils einer Aufgabe. eval generate führt den Agenten gegen einen Satz von Fällen aus. eval grade bewertet die erzeugten Abläufe. eval compare stellt zwei Ergebnisdateien nebeneinander. eval analyze fasst Fehler zu Themen zusammen. eval optimize startet einen automatischen Durchlauf, der den Prompt des Agenten verbessert. Die Autoren nennen das Ganze Hill-Climbing: den Agenten ändern, die Fälle neu laufen lassen, die Änderung behalten, wenn der Wert steigt, und zurücknehmen, wenn er fällt.
Die Demo nutzt eine LangChain-Vorlage, die mit Agents CLI v1.8.0 ausgeliefert wird. Eine eigene Bewertungsmetrik, betrieben von gemini-3.8-flash, bewertet jede Antwort von 1 bis 5 nach Genauigkeit, Relevanz und Klarheit. Die Autoren erweitern den Standarddatensatz mit einem Fall auf vier: eine Begrüßung, zwei Wetterfragen und eine themenfremde Frage. Der Ausgangsmittelwert beträgt 4,0 von 5 bei einer Standardabweichung von 1,41. Die Streuung werten die Autoren als gesund, denn überall 5,0 hieße, der Agent sei perfekt oder der Datensatz zu leicht, um Unterschiede zu zeigen.
Dann bauen sie einen realistischen Fehler ein: Ein Entwickler fügt eine Koch-Persona in den Systemprompt des Wetteragenten ein. Lint, Unit-Tests und Typprüfungen laufen durch, und der Agent läuft weiter. Der Mittelwert fällt auf 2,75. Der Fallvergleich zeigt, wo der Schaden liegt. Die Begrüßung verlor einen Punkt beim Ton, der themenfremde Fall zwei Punkte wegen ausufernder Antwort, und der Fall sf_weather zwei Punkte, weil der Agent sein Wetterwerkzeug nicht mehr aufrief und Werte erfand. Nach Ansicht der Autoren erkennt nur eine Ende-zu-Ende-Bewertung, die das Verhalten im Kontext bewertet, solche Fehler.
Im zweiten Experiment wird das Modell des Agenten von gemini-3.8-flash auf gemini-2.5-flash getauscht. Laut Beitrag fällt der Mittelwert erneut von 4,00 auf 2,75, doch die Sicht je Fall unterscheidet sich. Das günstigere Modell lag bei der Begrüßung und bei einer Wetterfrage gleichauf, verlor bei der anderen einen Punkt, und der sichtbare Rückgang geht auf den themenfremden Fall zurück, bei dem es mit der Ausflucht ablehnte, das Ereignis habe noch nicht stattgefunden. Die Autoren warnen, dass ein für ein Modell abgestimmter Prompt bei einem anderen an Leistung verlieren kann und dass das Bewertungsmodell konstant bleiben muss, damit der Vergleich fair ist.
Der Beitrag behandelt auch Zeitplanung und Grenzen. Agents CLI bringt keinen Scheduler mit; Teams können generate und grade nachts per cron oder Cloud Scheduler laufen lassen und ein Skript ergänzen, das mit einem Fehlercode endet, wenn der Mittelwert über eine Schwelle hinaus fällt. eval optimize funktioniert für ADK-Projekte über das GEPA-Framework, nicht für die LangChain-Erweiterung. Es ändert nur den Prompt und kann einen Wert durch Überanpassung an die Formulierung der Metrik erhöhen, weshalb ein Mensch die Kandidaten prüft. Google berichtet außerdem von einer eigenen kontrollierten Studie: Coding-Agenten mit dem Werkzeug führten viermal so viele Bewertungen aus, änderten den Agenten nach einer Bewertung aber ungefähr so oft wie die Vergleichsgruppe. Das ist Googles Aussage, im Beitrag ohne Daten.
Die praktische Lehre ist bescheiden. Den täglichen Datensatz so klein halten, dass er bei jeder Änderung läuft, vollständige Ergebnisdateien speichern statt nur Werte und den Fallvergleich lesen, bevor man einem Mittelwert traut. Ein Werkzeug liefert nicht das Urteil darüber, welche Fälle zählen; das muss das Team selbst beisteuern.
Sources
FAQ
Was tun die fünf eval-Befehle von Agents CLI?
eval generate führt den Agenten gegen einen Satz von Fällen aus, eval grade bewertet die Abläufe, eval compare stellt zwei Ergebnisse nebeneinander, eval analyze fasst Fehler zu Themen zusammen und eval optimize verbessert den Prompt automatisch. Die Autoren nennen die Schleife Hill-Climbing: ändern, neu laufen lassen, bei steigendem Wert behalten.
Was zeigte die Demo mit vier Fällen tatsächlich?
Es war eine Demo mit vier Fällen, kein Benchmark. Der Ausgangsmittelwert lag bei 4,0 von 5; eine eingefügte Koch-Persona senkte ihn auf 2,75, und das Wetterwerkzeug wurde nicht mehr aufgerufen. Mit gemini-2.5-flash ergab sich ebenfalls 2,75, doch der Rückgang kam vor allem vom themenfremden Fall. Man muss die Unterschiede je Fall lesen.
Welche Grenzen gelten für die Methode und die Aussagen des Beitrags?
eval optimize gilt nur für ADK-Projekte, ändert nur den Prompt und kann sich an die Formulierung der Metrik überanpassen, weshalb ein Mensch die Kandidaten prüft. Das Bewertungsmodell muss konstant bleiben, ein Modelltausch braucht einen eigenen Prompt. Die Aussage zu viermal mehr Bewertungen stammt aus Googles eigener Studie ohne Daten.