KI-Agenten evaluieren, testen & überwachen 2026: Wie man einem Agenten in der Produktion vertraut

Einen KI-Agenten zu bauen war noch nie so einfach. Ein Modell an ein paar Tools anbinden, ihm ein Ziel geben und zusehen, wie es arbeitet — das ist 2026 ein Wochenendprojekt. Der schwierige Teil, der ein virales Demo von einem System trennt, auf dem ein Unternehmen tatsächlich läuft, beantwortet eine viel leisere Frage: Funktioniert er noch? Nachdem Sie den Prompt angepasst haben. Nachdem der Modellanbieter ein Upgrade ausgeliefert hat. Nachdem letzten Dienstag jemand ein neues Tool hinzugefügt hat. Die Teams, die dieses Jahr zuverlässige Agenten ausliefern, sind nicht die besten Prompt-Schreiber. Es sind jene, die die Disziplin aufgebaut haben, zu messen, zu verfolgen und zu überwachen, was ihre Agenten tatsächlich tun.

Die Lücke zwischen Demo und Produktion

Ein Agenten-Demo gelingt bei einer sorgfältig gewählten Eingabe. Die Produktion wirft demselben Agenten jeden Tag Tausende unordentliche, feindselige, randständige Eingaben entgegen — und anders als klassische Software kann dieselbe Eingabe zweimal unterschiedliche Ausgaben erzeugen. Dieser Nichtdeterminismus ist das ganze Problem. Sie können nicht Ausgabe === erwartet schreiben und es einen Test nennen. Eine Änderung, die den Agenten bei dem Fall verbessert, den Sie angeschaut haben, kann ihn bei zehn anderen still verschlechtern. Ohne Messung fliegen Sie blind und nennen es Vertrauen.

Die obigen Zahlen sind richtungsweisend, aus dem gezogen, was wir über Projekte hinweg sehen, nicht aus einer einzelnen Studie — doch das Muster ist universell. Die Lücke zwischen "es hat funktioniert, als ich es probierte" und "es funktioniert" ist genau die Lücke, die Evaluation und Observability schließen.

Zwei Disziplinen, nicht eine

Man vermischt "Evals" und "Observability", doch sie beantworten verschiedene Fragen zu verschiedenen Zeitpunkten. Evaluation ist offline und vor dem Deployment: Wie gut ist diese Version des Agenten bei einer festen Menge von Testfällen? Observability ist online und nach dem Deployment: Was tut der Agent gerade wirklich, im echten Traffic, und wo geht es schief? Sie brauchen beides. Evals verhindern, dass Sie eine Regression ausliefern; Observability sagt Ihnen, was Sie als Nächstes in die Eval-Menge aufnehmen sollten.

Eine Eval-Menge bauen, die Sie wirklich schützt

1. Von echten Fehlern ausgehen, nicht von erdachten

Die besten Eval-Fälle kommen aus der Produktion, nicht aus einem Brainstorming. Jedes Mal, wenn Ihr Agent etwas falsch macht — ein schlechter Tool-Aufruf, eine halluzinierte Zahl, eine abgelehnte Anfrage, die er hätte bearbeiten sollen — wird dieses Transkript zu einem dauerhaften Testfall. Über Wochen hört Ihre Eval-Menge auf, eine Vermutung über mögliche Fehler zu sein, und wird zu einer präzisen Karte dessen, was tatsächlich kaputtging. Deshalb speist Observability die Evaluation: Die Traces, die Sie heute erfassen, sind die Regressionstests, die Sie morgen laufen lassen.

2. Den Pfad bewerten, nicht nur die Antwort

Bei Agenten ist die endgültige Antwort nur die halbe Geschichte. Ein Agent kann auf einem rücksichtslosen Weg zum richtigen Schluss kommen — ein teures Tool zehnmal aufrufen, einen Fehler ignorieren, eine Route wählen, die nicht skaliert. Gute Agenten-Evals bewerten den Pfad (Trajektorie): Hat er die richtigen Tools gewählt, in sinnvoller Reihenfolge, mit korrekten Argumenten, und sich elegant von Fehlern erholt? Dasselbe Prinzip, das wir im Context Engineering für Agenten behandeln, gilt auch hier — wie der Agent dorthin kam, zählt genauso wie, wo er landete.

3. LLM-as-judge nutzen — mit Vorsicht

Die meiste Agenten-Ausgabe ist offener Text ohne einen einzigen korrekten String, also können Sie sie nicht mit einer Gleichheitsprüfung bewerten. Die pragmatische Antwort 2026 ist LLM-as-judge: Ein separates Modell bewertet jede Ausgabe anhand eines expliziten Kriterienkatalogs — ist sie belegt, ist sie vollständig, hat sie die Richtlinie befolgt. Das skaliert in Minuten auf Tausende von Fällen. Doch ein Judge ist selbst ein Modell und braucht seine eigene Validierung: Ziehen Sie Stichproben seiner Urteile, vergleichen Sie sie mit menschlicher Bewertung auf einer Teilmenge und kalibrieren Sie den Kriterienkatalog, bis sie übereinstimmen. Ein unkalibrierter Judge ist nur eine selbstbewusste Vermutung im Laborkittel.

Observability: der Blick in die Black Box

Sobald ein Agent live ist, müssen Sie jeden Schritt sehen, den er unternimmt — nicht nur Eingabe und Ausgabe, sondern den vollständigen Trace: jeden Modellaufruf, jeden Tool-Aufruf mit seinen Argumenten und Ergebnissen, die verbrauchten Tokens, die Latenz, die Wiederholungen. Wenn um 2 Uhr nachts etwas schiefgeht, ist der Trace der Unterschied zwischen einer Fünf-Minuten-Reparatur und einer Fünf-Stunden-Rätselei. Moderne Agenten-Stacks emittieren diese Telemetrie in Standardformaten, sodass sie in dieselben Observability-Tools fließt, die Ihre Ingenieure ohnehin nutzen.

Vier Signale lohnt es sich vom ersten Tag an zu beobachten:

• Qualitätsdrift — lassen Sie kontinuierlich einen Ausschnitt des Live-Traffics durch Ihren Judge laufen. Ein langsamer Rückgang der Bewertungen ist die Frühwarnung, dass ein Modell-Update, eine Datenverschiebung oder eine Prompt-Änderung etwas kaputtgemacht hat.
• Kosten und Token-Verbrauch — ein Agent, der in eine Schleife gerät oder Tools überbeansprucht, zeigt sich als Spitze bei den Tokens pro Aufgabe, lange bevor sich jemand beschwert. Das ist oft das erste Zeichen eines kaputten Pfads.
• Latenz und Tool-Fehler — ein instabiles Tool oder eine langsame API degradiert den gesamten Agenten. Zeitmessung auf Trace-Ebene sagt Ihnen genau, welchen Schritt Sie reparieren müssen.
• Menschliche Eskalationen und Daumen runter — jedes Mal, wenn eine Person den Agenten überstimmt oder korrigiert, ist das ein gelabelter Fehlerfall, der Ihnen gratis übergeben wird. Erfassen Sie ihn und leiten Sie ihn in die Eval-Menge.

Regressionstests, wenn der Boden ständig in Bewegung ist

Klassische Software ändert sich nur, wenn Sie sie ändern. Ein Agent ändert sich, wenn irgendwer irgendetwas ändert — Ihren Prompt, Ihre Tools, Ihren Retrieval-Korpus oder das Modell selbst, wenn der Anbieter eine neue Version ausliefert. Jedes davon ist ein Deployment, und jedes verdient dasselbe Tor: Lassen Sie die volle Eval-Menge laufen, vergleichen Sie die Bewertungen mit der letzten bekannt-guten Version und blockieren Sie die Änderung, wenn die Qualität sinkt. Behandeln Sie Ihre Evals wie CI. Eine Prompt-Änderung, die die Suite nicht besteht, sollte genauso schwer zu mergen sein wie Code, der seine Unit-Tests nicht besteht.

So machen Sie auch Modell-Upgrades sicher statt beängstigend. Wenn ein stärkeres Modell erscheint — wie es jetzt alle paar Monate geschieht — raten Sie nicht, ob Sie es übernehmen. Sie lassen es gegen Ihre Eval-Menge laufen, lesen die Bewertungs- und Kostendifferenz und entscheiden mit Zahlen. Dieselbe Strenge erlaubt es, für Schritte, die kein Spitzenmodell brauchen, auf ein kleineres, günstigeres Modell zu verkleinern und die Parität vor der Umstellung zu beweisen.

Wo Teams scheitern

• Nach Bauchgefühl ausliefern. "Sah im Demo gut aus" ist kein Qualitätsmaßstab. Wenn Sie keine Zahl auf Ihren Agenten setzen können, wissen Sie nicht, ob Ihre nächste Änderung geholfen oder geschadet hat.
• Eine Eval-Menge, die nie wächst. Eine statische 20-Fall-Suite vom Starttag entspricht innerhalb von Wochen nicht mehr der Realität. Speisen Sie sie kontinuierlich aus Produktionsfehlern, sonst verkommt sie zum Theater.
• Dem Judge blind vertrauen. Ein LLM-Judge, den niemand gegen Menschen kalibriert hat, kann selbstbewusst und konsistent falsch liegen. Validieren Sie ihn wie jedes andere Modell.
• Kein Tracing, bis etwas kaputtgeht. Observability während eines Vorfalls nachzurüsten ist der denkbar schlechteste Zeitpunkt. Instrumentieren Sie den Agenten vor dem Ausliefern, nicht nach dem Ausfall.
• Nur die endgültige Antwort bewerten. Verpassen Sie den Pfad, und Sie liefern einen Agenten aus, der zur richtigen Antwort auf dem falschen, teuren, nicht skalierbaren Weg kommt.

Ein praktischer 90-Tage-Weg zu vertrauenswürdigen Agenten

1. Wochen 1–2: Instrumentieren Sie Tracing auf Ihrem bestehenden Agenten, sodass jeder Modell- und Tool-Aufruf erfasst wird. Sie können nicht verbessern, was Sie nicht sehen.
2. Wochen 3–5: Bauen Sie eine erste Eval-Menge von 30–50 Fällen aus echten Transkripten und bekannten Fehlern; definieren Sie Kriterienkataloge und stellen Sie einen LLM-as-judge auf, dann kalibrieren Sie ihn gegen menschliche Bewertung.
3. Wochen 6–9: Verdrahten Sie die Eval-Suite in CI, sodass jede Prompt-, Tool- oder Modelländerung das Tor automatisch durchläuft und Regressionen blockiert.
4. Wochen 10–13: Schalten Sie kontinuierliche Online-Bewertung des Live-Traffics ein, setzen Sie Alarme auf Qualität, Kosten und Latenz und schließen Sie den Kreislauf — jeder Produktionsfehler wird zu einem neuen Eval-Fall.

Fazit

2026 ist der Wettbewerbsvorteil in der KI nicht, wer einen Agenten bauen kann — das können alle. Er liegt darin, wer einem genug vertrauen kann, um ihn vor Kunden zu stellen, in den Finanzabschluss, in die Support-Warteschlange, und ihn laufen zu lassen. Dieses Vertrauen ist kein Gefühl; es wird bewusst hergestellt — aus Evals, die Regressionen vor den Nutzern abfangen, und Observability, die Ihnen genau zeigt, was der Agent getan hat und warum. Die unglamouröse Arbeit des Messens ist es, die ein beeindruckendes Demo in ein verlässliches System verwandelt. Die Teams, die das verinnerlichen, liefern Agenten, die Bestand haben. Die anderen liefern Agenten, die sie überraschen — immer im denkbar schlechtesten Moment.