ai-agents production reliability llmops architecture

Warum Agenten, die in Demos beeindrucken, in der Produktion versagen – und was stattdessen entwickelt werden sollte.

Warum KI-Agenten, die in Demos beeindrucken, in der Produktion versagen: Wo sie versagen, Kompromisse zwischen Einzel- und Mehr-Agenten-Systemen, Wiederholungsversuche und Rückfallstrategien sowie die tatsächlichen Betriebskosten.

Verlag: REACTAPP.TOPAuf dieser Website hinzugefügt 28. Okt. 20269 Min. Lesezeit2087 Wörter

Quellen: Why Most AI Agents Fail in Production

Was die Demo nie zeigt

Eine gute Agent-Demo wird um den „happy path“ herum aufgebaut. Der Tool-Aufruf liefert genau das, was erwartet wurde, das Modell versteht die Aufgabe korrekt, und nichts läuft aus. Unter diesen Bedingungen wirkt ein Agent, der Tools aufruft und schrittweise eine Aufgabe bearbeitet, fast fertiggestellt. Die Distanz zwischen diesem Zustand und dem, worauf sich Menschen verlassen, wird regelmäßig unterschätzt.

Die Produktion umfasst einfach alles außerhalb des „happy path“. Zertifikate laufen ab, ein Schema ändert sich ohne Vorankündigung, ein Befehl wird falsch interpretiert. Antworten kommen verspätet, sind unvollständig oder gar nicht vorhanden, und jede externe API, mit der der Agent arbeitet, hat ihre eigenen Eigenheiten. Keines davon ist Pech – es handelt sich dabei um das, was zu erwarten ist, wenn ein nicht-deterministischer Bestandteil in einem System vorhanden ist und die Umwelt weiterhin in Bewegung bleibt.

Demos überspringen außerdem oft die Bewertung und Überwachung. Ohne diese lösen Halluzinationen oder ein leise überlaufendes Kontextfenster keinen Alarm aus. Der Agent antwortet weiter, die Antworten sind falsch, und das erste Anzeichen ist ein Kundenbeschwerde oder ein beschädigtes Datensatz. Ein System, das nur bei genauer Beobachtung gut aussieht, ist nicht bereit, unüberwacht zu laufen.

Ein kleines Beispiel macht diesen Unterschied konkret. Stellen Sie sich einen Agenten vor, der Termine bucht, indem er eine Kalender-API aufruft. In der Demo antwortet der Kalender innerhalb von 200 Millisekunden mit sauberem JSON. In der Produktion gibt die API manchmal ein über Nacht umbenanntes Feld zurück, manchmal eine leere Seite und manchmal hängt sie dreißig Sekunden lang. Das Modell kann dann einen plausiblen Zeitraum erfinden, um die Lücke zu füllen. Jeder dieser Fälle erfordert eine gezielte Handlung: Die Struktur muss überprüft werden, Leere muss als eigenständiger Zustand behandelt werden, die Wartezeit muss begrenzt werden und Raten muss vermieden werden.

Wo Agenten versagen, sobald sie versendet haben

Die gleichen wenigen Fehlerquellen tauchen immer wieder auf.

Unzuverlässige Modellausgaben. Das Modell gibt Aussagen ohne Bezug zur Realität ab. Wenn der Agent mit Live-Systemen verbunden ist oder um kritische Informationen gebeten wird, führt ein erfundener Detail zu einer falschen Aktion.
Tool-Fehler. Agenten sind von APIs und externen Tools abhängig, die ihre Struktur ändern, Verbindungen unterbrechen oder unerwartete Eingaben ablehnen. Der Agent benötigt einen Plan für den Fall, dass ein Tool versagt – beispielsweise einen erneuten Versuch oder den Wechsel zu einer einfacheren Methode.
Endlose Schleifen. Ein schlechtes Zustandsverfolgungssystem oder unberücksichtigte Randfälle können dazu führen, dass ein Agent ohne Fortschritt im Kreis läuft. Eine klare Dokumentation dessen, was bereits erledigt wurde, verhindert wiederholte Arbeit.

Kontextüberschreitung. Je mehr ein Agent liest, desto wahrscheinlicher ist es, dass er die Grenze seines Kontextfensters überschreitet, wodurch die Ausgabe unvollständig oder fehlerhaft wird. Insbesondere Aufgaben, die auf einem langfristigen Gedächtnis beruhen, leiden darunter am meisten.

Schlechte Reaktionszeiten und unkontrolliertes Tokenverbrauch. Verzögerungen verschlechtern das Benutzererlebnis, und ein unplanmäßiger Tokenverbrauch erhöht die Kosten, besonders in großem Maßstab.

Unklare Berechtigungsregeln. Wenn unklar ist, was ein Agent bearbeiten darf, liest oder ändert er früher oder später etwas, was er nicht tun sollte, was Sicherheits- und Privatsphäreprobleme nach sich zieht.

Geringe Beobachtbarkeit und schwache Bewertung. Fehler können nicht rechtzeitig behoben werden, wenn sie nicht sichtbar sind. Die Überwachung zeigt, was der Agent getan hat, und eine gute Bewertungsgrundlage zeigt, wo er stark ist und wo nicht.

Unzuverlässige APIs Dritter Anbieter. Die Antwortzeiten variieren und es kommt zu Ausfällen. Zeitlimits und Wiederholungsversuche sind die grundlegende Abwehrmaßnahme.

Mehr Agenten bedeutet nicht automatisch mehr Zuverlässigkeit

Ein gängiger Instinkt besagt, dass die Aufteilung der Arbeit auf mehrere Agenten die Leistung und Zuverlässigkeit verbessert. Oft verursacht dies jedoch mehr Probleme, als es löst, denn jeder zusätzliche Agent erfordert zusätzliche Kommunikations- und Koordinationsaufwände.

Ein einzelner Agent hat einen klaren Vorteil: Es gibt nur eine Sache, die angepasst werden muss, und nur eine Sache, die im Auge behalten werden muss. Wenn eine Aufgabe einer klaren, linearen Abfolge folgt, wie bei einer einfachen Suche mit gut verstandenen Schritten, ist in der Regel ein einziger Agent die bessere Wahl.

Mehrere Agenten sind sinnvoll für anspruchsvollere Aufgaben, die in unabhängige Teile aufgeteilt und gleichzeitig ausgeführt werden können. Auch dann entstehen Kosten. Jemand muss sicherstellen, dass die Agenten nicht in entgegengesetzte Richtungen arbeiten oder sich gegenseitig behindern. Ohne Koordination arbeiten sie mit veralteten oder widersprüchlichen Informationen. Jeder zusätzliche Agent ist ein weiterer Punkt für Fehler, und jede Übergabe ist ein Ort, an dem Kontext verloren gehen oder verfälscht werden kann. Zudem können Abhängigkeiten zwischen Agenten dazu führen, dass ein Fehler auf andere übergeht, weshalb die Überwachung entsprechend strenger sein muss.

Orchestrierung lohnt sich, wenn sich die Aufgabe von selbst in Teile aufteilen lässt. In einem Kundenservice-Umfeld könnte ein Agent Informationen abrufen, ein anderer die Stimmung der Nachricht bewerten und ein Dritter den Antwortentwurf erstellen, wobei die Orchestrierung alle Teile zu einer einzigen Antwort zusammenfügt.

Stellen Sie sich den Batch-Fall vor: Einige hundert nahezu identische Support-Anfragen, die alle dieselbe Klassifizierung sowie dieselbe vorgefertigte Bearbeitung benötigen. Ein fester Ablauf mit nur einem Modellaufruf an der Entscheidungsstelle ist einfacher zu testen, einfacher zu bewerten und weitaus leichter einem Prüfer zu erklären als ein Team kooperierender Agenten.

In vielen Fällen ist jedoch ein einfacher, deterministischer Workflow besser als ein Team von Agenten. Wenn eine Aufgabe keinen Parallelismus erfordert oder die Verwaltungskosten alle Vorteile überwiegen, kann ein einzelner Agent, der einer festen Sequenz folgt, eine Gruppe ähnlicher Anfragen effizienter bearbeiten, da es kaum Abweichungen zu berücksichtigen gibt.

Die Entscheidung sollte von der tatsächlichen Aufgabe abhängen: von ihrer Komplexität, davon, ob parallele Arbeit hilft, sowie davon, wie viel Koordination und Überwachung erforderlich sind. Eine ehrliche Abwägung dieser Faktoren ermöglicht es einem Design, die Stärken jedes Ansatzes zu nutzen und seine Schwächen zu vermeiden.

Seit Anfang an für die Produktion entwerfen

Bei der Entwicklung für die Produktion muss man auf das Ziel einer beeindruckenden Demonstration verzichten und stattdessen ein System anstreben, das mit den unvermeidlichen Fehlern umgehen kann. Mehrere Praktiken spielen dabei die wichtigste Rolle.

Gestrukturierte Ausgaben. Durch ein einheitliches Ausgabeformat wird das Risiko von Fehlinterpretationen verringert und das Debuggen erleichtert. Nachgeschaltete Systeme können sich auf eine vorhersehbare Struktur verlassen.

Wiederholte Versuche mit Verzögerung sowie Zeitlimits. Vorübergehende Probleme wie Netzwerkstörungen oder kurzfristig nicht verfügbare Dienste sollten durch wiederholte Versuche bewältigt werden, wobei die Wartezeiten zwischen den Versuchen zunehmen. Zeitlimits verhindern, dass ein Agent endlos auf etwas wartet, das nicht ankommt.

Fallback-Möglichkeiten. Eine Fallback-Kette sollte wie jeder andere Codepfad aufgeschrieben und getestet werden, da ein ungetester Fallback in der Regel genau dann versagt, wenn es am wichtigsten ist. Wenn der primäre Weg versagt, kann ein alternatives Tool oder eine alternative Methode zwar dasselbe Ergebnis erzielen, jedoch mit geringerer Genauigkeit oder Reichweite. Dadurch wird der Dienst fortgesetzt anstatt gestoppt.

Mitarbeiter im Entscheidungsprozess. Komplexe oder unklare Fälle stellen eine Herausforderung dar. Die Weiterleitung an einen menschlichen Operator bringt Urteilsvermögen in die wichtigsten Entscheidungen und sorgt für klare Verantwortlichkeiten.

Modellbasierte Routenplanung. Verschiedene Modelle haben unterschiedliche Stärken. Jede Aufgabe an das am besten geeignete Modell zu senden, verbessert Genauigkeit und Leistung – vorausgesetzt, man kennt die Fähigkeiten und Grenzen jedes Modells.

Bewertungssätze. Ein nützlicher Satz mischt normale Anfragen mit problematischen: fehlerhafte Eingaben, widersprüchliche Anweisungen sowie Tools, die den Zeitlimit erreichen. Ständige Tests mit einer vielfältigen Sammlung von Szenarien bringen Schwachstellen früh zum Vorschein und zeigen an, ob der Agent bei sich ändernden Bedingungen weiterhin zuverlässig bleibt.

Verfolgung von Abläufen und Kosten. Durch die Verfolgung der Daten- und Entscheidungspfade innerhalb des Systems wird das Debuggen und Tuning erleichtert. Die Kostenverfolgung sorgt dafür, dass der Ressourcenverbrauch innerhalb vereinbarter Grenzen bleibt, und zeigt an, ob das System seine Kosten rechtfertigt.

Geplante Degradierung. Ein Agent, der nicht auf sein Suchtool zugreifen kann, kann dennoch auf Basis von im Cache gespeicherten Daten antworten und dies klar mitteilen – das ist besser als eine Fehlerseite. Unter Belastung sollte ein System seine Funktionen geordnet einbüßen, anstatt zusammenzubrechen. Die Planung für Ausfälle ermöglicht ein schnelles Wiederherstellen und verringert den Einfluss auf die Benutzer.

Der wahre Preis der Nutzung eines Agenten

Tokenkosten sind die sichtbare Posten auf der Rechnung – doch sie stellen nur den oberen Teil dar. Eine faire Kostenaufstellung beinhaltet noch weitere Posten.

Toolaufrufe. Jeder Aufruf eines externen Services kostet Geld und Zeit und führt zu zusätzlichen Störquellen. Der Agent kann oft nicht ohne sie arbeiten, doch diese Abhängigkeiten machen das System teurer und komplizierter.
Infrastruktur. Server, Speicher und Netzwerke müssen der nach Nutzungsaktivitäten sowie Aufgabenkomplexität schwankenden Nachfrage angepasst werden. Die Gewährleistung einer hohen Verfügbarkeit dieser Infrastruktur verursacht weitere Kosten.
Wiederholungsversuche und Fehlerbehandlung. Sie sind für die Zuverlässigkeit notwendig, doch jeder Wiederholungsversuch verbraucht Rechenleistung. In Systemen mit häufigen vorübergehenden Fehlern summieren sich diese Kosten schnell auf.

Verzögerung. Langsamkeit frustriert Benutzer und kann zu mehr Wiederholungsversuchen oder einer längeren Belegung der Ressourcen führen. Ihre Verringerung erfordert Investitionen in Infrastruktur und Software.

Überwachung und Beobachtbarkeit. Sie sind für den Zustand der Systeme unerlässlich, erfordern jedoch zusätzliche Software, Hardware sowie Personal, um die von den Tools bereitgestellten Informationen auszuwerten und darauf zu reagieren.

Menschliche Intervention. Überprüfungen, Korrekturen und Freigaben gewährleisten Genauigkeit und Konformität, wobei die dafür benötigten Arbeitsstunden den Kostenvergleich stark beeinflussen können.

Eine Möglichkeit, ein realistisches Bild zu erhalten, besteht darin, die Kosten pro abgeschlossener Aufgabe statt pro Modellaufruf zu berechnen. Eine Aufgabe, die drei Wiederholungsversuche, zwei Toolaufrufe sowie eine menschliche Überprüfung erfordert, ist weitaus teurer, als ihre Anzahl an Tokens vermuten lässt – und genau diese Zahl sollte zum Vergleich zwischen verschiedenen Designs sowie zur wöchentlichen Überwachung herangezogen werden.

Die praktische Schlussfolgerung ist, dass die Kosten in all diesen Kategorien gemeinsam gesteuert werden müssen. Ein System, das allein nach den Tokenkosten günstig erscheint, kann sich als teuer erweisen, wenn Versuche, Support-Mitarbeiter und Server mit einbezogen werden.

Was „zuverlässig“ tatsächlich bedeutet

Die Zukunft der agierenden KI hängt weniger von den autonomesten, auffälligsten Demonstrationen ab als vielmehr davon, ob die Systeme in der Praxis funktionieren, sich erholen und sich selbst amortisieren. Der Fokus muss sich von der Demonstration technischer Fähigkeiten in kontrollierten Umgebungen auf die Bewältigung der schwierigen Realitäten der Implementierung verlagern.

Zuverlässigkeit steht an erster Stelle. Das bedeutet, Fehler ohne Aufhebens zu bewältigen, sich an sich ändernde Bedingungen anzupassen und unter Last stabil zu bleiben. Die dazu notwendige Architektur setzt auf strukturierte Ausgaben, sinnvolle Fehlerbehandlung sowie gründliche Überwachung. Indem man vorhersehen kann, wo Probleme auftreten können, und durch Wiederholungsversuche, Zeitlimits sowie Alternativen vorsorgt, erhält ein Team ein System, das sich erholt und gleichzeitig konstant gute Leistungen erbringt.

Wirtschaftlichkeit kommt an zweiter Stelle. Die tatsächlichen Kosten eines KI-Systems umfassen Infrastruktur, Interaktionen mit Tools, Verzögerungen und menschliche Arbeitszeit sowie Modelltokens. Um die Kosten in Grenzen zu halten, ist ein sorgfältiger Ressourceneinsatz sowie ein klares Verständnis dafür erforderlich, was jede architektonische Entscheidung kostet. Ein günstigeres Modell, das mehr Wiederholungsversuche und menschliche Überprüfungen erfordert, kann leicht teurer werden als ein leistungsstärkeres Modell, das bereits beim ersten Versuch richtig funktioniert.

Eine nützliche Checkliste vor jedem Start ist kurz. Können alle oben genannten Fehlermöglichkeiten benannt werden, und hat jeder eine Verantwortliche sowie einen Handlungsplan? Kann eine Person sehen, was der Agent gestern getan hat? Gibt es Grenzen für die Ausgaben und die Tiefe der Schleifen? Gibt es eine Möglichkeit, den Agenten schnell auszuschalten? Wenn die Antwort auf eine dieser Fragen Nein lautet, handelt es sich beim System immer noch um eine Demo.

Letztendlich wird der Erfolg daran gemessen, wie gut die Agenten in die bereits vorhandenen Workflows passen und welchen konkreten Wert sie liefern. Dafür ist eine Veränderung der Denkweise notwendig – von Agenten, die für sich allein gut aussehen, zu Systemen, die das tun, was die Menschen bereits können, erweitern. Wenn der Fokus weiterhin auf Zuverlässigkeit, soliden wirtschaftlichen Aspekten und den Bedürfnissen der Nutzer liegt, kann agierende KI zu einem zuverlässigen Partner für schwierige Probleme genauso wie für den Alltag werden.