Agent-Planungsfähigkeit messen: Inferenztiefe, Aufgabenzerlegung und Selbstkorrektur in der Praxis

Die Agent-Evaluation lief über Nacht, 94 % Genauigkeit – sieht gut aus. In Produktion kamen innerhalb von drei Tagen elf Nutzerbeschwerden: Tasks blieben mitten im Prozess hängen, es gab Endlosschleifen beim gleichen Tool-Call oder wichtige Schritte wurden übersprungen.

Klassische Evaluationsmethoden greifen zu kurz. 94 % Genauigkeit sagt nur, dass einzelne Antworten stimmen – nicht, ob ein Agent sieben- oder achtschrittige Reasoning-Tasks durchhält. Wie eine Prüfung, die nur Multiple Choice testet: hohe Punktzahl, aber im Job unbrauchbar.

Wie misst man Agent-Planungsfähigkeit? Warum reicht Genauigkeit allein nicht? Wie baut man ein Evaluations-Setup, das echte Probleme findet? Dieser Artikel erklärt Methoden für Inferenztiefe, Aufgabenzerlegung und Selbstkorrektur und vergleicht AgentBench, ToolBench, ACPBench und weitere Benchmarks.

1. Warum ist Agent-Evaluation komplexer als Modell-Evaluation?

Modell-Evaluation ist eigentlich klar: Frage stellen, Antwort prüfen. Multiple Choice A oder B, Code-Generierung gegen Tests, Übersetzungsqualität – viele Dimensionen, aber die Logik ist eindeutig.

Bei Agenten sieht das anders aus. Das Engineering-Team von Anthropic schrieb 2025 in einem Blog: Agent-Fähigkeit ist „Prozessfähigkeit“, nicht „Punktfähigkeit“. Es geht nicht um „weiß es“, sondern um „trifft es in komplexen Umgebungen eine Reihe richtiger Entscheidungen“.

Konkret brauchen Agenten sechs Kernfähigkeiten:

1. Tool-Calling: Wissen, wann welches Tool mit welchen Parametern
2. Aufgabenzerlegung: Große Ziele in ausführbare Teilschritte mit sinnvollen Abhängigkeiten
3. Reasoning: Multi-Hop-Inferenz Schritt für Schritt, nicht alles in einem Schritt
4. Gedächtnis: Kontext behalten, Schritt 2 ohne Schritt 1 nicht vergessen
5. Selbstkorrektur: Fehler erkennen, Strategie anpassen, nicht stur weiter
6. Langzeitplanung: Lange Ketten mit Dutzenden Schritten ohne Abweichung

Klassische Metriken – Genauigkeit, F1, BLEU – zielen auf Einzelausgaben. Agenten brauchen Prozess-Evaluation – deutlich komplexer.

Beispiel: Ein Agent soll einen Flug von Peking nach Shanghai buchen – morgen Nachmittag, Budget max. 800 Yuan. Einfach klingend, aber es braucht:

• Flugdaten abfragen (Tool-Call)
• Ergebnisse filtern (Reasoning)
• Bei keinem passenden Flug: Zeit oder Budget lockern (Entscheidung)
• Buchungs-API aufrufen (Tool-Call)
• Fehler behandeln (Selbstkorrektur)

Jeder fehlerhafte Schritt bedeutet Task-Fail. Nur das Endergebnis „gebucht ja/nein“ zu prüfen, verdeckt viel: falsche Uhrzeit, Budget überschritten ohne Erkennen, API-Fehler ohne Retry.

Deshalb ist eval-driven development in der Agent-Welt so wichtig. Anthropic empfiehlt: Evaluation schon in der Entwicklung designen und Iteration daran ausrichten – nicht erst nach dem Go-live Probleme entdecken.

2. Kern-Dimensionen der Agent-Planungs-Evaluation

Drei Dimensionen stehen im Mittelpunkt: Aufgabenzerlegung, Inferenztiefe, Langzeitkonsistenz.

Aufgabenzerlegung

Kurz: Kann der Agent ein großes Ziel in ausführbare Teilschritte zerlegen, deren Beziehungen sinnvoll sind?

Kernmetrik: Plan Graph Coherence (Kohärenz des Planungsgraphen). Die Schritte des Agenten werden als gerichteter Graph modelliert – Knoten = Teilaufgaben, Kanten = Abhängigkeiten. Zwei Prüfpunkte:

1. Topologische Sortierung: Gibt es eine sinnvolle Ausführungsreihenfolge ohne Zyklen wie „B vor A, aber A vor B“?
2. Keine zyklischen Abhängigkeiten: Der Graph darf keine Ringe enthalten

Ein Fail-Beispiel: Agent soll einen Datenanalyse-Bericht schreiben und plant:

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

Preise ansehen →Anzeige

1. Daten sammeln
2. Daten bereinigen
3. Daten analysieren
4. Bericht erstellen
5. Basierend auf Analyse weitere Datensammlung

Schritt 5 springt zurück zu Schritt 1 – der Agent erkennt den Zyklus nicht und hängt in einer Endlosschleife.

Typische Fehlermuster:

• Zyklische Abhängigkeit: Schritte bilden einen Ring
• Schritte überspringen: Direkt zum Ergebnis, wichtige Zwischenschritte fehlen
• Unvollständige Teilaufgaben: Zerlegung reicht nicht für das Ziel

Inferenztiefe

Hier geht es um Multi-Step-Reasoning. DeepSeek-V3-0324 erreicht laut Technical Report 91 % bei Multi-Hop-Tests. Was bedeutet „Multi-Hop“?

Von einem bekannten Fakt aus braucht es N Inferenzschritte zur Antwort. Beispiel:

• Gegeben: A ist größer als B, B ist größer als C
• Frage: Wer ist größer, A oder C?
• Das ist ein 2-Hop-Problem

In der Praxis sind oft 5+ Schritte nötig. Nutzer fragt: „Finde das umsatzstärkste Produkt des letzten Monats und erkläre, warum es gut lief.“ Das erfordert:

1. Verkaufsdaten des letzten Monats abfragen
2. Sortieren, Top-Produkt finden
3. Produkteigenschaften analysieren
4. Mit anderen Produkten vergleichen
5. Gründe zusammenfassen

Jeder Schritt baut auf dem vorherigen auf. Metrik: Multi-Hop-Genauigkeit – aufgeschlüsselt nach Hop-Anzahl. Oft funktionieren 3 Hops, bei 5 bricht es ein.

Langzeit-Planungskonsistenz

Hier scheitern viele Agenten. Bei einem 50-Schritt-Task: Erinnert sich der Agent bei Schritt 30 noch an den ursprünglichen Kontext?

Metrik: State Drift Rate – Anzahl Zustandsabweichungen vom erwarteten Zustand geteilt durch Gesamtschritte.

Ein realer Fall: Support-Agent bearbeitet Erstattung, alles läuft – dann sagt der Nutzer „Nein, ich meinte die andere Bestellung“. Der Agent verliert den Anker, alles dreht sich um „die andere Bestellung“, obwohl die ursprüngliche Erstattung gemeint war. Das ist State Drift.

Idealerweise liegt State Drift Rate unter 0,05 – maximal 5 Abweichungen pro 100 Schritte. Viele Open-Source-Agenten liegen bei 0,15–0,25.

3. Benchmarks im Detail

Es gibt viele Agent-Benchmarks mit unterschiedlichen Schwerpunkten. Vier etablierte im Vergleich:

AgentBench: der Allrounder

AgentBench (Tsinghua, ICLR’24) deckt LLM-as-Agent am breitesten ab – 8 Umgebungen:

• Betriebssystem-Interaktion
• Datenbankabfragen
• Wissensgraph-Reasoning
• Shopping-Szenarien
• Suchmaschine
• Haushaltsplanung
• Web-Browsing
• Videospiele

29 LLMs wurden getestet – solide Quer-Vergleiche. Für einen schnellen Überblick reicht oft die vereinfachte AgentBench-Variante.

Schwäche: Keine explizite Selbstkorrektur-Evaluation – nur „beim ersten Versuch richtig“, nicht „Fehler erkennen und korrigieren“. In Produktion ist Letzteres oft entscheidend.

ACPBench: Experte für Inferenztiefe

IBM ACPBench testet Planungslogik und tiefe Inferenz. ACP = Action, Change, Planning.

Besonderheit: formalisierte Reasoning-Validierung. Nicht nur Endergebnis, sondern ob jeder Inferenzschritt logischen Regeln folgt – Voraussetzungen, Kausalität.

Geeignet für tiefe Planungs-Tests. Enger Fokus, wenig zu Tool-Calls oder Multimodalität.

ToolBench: Tool-Calling

ToolBench misst API-Tool-Nutzung – ideal für tool-lastige Agenten.

Groß angelegte API-Planning-Szenarien prüfen:

• Richtige API-Auswahl
• Korrekte Parameter
• Logik bei verketteten API-Calls
• Fehlerbehandlung bei API-Failures

Sehr praxisnah für Tool-Nutzungsfähigkeit.

DeepPlanning: Langzeit-Planung

DeepPlanning testet lange agentische Planungsketten – 20–50+ Schritte statt 5–10.

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

Jetzt starten →Anzeige

Wichtig für Langzeitkonsistenz: Bleibt das ursprüngliche Ziel erhalten? Verliert der Agent die Richtung?

Auswahl-Empfehlung

Praxis: AgentBench als Baseline, dann je nach Business-Fokus spezialisierte Benchmarks – ToolBench für Tool-Agents, ACPBench + DeepPlanning für komplexe Planung.

4. Selbstkorrektur in der Evaluation

Dieses Kapitel ist vermutlich das wichtigste. Agenten machen in Produktion Fehler – entscheidend ist: Erkennung und Korrektur.

Warum Selbstkorrektur zählt

Zahlen: Reflexion hebt HumanEval von 80 % auf 91 % – 11 Prozentpunkte. In AlfWorld: 130 von 134 Challenges gelöst, 97 % Erfolgsrate.

"Reflexion ist ein Self-Reflection-Framework: Agent analysiert nach Fehlschlag die Ursache und passt die Strategie an – HumanEval von 80 % auf 91 %, AlfWorld 97 % (130/134)."

Galileo-Forschung: Self-Reflection steigert Problemlösung um 9–18,5 %.

Wie Reflexion funktioniert

Vier Schritte:

1. Ausführen: Agent versucht den Task
2. Reflektieren: Bei Fehlschlag Ursache analysieren
3. Korrigieren: Strategie anpassen
4. Wiederholen: Mit neuer Strategie erneut versuchen

Entscheidend ist Reflexion – nicht blind retry, sondern „warum falsch“ und „was ändern“. Das erfordert Metakognition.

Selbstkorrektur evaluieren

Schritt 1: Kontrollierte Fehler injizieren

In der Testumgebung reproduzierbare Fehler erzeugen:

• Tool-Call-Timeout
• API-Fehlercodes
• Falsches Parameterformat
• Nicht existierende Ressourcen

Schritt 2: Reaktion beobachten

Protokollieren:

• Erkennt der Agent den Fehler?
• Analysiert er die Ursache?
• Welche Korrekturstrategie?
• Erfolg nach Korrektur?
• Wie viele Retries?

Schritt 3: Metriken

Drei Kernmetriken:

1. Korrekturerfolgsrate: Anteil selbst korrigierter und erfolgreich abgeschlossener Tasks nach Fehler
2. Durchschnittliche Retry-Anzahl: Versuche von Fehler bis Erfolg
3. End-Erfolgsrate: Gesamterfolg inkl. Korrekturen

Gute Evaluation unterscheidet „beim ersten Mal richtig“ und „falsch, aber korrigiert“.

Praxisbeispiel

Task: Nutzerdaten aus DB abfragen und Bericht generieren.

Erster Lauf: falsche Query, leeres Ergebnis.

• Ohne Selbstkorrektur: Bericht mit „keine Daten gefunden“ aus leerem Resultat
• Mit Selbstkorrektur: leeres Resultat erkannt, Query überdacht, korrigiert, erneut versucht

Im Report getrennt ausweisen:

• Erstversuch-Erfolgsrate
• Erfolgsrate nach Korrektur
• Endgültige Fehlerrate

Erst zusammen ergibt sich ein vollständiges Agent-Profil.

5. Eigenes Agent-Evaluations-Setup

Theorie reicht – hier eine dreistufige Architektur zum direkten Einsatz.

Alibaba Cloud - Top-Wahl für Entwickler, exklusiv 15 % Rabatt auf Lighthouse-Server

15 % Rabatt sichern →Anzeige

Dreistufige Architektur

Stufe 1: Basisfähigkeiten

Einzelne Skills isoliert testen:

• Tool-Call-Korrektheit: API und Parameter
• Einfache Aufgabenzerlegung
• Ein-Schritt-Reasoning-Genauigkeit

Unit-Test-Denken: unabhängige, isolierte Tests.

Stufe 2: Szenario-Tasks

Simulierte Business-Flows:

• Typische Prozessabläufe definieren
• Je 5–15 Schritte
• Normal- und Fehlerpfade (Korrektur nötig)

Hier werden Fähigkeiten kombiniert.

Stufe 3: Gesamtbewertung

Aggregation:

• Scores pro Dimension
• Gewichtete Gesamtbewertung (Business-Prioritäten)
• Visualisierter Report

Standardisierter Evaluations-Flow

# Evaluations-Umgebung starten
docker compose -f eval-spec.yml up --build

# Benchmark ausführen, 3 Durchläufe für Mittelwert
python run_eval.py --benchmark agentbench-v2.1 --num-trials 3

# Report exportieren
python export_report.py --format markdown --output eval_results.md

Wichtig: 3 Wiederholungen. Agent-Output ist stochastisch – ein Lauf reicht nicht.

Kernmetriken-Referenz

Schwellwerte sind Erfahrungswerte – je nach Szenario anpassen.

Fazit

Kernbotschaft: Agent-Evaluation misst Prozessqualität, nicht nur Endergebnis. Klassische Metriken sagen „richtig oder falsch“ – Agenten brauchen feinere Prozessanalyse: Wie kam das Ergebnis zustande? Gab es Umwege? Konnte der Agent korrigieren?

eval-driven development sollte Standard in der Agent-Entwicklung sein. Evaluation früh aufsetzen, nicht erst nach dem Go-live.

Praktischer Einstieg:

1. AgentBench-Baseline – wo steht Ihr Agent?
2. 2–3 Spezial-Benchmarks passend zum Business
3. Dreistufige Architektur, standardisierter Flow
4. Bei jeder Iteration evaluieren und vergleichen

Agent-Zuverlässigkeit basiert auf Daten, nicht auf Bauchgefühl. Diese Methoden sollen typische Fallstricke vermeiden helfen.

Referenzen

• Anthropic Engineering: Demystifying evals for AI agents - Offizieller Engineering-Blog, 2025
• AgentBench: Evaluating LLMs as Agents (ICLR’24) - Tsinghua, akademischer Benchmark
• Survey on Evaluation of LLM-based Agents - arXiv-Übersicht, 2026
• Self-Reflection in LLM Agents - Reflexion-Paper
• ACPBench: Reasoning about Action, Change, and Planning - IBM-Forschung