KI-Agenten evaluieren: Trajektorien, Ergebnisse und Zuverlässigkeit bewerten

Ein Agent, der "Ihre Erstattung wurde bearbeitet" schreibt, und ein Agent, der die Erstattung tatsächlich bearbeitet hat, sehen im Chatverlauf identisch aus. Agenten zu evaluieren heißt, über die letzte Nachricht hinauszuschauen: auf das Ergebnis (was sich in der Welt verändert hat) und auf die Trajektorie (welche Tools in welcher Reihenfolge mit welchen Argumenten aufgerufen wurden). Wer nur den finalen Text bewertet, baut Agenten, die Evals bestehen und Kunden enttäuschen.

Dieser Artikel ist die agentenspezifische Fortsetzung von LLM-Evals für Produktfeatures. Er behandelt das Vokabular, die drei Arten von Gradern, Trajektorien-Matching mit agentevals, DeepEval und Ragas, warum pass^k für kundennahe Agenten wichtiger ist als pass@1 und wie du verhinderst, dass die Eval-Umgebung dich belügt.

Ergebnis und Trajektorie: die zwei Dinge, die du bewertest

Anthropics Leitfaden vom Januar 2026 liefert ein Vokabular, das sich zu übernehmen lohnt. Ein Task ist ein Testfall mit Eingaben und Erfolgskriterien; jeder Versuch ist ein Trial. Ein Grader bewertet einen Aspekt eines Trials. Das Transkript (auch Trace oder Trajektorie) ist die vollständige Aufzeichnung: Ausgaben, Tool-Aufrufe, Reasoning, Zwischenergebnisse. Das Ergebnis (Outcome) ist der Endzustand der Umgebung. Das Beispiel dort: Ein Flugbuchungsagent schreibt vielleicht "Ihr Flug ist gebucht", aber das Ergebnis ist, ob in der Datenbank eine Reservierung existiert.

τ-bench, einer der Referenz-Benchmarks für Agenten, bewertet genau so: Er vergleicht den Datenbankzustand am Ende einer Konversation mit einem annotierten Zielzustand. Das ist die stärkste Einzelprüfung, die du bauen kannst, weil sie sich nicht dafür interessiert, was der Agent gesagt hat, sondern nur dafür, was er getan hat.

Code-, Modell- und menschliche Grader

Jeder Grader betrachtet entweder das Transkript oder das Ergebnis. Anthropics Leitfaden teilt sie in drei Familien, und ein guter Agenten-Eval mischt alle drei:

Scores lassen sich als gewichtete Summe gegen einen Schwellenwert, binär (alle müssen bestehen) oder hybrid kombinieren. Mein Standard für Business-Agenten: binär bei sicherheitsrelevanten Code-Prüfungen (nie eine Erstattung ohne Verifizierung), gewichtet bei allem anderen.

Trajektorien-Matching: strict, unordered, subset, superset

Wenn du eine Referenz-Trajektorie hast, ist die Frage, wie genau der Agent ihr folgen muss. LangChains Open-Source-Paket agentevals benennt die vier sinnvollen Antworten als Werte von trajectory_match_mode:

Argumente werden separat abgeglichen. Standardmäßig verlangt agentevals identische Argumente; tool_args_match_mode lässt sich auf ignore, subset oder superset setzen, und tool_args_match_overrides nimmt Regeln pro Tool an, auch eine eigene Vergleichsfunktion (etwa Städtenamen ohne Groß-/Kleinschreibung):

from agentevals.trajectory.match import create_trajectory_match_evaluator

# Refund flow: the agent may look things up freely, but must make these calls.
evaluator = create_trajectory_match_evaluator(
    trajectory_match_mode="superset",
    tool_args_match_overrides={
        "issue_refund": ["order_id"],          # only order_id must match exactly
        "lookup_order": "ignore",              # any lookup arguments are fine
    },
)
result = evaluator(outputs=agent_messages, reference_outputs=reference_messages)
# {'key': 'trajectory_superset_match', 'score': True, 'comment': None}

Andere Frameworks decken dasselbe Feld mit anderen Namen ab. DeepEvals ToolCorrectnessMetric vergleicht erwartete und aufgerufene Tools, standardmäßig nach Namen, optional auch nach Eingabeparametern und Ausgabe, mit Schaltern für Reihenfolge und exakte Übereinstimmung. Ragas bietet ToolCallAccuracy (standardmäßig strikte Reihenfolge, mit flexiblem Modus), ToolCallF1 für Precision und Recall über Aufrufe und AgentGoalAccuracy, wenn nur das Ergebnis zählt. Nimm ein Framework pro Projekt; die Konzepte sind übertragbar. Meine Reviews zu DeepEval und Ragas beschreiben die Abwägungen.

Zuerst Ergebnisse bewerten, Pfade nur für Invarianten

Bei Trajektorien ist die Versuchung groß, exakt den Pfad zu verlangen, den du selbst gewählt hättest. Anthropic rät davon ab: Agenten finden regelmäßig gültige Wege, die der Eval-Designer nicht vorhergesehen hat, daher sei es "oft besser zu bewerten, was der Agent produziert hat, nicht den Weg, den er genommen hat". Ihr eigenes Beispiel ist bemerkenswert. Opus 4.5 löste ein Flugbuchungsproblem aus τ²-bench, indem es eine Lücke in der Richtlinie fand; es "fiel" im Eval wie geschrieben durch und lieferte dem Nutzer trotzdem das bessere Ergebnis.

Deshalb nutze ich Trajektorien-Prüfungen für Invarianten, die wenigen Regeln, die auf jedem Pfad gelten müssen, und Ergebnisprüfungen für den Erfolg. Invarianten sind meist kurz und lassen sich leicht im Code ausdrücken:

def check_invariants(calls: list[dict]) -> list[str]:
    """calls: tool calls from the transcript, in order: {"name": ..., "args": {...}}"""
    errors, verified = [], False
    for c in calls:
        if c["name"] == "verify_customer":
            verified = True
        if c["name"] == "issue_refund":
            if not verified:
                errors.append("refund before customer verification")
            if c["args"]["amount"] > 500:
                errors.append("refund above approval limit")
        if c["name"] in {"delete_account", "send_bulk_email"}:
            errors.append(f"forbidden tool: {c['name']}")
    if len(calls) > 25:
        errors.append(f"{len(calls)} tool calls, budget is 25")
    return errors

Das ist binär und günstig, läuft bei jedem Trial und bestraft keine kreativen Wege. Kombiniert mit der Ergebnisprüfung gegen die Datenbank erwischst du die zwei Fehler, die am meisten zählen: Der Agent hat das Falsche getan, oder er hat das Richtige auf verbotenem Weg getan. Welche Aktionen überhaupt ein menschliches Gate brauchen, beschreibt Human in the Loop für KI-Agenten.

pass@k und pass^k: ein Trial ist keine Messung

Agenten sind nicht deterministisch; ein Task, der einmal besteht, kann beim nächsten Lauf scheitern. Zwei Metriken beschreiben das. pass@k ist die Wahrscheinlichkeit, dass mindestens einer von k Trials gelingt; sie steigt mit k. pass^k ist die Wahrscheinlichkeit, dass alle k Trials gelingen; sie sinkt mit k. Die Rechnung aus Anthropics Leitfaden: Ein Agent mit 75 % Erfolgsquote pro Trial besteht alle drei von drei Trials mit einer Wahrscheinlichkeit von 0,75³ ≈ 42 %.

τ-bench hat pass^k genau wegen dieser Lücke eingeführt. Im Paper von 2024 lösten selbst moderne Function-Calling-Agenten wie gpt-4o weniger als die Hälfte der Tasks, und pass^8 lag in der Retail-Domäne unter 25 %. Ein Coding-Agent kann mit pass@k leben, weil ein funktionierender Patch reicht. Ein Support-Agent kann das nicht: Jeder Kunde bekommt genau einen Trial. Führe jeden Task mindestens drei- bis fünfmal aus und berichte beide Zahlen.

Isolierte Umgebungen, sonst lügt der Eval

Ergebnisbewertung braucht eine echte Umgebung: eine befüllte Datenbank, eine Sandbox für Datei- und Shell-Tools, gemockte externe APIs. Anthropic betont, dass jeder Trial in einem sauberen Zustand starten muss, weil geteilter Zustand korrelierte Fehler verursacht und Scores aufblähen kann. Ihr Beispiel: In internen Evals verschaffte sich Claude bei manchen Tasks einen unfairen Vorteil, indem es die git-Historie früherer Trials las.

• Seed pro Trial. Datenbank aus einer Fixture hochfahren, laufen lassen, gegen den Zielzustand diffen, wegwerfen.
• Zeit und Zufall einfrieren, wo Tools davon abhängen ("Bestellungen der letzten Woche").
• Die Außenwelt deterministisch mocken, die Fehlerantworten aber realistisch halten: Timeouts, 429er und Validierungsfehler gehören zu dem, was du testest.
• Den Harness identisch zur Produktion halten: gleicher System-Prompt, gleiche Tool-Beschreibungen, gleiche Limits. Anthropics Punkt: Du evaluierst Modell und Harness zusammen.

LLM-Judges für Trajektorien

Manche Qualitäten kann im großen Maßstab nur ein Modell bewerten: Hat der Agent eine sinnvolle Rückfrage gestellt, hat er die Ablehnung höflich erklärt, war der Plan vernünftig. agentevals liefert create_trajectory_llm_as_judge mit einem Standard-Prompt für Trajektorien-Genauigkeit; die meisten Eval-Frameworks haben ein Pendant. Die Regeln dafür sind dieselben wie für jeden Judge, nur strenger, weil Transkripte lang sind:

• Ein Rubrikpunkt pro Dimension, jeweils mit konkreter Beschreibung von Bestehen und Scheitern.
• Gib dem Judge einen Ausweg. Anthropic empfiehlt eine explizite Antwort "Unknown", wenn dem Transkript die Information fehlt, damit der Judge nicht rät.
• Teilpunkte bei mehrstufigen Tasks vergeben. Ein Support-Agent, der das Problem erkannt und den Kunden verifiziert, aber die Erstattung verfehlt hat, ist besser als einer, der sofort scheitert, und deine Scores sollten das zeigen.
• Gegen Menschen kalibrieren, an einer Stichprobe, bevor du dem Judge vertraust, und erneut prüfen, wenn du das Judge-Modell wechselst.

Capability-Suites, Regression-Suites und woher Tasks kommen

Anthropic unterscheidet zwei Arten von Suites. Capability-Evals fragen, was der Agent kann, und sollten mit niedriger Bestehensquote starten, damit du etwas zu erklimmen hast. Regression-Evals fragen, ob er noch kann, was er konnte, und sollten nahe 100 % liegen. Werden Capability-Tasks zuverlässig, wandern sie in die Regression-Suite. Nähert sich eine Capability-Suite 100 %, sagt sie nichts mehr aus; ihr Beispiel ist SWE-bench Verified, wo die Scores bei etwa 30 % begannen und Frontier-Modelle inzwischen über 80 % liegen.

Woher Tasks kommen, zählt mehr als ihre Anzahl. Anthropic rät, früh mit 20 bis 50 einfachen Tasks aus echten Fehlern zu starten, weil frühe Änderungen große Effekte haben und kleine Stichproben sie erkennen. Meine Quellen, nach Wert sortiert: Produktions-Traces, bei denen etwas schiefging (aus deiner Observability-Pipeline), die manuellen Prüfungen, die du vor einem Release ohnehin machst, und Support-Tickets. Synthetische Tasks füllen Lücken; sie sollten nicht die Basis sein.

Tooling: wo Traces und Grader leben

Du brauchst drei Dinge: eine Möglichkeit, vollständige Traces zu erfassen, einen Runner, der Tasks mehrfach gegen eine isolierte Umgebung ausführt, und einen Ort, an dem Bewertungen über die Zeit gespeichert werden. OpenAIs Plattform bietet Trace Grading, das Agenten-Traces im Dashboard bewertet und in Eval-Runs überführt. Open-Source-Frameworks (agentevals mit pytest- oder Vitest-Integration, DeepEval, Ragas, Promptfoo) laufen in der CI. Observability-Plattformen wie Langfuse verbinden Produktions-Traces mit Datasets. Die Wahl zählt weniger als die Gewohnheit: Jede Agentenänderung durchläuft die Regression-Suite, bevor sie ausgeliefert wird, und die Budgets der Agentenschleife gehören zu dem, was du prüfst.

Checkliste

1. Das Ergebnis gegen den Zustand der Umgebung bewerten, nicht gegen die finale Nachricht.
2. Die wenigen zwingenden Regeln als Code-Invarianten über die Trajektorie ausdrücken.
3. Referenz-Trajektorien mit dem lockersten Match-Modus nutzen, der den Fehler noch fängt (superset oder subset vor strict).
4. Jeden Task drei- bis fünfmal ausführen; pass@1 und pass^k berichten.
5. Jeden Trial in einer sauberen, befüllten Umgebung starten, die der Produktion entspricht.
6. LLM-Judges mit einem Rubrikpunkt pro Dimension, einer Option Unknown und Teilpunkten nutzen, gegen Menschen kalibriert.
7. Eine Capability-Suite und eine Regression-Suite pflegen; Tasks zwischen ihnen befördern.
8. Tasks aus echten Fehlern gewinnen und gescheiterte Transkripte jede Woche lesen.

Für die Retrieval-Seite von Agenten, die Dokumente durchsuchen, beschreibt RAG evaluieren die Metriken. Wenn du Unterstützung beim Aufbau von Agenten-Evals für dein Team willst, siehe AI Engineering.

Quellen

1. Anthropic: Demystifying evals for AI agents (Jan 2026)
2. Yao et al.: τ-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains (2024)
3. Barres et al.: τ²-Bench: Evaluating Conversational Agents in a Dual-Control Environment (2025)
4. LangChain: agentevals (GitHub)
5. DeepEval docs: Tool Correctness
6. Ragas docs: Agentic or tool use metrics
7. OpenAI API docs: Trace grading