# Dein Agent scheiterte drei Schritte vor dem Fehler Canonical URL: https://huecki.com/blog/dein-agent-scheiterte-vor-dem-fehler/ Markdown URL: https://huecki.com/blog/dein-agent-scheiterte-vor-dem-fehler.md Language: German Published: 2026-07-22 Updated: 2026-07-22 Author: Dominic Hückmann Topic: KI-Agent Reliability - Agent topics: Context Engineering, Agent Evals, LLM-native Engineering - Tags: KI-Agenten, Agent Debugging, Observability, Evaluation, Developer Workflow - Audience: Teams mit Coding-Agenten, Entwickler von Browser- und Workflow-Agenten, Agent-Plattform-Teams mit Trace-Logging - Concepts: agent-traces, root-cause-attribution, checkpoint-reruns, regression-cases, agent-observability Thesis: Agenten-Traces werden erst dann zu einem Debugging-System, wenn sie Symptom und Ursache trennen und jede Reparatur gegen einen neuen Lauf testen. Content status: field-note ## Summary Bei langen Agentenläufen ist der letzte Fehler oft nur das Symptom. Der bessere Debugging-Loop sucht den frühesten kausal verantwortlichen Schritt, formuliert eine minimale Korrektur und prüft sie in einem kontrollierten Rerun. ## Description AgentDebugX zeigt einen besseren Debugging-Loop für KI-Agenten: sichtbaren Fehler erkennen, die frühere Ursache belegen, gezielt reparieren und den Fix durch einen Rerun prüfen. ## Body ## Kurz erklärt Dein Agent meldet im Schritt 18 einen fehlgeschlagenen Tool Call. Also reparierst du Schritt 18. Das Problem begann aber vielleicht in Schritt 7: Der Planner vergaß eine Nebenbedingung. In Schritt 11 wurde deshalb das falsche Objekt gewählt. Schritt 18 ist nur der Moment, in dem die Welt widerspricht. Genau hier wird Agent-Observability oft überschätzt. Ein Trace zeigt, **was** nacheinander passiert ist. Er sagt noch nicht, **welcher frühere Schritt den Lauf zum Scheitern gebracht hat**. Das neue Open-Source-Projekt [AgentDebugX](https://arxiv.org/abs/2607.18754) baut deshalb einen geschlossenen Debugging-Loop: Der nützliche Gedanke ist nicht das Dashboard. Es ist die Trennung zwischen Symptom, Ursache und Beweis. ## Der letzte rote Schritt ist selten die ganze Geschichte Bei normalem Code führt ein Stacktrace oft nah an die fehlerhafte Stelle. Bei Agenten ist die Kette lockerer: ```txt Ziel → Plan → Memory → Tool-Auswahl → Tool-Ergebnis → Handoff → Antwort ``` Ein alter Memory-Eintrag kann einen plausiblen Plan vergiften. Ein falscher Handoff kann erst fünf Tool Calls später auffallen. Ein Browser-Agent kann korrekt klicken und trotzdem auf dem falschen Account arbeiten, weil er eine frühere Observation falsch interpretiert hat. Deshalb braucht ein Agent-Debugger zwei Marker: - **Manifestation:** Wo wurde der Fehler sichtbar? - **Root cause:** Welcher frühere Schritt machte den Fehlschlag wahrscheinlich unvermeidbar? AgentDebugX behandelt Attribution nicht als sichere Wahrheit, sondern als Hypothese mit Schritt, Agent, Evidenz und Provenienz. Das ist wichtig: Eine gut formulierte Diagnose kann genauso halluziniert sein wie die Agent-Antwort selbst. ## Der Workflow zum Kopieren Du brauchst AgentDebugX nicht zwingend, um das Muster zu testen. Für einen internen Coding- oder Workflow-Agenten reicht zunächst ein strukturierter Incident-Loop. Kopier dafür diesen Prompt über einen vollständigen, redigierten Trace: ```txt Analysiere diesen fehlgeschlagenen Agentenlauf. Gib zurück: 1. den sichtbaren Fehler und seinen Schritt 2. den frühesten kausal verantwortlichen Schritt 3. die dort eingeführte falsche Annahme 4. konkrete Evidenz aus früheren und späteren Trace-Events 5. eine alternative Ursache, die du verworfen hast, plus Begründung 6. die minimale Recovery Action 7. einen Rerun Guard mit eindeutigem Pass/Fail Regeln: - Verwechsle zeitliche Reihenfolge nicht mit Kausalität. - Wenn die Evidenz nicht reicht, antworte UNCERTAIN. - Verändere beim Rerun nur die diagnostizierte Ursache. - Ein simulierter Verlauf ist kein Beweis für einen erfolgreichen Fix. ``` Der Gegenkandidat in Punkt 5 ist entscheidend. Ohne ihn verankert sich ein Diagnosemodell schnell am lautesten Fehler und schreibt rückwirkend eine überzeugende Geschichte. ## Was AgentDebugX tatsächlich zeigt Das Paper berichtet auf dem Who&When-Benchmark für `qwen3.5-9b` eine exakte Agent-und-Schritt-Zuordnung von 28,8 Prozent. Der stärkste untersuchte Single-Pass-Ansatz erreicht 21,7 Prozent. Auf GAIA reparierte DeepDebug 13 von 73 zuvor fehlgeschlagenen Aufgaben in einem einzelnen Rerun; drei entkoppelte Self-Correction-Baselines reparierten 4 bis 6. Das ist ermutigend, aber keine Magie. Selbst der beste berichtete Wert bedeutet, dass eine strikte Zuordnung in der Mehrzahl der Benchmark-Fälle nicht exakt stimmt. Außerdem wurde der GAIA-Vorteil als komplettes Rezept evaluiert; er isoliert nicht, welcher Anteil allein aus der besseren Attribution kommt. Die richtige Produktentscheidung lautet deshalb nicht: „Lass das Diagnosemodell den Agenten automatisch reparieren.“ Sie lautet: „Nutze Attribution, um einen kleinen, prüfbaren Rerun vorzubereiten.“ ## Aus einem Fix wird erst durch den Rerun ein Befund Ein guter Rerun hält möglichst viel konstant: ```txt gleiches Ziel gleiche Eingangsdaten gleiche Berechtigungen gleiche Bewertung nur die diagnostizierte Korrektur verändert ``` Dann vergleichst du Original und Branch. Nicht nur auf „Task passed“, sondern auch auf neue Nebenwirkungen: mehr Tool Calls, höhere Kosten, übersprungene Constraints oder einen Fehler, der lediglich später auftaucht. Wenn der Branch besteht, speicherst du Trace, Diagnose, Korrektur und Guard als Regression Case. Beim nächsten ähnlichen Incident hast du nicht nur Erinnerung, sondern eine wiederholbare Prüfung. ## Wo es gefährlich wird Agenten-Traces können Prompts, Tool-Argumente, Kundendaten, Screenshots, Tokens und interne URLs enthalten. AgentDebugX ist local-first und teilt Failure Bundles nur opt-in. Trotzdem sagt das Projekt selbst klar: Pattern-basierte Redaction garantiert nicht, dass alle sensiblen Inhalte entfernt wurden. Der praktische Test ist langweilig und gut: > Kannst du zeigen, welcher frühere Schritt den Fehler ausgelöst hat, welche minimale Änderung ihn behebt und welcher neue Lauf das beweist? Wenn nicht, hast du einen Trace. Noch keinen Debugging-Loop. ## Quellen - [AgentDebugX Paper](https://arxiv.org/abs/2607.18754) - [AgentDebugX auf GitHub](https://github.com/AgentDebugX/AgentDebugX) - [AgentDebugX Projekt und Demo](https://www.agentdebugx.com/) ## FAQ ### Warum reicht ein Agent-Trace nicht zum Debuggen? Ein Trace zeigt die Reihenfolge der Ereignisse. Er sagt aber nicht automatisch, welcher frühere Schritt den später sichtbaren Fehler kausal ausgelöst hat. ### Was ist Root-Cause Attribution bei KI-Agenten? Sie ordnet einen fehlgeschlagenen Lauf dem Agenten und dem frühesten entscheidenden Schritt zu, dessen Korrektur den Fehler wahrscheinlich verhindert hätte. ### Was sollte nach der Diagnose passieren? Eine minimale Korrektur wird ab einem geeigneten Checkpoint erneut ausgeführt und gegen das ursprüngliche Ziel bewertet. Erst ein erfolgreicher Rerun macht aus der Diagnose belastbare Evidenz. ## Related - Eine Failure Vocabulary benennt wiederkehrende Fehler; Root-Cause Attribution lokalisiert den verantwortlichen Schritt im einzelnen Lauf.: agent-failure-vocabulary - Erst eine belegte Diagnose sollte aus einem fehlgeschlagenen Lauf eine dauerhafte Agent-Regel machen.: failed-agent-runs-should-become-skills - Kontrollierte Reruns und gespeicherte Regression Cases verbinden Debugging mit Evaluation.: perfect-automated-ai-agent-eval-stack ## Source References - [AgentDebugX: An Open-Source Toolkit for Failure Observability, Attribution, and Recovery in LLM Agents](https://arxiv.org/abs/2607.18754) (paper) - [AgentDebugX GitHub repository](https://github.com/AgentDebugX/AgentDebugX) (code) - [AgentDebugX project and demo](https://www.agentdebugx.com/) (project)