AI Operations · 9 Min.
OpenAI Agent Evals: Wie Unternehmen Agenten vor dem Rollout wirklich testen
Agenten werden nicht dadurch produktionsreif, dass sie in Demos gut wirken. Sie brauchen Evals, Traces und Regressionstests gegen echte Workflows.
SYSTEMS Grafik zu OpenAI Agent Evals: Trace -> Metric -> Decision. Fokus: Wie Teams agentische Workflows mit OpenAI Evals, Traces und Gradern vor und nach dem Rollout kontrollieren.
Kurzfassung
Agent Evals prüfen nicht nur Antwortqualität, sondern komplette Workflows: Tool-Auswahl, Zwischenschritte, Kosten, Latenz, Sicherheit und Eskalation. Traces sind entscheidend, weil Agentenfehler oft nicht im Endtext sichtbar sind, sondern in falschen Tool Calls oder schlechten Zwischenentscheidungen. Unternehmen sollten Evals vor Migrationen, Modellwechseln, Tool-Änderungen und jedem größeren Rollout nutzen.
Strategischer Lesepfad
Baue das Thema im passenden Cluster weiter aus und verknüpfe es mit den nächsten Architekturentscheidungen.
Warum normale Prompt-Tests für Agenten nicht reichen Ein Chatbot kann mit Beispiel-Prompts getestet werden. Ein Agent braucht mehr.
Ein Agent entscheidet über Tools, liest Kontext, ruft Funktionen auf, verarbeitet Zwischenergebnisse und kann länger laufen. Das finale Ergebnis kann korrekt aussehen, obwohl der Weg dorthin falsch war: zu teure Tool Calls, falsche Datenquelle, fehlende Freigabe, unnötige Eskalation oder eine riskante Aktion.
Deshalb müssen Unternehmen agentische Workflows anders testen. Nicht nur "War die Antwort gut?", sondern:
OpenAI Agent Evals und Trace Grading adressieren genau diese Ebene.
Hat der Agent das richtige Tool gewählt? Hat er sensible Daten vermieden? Hat er bei Unsicherheit eskaliert? Hat er Quellen korrekt genutzt? Hat er Kosten- und Latenzgrenzen eingehalten? Hat er einen Fehlerfall sauber behandelt? Ist das Ergebnis reproduzierbar genug für Betrieb? Stand Mai 2026: Trace-first ist der richtige Einstieg OpenAI beschreibt Agent Evals nicht als reinen Antwortvergleich, sondern als Zusammenspiel aus Traces, Gradern, Datasets und Eval Runs. Für Teams ist die Reihenfolge wichtig: Erst Verhalten sichtbar machen, dann wiederholbar messen.
Der beste Start ist daher nicht sofort ein riesiges Eval-Programm. Der beste Start ist ein Trace-first-Gate:
So entsteht ein Eval-System aus realem Verhalten, nicht aus theoretischen Wunschfällen.
Traces für echte Agentenläufe aktivieren. Fünf bis zehn typische Runs manuell lesen. Fehlertypen markieren: falsches Tool, falscher Handoff, fehlende Freigabe, Sicherheitsverletzung, unnötige Kosten. Daraus Grader-Kriterien ableiten. Danach ein Dataset bauen, das diese Fehler regelmäßig prüft. Was bei Agent Evals gemessen werden sollte Ein gutes Eval-Set bildet echte Aufgaben ab. Nicht nur perfekte Happy Paths.
Für einen Sales-Agenten könnte das bedeuten:
Für jeden Fall braucht das Team erwartete Kriterien. Nicht zwingend eine einzige perfekte Antwort, sondern messbare Eigenschaften: richtige Klassifikation, richtige Tool-Reihenfolge, keine verbotene Aktion, nachvollziehbare Begründung, akzeptable Kosten.
guter Lead mit vollständigen Daten Lead mit widersprüchlichen Quellen Lead ausserhalb des Zielsegments fehlende Website CRM-Dubletten verbotene Outreach-Formulierung Tool-Ausfall Nutzer fordert etwas Riskantes Agent muss menschliche Freigabe anfragen Traces: Der Unterschied zwischen Ergebnis und Verhalten Bei Agenten ist das Verhalten oft wichtiger als der Endtext. Traces zeigen, welche Schritte der Agent gegangen ist: Modellaufrufe, Tool Calls, Zwischenergebnisse, Fehler und finale Antwort.
Trace Grading ist deshalb wertvoll, weil Teams nicht nur Output bewerten. Sie können prüfen, ob der Agent den Prozess richtig geführt hat.
Beispiele:
Ohne Trace sieht das alles schnell unsichtbar aus.
Der Agent hat zwar eine gute Antwort geliefert, aber eine interne Datenquelle genutzt, die für diesen Nutzer nicht erlaubt war. Der Agent hat drei Websuchen ausgeführt, obwohl eine CRM-Abfrage gereicht hätte. Der Agent hat ein Tool genutzt, obwohl er erst eine Freigabe gebraucht hätte. Der Agent hat einen Tool-Fehler ignoriert und trotzdem ein sicheres Ergebnis behauptet. Was ein Trace-Grader konkret prüfen sollte Ein Trace-Grader sollte nicht "war gut" bewerten. Er sollte scharf genug sein, um operative Fehler zu finden.
Sinnvolle Kriterien:
Diese Kriterien machen Trace Grading zu einem Betriebsinstrument, nicht zu einem Demo-Score.
Tool-Auswahl: Wurde das passende Tool genutzt? Tool-Reihenfolge: Wurde zuerst gelesen, dann bewertet, dann geschrieben? Handoff: Wurde an den richtigen Agenten übergeben? Approval: Wurde bei Write-Backs oder Risiko gestoppt? Datenzugriff: Wurden nur erlaubte Quellen genutzt? Fehlerbehandlung: Wurde ein Tool-Fehler sichtbar gemacht statt überspielt? Kosten: Wurde ein teures Modell oder Tool nur genutzt, wenn es nötig war? Endzustand: Wurde die Aufgabe sauber abgeschlossen oder bewusst eskaliert? Grader: Nicht alles muss ein Mensch bewerten Ein Eval braucht Bewertung. Ein Teil davon kann automatisiert werden.
Grader können prüfen, ob ein Ergebnis bestimmte Kriterien erfüllt. Das kann regelbasiert sein, modellbasiert oder kombiniert. Wichtig ist, dass die Kriterien vorher fachlich klar sind.
Sinnvolle Grader-Fragen:
Grader ersetzen nicht jeden menschlichen Review. Aber sie machen Regressionen sichtbar, bevor ein schlechter Agent in Produktion landet.
enthält die Antwort eine Quelle, wenn Quellenpflicht besteht? wurde eine verbotene Aktion nicht ausgeführt? ist die Antwort im richtigen Format? wurde ein Tool-Fehler korrekt gemeldet? wurde bei niedrigem Vertrauen eskaliert? wurde eine Kundengrenze eingehalten? ist die Begründung kurz genug für den operativen Nutzer? Datasets: Ohne Testdaten kein Lernsystem Viele AI-Projekte scheitern nicht am Modell, sondern an fehlenden Testdaten. Es gibt keine Sammlung echter Fälle, keine schlechten Beispiele, keine Grenzfälle, keine Sicherheitsfälle.
Ein produktives Agenten-Team sollte ein wachsendes Eval-Dataset pflegen:
Dieses Dataset ist nicht einmalig. Es wächst mit echten Incidents, Support-Fällen, Sales-Feedback und neuen Tool-Rechten.
30 typische Aufgaben 20 schwierige Grenzfälle 10 Tool-Fehler 10 Sicherheits- oder Prompt-Injection-Fälle 10 Beispiele für richtige Eskalation 10 Beispiele für falsche Nutzerannahmen Das Regression-Flywheel Agenten werden nicht einmal getestet und dann vergessen. Jede produktive Änderung muss durch ein kleines Regression-Flywheel:
1. Incident, Feedback oder neue Anforderung erfassen. 2. Einen oder mehrere Eval-Fälle daraus bauen. 3. Trace-Grader oder Output-Grader ergänzen. 4. Änderung gegen altes und neues Verhalten laufen lassen. 5. Rollout nur freigeben, wenn Qualität, Sicherheit, Kosten und Latenz im Zielkorridor bleiben.
So wird jeder Fehler zu einem neuen Schutzgitter für den nächsten Rollout.
Evals bei Migrationen und Modellwechseln Evals sind besonders wichtig, wenn sich etwas am Agentenstack ändert.
Typische Auslöser:
Ohne Evals merkt ein Team oft erst im Betrieb, dass ein Agent schlechter delegiert, mehr kostet oder riskanter handelt. Mit Evals wird jede Änderung messbar.
Migration von Assistants API zur Responses API Wechsel des Modells neues Tool oder MCP-Server neue Systemanweisung neue Dokumentenquelle neues Rollenmodell Kostenoptimierung durch Modellrouting Veränderung am Approval-Flow Der SYSTEMS-Eval-Blueprint Für Unternehmen würden wir Agent Evals in sechs Ebenen bauen:
1. Task Accuracy: Löst der Agent die eigentliche Aufgabe? 2. Tool Correctness: Nutzt er die richtigen Tools in der richtigen Reihenfolge? 3. Safety: Vermeidet er verbotene Daten, Aktionen und Annahmen? 4. Escalation: Fragt er bei Risiko nach menschlicher Entscheidung? 5. Cost and Latency: Bleibt der Workflow im Budget? 6. Trace Quality: Ist die Entscheidungskette auditierbar?
Diese Ebenen machen aus einem Agenten kein starres Skript. Sie geben ihm Leitplanken, an denen man Verbesserung messen kann.
Der SYSTEMS-Blick auf OpenAI Agent Evals Agent Evals sind kein akademischer Zusatz. Sie sind der Unterschied zwischen "wir hoffen, dass der Agent funktioniert" und "wir können Verhalten messen".
OpenAI liefert mit Agent Evals, Traces und Grading wichtige Bausteine. Aber Unternehmen müssen die richtigen Testfälle, Business-Kriterien und Rollout-Gates selbst definieren.
SYSTEMS baut Agenten deshalb nie nur mit Prompts. Wir bauen sie mit Eval-Sets, Tool-Grenzen, Trace-Reviews, Freigaben und Produktionssignalen. Erst dann darf ein Agent operative Verantwortung übernehmen.
