26.02.2026 AI Engineering5 Minuten Lesezeit

Agent-Evals in der CI: Regressions-Gates für Trajektorien und Tool-Calls

Agenten brauchen andere Regressions-Gates als deterministische Software. Wir zeigen, wie Tool-Calls, Trajektorien, Offline-Datensätze, Produktions-Traces und Kostenbudgets zu einer gestuften CI-Strategie werden — schnell genug für Pull Requests und belastbar genug für den Betrieb.

Warum Agenten klassische CI sprengen

Ein Agent arbeitet als Schleife: Das Modell erhält eine Aufgabe, ruft Tools auf, beobachtet Ergebnisse und wählt den nächsten Schritt. Selbst bei identischem Input entsteht selten zweimal derselbe Pfad. Klassische Tests setzen dagegen einen festen Vertrag voraus — eine erwartete Ausgabe pro Eingabe. Für Agenten greift dieser Vertrag zu kurz. Eine Prompt-Änderung kann ein Szenario reparieren und unbemerkt drei andere verschlechtern, ohne dass ein Unit-Test anschlägt.

Wie groß diese Lücke ist, zeigt τ-bench vom Juni 2024. Der Benchmark ließ Function-Calling-Agenten mit simulierten Nutzern und realen APIs interagieren. GPT-4o löste im Retail-Szenario rund 61 Prozent der Aufgaben in einem einzelnen Versuch. Müssen dagegen acht Durchläufe derselben Aufgabe erfolgreich sein — pass^8 —, sinkt die Quote unter 25 Prozent. Der Engpass ist damit nicht die Spitzenleistung, sondern ihre Wiederholbarkeit. Genau diese Eigenschaft muss CI sichtbar machen.

Eine Änderung landet — Prompt, Modell oder Retrieval. 1/4

Die Trajektorie ist die Testeinheit

Eine Trajektorie ist die Folge der Tool-Aufrufe eines Agenten samt der generierten Argumente sowie der hinterlassene Zustand — Dateien, Datenbankzeilen, Nachrichten. Evals prüfen diese Folge, nicht nur die finale Antwort: Wurde das richtige Tool mit den richtigen Argumenten aufgerufen, bevor der Seiteneffekt eintrat?

In der Praxis ergänzen sich zwei Granularitäten. Single-Step-Evals halten den Agenten nach einer Entscheidung an und prüfen genau diesen Schritt — günstig, schnell und präzise. LangChain berichtete im Dezember 2025, dass etwa die Hälfte seiner Agenten-Testfälle diesem Muster folgte. Full-Turn-Evals lassen dagegen die gesamte Schleife laufen und bewerten finale Antwort, Trajektorie und Zustandsänderungen als zusammenhängendes Ergebnis.

Eine Warnung: Strikter Sequenzabgleich überbestimmt. Agenten erreichen korrekte Ergebnisse über gültige Pfade, die der Testautor nicht vorhergesehen hat. Reservieren Sie exakte Reihenfolge-Assertions für Fälle, in denen die Reihenfolge eine Korrektheits- oder Sicherheitsanforderung ist; überall sonst prüfen Sie, dass ein Tool aufgerufen wurde — nicht wann. Open-Source-Evaluatoren wie agentevals (Februar 2025) unterstützen beide Modi: strikten Trajektorienabgleich und Judge-basierte Trajektorienbewertung.

Regressions-Gates für jeden Pull Request

Ein Gate wirkt nur, solange das Team nicht daran vorbeiarbeitet — und langsame Gates werden früher oder später umgangen. Eine LLM-Judge-Suite mit zehn Minuten Laufzeit pro Push verliert binnen Wochen ihren Pflichtstatus. Deshalb staffeln wir die Prüfungen nach Latenz und Kosten: deterministische Checks bei jedem Commit, Judge-Bewertungen beim Merge, den vollständigen Datensatz in der Nacht.

Entscheidend ist außerdem das Delta, nicht nur der Absolutwert. Fällt eine Suite von 96 auf 91 Prozent, liegt eine Regression vor, auch wenn sie einen Schwellwert von 90 Prozent noch passiert. Speichern Sie deshalb den Baseline-Score des Main-Branches, vergleichen Sie jeden Pull Request damit und blockieren Sie ab einem definierten Abfall. Nicht-deterministische Fälle sollten mehrfach laufen — etwa dreimal mit Mehrheitsentscheid —, damit Sampling-Rauschen nicht als Regression erscheint.

Stufe	Auslöser	Prüfungen	Merge-Gate
Deterministisch	Jeder Commit	Schema-Validität, erwartete Tool-Calls, Argument-Checks, Kostenobergrenzen	Ja — 100 Prozent Pflicht
LLM-as-Judge	Merge auf main	Rubrik-Scores, Ablehnungsverhalten, Trajektorien-Qualität	Ja — Schwellwert mit Wiederholungsläufen
Volle Regression	Nächtlich	Kompletter Datensatz, Modellvergleich, Kosten-Audit	Nein — nur Alarm

Offline-Datensätze und Online-Judges

Offline-Evals laufen gegen einen kuratierten Datensatz mit Referenzausgaben. Korrektheit ist pro Fall definiert; deterministische Grader prüfen sie. Hier lebt das Regressions-Gating. Der Datensatz muss nicht groß sein: Anthropics Leitfaden vom Januar 2026 nennt 20 bis 50 Aufgaben aus realen Fehlern als ausreichenden Start, weil frühe Änderungen große Effektstärken haben.

Ein Offline-Datensatz kann reale Nutzer nie vollständig vorwegnehmen. Online-Judges ergänzen ihn deshalb um eine zweite Perspektive: Ein LLM bewertet Stichproben aus Produktions-Traces fortlaufend und ohne Referenzantwort gegen eine Rubrik. LangSmith lieferte im Oktober 2025 Multi-Turn-Evals für ganze Konversationen aus; Langfuse führt Judge-Pipelines über gespeicherte Traces aus. Der Wert entsteht im Kreislauf: Ein online markierter Trace wird zum neuen Offline-Fall, sodass derselbe Fehler nach seiner Behebung nicht zurückkehrt.

Judges sind Messinstrumente und brauchen Kalibrierung. Bewerten Sie bei Temperatur null, schreiben Sie Rubriken mit expliziten Bedingungen und prüfen Sie Judge-Ausgaben gegen menschliche Labels, bevor Sie ihnen vertrauen. Ein unkalibrierter Judge liefert eine Zahl, keine Messung — und Judges driften genau wie die Agenten, die sie bewerten.

Kosten pro Lauf als Metrik erster Klasse

Agenten-Evals verbrauchen echte Tokens. Die τ-bench-Autoren berichteten rund 0,61 US-Dollar pro Aufgabe und Durchlauf — 0,38 für den Agenten, 0,23 für den simulierten Nutzer —, wobei 96 Prozent der Agentenkosten auf Input-Tokens entfielen. Eine Suite mit 100 Fällen und drei Wiederholungen ist ein messbarer Posten pro Pull Request. Verfolgen Sie ihn pro Lauf, sonst fällt die Suite der nächsten Budgetrunde zum Opfer.

Token-Abrechnung standardisiert sich; Kosten-Abrechnung nicht. Die OpenTelemetry-GenAI-Konventionen definieren Token-Attribute und -Metriken (gen_ai.usage.input_tokens, gen_ai.client.token.usage), im Februar 2026 weiterhin im Status Development. Eine standardisierte Kostenmetrik existiert nicht — Kosten berechnen Sie aus Token-Zählern und einer gepflegten Preistabelle. Und nutzen Sie sie: Eine Änderung, die die Tokens pro Aufgabe verdoppelt, ist eine Regression, auch wenn die Qualitäts-Scores halten. Kostenobergrenzen gehören in die deterministische Stufe.

Eval-getriebene Entwicklung

Eval-getriebene Entwicklung kehrt die übliche Reihenfolge um: Die Evaluation entsteht vor der Fähigkeit. Ihre zunächst niedrige Pass-Rate beschreibt nicht das Scheitern des Projekts, sondern das Ziel, das es zu erreichen gilt. Erscheint ein neues Modell, zeigt ein einziger Suite-Lauf, welche Fälle besser wurden und welche brachen. Anthropic beschreibt Funktionen, die heute nur "gut genug" arbeiten, als Wetten auf künftige Modelle; Capability-Evals machen diese Wetten überprüfbar.

Zwei Disziplinen halten die Schleife ehrlich. Erstens Umgebungshygiene: Jeder Durchlauf startet aus sauberem Zustand, externe APIs werden aufgezeichnet und wieder abgespielt — geteilter Zustand erzeugt flakige Evals, die nichts messen. Zweitens: Lesen Sie die Transkripte. Eine schlechte Note unterscheidet nicht zwischen einem Agentenfehler und einem Grader, der eine gültige Lösung ablehnt. Das Transkript schon.

Ausblick vom Februar 2026

Drei Entwicklungen erscheinen von hier aus wahrscheinlich. Erstens werden Trajektoriendaten portabel: Die GenAI-Konventionen von OpenTelemetry modellieren bereits Tool-Call-Spans, während MCP die Tool-Schnittstelle standardisiert. Eval-Harnesse werden dadurch Traces aus unterschiedlichen Laufzeitumgebungen verarbeiten können. Zweitens werden Kosten als eigenständiges Signal in die Konventionen einziehen. Drittens wandert die Kalibrierung von Judges aus Ad-hoc-Skripten in die Plattformen.

Das dauerhafte Asset ist daher nicht der öffentliche Benchmark; er sättigt. Wertvoll bleibt die private, produktspezifische Suite, die mit jedem Produktionsfehler wächst. Wir behandeln sie als Liefergegenstand mit demselben Status wie den Agenten selbst: neben dem Code versioniert, vor jedem Merge als Gate ausgeführt und von derselben Rolle verantwortet wie die Spezifikation. Modelle werden ausgetauscht; die Evals bewahren das Wissen über das erwartete Verhalten.