Evaluation-Driven Development: Agent-Verhalten als Release-Vertrag

Was ist Evaluation-Driven Development für Agenten?

Evaluation-Driven Development ist eine Entwicklungspraxis, bei der du das Verhalten eines KI-Agenten als versionierten Release-Vertrag behandelst. Du definierst repräsentative Szenarien, legst fest, was akzeptables Verhalten ist, führst diese Szenarien gegen eine Kandidatenänderung aus und nutzt die Ergebnisse für Entscheidungen im Delivery-Prozess.

Das klingt nach Testing – und das ist es auch. Der Unterschied liegt im Testobjekt. Eine klassische Funktion hat meist bekannte Eingaben und deterministische Ausgaben. Ein Agent verbindet die probabilistische Sprachgenerierung eines Modells mit Anweisungen, Tools, Berechtigungen, externen Daten und mehrstufigen Entscheidungen. Eine scheinbar harmlose Änderung am Prompt, ein Modellwechsel, geänderte Credentials oder ein angepasstes Tool-Schema kann nicht nur die finale Antwort verändern. Sie kann auch beeinflussen, welches Tool der Agent auswählt, welche Argumente er sendet und ob er die Aufgabe überhaupt abschließt.

Einfach gesagt: Veröffentliche einen Agenten nicht, weil sein Prompt plausibel aussieht. Veröffentliche ihn, weil er die wichtigen, von dir definierten Situationen wiederholt gut genug bewältigt.

Der Begriff ist noch keine vollständig standardisierte Methodik. Du wirst auch „evaluation-first development“, kontinuierliche Agent-Evaluierung und Agent-Quality-Gates sehen. Die dauerhafte Idee ist einfacher: Verhalten soll vor der Produktion beobachtbar, messbar und überprüfbar sein.

Das bedeutet nicht, einer universellen Kennzahl hinterherzulaufen. Es bedeutet, für deine Anwendung eine kleine, explizite Menge an Zusagen festzulegen. Ein Support-Agent muss vielleicht das richtige Tool für die Kontosuche wählen und darf keine unbelegten Richtlinienbehauptungen aufstellen. Ein interner Engineering-Agent muss möglicherweise das richtige Repository identifizieren, innerhalb seines autorisierten Geltungsbereichs bleiben und Unsicherheit kenntlich machen, statt eine Schlussfolgerung zu erfinden. Das sind Software-Qualitätseigenschaften, auch wenn eine klassische Assertion eine gute Antwort in natürlicher Sprache nicht vollständig beschreiben kann.

Warum das jetzt wichtig ist

Am 8. September veröffentlichte AWS ein CI/CD-Referenzmuster, das einen Agenten und einen MCP-Server deployt, Evaluation Prompts ausführt, das Verhalten bewertet und Pull Requests blockiert, wenn die Evaluation Scores schlechter werden. Die Implementierung bezieht sich konkret auf Amazon Bedrock AgentCore und GitHub Actions, doch das Engineering-Muster ist übertragbar: Agent-Verhalten kann ein Merge-Kriterium sein statt einer manuellen Demo nach dem Merge.

Wichtig ist nicht, dass jedes Team eine weitere Plattform braucht. Agenten haben vielmehr die Fläche für Regressionen vergrößert. In der gewöhnlichen Service-Entwicklung lässt sich eine Änderung an einem Endpoint gegen einen Vertrag prüfen. Bei Agenten kann eine Änderung Instructions, Retrieval Context, ein Modell, Orchestrierungslogik, eine MCP-Integration, Berechtigungen oder alles zugleich verändern. Ein Blick auf einige Chat-Transkripte erkennt offensichtliche Defekte, kann aber nicht zeigen, ob ein bekannter, fragiler Fall unbemerkt schlechter geworden ist.

AWS dokumentiert mehrere Phasen: On-Demand-Evaluation für Build-Time-Testing, Batch-Evaluation für Baselines, Vorher-Nachher-Vergleiche, Regressionstests und Audits sowie Online-Evaluation für Produktionsaktivität. Die Dokumentation zu Evaluation Types beschreibt diese getrennten Modi. Diese Aufteilung ist auch ohne AWS-Dienste sinnvoll. Schnelle, gezielte Prüfungen gehören an einen Pull Request; breitere und langsamere Suites vor die Promotion; Stichproben aus der Produktion decken Fehler auf, die dein kuratiertes Set nicht vorhergesehen hat.

Einfach gesagt: Evaluation ist kein einmaliger Benchmark. Sie ist ein Feedback-Loop, der in der CI beginnt und nach dem Deployment weiterläuft.

So funktioniert der Kreislauf

Am Anfang steht ein Szenario, also eine kontrollierte Aufgabe, die ein schützenswertes oder zu verhinderndes Verhalten abbildet. Jedes Szenario sollte genug Context enthalten, um es wiederholen zu können: Nutzeranfrage, relevante Fixture-Daten, erlaubte Tools, relevante Berechtigungen und die erwartete Bedingung. Decke normale Arbeit, unangenehme, aber gültige Anfragen, berechtigungssensible Operationen und bereits aufgetretene Fehler ab. Ein in Produktion gefundener Fehler ist besonders wertvoll: Mache ihn zu einem versionierten Szenario, sobald du ihn verstanden hast.

Führe dann den Kandidaten-Agenten in einer Umgebung aus, die der zu bewertenden Laufzeit ausreichend nahekommt. „Ausreichend nahe“ ist entscheidend. Hat die CI weitergehende Berechtigungen, anderes Tool-Verhalten oder andere externe Daten als die Produktion, beweist ein erfolgreiches Ergebnis weniger, als es scheint. Erfasse die Interaktion als Trace: strukturierte Evidenz eines Agent-Laufs. Je nach System gehören dazu eine vollständige Session, Zwischenschritte und Tool-Call-Spans, also einzelne aufgezeichnete Tool-Aufrufe. AgentCore kann Sessions, Traces oder einzelne Tool-Call-Spans als Ziele einer Evaluation verwenden. AWS dokumentiert diese Evaluationsziele.

Wende anschließend mehr als eine Art von Evaluator an. Die stärksten Release-Prüfungen sind meist deterministisch. Ein Code-basierter Evaluator kann prüfen, ob ein Argument einen erlaubten Wert hat, eine erforderliche Richtlinienbedingung erfüllt ist, ein Identifier einem Format entspricht oder der Agent keine verbotene Operation aufgerufen hat. Laut AgentCore-Dokumentation können Code-basierte Evaluators deterministische Prüfungen, externe API-Aufrufe, Regular-Expression-Matching und geschäftsspezifische Regeln umsetzen. Siehe die Dokumentation zu Evaluators.

Für Aufgaben mit einer bekannten akzeptablen Antwort oder Aktionsfolge ergänzt du Ground Truth: explizites Referenzmaterial, gegen das ein Lauf geprüft werden kann. Die Evaluation API von AWS unterstützt erwartete Antworten, Assertions und erwartete Tool Trajectories. Damit lassen sich sowohl Korrektheit als auch Verhalten prüfen. Eine erwartete Trajectory sollte nicht bedeuten, dass es nur einen gültigen Weg gibt, wenn mehrere Wege tatsächlich sicher sind. Nutze sie, wenn die erforderliche oder verbotene Aktion wesentlich ist.

Einige Qualitäten lassen sich nicht sauber auf eine exakte Assertion reduzieren. Ein LLM-as-a-judge-Evaluator verwendet ein Modell und eine schriftliche Rubrik, um eine Antwort oder Interaktion zu bewerten. Er kann einschätzen, ob eine Erklärung nützlich ist, eine Antwort einer Richtlinie folgt oder ein mehrstufiges Ergebnis die Anfrage beantwortet. Referenzfreies Judging beruht auf der eigenen Einschätzung des Evaluator-Modells statt auf Ground-Truth-Daten. Es ist deshalb ein skalierbares Signal für qualitative Eigenschaften, aber kein Beweis für Korrektheit. AWS trifft diese Unterscheidung ausdrücklich.

Zum Schluss fasst du die Ergebnisse in einem klaren Quality Gate zusammen. Ein Gate kann verlangen, dass jede sicherheitskritische Prüfung besteht, eine Regression in bestimmten Dimensionen verbieten und einen nicht kritischen semantischen Score zunächst nur sichtbar machen, während du ihn kalibrierst. Behalte Ergebnisse pro Szenario sichtbar. Ein globaler Durchschnitt kann stabil bleiben, während eine einzelne risikoreiche Aufgabe schlechter wird.

Einfach gesagt: Nutze exakte Checks für Zusagen, die nicht brechen dürfen. Nutze modellbasierte Bewertung für Qualitäten, die Menschen erkennen, aber Code nicht sauber beschreiben kann – und verwechsle dieses Urteil nicht mit Gewissheit.

Was es nicht ist

Evaluation-Driven Development ist nicht gewöhnliches Unit Testing mit einem zusätzlich angehängten Modell. Unit Tests bleiben für deterministischen Code unverzichtbar: Autorisierungslogik, Parser, Validatoren, Tool-Implementierungen und Zustandsübergänge sollten weiterhin direkt getestet werden. Agent-Evaluation erweitert die Testfläche auf sprachvermittelte Entscheidungen und Ausführungspfade, bei denen das Ergebnis variieren kann und dennoch akzeptabel ist.

Es ist auch nicht bloß Observability. Observability zeigt dir über Logs, Telemetrie, Traces und Inspektion, was passiert ist. Evaluation ergänzt ein Urteil darüber, ob dieses Verhalten eine Qualitäts- oder Geschäftsanforderung erfüllt hat. Du brauchst beides: Ein niedriger Score ohne Trace ist schwer zu diagnostizieren; ein Trace ohne explizites Kriterium ist leicht zu bewundern, aber schwer in eine Entscheidung zu übersetzen.

Ebenso wenig ist es ein generischer Benchmark. Ein Benchmark vergleicht Systeme meist mit einer festen Aufgabensammlung. Deine Suite sollte stattdessen deine Nutzer, Richtlinien, Tools und Incidents abbilden. Sie sollte sich mit der Anwendung weiterentwickeln. Und sie ist kein Agent-Harness, auch wenn ein Harness die kontrollierten Tools, Fixtures, die simulierte Umgebung und Eingaben für Tests bereitstellen kann. Der Harness führt das Experiment aus; die Evaluationsrichtlinie entscheidet, was als bestanden gilt.

Ein praktisches Engineering-Beispiel

Betrachte einen hypothetischen internen Agenten für Incident-Triage. Er kann Alerts lesen, den Service-Katalog abfragen, Informationen zu jüngsten Deployments abrufen und ein Incident-Update entwerfen. Änderungen an der Produktion darf er nicht ausführen. Ein Team ändert die System Instructions und ersetzt eine Katalogintegration.

Eine nützliche CI-Suite würde nicht nur fragen: „War das finale Update gut formuliert?“ Sie könnte ein Szenario enthalten, in dem ein Alert einen mehrdeutigen Service nennt. Die erwartete Bedingung lautet, dass der Agent den Katalog abfragt, bevor er Ownership zuschreibt. Ein deterministischer Evaluator prüft, dass er kein Tool mit Schreibberechtigung aufruft und jedes Tool-Argument dem Schema entspricht. Eine Ground-Truth-Assertion prüft, dass die Antwort den verifizierten verantwortlichen Service nennt oder ausdrücklich sagt, dass die Ownership ungeklärt bleibt. Eine Judge-basierte Rubrik bewertet, ob der Entwurf beobachtete Fakten von Hypothesen trennt.

Ein weiteres Szenario kann einen früheren Fehler nachstellen: Das Deployment-System liefert kein passendes Release. Das Akzeptanzkriterium ist dann keine flüssige erfundene Erklärung. Der Agent soll fehlende Evidenz benennen, keine falsche Kausalbehauptung aufstellen und einen erlaubten nächsten Schritt vorschlagen. Der Trace zeigt den Reviewern, ob Retrieval, Tool-Auswahl, Konstruktion der Argumente, Modellschlussfolgerung oder eine unerwartete Berechtigungsantwort die Ursache war.

Führe in der CI für jeden Pull Request das kompakte Set aus. Vor einer Promotion in die Produktion startest du einen breiteren Batch mit stabilen Fixtures und vergleichst ihn mit einer Baseline. Nach dem Deployment ziehst du mit angemessenen Datenschutz- und Zugriffskontrollen Stichproben realer Sessions, untersuchst schlecht bewertete Abläufe und übernimmst wiederkehrende Fehlermuster in die Suite. Die Online-Evaluation-Dokumentation von AWS beschreibt Sampling, Filtering, aggregierte Trends und die Untersuchung niedrig bewerteter Sessions. Siehe die Hinweise zu Online Evaluation.

Wo es scheitert

Eine grüne Suite ist Evidenz für die enthaltenen Szenarien, kein Zertifikat für allgemeine Korrektheit. Sie kann neue Anfragen, adversariale Instructions, ungewöhnliche Tool-Interaktionen, Ausfälle externer Dienste und Verteilungsverschiebungen in der Produktion übersehen. Eine Suite, die nie eine schwierige Berechtigungsgrenze testet, kann nicht zeigen, ob diese Grenze sicher ist.

Judge-basierte Scores bringen einen weiteren Fehlermodus mit: Der Judge besitzt eigenes Modellverhalten, Prompt-Sensitivität und eine eigene Interpretation der Rubrik. Kalibriere ihn mit überprüften Beispielen. Bewahre menschlich geprüfte Fälle auf, suche nach Abweichungen und mache einen einzigen undurchsichtigen Judge-Score nicht zum alleinigen Release-Blocker für eine kritische Aktion.

Kosten und Zeit sind reale Einschränkungen. Dependencies zu deployen, Inference auszuführen, Tools aufzurufen und Traces zu sammeln, macht Agent-Suites langsamer als einen normalen Unit-Test-Lauf. Staffel die Suite, statt sie aufzugeben: kleine verpflichtende Checks pro Pull Request, breitere Regression Runs bei der Promotion und Stichproben als Online-Evaluation. Behandle außerdem flüchtige externe Dependencies als Engineering-Problem. Trenne echten Verhaltensfehler von nicht verfügbaren Testdaten, geänderten Credentials oder einem beeinträchtigten Provider.

Was du diese Woche tun kannst

Wähle einen Agent-Workflow mit echtem Nutzer- oder Betriebsnutzen. Schreibe zehn bis zwanzig Szenarien aus Support-Tickets, Incidents und erwarteten Happy Paths. Bestimme für jedes eine Bedingung, die deterministisch sein muss: ein verbotenes Tool, eine erforderliche Berechtigungsprüfung, eine zwingende Datenquelle oder ein Antwortfeld, das vorhanden sein muss.

Füge Trace-Erfassung rund um den Agenten und seine Tools hinzu. Lege zunächst eine kleine Teilmenge der Szenarien in die CI und hänge die Ergebnisse an den Pull Request. Beginne nicht mit einer komplizierten Scorecard. Mache ein oder zwei kritische Bedingungen zu Merge-Blockern, bewahre die Evidenz zu Fehlern auf und nutze andere Messwerte als sichtbare, aber nicht blockierende Signale, während du ihr Verhalten kennenlernst.

Mache die Suite dann zu einem Teil der normalen Wartung. Jeder entkommene Defekt sollte zu einer Frage führen: Können wir ihn als Szenario, Assertion, Fixture oder Prüfung an der Tool-Grenze darstellen? Mit der Zeit wird die Suite zu einem Protokoll dessen, was dein Agent tun darf und zuverlässig vermeiden muss.