Persistente KI-Agenten in der Praxis: Kosten, Speicherverschiebungen und das 80%-Problem

Etwa zwei Jahre lang war die übliche Art, ein Modell zu nutzen, ein Dialog. Man tippt eine Nachricht ein, liest die Antwort und verwendet sie anschließend oder diskutiert mit ihr. Man befindet sich in einem Kreislauf und überprüft jede Ausgabe, bevor sie weitergeleitet wird. Dann änderte sich der Ansatz: Man hörte auf, Eingabefragen zu tippen, und nutzte stattdessen Agenten, die eigenständig weiterarbeiten konnten – mit Speicherfähigkeit, Werkzeugen sowie der Befugnis, Aufgaben ohne ständige Überwachung abzuschließen. Probieren Sie das eine Woche lang mit Agenten aus, die Code lesen, Befehle ausführen und Pull Requests erstellen – in einigen Fällen hält dieser Ansatz, in vielen anderen jedoch nicht. Die Misserfolge treten in einer recht vorhersehbaren Reihenfolge auf.

Warum die Leute auf Eingabefragen verzichteten

Der Verzicht auf Anfragen spiegelt eine echte Grenze wider. Eine Anfrage besteht aus einer Frage und einer Antwort, was für eine Suche ausreicht. Sie eignet sich jedoch nicht für Aufgaben, bei denen das Modell Informationen aus mehreren Quellen sammeln, über das Gekannte nachdenken, ein Werkzeug nutzen und auf der Grundlage der Rückmeldung anpassen muss. All das auf einmal zu verlangen, entspricht nicht der Vorgehensweise in der realen Arbeit.

Was benötigt wird, ist ein Kreislauf: Denken, handeln, das Ergebnis betrachten, erneut nachdenken. Fügt man eine zwischen den Sitzungen bestehende Speicherung hinzu, erhält man das, was man als persistenten Agenten bezeichnet. Eine Unterscheidung, die früh klar definiert werden sollte: Eine Chat-Transkript ist nicht der Speicher des Agenten. Der Speicher ähnelt eher einer Datei, in die der Agent lesen und schreiben kann, um sich Dinge zu merken. Dieser Unterschied wird weiter unten erläutert.

Daher macht der Schritt Sinn, und niemand sollte so tun, als wäre das nicht der Fall. Entscheidend ist, was passiert, sobald man ihn tatsächlich durchführt – angefangen bei den Kosten bis hin zu der Frage, wer weiterhin für das Ergebnis verantwortlich ist.

Die Rechnung

Das Erste, was niemand erwähnt: Jeder API-Aufruf beginnt von vorne. Der Anbieter speichert keine Erinnerung an frühere Aufrufe, sodass das Programm jedes Mal den gesamten Dialog erneut senden muss, wenn es etwas anfordert. Der erste Schritt ist günstig. Bei Schritt zwanzig, mit Tool-Ausgaben und zusätzlichen Details, können einzelne Aufrufe Tausende von Wörtern enthalten – und man zahlt für all das bei jedem Aufruf.

Die Rechnung wird unangenehm. Eine Untersuchung von dreißig Ingenieurteams ergab, dass ein verspäteter Schritt in einer Aufgabe etwa fünfzehn Cent kostete. Das klingt unbedeutend, bis man es mit fünfzig Schritten pro Aufgabe, Dutzenden von Aufgaben pro Entwickler pro Tag sowie einem ganzen Team multipliziert. Das Ergebnis liegt bei sechsstelligen Beträgen pro Monat, und die Agenten verbrauchen für dieselbe Aufgabe weitaus mehr Token als ein einfacher Chat.

Ein weiteres Risiko sind die außer Kontrolle geratenen Kosten. Eine Schleife, die ständig versucht, etwas zu wiederholen, das nicht funktionieren kann, führt weiterhin zur Abrechnung. Es gibt eine Geschichte über ein Unternehmen, das genau aufgrund dieses Musters mit einer Rechnung in Höhe von einer halben Milliarde Dollar konfrontiert wurde. Unabhängig davon, ob diese Zahl genau stimmt oder nicht, ist es durchaus glaubwürdig, dass ein einziger falsch konfigurierter Agent einen ganzen täglichen Budgetbetrag für eine zehnminütige manuelle Aufgabe verbraucht. Beunruhigend ist, dass alles normal erscheint, während es passiert – der Agent arbeitet schließlich weiter, auch wenn er im Kreis läuft.

Die in der Praxis funktionierende Lösung besteht aus drei Teilen:

• Ein festes Tagesbudget für jeden Agenten, das außerhalb des Agenten selbst durchgesetzt wird
• Ein rollierendes Kontextfenster, sodass frühere Schritte verschwinden und sich nicht anhäufen
• Die Übertragung routinemäßiger Aufgaben an ein günstiges Modell sowie die Weiterleitung nur der schwierigen Fälle an ein leistungsstärkeres Modell

Teams, die diese einfache Instrumentierung einsetzten, berichteten, dass die Kosten pro Agent innerhalb eines Monats um über 50 % sanken. Ein intelligenteres Modell war dabei nie der Schlüssel – vielmehr war es die Kontrolle, und das sollte unverblümt gesagt werden, denn der erste Impuls, wenn die Rechnung eintrifft, ist es, nach einem besseren Modell zu suchen.

Der erste Pull Request ist ein Trick

Der erste Pull Request eines Agenten kann beeindruckend aussehen: Eine ganze Funktion erscheint innerhalb von Minuten und alle Tests bestehen, wodurch man zunächst Erleichterung verspürt. Danach entsteht jedoch der Verdacht, dass die eigentliche Arbeit noch nicht erledigt wurde – und dieser Verdacht ist in der Regel berechtigt.

Die Teams melden weiterhin dasselbe Muster: Der erste Pull Request ist beeindruckend, und beim fünften bricht in der Produktion etwas, was von keinem Test erkannt wurde. Es fehlte eine Wiederholung des Vorgangs. Ein Nullfall wurde nicht behandelt. Eine Authentifizierungsprüfung umfasste drei Endpunkte und übersprang den vierten. Der Code funktionierte, hielt aber dem realen Einsatz nicht stand.

Das wird oft als das 80%-Problem bezeichnet. Der Automatisierungsagent erledigt die offensichtlichen 80 % und übersieht stets die 20 %, die aus nicht-funktionalen Anforderungen, Ausfallmöglichkeiten und architektonischer Konsistenz bestehen – schließlich benötigt dieses 20 % einen Kontext, den der Agent nicht besitzt. Er schreibt Code, der läuft, aber keinen Code, der Bestand hat.

Hier ist eine einzeilige Beschreibung dieser Falle: Der Code wurde kompiliert, überstand die Formatprüfung und tat dennoch das Falsche, weil ihm keine weitere Aufmerksamkeit geschenkt wurde. Die Ausgabe sieht vollständig aus, weshalb sie nur flüchtig überflogen wird – so wie man die Arbeit eines Junior-Mitarbeiters kurz betrachtet.

Es kostet mehr, es später zu reparieren, als es von Anfang an richtig zu machen. Die Probleme treten im gesamten Codebase wieder auf, sodass es keinen einzigen Ort gibt, an dem man sie beheben könnte.

Es gibt zwei Arten von Speicher

Das größte Problem war der Speicher, in zwei Formen, die anfangs nicht offensichtlich waren.

Die erste ist das Vergessen innerhalb einer Aufgabe. Wenn eine Aufgabe zu lange dauert, vergisst der Agent die Entscheidungen, die er zu Beginn getroffen hat. Die übliche Lösung in der Branche besteht darin, ihm mehr Kontext zur Verfügung zu stellen – ein oder zwei Millionen Token – in der Annahme, dass das Sehen von allem zu besseren Entscheidungen führt. Das hält jedoch nicht stand. Ein Agent, der sich mit einem großen Haufen komplizierten Codes konfrontiert sieht, gerät in Verwirrung. Er kann zwar ein Problem beheben, aber dadurch ein größeres verursachen, weil er viele kleine Teile sieht, aber das Ganze nicht versteht.

Die zweite Form ist heimtückischer und verursacht den eigentlichen Schaden: den Kontextverlust. Der Agent befolgt Konfigurations- und Spezifikationsdateien. Während die Codebasis weiterentwickelt wird, bleiben diese Dateien unverändert. Bald schreibt ein ständig aktiver Worker selbstbewusst Code nach einem Standard, der bereits vor Monaten veraltet ist – und es scheint alles in Ordnung zu sein, weil er den Anweisungen einer veralteten „Wahrheitskopie“ getreulich folgt. Wenn man das auf mehrere Agenten und Repositorien ausdehnt, wird die Kluft jeden Tag lautlos größer.

Dort weicht die Schuld vom Modell ab. Das defekte Element war nicht das Modell, sondern das Projektgedächtnis – jener Teil, der auf der Festplatte gespeichert ist und länger besteht als jede Sitzung –, das nicht richtig implementiert wurde.

Die Aufgabe des Entwicklers hat sich verlagert

Der Entwickler selbst ist nicht weniger geworden. Die Aufgabe hat sich lediglich verlegt, und das Ergebnis ist weniger dramatisch als die damit verbundenen Erwartungen oder Kritiken.

Sobald ein Agent lange Zeit läuft, spielt die Erstellung von Prompten kaum noch eine Rolle. Entscheidend ist der Kontext: Was der Agent sehen kann, was er sich merken kann, was ihm erlaubt ist zu tun und wie man überhaupt herausfinden kann, was er getan hat. Die Teams, die Ergebnisse erzielten, verfügten nicht über kluge Prompts. Sie erstellten Spezifikationen, hielten diese auf dem neuesten Stand, gaben sie dem Agenten als „Gedächtnis“ und überprüften selbst die Architektur.

Eine auf Spezifikationen basierende Arbeitsweise macht den Entwickler wichtiger und lenkt die Anstrengungen in eine andere Richtung: Die Definition dessen, was das System tun soll, die Genehmigung dafür, wie weit der Agent gehen darf, sowie die Überprüfung der von ihm vorgeschlagenen Architektur. Wenn sich die Anforderungen ändern, ändern sich auch die Spezifikationen – nicht die Prompts. Der Agent entwirft, implementiert und testet anhand dieser Spezifikationen und hat keinen Einfluss auf die Richtung. Diese Trennung war die einzige Vorgehensweise, die verhinderte, dass alles aus dem Ruder lief.

Hinter all dem verbirgt sich eine gemessene Schärfe. Eine Studie maß die Arbeitsgeschwindigkeit von Entwicklern in echten Codebasen und stellte fest, dass sie etwa 19 % langsamer waren, obwohl sie das Gefühl hatten, etwa 20 % schneller zu arbeiten. Das Gefühl von Schnelligkeit und tatsächliche Geschwindigkeit trennten sich dabei voneinander. Persistente Agenten vergrößern diesen Unterschied, wenn sie die Möglichkeit dazu haben, da sie hervorragend darin sind, das Gefühl von Geschwindigkeit zu erzeugen. Was ihn verringert, ist langweilig, aber notwendig: Governance, Überprüfungen, eine Spezifikation, die der Realität entspricht, sowie Obergrenzen für Ausgaben.

Zurück zu reinem Prompting zu greifen, ist nicht die Lösung, da der Kreislauf mächtiger ist. Doch der Agent ist kein Kollege – er ist ein schneller, selbstbewusster Auftragnehmer, der niemals zugegeben hat, unsicher zu sein. Man behält einen solchen Auftragnehmer, weil er nützlich ist, und man liest jedes Mal alles, was er einem überreicht.