26.02.2026 AI Engineering 5 Minuten Lesezeit

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

Agenten scheitern an deterministischen Tests, weil derselbe Input unterschiedliche Trajektorien erzeugt. Dieser Artikel zeigt, wie Sie Regressionen 2026 in der CI abfangen: Assertions auf Tool-Calls und Trajektorien, Offline-Datensätze mit Referenzausgaben, Online-LLM-Judges auf Produktions-Traces, Kostenverfolgung pro Lauf und eval-getriebene Entwicklung als Arbeitsweise für Agenten in Produktion.

Warum Agenten klassische CI sprengen

Ein Agent ist eine Schleife: Ein Modell erhält eine Aufgabe, ruft Tools auf, beobachtet Ergebnisse und entscheidet den nächsten Schritt. Derselbe Input erzeugt selten zweimal denselben Pfad. Klassische Tests prüfen eine erwartete Ausgabe für eine Eingabe. Dieser Vertrag gilt für Agenten nicht. Eine Prompt-Änderung, die ein Szenario repariert, verschlechtert stillschweigend drei andere — und kein Unit-Test schlägt an.

Das Problem ist vermessen. τ-bench (Juni 2024) ließ Function-Calling-Agenten gegen simulierte Nutzer und reale APIs laufen. GPT-4o löste im Retail-Szenario rund 61 Prozent der Aufgaben im Einzelversuch. Verlangt man acht erfolgreiche Durchläufe derselben Aufgabe — pass^8 —, fällt die Quote unter 25 Prozent. Das Defizit ist Zuverlässigkeit, nicht Spitzenleistung. Genau das muss die CI messen.

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?

Zwei Granularitäten haben sich bewährt. Single-Step-Evals frieren den Agenten nach einer Entscheidung ein und prüfen sie — günstig, schnell, präzise; LangChain berichtete im Dezember 2025, dass etwa die Hälfte ihrer Agenten-Testfälle Single-Step-Tests waren. Full-Turn-Evals lassen die ganze Schleife laufen und bewerten finale Antwort, Trajektorie und Zustandsänderungen gemeinsam.

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 funktioniert nur, wenn das Team es nicht umgeht — und Teams umgehen langsame Gates. Eine LLM-Judge-Suite mit zehn Minuten Laufzeit pro Push wird binnen Wochen auf nicht-verpflichtend gestellt. Wir teilen das Gate deshalb in Stufen, geordnet nach Latenz und Kosten: Deterministische Checks laufen bei jedem Commit, Judge-Bewertungen beim Merge, der volle Datensatz nächtlich.

Gaten Sie auf Deltas, nicht auf Absolutwerte. Eine Suite, die von 96 auf 91 Prozent fällt und einen 90-Prozent-Schwellwert weiter passiert, ist eine Regression im Anmarsch. Speichern Sie den Baseline-Score des Main-Branches, vergleichen Sie jeden Pull Request dagegen und blockieren Sie ab einem definierten Abfall. Wiederholen Sie nicht-deterministische Fälle — drei Läufe, Mehrheitsentscheid —, um Agenten-Regressionen von Sampling-Rauschen zu trennen.

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.

Offline-Datensätze können reale Nutzer nicht antizipieren. Online-Judges schließen diese Lücke: Ein LLM bewertet gesampelte Produktions-Traces gegen eine Rubrik — referenzfrei, kontinuierlich, driftsensitiv. LangSmith lieferte im Oktober 2025 Multi-Turn-Evals für ganze Konversationen aus; Langfuse führt Judge-Pipelines über gespeicherte Traces aus. Beide speisen einander: Ein vom Online-Judge markierter Trace wird zum Offline-Datensatzeintrag, und der aufgedeckte Fehler bleibt behoben.

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 dreht die Reihenfolge um: Der Eval entsteht vor der Fähigkeit. Die Suite startet mit niedriger Pass-Rate und definiert den Hügel, den es zu erklimmen gilt. Erscheint ein neues Modell, zeigt ein Suite-Lauf, was besser wurde und was brach. Anthropic beschreibt Features, die heute "gut genug" funktionieren, als Wetten auf künftige Modelle — Capability-Evals machen die Wette messbar.

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. Trajektorien-Daten werden portabel: Die GenAI-Konventionen von OpenTelemetry modellieren bereits Tool-Call-Spans, und MCP standardisiert die Tool-Schnittstelle — Eval-Harnesse werden Traces aus beliebigen Laufzeitumgebungen konsumieren. Kosten ziehen als eigenständiges Signal in die Konventionen ein. Und Judge-Kalibrierung wandert aus Ad-hoc-Skripten in die Plattformen.

Das dauerhafte Asset wird nicht der öffentliche Benchmark sein — die saturieren. Es wird die private, produktspezifische Suite sein, die mit jedem Produktionsfehler wächst. Wir behandeln diese Suite als Liefergegenstand mit demselben Status wie der Agent selbst: versioniert neben dem Code, als Gate vor jedem Merge, verantwortet von dem, der die Spezifikation verantwortet. Agenten wechseln ihre Modelle; die Evals tragen das Wissen hinüber.