Behavioral Evals: Google erklärt Tests für Coding-Agenten

Wenn der Benchmark nur „schlechter“ meldet

Ein Gesamtscore in Terminal-Bench oder DeepSWE fällt um einige Prozentpunkte, und niemand weiß, warum. Google beschreibt dieses Muster in einem Beitrag vom 9. September 2026 als typische Falle für Entwickler, die neu ins Harness Engineering für agentische Coding-Systeme einsteigen. Der Score meldet eine Bewegung. Mehr nicht.

Laut Google beantwortet er nicht direkt, ob das Modell bei einem mehrdeutigen Prompt überkonfident war, die Testsuite vor der Abgabe nicht geprüft oder ein CLI-Flag erfunden hat. Wer nach einer Prompt- oder Modelländerung wissen will, was kaputtgegangen ist, muss deshalb auf das Verhalten zwischen Auftrag und Resultat schauen.

Behavioral Evals prüfen Zwischenschritte

Google setzt dafür auf Behavioral Evals, die diskrete, beobachtbare Aktionen messen und im Harness wie Integrationstests funktionieren. Stellt der Agent bei einem unterspezifizierten Prompt eine Rückfrage, statt zu raten? Führt er nach einer Änderung an einer Build-Datei den lokalen Validator aus, bevor er die Aufgabe als erledigt meldet? Geprüft werden Tool-Aufrufe und Dateiänderungen, nicht die exakte Übereinstimmung des Endergebnisses.

Googles Beispiel, geschrieben für das Antigravity SDK, macht das greifbar. Der Agent bekommt die Frage nach dem Wetter in Mountain View, und der Test schaut nicht auf die Antwort. Er prüft nur, ob unter den Tool-Aufrufen die Websuche auftaucht. Fehlt sie, hat der Agent aus dem Gedächtnis geantwortet.

Die Prüftiefe hängt laut Google von der Aufgabe ab. Bei einfachen Aufgaben mit einem klaren Lösungsweg reicht eine strikte Assertion auf einen bestimmten Schritt, etwa den Aufruf des Test-Runners. Bei komplexen Aufgaben kann der Agent einen unerwarteten, aber korrekten Weg wählen; dort rät Google von starren Tool-Sequenzen ab und empfiehlt ergebnisorientierte Prüfungen, zum Beispiel mit einem LLM als Bewerter. Weil einzelne Durchläufe durch den Nichtdeterminismus der Modelle schwanken, sollen Batch-Auswertungen die Passraten über die Zeit verfolgen, statt Pull Requests an einem einzelnen Lauf scheitern zu lassen.

Erst Dogfooding, dann die Eval-Suite

Google verortet die formale Eval-Suite ausdrücklich in der zweiten Entwicklungsphase. Zuvor soll der Agent beim Dogfooding die eigene Codebasis bearbeiten und Routineaufgaben erledigen können; bis dahin tragen Entwicklerintuition und Experimente. Der Zweck der Evals ist laut Google nicht, zwei Prozent Fortschritt zu feiern. Sie sollen Gewissheit geben, dass ein Prompt-Tweak, eine Änderung am Tool-Schema oder ein Modell-Upgrade den Agenten nicht insgesamt verschlechtert hat.

Der Einstieg ist bewusst klein. Google empfiehlt, einen konkreten Fehler aus jüngster Zeit auszuwählen, etwa vergessene Unit-Tests vor dem Abschluss einer Aufgabe, und genau diese ausgelassene Aktion zum Ausgangspunkt der Suite zu machen.

Fazit

Benchmark und Behavioral Eval konkurrieren nicht. Auch die Zusammenfassung bei daily.dev betont, dass Behavioral Evals größere End-to-End-Benchmarks ergänzen und nicht ersetzen. Der Benchmark zeigt, ob der Agent Aufgaben insgesamt löst; die Behavioral Eval zeigt, welcher erwartete Schritt auf dem Weg dorthin ausgefallen ist.

Ich halte diese Arbeitsteilung für überzeugend, und sie führt zu einer einfachen Mindestregel: Sobald der Agent die Dogfooding-Phase hinter sich hat, bekommt jede Änderung an Prompt, Tool-Schema oder Modell neben dem Gesamtbenchmark mindestens einen lokalen Verhaltenscheck für den zuletzt beobachteten Fehler. So wird aus einem fallenden Score eine Spur.