KI-Agenten stürzen selten ab. Sie versagen unbemerkt – und die Forschung zeigt, warum

Agenten auf Basis großer Sprachmodelle beantworten inzwischen Supportanfragen, fragen Datenbanken ab und planen Reisen. Wenn etwas schiefläuft, geben sie meist eine überzeugend klingende Antwort und einen Erfolgscode zurück. Eine wachsende Zahl von Forschungsarbeiten erklärt, warum solche Fehler schwer zu erkennen sind und wie Entwicklungsteams lernen, sie zu messen.

Ein Fehler, der wie ein Erfolg aussieht

Herkömmliche Software versagt meist auf auffällige Weise. Eine Funktion löst eine Ausnahme aus, ein Server gibt einen Fehlercode zurück und ein Überwachungs-Dashboard färbt sich rot. Bei einem KI-Agenten sieht das anders aus. Er arbeitet in einer Schleife: Ein Sprachmodell liest eine Eingabeaufforderung, entscheidet sich für den Aufruf eines Werkzeugs, etwa einer Such-API oder einer Datenbank, liest das Ergebnis und entscheidet, was als Nächstes zu tun ist. Jeder Schritt kann fehlschlagen, während trotzdem jede Netzwerkanfrage in der Kette erfolgreich ist.

Betrachten wir einen typischen Fall. Ein Wetterdienst-Werkzeug fällt aus und gibt in einer ansonsten normalen Antwort den Text „Dienst nicht verfügbar“ zurück. Das Modell liest diesen Text und entschuldigt sich höflich – oder schlimmer noch: Es erstellt auf Grundlage seiner Trainingsdaten eine plausibel klingende Wettervorhersage. Der Nutzer erhält eine flüssig formulierte Antwort. In den Serverprotokollen ist eine erfolgreiche Anfrage mit normaler Latenz vermerkt. Nichts in einer herkömmlichen Überwachungsumgebung hält fest, dass etwas schiefgelaufen ist.

Anbieter von Modellen beschreiben dieselbe Lücke in ihrer eigenen Dokumentation. Der Gemini-API-Leitfaden von Google weist darauf hin, dass das Modell „die Funktion nicht selbst ausführt“. Es schlägt lediglich einen Funktionsnamen und Argumente vor; den Aufruf führt die Anwendung des Entwicklers aus. Somit ist die Anwendung der einzige Teil des Systems, der das tatsächliche Ergebnis sieht. Anthropics Leitfaden zur Entwicklung von Agenten führt einen ähnlichen Punkt an: Agenten benötigen bei jedem Schritt eine „Ground Truth“ aus ihrer Umgebung, etwa die Ergebnisse von Werkzeugaufrufen, um ihren eigenen Fortschritt beurteilen zu können. Meldet ein Werkzeug einen Fehler als gewöhnlichen Text, ist diese Ground Truth falsch, und der Agent kann das nicht erkennen.

Das ist keine neue Art von Problem, sondern lediglich eine zugespitzte Form eines alten. 2015 beschrieben von D. Sculley geleitete Google-Ingenieure „verborgene technische Schulden“ in Systemen des maschinellen Lernens. Sie argumentierten, dass der größte Teil des Risikos in einem ML-Produktivsystem außerhalb des Modellcodes liege – in Datenabhängigkeiten, Konfigurationen und Verbindungscode. Agenten erweitern diese Liste um eine neue Ebene. Eingabeaufforderungen und Werkzeugbeschreibungen sind Konfigurationen, die das Verhalten eines Systems verändern können, ohne dass sich sein Code ändert.

Kleine Änderungen, große Auswirkungen

Wie viel kann eine kleine Änderung an einer Eingabeaufforderung ausmachen? In einer auf der ICLR 2024 vorgestellten Forschungsarbeit änderten Melanie Sclar von der University of Washington und ihre Kollegen lediglich die Formatierung von Few-Shot-Eingabeaufforderungen: Trennzeichen, Abstände und Groß- und Kleinschreibung. Die Bedeutung blieb gleich. Dennoch schwankte die Leistung bei derselben Aufgabe mit LLaMA-2-13B um bis zu 76 Genauigkeitspunkte. Diese Empfindlichkeit verschwand auch bei größeren Modellen, mehr Beispielen oder Instruction Tuning nicht.

Die Autoren empfehlen, statt eines einzelnen Werts eine Leistungsspanne für plausible Formate von Eingabeaufforderungen anzugeben. Für Entwicklungsteams ist die praktische Lehre einfacher: Eine Änderung an einer Eingabeaufforderung ist eine Codeänderung. Sie braucht eine Versionshistorie und muss getestet werden, bevor sie Nutzer erreicht.

Dasselbe gilt für Werkzeugbeschreibungen, die das Modell als Teil seiner Eingabeaufforderung liest. Anthropics Leitfaden empfiehlt, Werkzeugdefinitionen „genauso viel Aufmerksamkeit beim Prompt Engineering“ zu widmen wie der Haupteingabeaufforderung. Darin wird ein Programmieragent beschrieben, der immer wieder Fehler mit relativen Dateipfaden machte. Nachdem das Werkzeug so geändert worden war, dass es absolute Pfade erforderte, verwendete das Modell es fehlerfrei. Das Modell änderte sich nicht. Nur die Beschreibung, die es las, war eine andere.

Ein einziger Erfolg sagt wenig aus

Eine zweite Forschungsrichtung untersucht die Zuverlässigkeit. Der τ-bench-Benchmark, veröffentlicht von Shunyu Yao und Kollegen bei Sierra und auf der ICLR 2025 vorgestellt, simuliert Kundendienstgespräche, in denen ein Agent Werkzeuge einsetzen und Geschäftsregeln befolgen muss. Die Autoren führten eine Kennzahl namens pass^k ein: die Wahrscheinlichkeit, dass ein Agent dieselbe Aufgabe bei allen k Versuchen korrekt löst.

Die Ergebnisse waren ernüchternd. Ein GPT-4o-Agent löste bei einem einzigen Versuch etwa 61 % der Aufgaben im Einzelhandel. Musste er dieselbe Aufgabe achtmal hintereinander erfolgreich bewältigen, sank die Quote auf etwa 25 %. Eine Demo, die einmal funktioniert, sagt wenig darüber aus, wie sich ein System beim tausendsten Durchlauf verhält.

Wo Multi-Agenten-Systeme scheitern

Viele Teams verketten inzwischen mehrere Agenten miteinander: Einer plant, ein anderer führt aus und ein dritter überprüft die Arbeit. Eine Studie der UC Berkeley aus dem Jahr 2025, „Warum scheitern LLM-Systeme mit mehreren Agenten?“, analysierte mehr als 1.600 annotierte Ausführungsprotokolle aus sieben beliebten Multi-Agenten-Frameworks. Die von Mert Cemri geleiteten Autoren entwickelten eine Taxonomie namens MAST mit 14 Fehlermodi in drei Gruppen: Probleme beim Systemdesign, mangelnde Abstimmung zwischen Agenten und Aufgabenüberprüfung.

Ihre zentrale Erkenntnis lautet, dass viele Fehler auf den Aufbau des Systems zurückgehen und nicht nur auf die Grenzen des zugrunde liegenden Modells. Agenten ignorieren ihre zugewiesene Rolle, verlieren den Gesprächsverlauf aus dem Blick oder erklären eine Aufgabe für abgeschlossen, ohne das Ergebnis zu überprüfen. Diese Fehler hinterlassen keine Fehlermeldung. Sie werden nur sichtbar, wenn jemand nachvollziehen kann, was jeder Agent tatsächlich getan hat. Die Berichterstattung von Unite.AI zum Paradoxon der Multi-Agenten-Systeme führt einen verwandten Architekturgedanken aus: Zusätzliche Agenten können einen frühen Fehler verstärken, statt ihn auszugleichen.

Das Unsichtbare sichtbar machen

Die technische Antwort greift auf verteilte Systeme zurück, in denen Anfragen schon lange über viele Dienste hinweg mit einer Technik namens Tracing nachverfolgt werden. Auf Agenten übertragen wird jede Nutzeranfrage zu einem Trace, und jeder Modell- oder Toolaufruf zu einem darin enthaltenen „Span“. Ein Span hält die Eingabe, die Ausgabe, die verwendeten Tokens und die benötigte Zeit fest. OpenTelemetry, die zuständige Branchenorganisation für Standards, erarbeitet gemeinsame Konventionen für Spans generativer KI. Auch 2026 sind diese Konventionen noch als in Entwicklung gekennzeichnet, weshalb sich die Attributnamen noch ändern können.

Mehrere Open-Source-Projekte wie Langfuse, Arize Phoenix und AcruxCore setzen diese Idee bereits um. Ihr Quellcode ist öffentlich, sodass Teams prüfen können, wie ein Trace gespeichert wird, und die Software auf eigenen Servern betreiben können. Sie erfassen Modell- und Toolaufrufe als Spans eines einzelnen Traces und ermöglichen es Teams, ihnen Qualitätsbewertungen zuzuordnen. Die Wahl des Tools ist weniger wichtig als ein Detail: Ein Tool-Span muss festhalten, was das Tool tatsächlich zurückgegeben hat, und nicht nur, ob die Netzwerkanfrage erfolgreich war. Andernfalls bleibt der oben beschriebene Ausfall des Wetter-Tools unsichtbar.

Branchenumfragen legen nahe, dass Tracing inzwischen weit verbreitet ist, Tests jedoch hinterherhinken. LangChains Bericht zum Stand der Agentenentwicklung befragte Ende 2025 insgesamt 1.340 Fachleute. Die Qualität wurde am häufigsten als Hindernis für den Produktiveinsatz von Agenten genannt: 32 % der Befragten führten sie an. 89 % der Organisationen gaben an, ihre Agenten in irgendeiner Form zu überwachen, und 62 % verfügten über detailliertes Tracing einzelner Schritte und Toolaufrufe. Nur 52,4 % führten Offline-Evaluierungen mit Testdatensätzen durch, und 37,3 % bewerteten den Live-Datenverkehr. Die meisten Teams können sehen, was ihre Agenten getan haben. Weniger Teams prüfen, ob es richtig war.

Antworten in großem Maßstab bewerten

Traces zeigen, was passiert ist. Sie sagen jedoch nicht aus, ob die Antwort gut war. Jede Unterhaltung von Hand zu lesen, lässt sich nicht skalieren. Deshalb setzen Teams zunehmend ein zweites Modell als Bewerter ein – ein Ansatz, der als LLM-as-a-Judge bekannt ist. Eine Arbeit auf der NeurIPS 2023 von Lianmin Zheng und Kollegen ergab, dass leistungsstarke Modelle wie GPT-4 in mehr als 80 % der Fälle mit menschlichen Präferenzen übereinstimmten – ungefähr so häufig, wie Menschen untereinander übereinstimmen.

Dieselbe Arbeit dokumentierte die Schwächen der Methode. Bewertungsmodelle bevorzugen die zuerst gezeigte Antwort und längere Antworten und können Texte bevorzugen, die sie selbst verfasst haben. Die Bewertungen dieser Modelle sind daher Schätzungen. Sie sind bei großen Datenmengen nützlich, müssen aber anhand einer kleinen Auswahl von Beispielen mit menschlichen Bewertungen überprüft werden, wobei die Reihenfolge der Antworten zufällig festgelegt wird.

Von der Praxis zur Richtlinie

Diese Messarbeit entwickelt sich auch zu einer Governance-Anforderung. Das US National Institute of Standards and Technology veröffentlichte sein Rahmenwerk für das Risikomanagement von KI im Januar 2023. Eine der vier Kernfunktionen des Rahmenwerks, „Messen“, fordert Organisationen dazu auf, KI-Risiken im Laufe der Zeit zu quantifizieren, zu verfolgen und zu dokumentieren. Bei einem Agenten sind Traces und Evaluierungsbewertungen genau die Nachweise, die diese Funktion verlangt.

Was Teams jetzt tun können

Das greift das Argument auf, das auf dieser Plattform vorgebracht wurde: Zuverlässigkeit ist der eigentliche Prüfstein agentischer KI. Die obige Forschung ergänzt dieses Argument um die messtechnische Grundlage: Zuverlässigkeit ist keine Eigenschaft, die man einmal beobachtet, sondern eine Bandbreite, die man fortlaufend messen muss.

Die Forschung verweist auf eine kurze Liste sinnvoller Praktiken, von denen viele auch von den großen Modellanbietern empfohlen werden. OpenAIs praxisnaher Leitfaden zum Erstellen von Agenten empfiehlt Teams, „Evaluierungen einzurichten, um eine Leistungsbaseline festzulegen“, bevor sie optimieren, und die Kontrolle an einen Menschen zu übergeben, wenn ein Agent eine festgelegte Anzahl fehlgeschlagener Versuche überschreitet oder vor einer Handlung mit hohem Risiko steht. Anthropic empfiehlt „umfangreiche Tests in Sandbox-Umgebungen“, bevor Agenten eigenständig handeln.

In der Praxis bedeutet das einige konkrete Schritte. Prompts und Toolbeschreibungen sollten wie Code unter Versionskontrolle stehen. Testen Sie jede Promptänderung anhand eines festen Datensatzes und rechnen Sie mit einer Bandbreite an Ergebnissen statt mit einem einzigen Wert. Führen Sie jeden Testfall mehrmals aus, denn ein einzelner Durchlauf macht Unbeständigkeit nicht sichtbar. Erfassen Sie Toolausgaben in Traces, damit ein fehlerhaftes Tool sich nicht hinter einem Erfolgscode verbergen kann. Betrachten Sie automatisierte Bewertungen durch Modelle als Schätzungen und überprüfen Sie sie mit Menschen.

Keine dieser Praktiken setzt einen Durchbruch bei den Fähigkeiten von Modellen voraus. Sie erfordern, einen KI-Agenten als das zu behandeln, was er ist: ein probabilistisches System, das gemessen werden muss, weil es nur selten selbst auf seine Fehler hinweist.