KI-Agenten zuverlässig betreiben

Die Demo funktioniert. Sie funktioniert immer. Jemand nimmt dreißig Sekunden auf, in denen ein Agent sich an einem Portal anmeldet, eine Rechnung herunterlädt und ablegt, und die Aufnahme ist ehrlich, das ist tatsächlich passiert.

Dann läuft dieselbe Aufgabe einen Monat lang vierhundertmal am Tag, und das Bild ändert sich vollständig.

Was folgt, ist eine Systematik dessen, was tatsächlich schiefgeht, geordnet nach Fehlerbild statt nach Komponente. Denn die brauchbare Frage um drei Uhr nachts lautet nicht, welche Schicht betroffen ist, sondern welche Art von Problem vorliegt und ob es wiederkehrt.

Die wichtigste Eigenschaft dieser Liste: Vier der acht Fehlerbilder sind still. Sie lösen keine Ausnahme aus. Der Prozess endet mit null. Eine Überwachung, die auf Rückgabewerten aufbaut, meldet wochenlang ein gesundes System, das nichts Brauchbares produziert.

Die acht Fehlerbilder

1. Selektoren greifen nicht mehr — laut, häufig, verstanden

Der Klassiker. Ein Knopf wandert, ein Klassenname wird beim Bauvorgang neu erzeugt, ein umschließendes Element kommt hinzu, und ein Selektor, der acht Monate getragen hat, greift nicht mehr.

Das ist der Fehler, mit dem alle rechnen, und deshalb der am wenigsten interessante. Er scheitert sofort und sichtbar. Die Wiederholung greift, die Alarmierung feuert, jemand repariert. Die Kosten sind real, aber es sind Pflegekosten und kein Korrektheitsrisiko.

Hier helfen Agenten tatsächlich, und das ist das stärkste ehrliche Argument für sie: Ein Modell, das die Seite in jedem Zug neu liest, stört ein geänderter Klassenname nicht.

2. Zeitpunkt und Bereitschaft — laut, häufig, falsch diagnostiziert

Das Element steht im DOM, ist aber noch nicht bedienbar. Der Klick landet auf der Überlagerung, die gerade ausblendet. Die Seite hat ihr Ladeereignis ausgelöst, aber das Framework hat die Ereignisbehandlung noch nicht angehängt.

Falsch diagnostiziert, weil das Symptom auf das Element zeigt und die Ursache ein Wettlauf ist. Das Erkennungsmerkmal ist die Sporadik: ein Schritt, der etwa jeden zwölften Lauf scheitert, immer bei den langsameren, und nie wenn man von Hand durchgeht.

Die Lösung ist fast nie eine längere Wartezeit, sondern eine Zusicherung auf den Zustand, der den Klick sinnvoll macht — und anschließend auf das Ergebnis statt auf die Ursache. Eine Prüfung, die scheitert, weil etwas nicht eingetreten ist, liefert eine brauchbare Fehlermeldung; eine, die scheitert, weil etwas nicht gefunden wurde, schickt Sie auf die falsche Fährte.

3. Sitzung und Anmeldung laufen ab — erst still, dann laut

Ein Sitzungs-Cookie läuft ab. Ein Token rotiert. Das Portal verwirft die Sitzung, weil es eine Anmeldung von einer anderen Adresse gesehen hat. Die nächste Anfrage liefert Status 200 und die Anmeldeseite.

Unangenehm, weil der Statuscode in Ordnung ist und die Seite korrekt dargestellt wird. Es ist eine erfolgreiche Antwort auf eine Anfrage, die niemand stellen wollte. Läuft die Extraktion danach weiter, extrahiert sie die Anmeldeseite, und was sie nachgelagert schreibt, ist strukturell gültig und inhaltlich leer.

Zwei Dinge helfen. Erstens eine Zusicherung auf ein Merkmal, das nur nach der Anmeldung existiert, bevor irgendetwas anderes geschieht. Zweitens die Sitzungsdauer als bekannte Größe zu behandeln: Läuft eine Sitzung nach zwanzig Minuten ab, hat eine Aufgabe von fünfundzwanzig Minuten einen Fehler, der nur noch nicht eingetreten ist.

4. Stille leere Extraktion — still, häufig, teuer

Der Selektor hat gegriffen. Das Element war da. Der Textinhalt war eine leere Zeichenkette, weil der Wert nachgeladen wird und zu früh gelesen wurde, oder weil das Feld für diesen Datensatz tatsächlich leer ist und niemand entschieden hat, was das bedeuten soll.

Das ist das Fehlerbild, das sechs Wochen später den Anruf produziert, warum die Zahlen nicht stimmen.

Die Abwehr ist eine Prüfschicht, die von der Extraktion getrennt ist und strukturell gültigen Unsinn nicht durchlässt. Die Prüfungen, die am meisten finden, gehen über mehrere Felder: Eine Rechnungssumme, die nicht der Summe ihrer Positionen entspricht, ist ein gefundener Fehler. Ein gefülltes Textfeld ist kein Beleg für irgendetwas.

5. Blockiert oder gedrosselt — laut oder still, je nach Gegenseite

Sie fragen schneller an, als die Gegenseite erwartet, aus einem Adressbereich mit schlechter Vorgeschichte, oder in einem Muster, das nicht nach einem Menschen aussieht. Die Antwort ist ein Statuscode 429, eine Zwischenseite, eine Aufgabe — oder, in der stillen Variante, eine normal aussehende Seite mit weniger Daten darauf.

Die wichtige Umdeutung: Das ist zuerst ein Zuverlässigkeitsproblem. Der Reflex in dieser Branche ist Proxy-Rotation, was Blockierung als Netzwerkproblem behandelt, um das herumzurouten wäre. Meist ist es ein Verhaltensproblem. Die Rate zu halbieren löst einen erheblichen Teil dieser Fälle, kostet nichts im Versuch und gehört genau deshalb an den Anfang.

Wo eine echte Geschäftsbeziehung besteht, ist die tragfähige Antwort ein Eintrag in einer Freigabeliste oder eine deklarierte Agentenidentität statt einer Tarnung. Was auf der Gegenseite tatsächlich gemessen wird, beschreibt der Glossareintrag zur Bot-Erkennung.

6. Auseinanderlaufende Pfade — still, agentenspezifisch

Zwei Läufe derselben Aufgabe nehmen verschiedene Wege. Beide sind zulässig. Einer klickt Alle herunterladen, der andere lädt jede Rechnung einzeln, und der zweite dauert elfmal so lange und kostet elfmal so viel.

Keiner der Läufe ist gescheitert. Ihre Erfolgsquote sagt hundert Prozent. Ihre Rechnung sagt etwas anderes.

Sichtbar wird das über die Zahl der Züge je Aufgabe, erfasst als Verteilung und nicht als Mittelwert. Eine Aufgabe mit einem Median von acht Zügen und einem fünfundneunzigsten Perzentil von sechzig ist nicht eine Aufgabe, sondern zwei mit demselben Namen.

7. Prompt Injection über Seiteninhalte — still, agentenspezifisch, sicherheitsrelevant

Die Seite enthält Text, den das Modell als Anweisung liest. Ein eingereichtes Ticket, eine Produktbewertung, ein Dateiname in einer Auflistung, ein bewusst platziertes verstecktes Element.

Das ist nicht hypothetisch. Jeder Ablauf, in dem ein Agent von Dritten verfasste Inhalte liest, hat diese Angriffsfläche, und ihr Ausmaß entspricht dem, was der Agent anschließend tun darf.

Für diese Systematik ist der Punkt enger: Injection zeigt sich als erfolgreicher Lauf. Der Agent hat etwas getan. Er hat Abschluss gemeldet. Nichts hat ausgelöst.

8. Ressourcen im Browser-Prozess erschöpfen — laut, aber spät

Lange Sitzungen sammeln an. Abgehängte Knoten, nicht entfernte Ereignisbehandlungen, ein wachsender Speicher in einer Anwendung, die für einen Menschen entworfen wurde, der den Tab irgendwann schließt. Der Browser wird langsam, dann unansprechbar, dann beendet.

Das ist ein Fehler des Betriebsmodells mehr als der Automatisierung. Eine Sitzung je Aufgabe mit erzwungener Obergrenze für Dauer und Speicher verwandelt eine langsame Verschlechterung in ein sauberes, zuordenbares Scheitern. Das ist eindeutig besser: Eine gescheiterte Aufgabe ist wiederholbar, eine still langsamer werdende Flotte nicht.

Das Muster

Fehlerbild	Signal	Wiederkehrend	Gefunden durch
Selektoren	Laut	Ständig	Rückgabewert
Zeitpunkt	Laut, sporadisch	Ständig	Sporadikquote
Sitzungsablauf	Still	Vorhersehbar	Zusicherung nach Anmeldung
Leere Extraktion	Still	Ständig	Füllgrad je Feld
Blockierung	Beides	Unter Last	Prüfung der Antwortform
Pfaddivergenz	Still	Immer	Verteilung der Zugzahl
Prompt Injection	Still	Selten, schwer	Protokoll der Handlungen
Ressourcen	Laut, spät	Bei Dauer	Sitzungsgrenzen

Jedes stille Fehlerbild in dieser Tabelle wird durch eine Datenprüfung gefunden und durch keine Prozessprüfung. Das ist das Nützlichste auf dieser Seite. Eine Überwachung, die fragt, ob der Prozess sauber beendet hat, ist für fünf von acht Zeilen blind.

Was stattdessen zu messen ist

Füllgrad je Feld über die Zeit. Nicht ob ein Datensatz kam, sondern welcher Anteil der Datensätze diese Woche ein gültiges Feld hatte, verglichen mit der Vorwoche. Alarmieren Sie auf die Veränderung, nicht auf den Absolutwert.

Verteilung der Zugzahl je Aufgabentyp. Median, fünfundneunzigstes Perzentil und die Zahl der Läufe über Ihrer Obergrenze. Das ist Kostenkontrolle und Divergenzerkennung in einer Kennzahl und nahezu kostenlos zu erheben.

Zeit bis zur ersten belastbaren Zusicherung. Wie lange vom Sitzungsstart bis zur ersten Prüfung, die belegt, dass Sie dort und als der angemeldet sind, wo und als der Sie sein wollten. Steigende Werte kündigen Blockierung an, bevor die Blockierung sichtbar wird.

Verfügbarkeit einer Aufzeichnung für gescheiterte Läufe. Keine Kennzahl, sondern eine Fähigkeit. Der Unterschied zwischen fünf Minuten und zwei Tagen Diagnose ist, ob Sie sehen können, was der Agent gesehen hat. Wer das beim Scheitern verwirft, hat Speicherplatz auf Kosten genau des Dinges optimiert, das am schlechtesten Tag gebraucht wird.

Vier Entscheidungen, die den Betrieb tragen

Legen Sie fest, was fertig bedeutet, in Daten. Jede Aufgabe braucht ein Abschlusskriterium, das ohne Vertrauen in den Selbstbericht des Agenten prüfbar ist. Der Agent hat gesagt, er habe die Rechnung abgelegt, ist kein Signal. Eine Zeile im Journal mit dieser Rechnungsnummer und dem heutigen Datum ist eines.

Geben Sie jedem Lauf ein Budget in drei Dimensionen. Wanduhrzeit, Zugzahl und Tokenverbrauch. Ein Lauf, der eine davon überschreitet, gehört beendet und nicht gemeldet. Ein abgedrifteter Lauf weiß nicht, dass er abgedriftet ist.

Trennen Sie die Entscheidung über die Wiederholung von der Wiederholung. Nicht jedes Scheitern gehört wiederholt. Zeitprobleme sofort, Sitzungsablauf nach erneuter Anmeldung, Drosselung mit langer Wartezeit, Selektorbruch gar nicht, Prüfungsfehler in die Warteschlange. Die überraschende Zeile ist die letzte: Der Reflex ist die Wiederholung, weil sie billig ist, doch ein Datensatz, der eine Konsistenzprüfung nicht bestanden hat, ist selten aus einem vorübergehenden Grund gescheitert.

Bewahren Sie den Nachweis auf und machen Sie ihn adressierbar. Je Lauf: die letzte Adresse, ein Zeitstempel, das Rohfragment je extrahiertem Feld und eine Aufzeichnung, sofern vorhanden. Das ist wenig Speicher und der ganze Unterschied zwischen einer Antwort auf eine Rückfrage und einem Achselzucken.

Was ein Agent im Betrieb tatsächlich kostet

Die Kostenfrage wird meist als Preis je Modellaufruf diskutiert, und das ist der kleinere Teil. Die Rechnung entsteht an einer Stelle, an der niemand nachsieht.

Jeder Zug überträgt eine Darstellung des aktuellen Bildschirms erneut an das Modell. Eine dichte Portalseite als Accessibility-Baum ist eine erhebliche Textmenge, und sie geht in jedem einzelnen Zug wieder hinaus. Über eine Aufgabe mit fünfzehn Zügen wird dieselbe Seite in Varianten fünfzehnmal gesendet. Die Token für die eigentliche Schlussfolgerung sind meist die kleinere Hälfte.

Daraus folgen drei Hebel, in dieser Reihenfolge:

Die Darstellung kürzen. Nur den relevanten Bereich statt des ganzen Dokuments zu senden halbiert die Rechnung regelmäßig und verbessert dabei häufig die Trefferquote, weil weniger ablenkt. Das ist der mit Abstand wirksamste Eingriff und er ist rein technisch.

Züge begrenzen. Ohne Obergrenze ist das obere Ende Ihrer Kostenverteilung unbegrenzt, und es besteht ausschließlich aus Läufen, die bereits schieflaufen. Die Grenze ist Ihr tatsächliches Budget, ob sie bewusst gesetzt wurde oder nicht.

Deterministisches skripten. Anmeldung, Navigation zu einem bekannten Bereich, Blättern und Herunterladen sind stabil und günstig zu kodieren. Ein Modell dort einzusetzen bezahlt Entscheidungen, die längst getroffen sind. Rufen Sie es dort, wo das Skript nicht auflösen kann, was es sieht, und kehren Sie danach ins Skript zurück.

Und eine Kennzahl, die alles andere ersetzt, wenn Sie nur eine erheben: Kosten je erfolgreichem Ergebnis. Kosten je Lauf schmeicheln, weil sie die günstigen Fehlläufe mitzählen. Scheitert ein Fünftel der Läufe nach zwanzig Zügen, stehen sie im Budget, ob sie im Dashboard stehen oder nicht.

Wo Agenten helfen und wo nicht

Agenten verringern Fehlerbild 1 deutlich, und das ist ihr gesamter Fall. Sie lassen die Bilder 2, 3, 5 und 8 unverändert, weil Bereitschaftsrennen, Sitzungsablauf, Blockierung und Speicherwachstum Eigenschaften des Browsers und des Netzes sind und nicht davon abhängen, wer entscheidet. Und sie führen die Bilder 6 und 7 neu ein, die beide still sind.

Der ehrliche Schluss: Agenten tauschen ein lautes, häufiges, verstandenes Fehlerbild gegen zwei stille, seltenere, weniger verstandene. Das ist oft ein guter Tausch, denn ein lautes Fehlerbild bei hoher Frequenz ist teuer. Aber es ist ein Tausch, und er gehört gemacht, wenn die Instrumentierung für die neuen Bilder schon steht — nicht nach dem ersten Vorfall.

Was darunter liegt, muss ohnehin jemand betreiben. Ob das eine eigene Flotte ist oder eine gemietete, ist eine getrennte Rechnung; wichtiger ist, dass die Messdisziplin oben unabhängig davon gilt.