Agent-Bewertungsbenchmarks in der Praxis: Leitfaden von AgentBench bis DeepEval

Wir haben einen Support-Agent mit 100 Testfällen geprüft – Erfolgsrate 78 %. Klingt okay. Derselbe Lauf noch einmal: 65 %.

Agent-Bewertung ist nicht dasselbe wie Q&A-Bewertung. Fragen Sie ein Modell nach der Hauptstadt Frankreichs: „Paris“ ist richtig, „Marseille“ falsch – klar. Agents planen, rufen Tools auf und ändern unterwegs die Strategie. Dieselbe Aufgabe: heute Pfad A erfolgreich, morgen Pfad B gescheitert, übermorgen Pfad C wieder erfolgreich.

Nach Papers und Docs zu AgentBench und WebArena war ich verwirrt – bis Projekterfahrung zeigte: Nicht nur das Ziel zählen, sondern die Trajektorie.

1. Warum ist Agent-Bewertung schwieriger als normales Q&A?

Das Kernproblem: Autonomie. Bei jedem Lauf kann der Agent einen anderen Pfad wählen.

Ein konkretes Beispiel: Ein Reisebuchungs-Agent mit der Aufgabe „Buche morgen den günstigsten Flug von Peking nach Shanghai“. Erster Lauf: Ctrip-Suche, drei Flüge verglichen, günstigster gebucht – perfekt. Zweiter Lauf, gleiche Eingabe: nach Ctrip noch Fluggesellschaft B, dann fünf Minuten Endlosschleife, Timeout.

Gleiche Eingabe, andere Trajektorie. Sie brauchen kein einfaches „richtig/falsch“, sondern ein Framework für den gesamten Ablauf.

Dreischichtiges Bewertungsframework

Laut Anthropic sollten Sie Agents in drei Schichten betrachten:

Reasoning-Schicht: Ist die Planung stimmig? Wurde die Aufgabe verstanden? Ist der Ausführungsplan sinnvoll?

Action-Schicht: Richtige Tools? Korrekte Parameter? Sinnvolle Reihenfolge der Tool-Aufrufe?

Gesamtausführung: Wurde die Aufgabe abgeschlossen? Wie viele Schritte? Wie effizient?

Eine Zahl aus der DeepEval-Dokumentation blieb hängen: Tool-Aufruf-Fehler sind die häufigste Agent-Ursache – rund 40 % der Fehlschläge durch falsches Tool oder falsche Parameter. Die meisten Probleme liegen in der Action-Schicht, nicht im Reasoning.

Grenzen klassischer Metriken

Bei Q&A reichen Genauigkeit und F1. Bei Agents nicht.

Angenommen, Ihre Erfolgsrate liegt bei 78 %. Was sagt das? Fast nichts.

Mögliche Ursachen:

• Planung korrekt, Tool-Aufruf scheitert (Action)
• Planung von vornherein falsch (Reasoning)
• Planung und Tools ok, letzter Schritt scheitert (Gesamtausführung)

Jede Ursache verlangt andere Maßnahmen: Prompt/Modell, Tool-Definition/Validierung oder Grenzfall-Handling.

🔥 Verschwende keine Monate für ungenutzte Produkte! Teste deine SaaS-Nutzenversprechen mit Adsterra bei kleinem Budget →

Jetzt testen →Anzeige

Kernfrage: nicht „Hat es geklappt?“, sondern „Wo ist es schiefgelaufen?“

2. Fünf etablierte Bewertungsbenchmarks im Vergleich

Es gibt viele Benchmarks – hier fünf, die ich recherchiert oder selbst ausgeführt habe.

AgentBench: Gesamtkompetenz

AgentBench (Tsinghua, ICLR’24) war einer der ersten umfassenden LLM-as-Agent-Benchmarks: 8 Umgebungen – Datenbank, Web, API, Codeausführung usw.

Mein Eindruck: breite Abdeckung, gut für die Auswahl eines Agent-Backbones. Setup ist aufwendig (Docker), das Dev-Set braucht tausende LLM-Aufrufe – Kosten beachten.

Einsatz: Vergleich mehrerer Modelle als Agent-Rückgrat mit Gesamtscore.

WebArena: Web-Navigation

WebArena fokussiert echte Web-Umgebungen (Shop, Forum, Karte). Aufgaben wie „Post auf Reddit finden und kommentieren“ testen reale Browser-Interaktion.

Einsatz: Browser-Agent oder Web-Automatisierung.

τ-Bench: Mehrfachdialog

τ-Bench (tau-bench, mit Anthropic-Beteiligung) simuliert Retail-Support und Flugbuchung mit simulierten Nutzern – Mehrfachdialog statt Einzelschritt.

Einsatz: Dialog-Agenten für Support oder Buchung.

SWE-Bench: Code

SWE-Bench nutzt echte GitHub-Issues und PRs: Agent repariert Code und muss Tests bestehen.

Einsatz: Programmier-Assistent oder Code-Reparatur-Agent.

Claw-Eval / ACE-Bench: neu 2026

ACE-Bench (ehemals Claw-Eval) bietet konfigurierbare Schwierigkeit – Bewertung skaliert mit der Agent-Leistung.

Einsatz: interne, anpassbare und iterierbare Bewertung.

Benchmark-Auswahl

Empfehlung: zuerst AgentBench für eine Baseline, dann spezialisierte Benchmarks je nach Szenario.

3. Metriken für Agent-Bewertung

Sechs Kernmetriken decken die wichtigsten Ebenen ab.

1. Aufgabenerfolgsrate (Success Rate)

Wurde die Aufgabe erledigt? Vorsicht: Was heißt „erledigt“ – Selbstauskunft des Agents oder objektive Kriterien?

Bei „Flug buchen“ definiere ich z. B.:

• Buchungsnummer vorhanden
• Flugdaten korrekt
• Preis im erwarteten Rahmen

Je klarer die Abnahmebedingungen, desto aussagekräftiger die Metrik.

2. Tool-Aufruf-Genauigkeit

Zwei Teile: richtiges Tool, richtige Parameter.

In einem Projekt: 82 % Erfolgsrate, aber nur 68 % Tool-Genauigkeit – häufig Verwechslung von „Abfrage“ und „Buchung“.

3. Fortschrittsrate (Progress Rate)

Bei mehrstufigen Aufgaben: fünf Schritte, Scheitern in Schritt 4 → Erfolgsrate 0 %, Fortschritt 80 %. Sie sehen: nah am Ziel, letzter Schritt optimieren.

Vultr - Hochleistungs-NVMe-Cloud-Server mit 32 Standorten weltweit, Docker per Klick

Preise ansehen →Anzeige

4. Reasoning-Qualität

PlanQuality: Ist der Plan sinnvoll? Stimmen die Schrittlogiken?

PlanAdherence: Weicht die Ausführung vom Plan ab?

Oft per LLM bewertet – z. B. PlanQualityMetric in DeepEval.

5. Effizienz

StepEfficiency: Ist-Zeit vs. Mindestschritte (3 nötig, 10 genutzt → 30 %).

Token-Verbrauch: gleiche Aufgabe mit 1.000 vs. 5.000 Tokens – fünffache Kosten.

6. Stabilität

Zehn Läufe, gleiche Aufgabe – wie groß ist die Streuung der Erfolgsrate?

Ein Produktionsfall: Test ok, Live stark schwankend – kürzeres Request-Timeout in Produktion kappte Teilaufgaben.

Zuordnung zu den drei Schichten

Niedrige Werte in einer Schicht → gezielte Optimierung.

4. Open-Source-Tools: DeepEval vs. LangSmith vs. Arize Phoenix

DeepEval: Komponentenbewertung

DeepEval (Confident AI) ist ein Open-Source-Python-Framework für LLM- und Agent-Bewertung.

Kern: Bewertung auf Komponentenebene – an jedem Knoten messen, nicht nur am Endergebnis.

Sechs eingebaute Metriken:

• TaskCompletionMetric
• StepEfficiencyMetric
• ToolCorrectnessMetric
• ArgumentCorrectnessMetric
• PlanQualityMetric
• PlanAdherenceMetric

Mit @observe verfolgt DeepEval Reasoning und Tool-Aufrufe automatisch. Confident AI Cloud optional für Visualisierung und Datensätze – die Open-Source-Teile reichen oft.

LangSmith: LangChain-Ökosystem

Bei LangChain-Agents ist LangSmith am naheliegendsten: automatisches Tracing jeder LLM- und Tool-Ausführung.

Stärke: Full-Chain-Tracing. Schwäche: kommerziell, Kosten bei großem Volumen.

Arize Phoenix: Observability

Phoenix nutzt OpenTelemetry: LLM- und Tool-Aufrufe als Spans, Gesamtlauf als Trace – wie ein verteiltes System.

Besonders für Produktion: Anomalieerkennung, Performance-Analyse.

Tool-Auswahl

LangChain im Einsatz?
  → Ja: LangSmith bevorzugen
  → Nein: Produktions-Monitoring nötig?
       → Ja: Arize Phoenix + DeepEval
       → Nein: nur Entwicklung → DeepEval

Meine Kombination: DeepEval in der Entwicklung, Phoenix in Produktion.

5. Code: DeepEval für einen Reisebuchungs-Agent

Agent-Implementierung

from deepeval.tracing import observe
from deepeval.metrics import (
    PlanQualityMetric,
    PlanAdherenceMetric,
    ToolCorrectnessMetric,
    ArgumentCorrectnessMetric,
    TaskCompletionMetric,
    StepEfficiencyMetric
)

# Tools definieren
@observe(type="tool")
def search_flights(origin: str, destination: str, date: str):
    """Flüge suchen"""
    # In Produktion: echte API
    # Beispiel: simulierte Daten
    return [
        {"flight": "CA1234", "price": 500, "time": "08:00"},
        {"flight": "MU5678", "price": 450, "time": "10:30"},
        {"flight": "CZ9012", "price": 520, "time": "14:00"}
    ]

@observe(type="tool")
def book_flight(flight_number: str, passenger_info: dict):
    """Flug buchen"""
    # In Produktion: echte Buchungs-API
    return {"order_id": "ORD123456", "status": "confirmed"}

# Agent-Hauptfunktion
@observe(type="agent")
def travel_agent(user_input: str):
    """
    Reisebuchungs-Agent
    Eingabe: Buchungsanfrage
    Ausgabe: Buchungsergebnis oder Fehler
    """
    # Reasoning: Aufgabe parsen und planen
    @observe(type="reasoning")
    def parse_and_plan(input_text):
        # Produktion: LLM für Parsing/Planung
        # Beispiel: einfache Regeln
        plan = {
            "task": "book_flight",
            "origin": "北京",
            "destination": "上海",
            "date": "明天",
            "steps": ["search", "compare", "book"]
        }
        return plan

    plan = parse_and_plan(user_input)

    # Action-Schicht: Tools ausführen
    # Schritt 1: Flüge suchen
    flights = search_flights(
        plan["origin"],
        plan["destination"],
        plan["date"]
    )

    # Schritt 2: günstigsten Flug wählen
    cheapest = min(flights, key=lambda x: x["price"])

    # Schritt 3: buchen
    result = book_flight(
        cheapest["flight"],
        {"name": "测试用户"}
    )

    return result

Metriken konfigurieren

from deepeval import evaluate
from deepeval.test_case import LLMTestCase

# Testdaten
test_cases = [
    LLMTestCase(
        input="预订明天从北京到上海最便宜的航班",
        expected_output={"order_id": "ORD123456", "status": "confirmed"}
    ),
    LLMTestCase(
        input="帮我查一下下周三从广州到深圳的航班",
        expected_output={"flights": [...]}
    )
]

# Bewertungsmetriken
metrics = [
    TaskCompletionMetric(
        threshold=0.7,
        evaluation_model="gpt-4o"
    ),
    StepEfficiencyMetric(
        threshold=0.5,  # mind. 50 % Effizienz
        minimum_steps=3  # mindestens 3 Schritte
    ),
    ToolCorrectnessMetric(
        threshold=0.8
    ),
    ArgumentCorrectnessMetric(
        threshold=0.8
    ),
    PlanQualityMetric(
        threshold=0.7,
        evaluation_model="gpt-4o"
    )
]

Bewertung ausführen

# Variante 1: Einzelbewertung
for test_case in test_cases:
    result = travel_agent(test_case.input)
    test_case.actual_output = result

evaluate(test_cases, metrics)

# Variante 2: Batch mit Dataset
from deepeval.dataset import EvaluationDataset, Golden

dataset = EvaluationDataset(goldens=[
    Golden(input="预订明天从北京到上海最便宜的航班"),
    Golden(input="查找下周从成都到昆明的航班信息")
])

for golden in dataset.evals_iterator(metrics=metrics):
    output = travel_agent(golden.input)
    # Bewertung wird automatisch protokolliert

Ergebnisse lesen

Interpretation:

• Hohe Abschlussrate (85 %)
• Niedrige Schritteffizienz (45 %) – überflüssige Schritte
• Tools meist richtig (90 %), Parameter oft falsch (72 %)

Fokus: Argument-Logik und Schrittreduktion.

6. Bewertung in Produktion

Nach dem Go-Live ist die Bewertung nicht vorbei. Nutzereingaben sind heterogener, Grenzfälle häufiger, Last höher – Sie brauchen eine Schleife von Entwicklung bis Produktion.

Railway - Moderne Deployment-Plattform, ohne DevOps-Aufwand, in Minuten live

Jetzt starten →Anzeige

Entwicklung: Baseline

Zuerst AgentBench oder vergleichbar für Gesamtfähigkeit, dann eigener Datensatz für Ihr Szenario – typische Aufgaben, Grenzfälle, bekannte Fehler.

Checkliste:

• Abdeckung der Nutzerszenarien ≥ 80 %
• Baseline pro Metrik dokumentiert
• Fehlfälle mit Ursachenverteilung

Deployment: Canary und A/B

Nicht sofort 100 % Traffic. Vergleich Treatment vs. Control:

# Canary-/A/B-Bewertung (Beispiel)
def ab_test_evaluation():
    # Kontrollgruppe: alte Agent-Version
    control_results = evaluate_agent(old_agent, test_cases)

    # Treatment: neue Agent-Version
    treatment_results = evaluate_agent(new_agent, test_cases)

    # Schlüsselmetriken vergleichen
    comparison = {
        "success_rate": {
            "control": control_results.success_rate,
            "treatment": treatment_results.success_rate,
            "delta": treatment_results.success_rate - control_results.success_rate
        },
        "step_efficiency": {
            "control": control_results.step_efficiency,
            "treatment": treatment_results.step_efficiency,
            "delta": treatment_results.step_efficiency - control_results.step_efficiency
        }
    }

    return comparison

Canary-Stufen: 1 % → 24 h beobachten → 5 % → 10 % → 20 % → 50 % → 100 %, jeweils mit Metrik-Check.

Produktion: kontinuierliches Monitoring

Alarme bei plötzlichem Erfolgsrate- oder Latenz-Einbruch oder Tool-Ausfällen – bevor Nutzer es massenhaft melden.

Sampling: normale Aufgaben 1–5 %, Zahlung/Buchung 100 %, Fehler/Timeout 100 % in die Bewertungs-Warteschlange.

Kosten: kleine Modelle (gpt-4o-mini), asynchrone Bewertung, Circuit Breaker bei 100–1000 Samples.

Manuelle Prüfung

Automatik markiert „unsicher“ → menschliche Review. Wöchentlich 10–20 Fälle prüfen und die Auto-Bewertung kalibrieren.

Menschen finden auch Ton, Verwirrung, UX-Probleme ohne harte Metrik.

Geschlossene Schleife

Entwicklung
├── AgentBench
├── eigener Datensatz
└── Fehleranalyse
    ↓
Deployment
├── Canary (1 % → 5 % → …)
├── A/B
└── Rollback
    ↓
Produktion
├── Sampling (1–5 %)
├── Anomalie-Alarme
├── manuelle Queue
    ↓
Iteration
├── Ursachen
├── Prompt/Tools
└── erneute Bewertung
    ↓ (Zyklus)

Bewertung ist fortlaufend – Agents und Szenarien ändern sich.

Fazit

Agent-Bewertung heißt: Trajektorie, nicht nur Ziel.

Typische Fehler: 78 % reichen – in Produktion ±30 % Schwankung; Tools „ok“ – 40 % Fehler durch Parameter; nur Dev-Tests – Produktion anders.

Dreischichtiges Framework, fünf Benchmarks, DeepEval mit @observe und sechs Metriken geben Struktur.

Nächste Schritte:

1. AgentBench für Ihre Baseline
2. DeepEval für Schwachstellen auf Komponentenebene
3. Monitoring mit Anomalieerkennung und Stichproben-Review

Bewertung ist Startpunkt, nicht Endpunkt – sie muss mit dem Agent mitwachsen.