Wenn das Dashboard grün ist und der Agent falsch liegt: Überwachung des Zustands
Das Dashboard ist grün und der Agent liegt falsch: Fehler verstecken sich im zwischen den funktionierenden Schritten übertragenen Zustand. Welche Überwachungs-, Routing-Protokolle und Bewertungen aufgezeichnet werden müssen.
Quellen: When the Dashboard Is Green and the Agent Is Wrong: Tracing Multi-Step Failures Past the LLM Call
Ein grünes Dashboard und eine falsche Antwort
Beim Debuggen von KI-Agenten gibt es eine ärgerliche Besonderheit: Der Überwachungsbildschirm kann behaupten, alles sei in Ordnung. Der Modellaufruf ist abgeschlossen, die Tools haben ihre Arbeit erledigt, die APIs haben mit 200-Statuscodes geantwortet, die Latenz scheint normal und der Tokenverbrauch liegt bei dem erwarteten Wert. Aus Sicht der Infrastruktur geschieht nichts, und dennoch kann das Endergebnis völlig falsch sein.
Das ist nicht die offensichtliche Art von Fehlern, bei der ein Modell etwas Absurdes erfindet. Solche Fehler sind einfacher zu erkennen, denn man weiß zumindest, wo man anfangen soll. Die schwierigere Variante ist die, bei der jeder Schritt sinnvoll erscheint, technisch nichts zusammengebrochen ist und die Antwort so glaubwürdig ist, dass jemand darauf reagieren könnte.
Das Problem verschärft sich, da Systeme von einfachen LLM-Aufrufen zu Agenten und mehrschrittigen Workflows entwickeln. Bevor eine Antwort erscheint, kann die zugrundeliegende Information bereits mehrere Modelle, Tools, APIs, Transformationen und Router durchlaufen haben, sodass das Endmodell möglicherweise mit perfekten Ergebnissen auf Daten arbeitet, die bereits fünf Schritte zuvor beschädigt wurden. Dieser Aspekt der Agent-Überwachbarkeit benötigt weitaus mehr Aufmerksamkeit, als er derzeit erhält.
Eine Schema-Änderung, die niemand bemerkt
Betrachten wir eine routinemäßige Aufgabe im Bereich Kundenerfolg. Der Agent soll Kunden finden, deren Verlängerungen innerhalb von 30 Tagen anstehen, Konten markieren, die wahrscheinlich kündigen werden, und einen Bericht für das Erfolgsteam erstellen. Dabei kann er ein CRM abfragen, einen Risikoscore berechnen, aktuelle Support-Threads abrufen, die Produktnutzung überprüfen und schließlich ein LLM beauftragen, den Bericht zu schreiben.
Nun nehmen wir an, das CRM ändert eines seiner Antwort-Schemata. Gestern sah die Payload so aus.
{
"health_score": 42
}
Heute sieht es so aus.
{
"health": {
"score": 42
}
}
Die API ist weiterhin aktiv, die Anfrage ist weiterhin erfolgreich und das JSON lässt sich weiterhin parsen. Je nach Integrationsskript muss an keiner Stelle eine Ausnahme ausgelöst werden. Der Schaden tritt später auf, wenn die Normalisierungsschicht weiterhin nach health_score sucht und dem nächsten Schritt null übergeben wird.
Möglicherweise interpretiert das Risikobewertungssystem einen fehlenden Wert als neutral, oder die Anweisung besagt, einfach den verfügbaren Wert zu verwenden. In beiden Fällen setzt sich der Workflow fort und endet mit einem glaubwürdigen Bericht, der ein Konto ausschließt, von dem das Team eigentlich wissen sollte.
Wenn man sich nur auf die endgültige Erzeugung konzentriert, wird das Modell leichtfertig zum Sündenbock, wodurch die Leute dazu neigen, Anweisungen umzuschreiben, Modelle zu wechseln oder die Temperatur anzupassen, ohne die eigentliche Ursache anzugehen. Eine bessere Frage lautet, wann der Zustand erstmals falsch wurde – mit dieser Frage sieht das Debuggen eines Agenten völlig anders aus.
Erfolgsereignisse beweisen kein Verständnis
Ein kürzlich veröffentlichter Artikel über die Verwandlung des Webs in eine API für Agenten beschreibt, wie Software von der Bereitstellung von Informationen zur Ausführung von Aktionen im Auftrag eines Benutzers übergeht. Darin wird argumentiert, dass das Bereitstellen von Tools für ein Modell nur ein Teil des Prozesses sei, da Absichten, Berechtigungen, Laufzeitkontrollen sowie Nachvollziehbarkeit entscheidend seien, sobald die Agenten tatsächliche Aktionen ausführen.
Das Gleiche gilt für das Debuggen dieser Aktionen. Es ist hilfreich zu wissen, welches Tool ausgeführt wurde, doch das verrät nicht, ob der Rest des Workflows verstanden hat, was das Tool erzeugt hat. Stellen Sie sich einen Protokollauszug vor, der solche Informationen enthält.
crm.search_accounts
status: success
duration: 184ms
records: 47
Man erfährt, dass das CRM mit 47 Datensätzen antwortete. Unbekannt bleibt jedoch, ob alle 47 Datensätze unversehrt in der nächsten Schrittphase ankamen. Vielleicht gab es noch sechs weitere Seiten und die Paginierung endete nach der ersten. Möglicherweise wurde eine Betragsangabe von Dollar in Cent umgerechnet, oder ein UTC-Zeitstempel wurde später als Ortszeit interpretiert. Vielleicht änderte sich die Schreibweise eines Enums von „cancelled“ zu „canceled“, oder eine API begann, Fehler auf Anwendungsseite in einer Antwort zu melden, deren HTTP-Status scheinbar in Ordnung war.
Es handelt sich dabei um gewöhnliche Softwarefehler. Bei Agenten liegt das Besondere darin, dass das folgende Modell in der Regel unbeeinflusst weiterarbeitet, Daten annimmt, die glaubwürdig erscheinen, und darauf basierend weiterverarbeitet. Daher behebt ein leistungsstärkeres Modell nicht unbedingt etwas. Wenn die Eingabedaten bereits fehlerhaft sind, löst das Modell einfach das falsche Problem nur mit größerer Geschicklichkeit.
An den entscheidenden Schnittstellen sollten Sie in der Lage sein, die Eingabe, die Ausgabe, die der Antwort angewendete Transformation sowie das Ergebnis des nächsten Schritts zu betrachten. Es ist nicht notwendig, den gesamten Rohdatenstrom für immer aufzubewahren – ausreichend Daten, um nach einem Fehler den Ablauf wiederherstellen zu können, schon.
Aufspüren eines fehlenden Wettbewerbers
Die Tools werden immer besser. Die GenAI-Semantikkonventionen von OpenTelemetry beginnen, die Beschreibung von Modellaufrufen und Tool-Exekutionen zu standardisieren, und Frameworks wie das OpenAI Agents SDK verfolgen Generierungen, Toolaufrufe, Übergaben sowie Sicherheitsregeln. Das sind nützliche Rohdaten, doch es bleibt schwierig, eine Trace hilfreich zu gestalten, wenn der Workflow abgeschlossen ist und der eigentliche Fehler in dem zwischen zwei funktionierenden Schritten übertragenen Zustand verborgen ist.
Betrachten Sie einen vereinfachten Ablauf wie den in der Abbildung dargestellten.
Nehmen wir an, der Endbericht enthält keinen Wettbewerber, der offensichtlich hineingehört. Früher war die übliche Vorgehensweise, die Endanfrage zu öffnen und die Antwort des Modells zu überprüfen. Vielleicht waren die Anweisungen nicht stark genug, das Modell ignorierte einen Teil des Kontexts oder ein anderes Modell würde besser abschneiden. Von dort aus vorzugehen, ist heute nicht mehr die richtige Strategie.
Arbeiten Sie stattdessen rückwärts. Hat das Endmodell den fehlenden Wettbewerber erhalten? Wenn nicht, dann beim Ranking-Schritt? Wenn er vor dem Ranking verschwand, war er nach der Extraktion noch vorhanden? Wenn er nach der Extraktion vorhanden war, aber nach der Normalisierung fehlte, liegt das Problem genau an einer Grenze.
{
"company": "Example Corp",
"website": {
"url": "https://example.com"
}
}
obwohl der Normalisierungs Schritt dies erwartet hatte.
{
"company": "Example Corp",
"website": "https://example.com"
}
Nichts daran war dramatisch. Mitten im Verlauf änderte ein Objekt seine Form und ein Schritt handhabte es falsch, doch die meisten anderen Operationen in der Nähe sahen weiterhin in Ordnung aus. Solche Fehler verdienen es, nachverfolgt zu werden, denn andernfalls fällt die Schuld auf den am meisten sichtbaren Komponenten – unabhängig davon, was zuvor passiert ist.
Die praktische Lektion ist nicht, dass ein bestimmtes Observability-Produkt erforderlich ist. Vielmehr sollte eine Trace es ermöglichen, den Zustand im gesamten Workflow nachzuvollziehen, anstatt lediglich aufzulisten, welche Komponenten ausgeführt wurden. Es besteht ein großer Unterschied zwischen dem Wissen, dass Schritt 4 ausgeführt wurde, und dem Wissen darüber, was Schritt 5 von ihm erhalten hat.
Plan-Drift erscheint sinnvoll
Sobald ein Fehler im Zusammenhang mit den Tools festgestellt wird, ist dieser in der Regel klar definiert. Planabweichungen sind schwieriger zu erkennen, da ein Agent die ursprüngliche Aufgabe durch Schritte verlassen kann, die jeweils sinnvoll erscheinen. Stellen Sie sich vor, einem Agenten wird aufgetragen, fünf Lieferanten zu recherchieren, deren Preise und Zuverlässigkeit zu bewerten und eine Empfehlung zu erstellen – unter der Anweisung, sie nicht zu kontaktieren.
Der Agent findet die Lieferanten und beginnt mit der Datenerhebung. Zwei von ihnen geben keine Preise an, weshalb er nach einer anderen Lösung sucht. Schließlich entdeckt er ein verfügbares E-Mail-Tool. Seine Logik ist nicht absurd: Preise sind notwendig, werden jedoch nicht öffentlich bereitgestellt, und eine Nachricht an den Lieferanten könnte das Problem lösen. Gleichzeitig bricht er damit eine der wichtigsten Regeln der Aufgabe.
Wenn die Regel nur ein Satz ganz oben in einem wachsenden Kontextfenster ist, hängt alles davon ab, ob das Modell sie auch nach dem Hinzukommen von Tausenden von Tokens an Suchergebnissen, Tool-Ausgaben und Zwischenzuständen weiterhin als wichtig betrachtet. Einschränkungen mit tatsächlichen Folgen verdienen eine explizite Formulierung.
{
"objective": "Compare suppliers and prepare a recommendation",
"constraints": [
"Do not contact suppliers"
],
"completed_steps": [
"discover_suppliers",
"collect_public_pricing"
],
"next_action": "request_missing_prices",
"requested_tool": "send_email"
}
Nun hat die Anwendung etwas, was sie vor einer Aktion überprüfen kann. Sie kann den Tool-Aufruf ablehnen, eine menschliche Genehmigung verlangen oder den Agenten beauftragen, einen anderen Weg zu finden. Die richtige Reaktion hängt vom Workflow ab, doch der entscheidende Punkt ist, dass die Einschränkung nicht mehr ausschließlich in der Formulierung der Anweisung liegt.
Regeln wie eine Ausgabobergrenze, „Entwurf erstellen, aber nicht senden“ oder „Niemals die Produktionsumgebung berühren“ funktionieren auf dieselbe Weise. Einfache Sprache ist gut, um den Zweck der Absicht des Benutzers zu vermitteln, doch die wichtigen Berechtigungen und Grenzen sollten ebenfalls als Laufzeitkontrollen umgesetzt werden.
Die Software handhabt dies überall sonst genauso. Niemand würde in einem Kommentar schreiben „Bitte lassen Sie nicht, dass unautorisierte Benutzer die Datenbank löschen“ und das als Zugriffskontrolle bezeichnen, und Agenten verdienen keine Ausnahme, nur weil ihre Anweisungen auf Englisch sind.
Modell-Routing setzt eine Grenze
Das Routing stellt ein ähnliches Problem dar. Die Auswahl eines Modells ist nicht mehr einfach nur ein Konfigurationswert, sobald Qualität, Kosten, Latenz, Werkzeugnutzung sowie unterschiedliche Fähigkeiten der Modelle in einem Produktionsystem abgewogen werden müssen – und die Routing-Entscheidung wird zu einem Teil der Protokolldaten, die für das Debuggen benötigt werden.
Nehmen wir an, Schritt 6 läuft normalerweise mit Modell A. Während eines Live-Laufs wird der Anbieter rate limited, wodurch der Router auf Modell B umschaltet. Das ist der vorgesehene Notfallmechanismus, da der Workflow weiterhin funktioniert anstatt zu versagen. Allerdings formatiert Modell B die strukturierten Argumente für das nächste Werkzeug geringfügig anders. Sie bleiben weiterhin gültig und das Werkzeug funktioniert, doch ein Feld wird auf eine Weise gelesen, die das Ergebnis im weiteren Verlauf verändert.
Falls Berichte zur Überwachbarkeit nur das für den Workflow konfigurierte Modell angeben, könnte jemand Stunden damit verbringen, den Fehler am Modell A nachzustellen, obwohl eigentlich Modell B die Anfrage bearbeitet hat, die zum Fehler führte. Daher sollte eine Spur das angeforderte Modell, das Modell, das geantwortet hat, eventuelle Fallback-Lösungen, die aktive Routing-Strategie sowie festhalten, ob es sich um einen erneuten Versuch handelte. Es handelt sich dabei um keine aufregenden Informationen, aber die meisten hilfreichen Fehlersuche-Methoden in der Produktion auch nicht. Abgesehen von Demonstrationen besteht der größte Teil der Arbeit darin herauszufinden, welcher unscheinbare Detailwandel unbemerkt blieb.
Spurzustand – und nicht nur Ereignisse
Die Agent-Tools leisten heute hervorragende Arbeit dabei, die Struktur eines Laufs anzuzeigen – mit Modellaufrufen, Tools, Übertragungen, Wiederholungen und anderen Ereignissen in zunehmend nützlichen Trace-Ansichten. Der Fehler wäre es, anzunehmen, dass die Aufzeichnung mehrerer Ereignisse automatisch zu einer guten Überwachbarkeit führt. Ein Lauf mit zehn gut instrumentierten Abschnitten bleibt weiterhin unübersichtlich, wenn man nicht erkennen kann, welcher Zustand zwischen ihnen wechselte.
Eine kurze Liste von Fragen hilft bei problematischen Läufen. Was wollte der Benutzer ursprünglich? Welche Einschränkungen galten? Welchen Plan folgte das System? Was gab jedes Tool zurück und was erhielt der nächste Schritt? Welches Modell traf jede Entscheidung? Hat sich etwas in der Außenwelt verändert? Wo stimmte die Ausgabe nicht mehr mit den Erwartungen überein?
Die Beantwortung dieser Fragen erfordert weniger Daten als die Erfassung aller Informationen, und die Erfassung von allem bringt eigene Probleme mit sich. Anfragen, Tool-Argumente sowie Tool-Antworten können vertrauliche Kundendaten, Zugangsdaten oder andere sensible Inhalte enthalten, die ohne sorgfältige Prüfung nicht auf einer Observabilitätsplattform landen sollten. Die Leitlinien von OpenTelemetry für GenAI weisen darauf hin, und seine detaillierte Span-Spezifikation macht die Erfassung von Eingaben und Ausgaben von Modellen optional und nicht standardmäßig.
Das Ziel ist daher, die relevanten Teile eines Laufs rekonstruierbar zu machen, nicht alles zu protokollieren. Manchmal reicht eine redigierte Antwort aus, manchmal eine Schema-Version zusammen mit einer Objekt-ID, und manchmal benötigt ein Zwischenergebnis ein Snapshot, weil sonst nichts den Lauf wiederherstellen kann. Entscheiden Sie sich bewusst, damit ein Incident nicht dazu führt, dass nur status: success als das Einzige erhalten bleibt.
Was das für die Bewertung bedeutet
Eine Spur erklärt, was geschehen ist, aber nicht, ob das Ergebnis gut war, weshalb eine Bewertung weiterhin notwendig ist. Anthropic argumentiert dasselbe in ihrem Artikel über Agentenbewertungen. Agenten sind schwieriger zu bewerten als einzelne Antworten, da sie über mehrere Schritte laufen, Tools aufrufen, den Zustand ändern und sich an das Vorherige anpassen.
Einige Ergebnisse können ohne zusätzliches Modell überprüft werden. Ein Agent, dem gesagt wurde, kein E-Mail zu senden, sendet eine – das ist ein Versagen –, und eine Extraktionsaufgabe, die 27 Einträge zurückgeben soll, liefert nur 11, was eine messbare Abweichung darstellt. Andere Fälle sind unklarer: War ein Forschungsbericht ausreichend detailliert? Waren die Quellen gut? Hat eine Supportantwort das Problem des Kunden gelöst? Für solche Fälle können menschliche Überprüfungen, Nutzerfeedback, Datensätze oder modellbasierte Bewertungstools erforderlich sein.
Der wahre Wert entsteht durch die Verbindung der Bewertung mit dem Ablaufverlauf. Ein „Mist“-Zeichen neben einer gespeicherten Endantwort sagt lediglich aus, dass dem Benutzer diese nicht gefallen hat. Wenn dieses Signal mit dem gesamten Ablauf verknüpft ist, ermöglicht es es, sich das abgerufene Material, die verwendeten Tools, die beteiligten Modelle sowie den Punkt anzusehen, an dem sich der Zustand geändert hat.
Sobald der eigentliche Fehler gefunden ist, behält jener Produktionsablauf auch nach dem Vorfall seinen Wert, denn er kann zu einem Bewertungsfall werden, der vor Wiederholungen nach zukünftigen Änderungen an Prompten, Modellen oder Arbeitsabläufen schützt. Das ist weitaus besser, als schlechte Antworten nacheinander zu beheben und zu hoffen, dass nichts anderes ausfällt.
Hören Sie auf, bei dem finalen Prompt anzufangen
Wahrscheinlich ist dies der größte Wandel bei der Fehlersuche in KI-Systemen. In einer einfachen LLM-Anwendung, die eine schlechte Antwort liefert, ist es sinnvoll, den Prompt sowie die Antwort zu prüfen, da es kaum andere Stellen geben kann, an denen ein Problem liegen könnte. Wenn die Systeme komplexer werden, ist diese Vorgehensweise weniger nützlich. Stellen Sie sich ein Pipeline-System vor, das mehrere Modelle, Tools zur Informationsabrufung und -suche, externe APIs, Router sowie einen Überprüfungszyklus enthält – der letzte Prompt könnte einfach der Punkt sein, an dem ein früherer Fehler schließlich zum Vorschein kommt.
RAG hat die Lektion bereits gelehrt. Wenn die Dokumentensuche das falsche Dokument in das Kontextfenster einfügt, wird ein größeres Generierungsmodell dies nicht korrigieren, und man muss zurückgehen, um die Dokumentensuche zu beheben. Agenten folgen derselben Logik, allerdings mit zusätzlichen Grenzen. Ist die Dokumentensuche in Ordnung? Schauen Sie sich das Ergebnis an. Ist auch das in Ordnung? Schauen Sie sich die nächste Entscheidung an. Ist das richtige Werkzeug gewählt? Schauen Sie sich die Argumente und die Ausgabe an. Ist der Zustand immer noch richtig? Setzen Sie den Prozess fort, bis Sie zum ersten Punkt kommen, an dem er von Ihren Erwartungen abweicht.
Auf dem Papier klingt das einfach, doch die Menschen vergessen es, weil die endgültige Antwort das ist, was vor ihnen liegt, und es ist in der Regel am einfachsten, diese dafür verantwortlich zu machen.
Überwachbarkeit für den gesamten Ablauf
Agenten werden nur immer komplexer. MCP stellt ihnen weitere Tools zur Verfügung, mehragentige Konzepte beinhalten Delegation und Übergabe von Aufgaben, Router wählen Modelle in Echtzeit aus, und langlaufende Workflows ermöglichen einen persistenten Zustand sowie Wiederholungs- und Fortsetzungsmechanismen. Die menschliche Genehmigung kann mitten in einem Ablauf erforderlich sein, und Agenten, die über Browser oder Computer genutzt werden, können Systeme weit über das Chat-Fenster hinaus verändern. All das macht Agenten leistungsfähiger, erhöht aber gleichzeitig die Gefahr von Fehlern, während jede Komponente einen Erfolg meldet.
Deshalb muss die Überwachbarkeit über reine LLM-Metriken hinausgehen. Latenz, Tokenzahlen, Fehler und Kosten sind wichtig, und ein Dashboard sollte auf jeden Fall warnen, wenn ein Agent in einer Schleife feststeckt und um 2 Uhr morgens API-Kredite verbraucht. Dennoch geben diese Zahlen meist nur an, ob die Systeme funktionieren. Ein mehrschrittiger Agent benötigt außerdem eine Möglichkeit, sicherzustellen, dass das, was durch ihn fließt, weiterhin zur Aufgabe des Benutzers passt.
In der Praxis bedeutet das, den ursprünglichen Zweck, die wichtigsten Einschränkungen, die tatsächlich genutzten Tools und Modelle, den Zustand zwischen den Schritten sowie das endgültige Ergebnis nachzuvollziehen. Wenn das Ergebnis falsch ist, sollte man in der Lage sein, rückwärts zum ersten Punkt zu gehen, an dem der Zustand von der Realität abwich. Mit dieser Fähigkeit wird ein fehlerhafter Ablauf zu einem gewöhnlichen Ingenieurproblem, das untersucht, reproduziert und getestet werden kann. Ohne diese Fähigkeit starrt man auf die endgültige Antwort und vermutet, welcher Bestandteil des Systems bereits früher versagt hat.
Verwandte Literatur
- Praktische Notizen: Erstellung eines Private-Cloud-Coding-Agenten: OpenCode + ein lokales LLM — Detaillierte Anleitung zu den Praktischen Notizen zur Erstellung eines Private-Cloud-Coding-Agenten: OpenCode + ein lokales LLM: Verträge, Überprüfungen sowie Code-Blöcke für Teams, die dieses Muster einsetzen.