Warum KI-Agenten die QA bestehen und dennoch in der Produktion fehlschlagen

Das kontinuierliche Lernen wird zur Ingenieurdisziplin, um Agenten nach der Bereitstellung zu verbessern, ohne das bereits Funktionierende zu brechen.

Ein KI-Agent kann jeden vorherigen Test bestehen und dennoch eine Woche später in der Produktion fehlschlagen. Das ist kein Widerspruch. Die Testmenge spiegelt das wider, was das Team vor der Bereitstellung getestet hat. Die Produktion ist der Ort, an dem die fehlenden Fälle auftauchen: seltsame Formulierungen, fehlender Kontext, Tool-Sonderfälle, ungeduldige Benutzer, widersprüchliche Richtlinien und Workflows, die kein Benchmark-Designer sich vorstellen konnte.

Der Agent wird ständig von den Benutzern korrigiert. Er enttäuscht Benutzer. Dann endet die Sitzung, die Protokolldatei wird gespeichert und der nächste Benutzer trifft im Wesentlichen auf das gleiche System.

Das ist der Grund, warum das kontinuierliche Lernen zur zentralen Rolle bei der Agenten-Entwicklung wird. Es ist kein Feature eines Produkts. Es ist eine Kategorie von Methoden, um Agenten durch Erfahrung zu verbessern, während das bereits Funktionierende erhalten bleibt. Klassische Forschung zum kontinuierlichen Lernen hat das Problem als Lernen über die Zeit ohne katastrophales Vergessen definiert. Agenten machen dieses Problem breiter. Das, was sich ändert, kann ein Modell sein, aber es kann auch eine Aufforderung, ein Tool, eine Fähigkeit, ein Workflow oder ein Gedächtnis sein.

Diese Unterscheidung ist wichtig, weil die meisten Agentenfehler nicht durch das bloße Aktualisieren des Modells gelöst werden.

Der Feinabstimmungsreflex ist zu eng

Wenn Teams über die Verbesserung eines KI-Systems sprechen, klingt der Standardplan oft so: sammle Fehler, beschrifte bessere Antworten, feinabstimme das Modell. Dieser Instinkt ist verständlich. Überwachtes Feinabstimmen, Direkte Präferenzoptimierung, Gruppenrelative Richtlinienoptimierung und parameter-effiziente Methoden wie LoRA sind nützliche Werkzeuge, wenn das Modell selbst geändert werden muss.

Aber viele Produktionsfehler sind keine Modellfehler. Sie sind Systemfehler.

Der Agent kann auf veraltete Erinnerungen angewiesen sein, eine erforderliche Bestätigung überspringen, ein Tool mit dem falschen Argument aufrufen oder einen Fall durch den falschen Workflow leiten. Oft ist das Problem nicht die Fähigkeit des Basismodells. Es ist der Kontext, das Gedächtnis, die Tool-Schnittstelle oder der Workflow, der darum herum gewickelt ist.

Ein moderner Agent hat mehrere Schichten. Das Modell begründet und generiert. Die Umgebung um es herum definiert die Aufforderungen, Tools, Fähigkeiten, Code, Routing und Workflow. Das Gedächtnis trägt Fakten und gelernte Verfahren über Sitzungen hinweg. Kontinuierliches Lernen ist die Disziplin, zu entscheiden, welche Schicht geändert werden sollte, wie klein die Änderung sein kann und wie zu überprüfen ist, ob die Änderung tatsächlich geholfen hat.

Manchmal ist die richtige Korrektur eine Gedächtnisaktualisierung. Manchmal ist es eine Bearbeitung der Aufforderung. Manchmal ist es ein Tool-Wrapper, eine Routing-Regel oder ein Workflow-Patch. Feinabstimmung sollte weiterhin verfügbar bleiben, sollte aber nicht die erste Antwort auf jeden Fehler sein.

Benchmarks sind nützlich, aber die Produktion gibt sie selten

Es gibt spannende Arbeiten zur Optimierung der Agenten-Umgebung selbst. Methoden wie GEPA, Meta-Harness und verwandte Ansätze zur Optimierung von Aufforderungen oder Workflows behandeln den Agenten als ein System, das mutiert und getestet werden kann. Sie können Änderungen an Aufforderungen oder anderen Umgebungskomponenten vorschlagen, Kandidaten ausführen und die Versionen beibehalten, die besser abschneiden.

Das ist die richtige Richtung. Es verlagert die Verbesserung aus dem engen Rahmen des “Modellgewichtsaktualisierens” in den breiteren Rahmen des “Agentenverbesserns”.

Aber es gibt einen Haken: diese Methoden nehmen normalerweise an, dass ein Benchmark vorhanden ist. Sie benötigen eine Aufgabe, die wiederholt ausgeführt werden kann, und einen Evaluator, der sagt, ob Kandidat A besser ist als Kandidat B. Ohne das wird die Optimierung zu einer Vermutung mit besseren Werkzeugen.

Das ist nicht das, was die meisten Teams in der Produktion haben.

Was sie haben, sind Protokolle. Sie haben Spuren, Benutzerkorrekturen, Support-Tickets, Daumen-hinunter-Ereignisse, Eskalationshinweise und gelegentliche Expertenfeedback. Diese Signale sind wertvoll, aber sie sind noch kein Benchmark. Sie sagen, dass etwas passiert ist. Sie sagen nicht automatisch, wie man es wiederholen, was Erfolg aussehen sollte oder wie man eine vorgeschlagene Korrektur bewerten soll.

Diese Lücke ist der Punkt, an dem viele kontinuierliche Lernbemühungen ins Stocken geraten. Das Team hat Erfahrung, aber noch keine Lernumgebung.

Protokolle sind keine Lektionen

Ein Produktionsprotokoll zeichnet einen Pfad durch eine Interaktion auf. Ein Benutzer hat nach einem Flug gefragt. Der Agent hat gesucht. Der Benutzer hat gesagt, das Datum sei falsch. Das ist ein Beweis für einen Fehler, aber es ist nicht genug, um daraus zu lernen.

Das Protokoll definiert nicht den kontrafaktischen Fall. Sollte der Agent um Bestätigung gebeten haben? Sollte er das Datum aus dem vorherigen Kontext abgeleitet haben? Sollte er ein anderes Tool aufgerufen haben? Sollte er den Vorgang abgebrochen haben, bis die Unklarheit aufgelöst war? Ein Mensch kann die Antwort kennen, nachdem er die Spur gelesen hat, aber das System erhält diese Struktur nicht kostenlos.

Damit kontinuierliches Lernen funktioniert, muss ein roher Fehler in etwas Wiederholbares umgewandelt werden. Das bedeutet eine Aufgabe, die der Agent wiederholen kann, ein Benutzer oder Simulator, der das relevante Muster wiederholt, Tools, die der Agent aufrufen kann, und Evaluator, die Erfolg definieren. Der Evaluator kann die endgültige Antwort überprüfen, die Tool-Aufrufe, eine Richtlinien-Grenze, Latenz, Kosten oder all diese.

Dies ist der weniger sichtbare Teil der Arbeit, aber es ist der Teil, der die Verbesserung real macht. Sobald ein Fehler zu einer wiederholbaren Umgebung wird, kann man eine konkrete Frage stellen: Hat die vorgeschlagene Korrektur tatsächlich das Verhalten verbessert?

Ohne diesen Schritt patchen Teams hauptsächlich aus dem Gedächtnis.

David Silver und Richard Sutton haben eine kommende Ära der Erfahrung beschrieben, in der Agenten hauptsächlich durch Interaktion mit der Welt und nicht durch statische menschliche Daten lernen. Für Unternehmensagenten hängt diese Vision davon ab, die chaotische Produktionserfahrung in Umgebungen umzuwandeln, die wiederholt, bewertet und wiederverwendet werden können.

Erfahrung allein reicht nicht aus. Sie muss testbar gemacht werden.

Regression ist die versteckte Kosten

Selbst wenn ein Fehler testbar wird, bleibt der schwierigste Teil: die Korrektur ohne etwas anderes zu brechen.

Jeder, der einen komplexen Agenten gewartet hat, hat dieses Muster gesehen. Man fügt eine Anweisung hinzu, damit der Agent aggressive Rückerstattungsanfragen eskaliert. Jetzt eskaliert er auch routinemäßige Rückerstattungen, die schnell bearbeitet werden sollten. Man reduziert Tool-Aufrufe in einem Workflow. Jetzt überspringt ein anderer Workflow eine erforderliche Überprüfung. Man korrigiert ein veraltetes Gedächtnis. Jetzt verallgemeinert der Agent die Korrektur zu einer anderen Produktlinie.

Jedes Patch macht lokal Sinn. Das System driftet dennoch global.

Das ist die Agenten-Version des katastrophalen Vergessens. In neuronalen Netzen bezieht sich der Begriff normalerweise auf neue Schulungen, die ältere Fähigkeiten überschreiben. Bei Agenten ist der Fehler breiter und oft schwerer zu erkennen. Vergessen kann in Aufforderungen, Tools, Gedächtnis, Routing und Workflow auftreten. Es zeigt sich nicht als saubere Metrik auf einer Trainingskurve, sondern als ein Benutzer, der sagt: “Das hat früher funktioniert”.

Das ist, warum die Regressionskontrolle nicht als endgültiger Überprüfungsschritt dienen kann. Sie muss innerhalb der Lernschleife selbst liegen.

Das Ziel ist nicht einfach, die Leistung auf den neuesten Fehler zu maximieren. Das Ziel ist, den neuen Fall zu verbessern, während die alten Fälle erhalten bleiben. Jede Korrektur, die funktioniert, sollte Teil des wachsenden Gedächtnisses des Agenten werden, was bereits funktioniert. In der Praxis bedeutet das, dass alte Fehler zu Regressions-Tests werden. Die Geschichte des Agenten wird zu einer Einschränkung, nicht nur zu einem Archiv.

Das ist der Punkt, an dem kontinuierliches Lernen mehr wie ernsthafter Software-Engineering als wie Prompt-Tüfteln wird. Eine Änderung ist nicht gut, weil sie besser klingt. Sie ist gut, weil sie ein gemessenes Verhalten verbessert und die Verhaltensweisen, die das System bereits erworben hat, nicht regressiert.

Was praktisches kontinuierliches Lernen erfordert

Eine produktionsreife kontinuierliche Lernschleife benötigt vier Eigenschaften.

Erstens müssen Fehler wiederholbar sein. Ein einmaliger Fehler ist eine Anekdote. Eine wiederholbare, bewertete Umgebung ist ein Test. Bis der Agent dem gleichen Muster wieder begegnen kann, kann niemand beweisen, dass die Korrektur funktioniert hat.

Zweitens muss die Diagnose holistisch sein. Die Korrektur kann im Modell liegen, aber sie kann auch im Gedächtnis, in der Aufforderung, in der Tool-Schicht oder im Workflow liegen. Die beste Korrektur ist normalerweise die kleinste dauerhafte Änderung, die den Fehler erklärt.

Drittens muss das Lernen lebenslang sein. Der Agent sollte sich nicht diese Woche verbessern, indem er stillschweigend das Verhalten der letzten Woche rückgängig macht. Vorherige Erfolge sollten während der Optimierung zu Einschränkungen werden, nicht zu Überraschungen nach der Bereitstellung.

Viertens muss die Schleife effizient sein. Wenn jede Verbesserung ein quartalsweises Schulungsprojekt erfordert, wird das System nie mit der Produktion Schritt halten. Die Schleife muss billige Korrekturen zuerst versuchen, nur dann eskalieren, wenn notwendig, und die Überprüfung nahe bei der Änderung halten.

Keines davon bedeutet, dass Agenten sich blind aktualisieren sollten. Es bedeutet das Gegenteil. Die Verbesserung sollte messbar werden. Jede Änderung sollte einen Test, einen Vorher-Nachher-Score und eine Regressions-Überprüfung haben.

Das ist, was kontinuierliches Lernen von einer vagen Aspiration zu einer Ingenieurdisziplin macht.

Die Zukunft der Agenten wird nicht nur durch größere Kontextfenster, stärkere Basismodelle oder mehr Tools definiert. Das wird wichtig sein. Aber die wichtigere Frage für Unternehmen ist, was nach der Bereitstellung passiert.

Wenn der Agent morgen fehlschlägt, kann das System diesen Fehler in einen Test umwandeln? Kann es die Korrektur an die richtige Schicht weiterleiten? Kann es beweisen, dass die Korrektur half? Kann es beweisen, dass nichts anderes gebrochen wurde?

Wenn die Antwort nein ist, lernt der Agent nicht wirklich aus der Produktion. Er sammelt Risiken.

Die Agenten, die zählen, werden etwas Besseres tun. Sie werden sich verdichten.