Warum KI-Agenten das Budget verbrauchen, ohne ihre Aufgaben zu erledigen, und wie man sie stoppen kann
Erfahren Sie, warum Tool-Aufruf-Agenten im Kreis laufen, wenn „erledigt“ nicht definiert ist, wohin die Token aufgebraucht werden und welche Stoppsbedingungen besser sind als das Einfachsteigen der Schritt- oder Budgetgrenzen.
Ein autonomer Agent, der abstürzt, ist leicht in den Griff zu bekommen. Der kostspielige Fehler ist jener, der niemals abstürzt: Er ruft weiterhin Tools auf, erzeugt stets scheinbar vernünftige Schritte und erreicht niemals die Ziellinie, während der Token-Zähler weiterläuft. Dieser Artikel erklärt den Mechanismus hinter diesem Verhalten, wo sich der Ressourcenverbrauch bei einem außer Kontrolle geratenen Agenten typischerweise ansammelt, sowie die konkreten Stoppsbedingungen, die dies verhindern, damit Sie Agentenschleifen entwerfen können, die wissen, wann sie abgeschlossen sind, anstatt auf einen größeren Budgetrahmen zu vertrauen, um den Verschwendung entgegenzuwirken.
Betrachten wir ein bescheidenes Beispiel: Ein unüberwachter Nachmittagseinsatz, der 40 Dollar kostet und nichts bringt. Nach den Standards für Agentenoperationen ist das eine unbedeutende Summe; Teams teilen sich Geschichten über unüberwachte Übernachtungseinsätze, bei denen die Kosten vierstellig wurden. Die Höhe der Rechnung ist nicht das Interessante. Entscheidend ist, was damit erreicht wurde. Der Agent saß nicht fest und löste keinen Fehler aus, auf den man verweisen könnte. Er war die ganze Zeit beschäftigt – mit nichts.
Wie ein außer Kontrolle geratener Agent in den Protokollen aussieht
Öffnen Sie das Protokoll eines Agenten, der vom Kurs abgekommen ist, und Sie finden selten einen Stack Trace. Was Sie stattdessen lesen, wirkt wie das Verhalten eines gewissenhaften Mitarbeiters, der den Überblick über seine Aufgabe verloren hat.
Der Agent öffnet eine Datei und fasst ihren Inhalt zusammen, öffnet anschließend denselben Inhalt in einer leicht abgewandelten Form und fasst ihn erneut zusammen. Er führt eine Suche durch, urteilt, dass die Antwort nicht ganz zufriedenstellend ist, und gibt die Anfrage mit ein paar vertauschten Worten erneut ab. Jeder Schritt für sich genommen ist nachvollziehbar. Genau deshalb fällt dieses Muster beim Überfliegen schwer auf: Kein einzelner Schritt wirkt fehlerhaft. Der Prozess konvergiert einfach nie.
Warum das Modell entscheidet, wann es fertig ist
Das Verhalten hat eine konkrete Ursache, die es zu verstehen lohnt, wenn man Agenten entwickelt oder betreibt. Jede Antwort eines toolaufrufenden Modells wie Claude endet mit einem Stoppsgrund, der aus einer kurzen, festgelegten Liste stammt. Anthropics Leitfaden zur Handhabung von Stoppsgründen behandelt mehrere Fälle; zwei sind für Agentenschleifen am wichtigsten. Der erste signalisiert, dass das Modell glaubt, seine Arbeit sei abgeschlossen:
"stop_reason": "end_turn"
Der zweite signalisiert, dass es ein Tool aufrufen und fortfahren möchte:
"stop_reason": "tool_use"
Ein Agent-Loop ist gewöhnlicher Anwendungscode. Er sendet eine Anfrage, führt jedes von dem Modell angeforderte Tool aus, sendet das Ergebnis zurück und wiederholt diesen Vorgang, bis das Modell end_turn zurückgibt. Nichts außerhalb des Modells deklariert, dass die Aufgabe abgeschlossen ist. Jedes Mal macht das Modell diesen Aufruf selbst, um zu prüfen, ob die vorliegende Arbeit abgeschlossen erscheint. Es gibt weitere Gründe zum Stoppen, wie beispielsweise das Erreichen der Ausgabotoken-Limite, doch diese sind Unterbrechungen und keine Feststellung, dass die Aufgabe erledigt ist.
Diese eine Tatsache erklärt den gesamten Misserfolg. Wenn das Ziel zu vage ist, sodass das Modell nicht erkennen kann, dass es erreicht wurde, gibt es stets etwas anderes, das überprüft werden muss, und der Kreislauf setzt sich fort, bis etwas Externes – in der Regel eine Budgetwarnung – eingreift. Für eine behandlung auf Codeebene des Loop-Designs siehe begrenzte agenteische Schleifen und zuverlässige TypeScript-Muster für die Nutzung von LLM-Tools.
Wie häufig das vorkommt
Es ist verlockend, dies als Besonderheit eines bestimmten Tools abzutun. Größere Mengen an Belegen deuten jedoch darauf hin, dass dem nicht so ist. Eine Studie der RAND Corporation, die auf Interviews mit 65 erfahrenen Datenwissenschaftlern und Ingenieuren beruht, gibt die Misserfolgsrate von KI-Projekten mit über 80 Prozent an – das ist etwa doppelt so viel wie bei herkömmlichen IT-Arbeiten. Diese Studie bezieht sich allgemein auf KI-Projekte, nicht speziell auf Agenten, doch Schleifen, die ohne Wertbeitrag laufen, gehören zu den alltäglichen Ursachen für solche Verschwendungen. Sie tauchen nie in Keynotes auf Konferenzen auf; sie erscheinen stattdessen auf Rechnungen.
Auch größere Versionen dieser Geschichte kursieren. Ein häufig zitiertes Bericht schildert einen rekursiven Loop, dessen Ausgaben vor Eingreifen auf fünfstellige Werte anstiegen. Diese Zahl wurde nicht unabhängig überprüft, und jedes solche dramatische Datum verdient Skepsis. Der Mechanismus existiert jedoch tatsächlich und verstärkt sich nur weiter: Derselbe Loop, der an einem Nachmittag 40 Dollar ausgibt, kann an einem unbeobachteten Wochenende 4.000 Dollar verbrauchen.
Wo sich die Ausgaben ansammeln
Wenn man die außer Kontrolle geratenen Kosten untersucht und sie mit dem vergleicht, was Betreiber großer Agentenflotten melden, neigen sich die Gelder meist in denselben wenigen Bereichen anzusammeln:
- Beschränkungslose Web-Recherche. Jede heruntergeladene Seite und jede wiederholte Suche hat ihren Preis. Ohne Obergrenze setzt sich die unbegrenzte Recherche fort, solange das Modell glaubt, dass es noch weitere wertvolle Quellen geben könnte.
- Ein teures Modell für einfache Aufgaben. Frontier-Modelle sind teurer, weil sie besser reasoning-fähig sind, doch viele Agentenschritte wie das Umformatieren einer Datei, das Überprüfen eines Status oder das Erneuten Versuchs einer Anrufung benötigen diese Fähigkeiten gar nicht. Ein kleineres Modell könnte sie zu einem Bruchteil des Preises bewältigen.
- Threads, die niemals enden. Ein Agent, der innerhalb eines langen Gesprächs arbeitet, verarbeitet bei jedem Schritt seine gesamte angesammelte Historie erneut, wodurch ein bereits wochenalter Thread pro Anfrage teurer wird als zu Beginn – egal wie klein die Anfrage auch ist. Prompt-Caching kann dies abmildern, sofern Ihr Anbieter es unterstützt, doch der Kontext wächst weiterhin.
Nichts davon ist außergewöhnlich. Zusammen verhalten sie sich wie ein vergessenes Abonnement, das nach Token statt nach Monaten abgerechnet wird. Für einen strukturellen Überblick darüber, wie sich diese Kosten summieren, geht der Artikel zu warum die Kosten für agentebasierte KI in die Höhe schießen tiefer darauf ein.
Bessern Sie die Stoppschranke statt die Obergrenze
Nach einem teuren Lauf ist die instinktive Reaktion, die Schritt- oder Ausgabengrenzen anzuheben. Das führt in der Regel zu negativen Folgen, denn eine höhere Obergrenze lässt den gleichen feststeckenden Schleifenprozess nur länger weiterlaufen, bevor er darauf stößt. Was tatsächlich hilft, ist es, dem Schleifenprozess eine Möglichkeit zu geben, festzustellen, dass der Fortschritt stagniert – das ist eine andere Frage als die, ob er bereits seine vorgegebene Anzahl an Schritten aufgebraucht hat.
Setzen Sie die Ziellinie im Ziel an
Definieren Sie „erledigt“ als Teil der Aufgabe und nicht erst im Nachhinein. Eine Anweisung wie „Beheben Sie den fehlgeschlagenen Test“ lässt Raum für zusätzliche Aufgaben wie das Ordnen von Importen oder das Umformatieren der gesamten Datei. „Stellen Sie sicher, dass dieser eine Test funktioniert, dann beenden Sie“ gibt ein klares Ende an, das das Modell erkennen kann. Je deutlicher die Erfolgskriterien sind, desto leichter fällt es dem Modell, zum richtigen Zeitpunkt end_turn zurückzugeben.
Machen Sie die Ergebnisse der Tools eindeutig
Die Rückmeldung der Tools sollte klar angeben, ob eine Aktion erfolgreich war oder fehlgeschlagen ist. Ein unklares Ergebnis wird vom Agenten als Aufforderung zum erneuten Versuch interpretiert, nicht als Signal zum Aufhören. Explizite Statusfelder und klare Fehlermeldungen beseitigen die Unsicherheit, die erneute Versuche auslöst.
Erkennen Sie Wiederholungen statt Schritte zu zählen
Ein fester Schrittzähler ist ein unpräzises Werkzeug. Derselbe Zähler könnte eine gültige Aufgabe mit 15 Schritten bereits in Schritt 11 abbrechen, während ein Zyklus mit 2 Schritten mehrere weitere kostspielige Aufrufe zulässt, bevor er abbricht. Ein viel besseres Signal ist die Wiederholung: Das Markieren aufeinanderfolgender Aufrufe derselben Funktion mit identischen Argumenten erfasst das zuvor beschriebene Muster direkt, ohne Aufgaben zu bestrafen, die einfach nur lang sind.
Fügen Sie einen menschlichen Kontrollpunkt sowie eine strenge Ausgabenbegrenzung hinzu
Jeder Auftrag, der länger als ein paar Minuten unüberwacht bleibt, sollte einen Zeitpunkt enthalten, zu dem ein Mensch den Fortschritt überprüft. Automatisierte Überwachungssysteme ergänzen dies. Beispielsweise bietet GitHubs gh-aw eine Kredit-Sicherheitsmaßnahme, die so konfiguriert werden kann, dass ein Workflow sofort gestoppt wird, sobald seine Ausgaben einen festgelegten Grenzwert überschreiten – anstatt die Erkennung demjenigen zu überlassen, der die Rechnung liest. Eine solche Sicherheitsmaßnahme dient als Notfallnetz, ersetzt aber keine gute Stoppbedingung; sie begrenzt jedoch den Schaden, wenn alles andere versagt.
Aktivität ist kein Fortschritt
Der beunruhigendste Aspekt eines außer Kontrolle geratenen Ablaufs ist nicht die Kosten, sondern das Selbstvertrauen. Die Ausgaben des Automaten zögern nie und geben niemals Unsicherheit darüber zu, ob irgendeine der durchgeführten Aufgaben hilft. Er erzeugt plausible Schritte, bis etwas Äußeres – oft eine Person, die sich über eine unerwartete Rechnung wundert – ihn stoppt.
Die Lektion besteht nicht darin, Agenten grundsätzlich weniger zu vertrauen. Sie besteht vielmehr darin, Bewegung nicht fälschlicherweise mit Fortschritt zu verwechseln – sowohl in automatisierten Systemen als auch bei vielen menschlichen Tätigkeiten.
Kernpunkte
- In einem Tool-Aufruf-Loop entscheidet das Modell allein, wann es fertig ist, indem es
end_turnzurückgibt; wenn das Ziel keinen erkennbaren Endpunkt hat, kann es dies möglicherweise nie tun. - Unkontrollierte Ausgaben konzentrieren sich auf unbegrenzte Forschungsarbeiten, überdimensionierte Modelle für einfache Schritte, ständig wachsende Aufgabenabläufe sowie vergessene geplante Aufträge.
- Das Erhöhen von Budgets oder Schrittlimits verzögert lediglich denselben Fehler; definieren Sie stattdessen die Fertigstellung explizit in der Aufgabe.
- Geben Sie eindeutige Ergebnisse der Tools zurück und erkennen Sie wiederholte, identische Tool-Aufrufe, anstatt sich auf die Anzahl der Schritte zu verlassen.
- Für unbeaufsichtigte Ausführungen sollten menschliche Kontrollpunkte mit strengen Ausgabenbegrenzungen kombiniert werden.
Zusätzliche Literatur
- AI-Agenten gegen Agentic AI: Ein praktischer Implementierungsleitfaden für Unternehmen — Erfahren Sie, wie man AI-Agenten von Agentic-AI-Systemen unterscheidet und ein strukturiertes Framework anwendet, um Implementierungswege auszuwählen, Risiken zu verwalten und die zukünftige Architektur zu planen.
- Chatbot gegen AI-Agent: Was sie tatsächlich voneinander unterscheidet – jenseits des LLM — Erfahren Sie, warum der eigentliche Unterschied zwischen Chatbots und AI-Agenten in der zugrundeliegenden Systemarchitektur liegt – Tools, Planung und Aktionen – und nicht im LLM selbst.