Wie wir in einer Stunde jährlich 1 Million US-Dollar an verschwendeten Ausgaben für AI-Agenten eliminiert haben

Databricks-Ingenieure verlassen sich stark auf AI-Agents, um ihre Arbeit zu rationalisieren und zu beschleunigen. Im Gegenzug benötigen diese Agents nicht nur Zugriff auf verschiedene Foundation Models, sondern auch auf MCP-Server mit Tools, die den Zugriff auf relevante Artefakte (z. B. Systemprotokolle, Nutzungstabellen, Support-Tickets, Wikis) ermöglichen. In einem früheren Blogbeitrag haben wir berichtet, dass die Verwaltung von AI-Kosten in großem Maßstab nicht nur die Optimierung der Modellauswahl erfordert, sondern auch die Art und Weise, wie Agents Tools nutzen. In diesem Beitrag beschreiben wir, wie wir nach Kosteneinsparungen bei der Tool-Nutzung unserer Agents gesucht haben, auf welche Herausforderungen wir dabei gestoßen sind und wie OTel-Tracing in Unity Gateway den Weg von der Analyse bis zu Einsparungen von 1,2 Mio. USD/Jahr auf eine einzige Stunde verkürzt hat.

Die Möglichkeit für unsere Entwickler, ihre eigenen Agents zu erstellen, war ein enormer Produktivitätsschub. Doch mit steigender Nutzung stiegen auch die Kosten. Wir begannen, verschiedene Optimierungen zu untersuchen, und ein Verdacht war die versteckten Kosten von fehlschlagenden Tool-Aufrufen. Wenn sich Tools fehlerhaft verhalten, schlägt der aufrufende Agent selten lautstark fehl. Stattdessen versucht er es erneut, rät und umgeht schließlich das Problem, während er die ganze Zeit über unbemerkt Token und Entwicklerzeit verbraucht. Diese Art von Verschwendung ist gefährlich: Von außen betrachtet wird die Aufgabe immer noch abgeschlossen, und ein Dashboard für die Gesamtkosten zeigt möglicherweise einen Anstieg der Token-Ausgaben um 10 % an, was leicht als Nutzungswachstum missverstanden werden kann. 

Wir haben diesen Verdacht in unserer Agent-Flotte mithilfe des Tracings von Unity Gateway und Genie One untersucht. Wir haben sieben kleine Fehler in unseren Tool-Servern gefunden, die schätzungsweise 499.000 USD/Jahr an verschwendeten Token und etwa 12.000 Entwicklerstunden pro Jahr an Agent-Wartezeit verursachten. Insgesamt entspricht dies einer geschätzten verlorenen Produktivität von 1,2 Mio. USD/Jahr. 

Das Finden, Quantifizieren und Beheben aller sieben Fehler dauerte etwa eine Stunde. Dieser Beitrag beschreibt den Prozess, den wir befolgt haben, und was wir daraus über die Entwicklung von Tools für Agents gelernt haben.

So überwachen Sie die Aktivitäten von AI-Agents und MCP

Als wir AI-Agents bei Databricks zum ersten Mal auf breiter Front für die Codierung und interne Workflows einsetzten, war es unmöglich, die Kosten zu verwalten oder auch nur vollständig zu verstehen, da uns die Sichtbarkeit der Tool-Aufrufe und der Gesamtaktivität der Agents fehlte. Um dieses Problem zu lösen, haben wir Unity Gateway genutzt, das automatisch einen OpenTelemetry-Trace für alle MCP-Tool-Aufrufe ausgibt, einschließlich Tool-Name, Argumenten, Fehlern (falls vorhanden), Token-Anzahl, Latenz und einer Session-ID, die die Aufrufe miteinander verknüpft. Diese Traces landen in einer einzigen Tabelle, die genau aufzeichnet, was unsere Agents in einem bestimmten Zeitfenster getan haben. Es war keine neue Instrumentierung erforderlich, und da das Gateway ohnehin im Pfad jedes Aufrufs liegt, waren die Daten sofort verfügbar.

Dies macht das Kostenmanagement für AI-Agents handhabbarer: Anstatt nur die gesamten Token-Ausgaben zu sehen, können wir verschwendete Ausgaben bestimmten Tools, Fehlern und Agent-Sessions zuordnen.

Da die Daten nun verfügbar sind, ist der nächste Schritt die Untersuchung:

• Welche Tool-Fehler treten am häufigsten auf?
• Wenn ein Agent auf einen Fehler stößt, wie viele Schritte (Turns) benötigt er, um sich davon zu erholen?
• Was kostet jeder Fehler an Token und tatsächlicher Wartezeit?

Normalerweise ist der aufwendige Teil einer solchen Analyse das Schreiben von SQL und das Durchforsten von Schemata. Aber mit Genie One haben wir das Tool einfach auf die Trace-Tabelle ausgerichtet, genau diese Fragen in natürlicher Sprache gestellt und innerhalb von Minuten Antworten erhalten. Die meiste Zeit unserer Stunde verbrachten wir mit dem Lesen dieser Antworten und nicht mit dem Schreiben von Abfragen.

Was die Traces zeigten: Wie MCP-Tool-Fehler die Kosten für AI-Agents in die Höhe treiben

Genie One verwandelte einen vagen Verdacht („Agents scheinen bei Jira-Aufrufen abzustürzen“) in wenigen Minuten in eine priorisierte, quantifizierte Fehlerliste. Hier ist ein Beispiel aus einem einzigen 24-Stunden-Fenster, das Fehler in unseren Jira- und Google Drive/Docs-Tool-Servern zeigt:

Nehmen wir als Beispiel den Fehler mit dem höchsten Volumen: 535 Fehlschläge pro Tag. Das Jira-Tool issues.search erwartet einen fields-Parameter, und der Server tat Folgendes:

Er erwartete eine kommagetrennte Zeichenfolge wie "key,summary,status". Ein Array ist jedoch der semantisch natürliche JSON-Typ für „eine Liste von Feldern“, und genau das leitete das Modell aus seinem Hintergrundwissen über JSON-Konventionen und aus benachbarten Tool-Aufrufen in derselben Session ab. Also übergab es den strukturierten Wert, den ein vernünftiger Aufrufer übergeben würde:

Eine Liste hat kein .split(), daher gab der Server 'list' object has no attribute 'split' aus – einen rohen Python-Traceback, der dem Agent nichts darüber verrät, was er falsch gemacht hat. Also riet der Agent erneut. Manchmal versuchte er es mit derselben Liste erneut und scheiterte auf dieselbe Weise; manchmal las er das Schema neu oder griff auf Ausprobieren zurück. Im Durchschnitt dauerte es 12 Schritte (Turns), um sich zu erholen, und bei 30 % der Sessions trat der Fehler mehr als einmal auf. Ein einziger .split()-Aufruf kostete schätzungsweise 87.000 USD/Jahr an Token und 4.850 Stunden Agent-Wartezeit.

Der Google Drive-Fehler Invalid field selection war vom Volumen her noch auffälliger: 49,6 % aller drive_file_get-Aufrufe schlugen fehl, weil das Modell immer wieder gültig aussehende Drive-API-Feldnamen (id, name, mimeType) übergab, die der Endpunkt des Tools nicht akzeptierte.

Die eigentliche Lektion: Wie man MCP-Tools für AI-Agents und LLMs entwickelt

Die offensichtliche Erkenntnis lautet „bessere Fehlermeldungen schreiben“, und die Daten bestätigen dies. Die Kosten für die Fehlerbehebung hängen fast perfekt von der Qualität der Fehlermeldung ab:

Aber dass „gute Fehlermeldungen helfen“ ein alter Hut ist, ist nichts Neues. Die interessantere Frage ist warum das Modell diese Tools überhaupt als „falsch“ aufgerufen hat. In den meisten dieser Fälle war das gar nicht der Fall.

MCP-Tool-Signaturen sind oft bewusst unterdefiniert. Wir halten sie absichtlich flexibel: teils aus Gründen der Allgemeingültigkeit, teils um Kontext-Token zu sparen, da jede Parameterbeschreibung Token kostet, die das Modell bei jedem Aufruf verbraucht. Die Folge ist: Wenn eine Signatur bei den Feldern vage ist, füllt das Modell die Lücke mit einer plausiblen Vermutung – und ein JSON-Array ist eine plausible Vermutung für eine Liste von Feldern. Der Fehler lag nicht darin, dass das Modell das Tool falsch aufgerufen hat. Er lag darin, dass der Server nur eine von mehreren plausiblen Interpretationen akzeptierte und bei den anderen abstürzte.

Das Designprinzip ist also genau umgekehrt wie die reflexive Reaktion: Tools für Agenten sollten sich an die Art und Weise anpassen, wie LLMs sie natürlicherweise aufrufen, z. B. indem sie die Liste in einen String umwandeln, für den ausgelassenen Parameter einen Standardwert verwenden, das unerwartete Argument abfangen und so weiter. Eine unterdefinierte Signatur ist ein Versprechen von Flexibilität, und das Tool sollte dieses Versprechen auf der Empfängerseite einlösen, anstatt beim ersten Input abzustürzen, der nicht genau der Form entspricht, die sich der Autor vorgestellt hat.

Der einfache Teil: Wie wir unnötige Ausgaben für KI-Agenten in einer Stunde reduziert haben

Die Fehlerbehebungen selbst waren einfach und sind nicht der spannende Teil dieser Geschichte. Sobald Genie One uns eine nach Priorität geordnete Liste der zu behebenden Fehler und der tatsächlich vom Modell gesendeten Daten geliefert hatte, war das Einspielen der Fixes auf den Tool-Servern mit einem Coding-Agenten schnell erledigt. Der gesamte Ablauf (Finden, Quantifizieren, Beheben) dauerte etwa eine Stunde.

Der schwierige und teure Schritt war nie das Schreiben des Fixes. Es war das Wissen, was überhaupt behoben werden muss. Tracing in Kombination mit Genie One hat diesen Schritt von einem Forschungsprojekt in eine einfache Frage verwandelt, die man einfach so stellen kann.

Den Kreislauf schließen: Wie Sie die Kosten für KI-Agenten kontinuierlich überwachen und senken

Da immer mehr echte Arbeit auf Agenten verlagert wird, entwickeln sich unbemerkte Tool-Fehler zu einem erheblichen Kostenfaktor – einer von der Sorte, die sich hinter dem „Nutzungswachstum“ verbirgt und bei dem nie jemand alarmiert wird. Der Prozess, um sie abzufangen, ist kostengünstig und wiederholbar: Unity Gateway macht das Verhalten der Agenten beobachtbar, und Genie One macht dieses Verhalten ohne SQL abfragbar.

Zusammen bietet dies Teams eine wiederholbare Methode, um KI-Agenten zu überwachen, MCP-Tool-Fehler zu diagnostizieren und unnötige KI-Ausgaben zu reduzieren. Wenn Sie Agenten mit Ihren eigenen Tools ausführen, tun Sie dasselbe. Tracen Sie die Aufrufe und fragen Sie Genie One, was immer wieder schiefläuft.

Erste Schritte mit der Unity Gateway-Trace-Analyse mit Genie One

Unity Gateway ist allgemein verfügbar, und Sie können jetzt alle KI-Aktivitäten über die einheitliche Trace-Tabelle überwachen, die sich derzeit in der Beta-Phase befindet. Weitere Informationen zum Einstieg finden Sie in unserer Dokumentation. 

(Dieser Blogbeitrag wurde mit KI-gestützten Tools übersetzt.) Originalbeitrag