Die meisten Engineering-Teams bewerten KI-Agenten immer noch so, wie sie Hausaufgaben in Mathematik korrigieren. Sie schauen sich das Endergebnis an. Wenn die Antwort richtig ist, geben sie die Veröffentlichung frei und machen weiter. Das ist eine gefährliche Abkürzung. Eine korrekte Antwort kann ein zutiefst fehlerhaftes System verbergen.

Die eigentliche Geschichte liegt in dem Pfad, den der Agent genommen hat, um dorthin zu gelangen. Dieser Pfad wird als Agenten-Trajektorie bezeichnet. Er umfasst jeden Tool-Aufruf, jede Routing-Entscheidung und jede Pause, in der der Agent innehält, um seine Entscheidung zu überdenken. Man kann es sich wie die Brotkrumen eines Agenten vorstellen. Und wenn man nur das Ziel untersucht, übersieht man alle Warnsignale, die entlang des Weges verstreut sind.

Das Problem mit unordentlichen Pfaden

Ein Agent kann die richtige Antwort finden, während er sich wie ein betrunkener Autofahrer verhält. Er schert durch die falschen Tools aus, kehrt zum Router zurück und durchläuft redundante Denkprozesse, bevor er schließlich zufällig etwas Richtiges findet. Der Nutzer sieht ein sauberes Ergebnis. Hinter den Kulissen verliert das System Ressourcen und häuft Risiken an.

Wie sieht dieses Chaos in der Praxis tatsächlich aus?

Erstens gibt es den redundanten Tool-Aufruf. Der Agent fragt Ihre Kundendatenbank ab, erhält das Ergebnis, vergisst es fünf Sekunden später und fragt denselben Datensatz erneut mit identischen Parametern ab. Das ist kein Datenproblem. Es ist ein Trajektorien-Problem. Der Agent hat es versäumt, den Zustand beizubehalten, also wiederholt er die Arbeit.

Dann gibt es das „Wrong-Tool-First“-Muster. Ein Coding-Agent versucht vielleicht, im Web nach einer Funktionsdefinition zu suchen, die bereits im lokalen Repository vorhanden ist. Oder ein Support-Agent greift auf die Billing-API zu, obwohl die Frage des Nutzers eindeutig das Tool für die Kontoeinstellungen erfordert. Jede falsche Entscheidung verbraucht Tokens, erhöht die Latenz und steigert die Wahrscheinlichkeit, dass die Kontextlimits gesprengt werden, bevor die eigentliche Arbeit beginnt.

Router-Schleifen sind ein weiteres Warnsignal. Der Entscheidungsknoten kann sich nicht festlegen. Er sendet die Aufgabe an Zweig A, ändert seine Meinung, zieht sie zurück, leitet sie an Zweig B weiter und routet sie dann ohne Grund durch einen allgemeinen Fallback-Knoten. Jede Schleife fügt einen weiteren Netzwerk-Hop und eine zusätzliche Ebene der Verwirrung im späteren Debug-Log hinzu.

Schließlich gibt es die wiederholte Analyse. Der Agent leitet bei jedem Schritt immer wieder dieselbe Schlussfolgerung ab, anstatt sie als feststehend zu betrachten. Das ist wie ein Zimmermann, der das Brett vor jedem Schnitt zehnmal misst. Die erste Messung war völlig ausreichend. Die nächsten neun sind reine Zeitverschwendung.

Diese zusätzlichen Schritte haben reale Konsequenzen. Die Latenz summiert sich. In einer synchronen Chat-Schnittstelle fühlen sich drei zusätzliche Sekunden wie eine Ewigkeit an. Bei Skalierung übersetzen sich diese Sekunden in tausende Dollar an Rechenkosten. Auch das Ausfallrisiko steigt. Jeder unnötige Hop ist eine weitere Chance für eine externe API, in ein Timeout zu laufen, ein Kontextfenster zu überlaufen oder eine Race Condition zu verursachen. Und wenn etwas kaputtgeht, viel Glück beim Debugging eines Traces, der wie Spaghetti aussieht. Sie werden Stunden damit verbringen, zu rekonstruieren, warum der Agent Schritt sieben ausgeführt hat, nur um festzustellen, dass Schritt sieben niemals hätte existieren dürfen.

Was Konvergenz eigentlich bedeutet

Wenn die Trajektorie der Pfad ist, dann ist die Konvergenz das Maß für dessen Effizienz. Die Konvergenz sagt Ihnen, wie eng der Agent der kürzesten gangbaren Route zwischen der Anfrage des Nutzers und der korrekten Lösung folgt.

Das ist nicht dasselbe wie Genauigkeit. Genauigkeit ist ein stumpfes Instrument. Sie fragt, ob der Endzustand korrekt ist. Konvergenz fragt, ob der Weg vernünftig war. Ein Agent mit hoher Genauigkeit und geringer Konvergenz ist eine Belastung im Kostüm des Erfolgs. Ein Agent mit hoher Konvergenz und mäßiger Genauigkeit ist in der Regel einfacher zu korrigieren, da seine Logik sauber ist und seine Fehler lokal begrenzt sind.

Sie können einen groben Konvergenzwert berechnen, indem Sie die tatsächlich vom Agenten unternommenen Schritte mit dem kürzesten Pfad vergleichen, den Sie für diese Aufgabenklasse definiert haben. Wenn eine Standard-Rückerstattungsanfrage genau drei Tool-Aufrufe erfordern sollte und der Agent neun verwendet hat, sinkt Ihr Konvergenzverhältnis. Sie können dies verfeinern, indem Sie verschiedene Arten von Verschwendung gewichten. Ein einziger falscher Tool-Aufruf könnte mehr kosten als ein einzelner redundanter Aufruf, abhängig von der Latenz und dem Preis des Tools. Eine Router-Schleife, die keinen Mehrwert bietet, könnte die schwerste Strafe von allen nach sich ziehen, da sie auf eine architektonische...