Fortgeschrittenes Tool Calling, das meine KI-Agenten-Kosten halbierte

Es war donnerstagabends um 23:00 Uhr, als ich auf mein Langfuse-Dashboard schaute und etwas bemerkte, das mich dazu brachte, meinen Laptop zuzuklappen und vom Schreibtisch aufzustehen. Ein einziger Agent-Run -- eine Aufgabe, eine Benutzeranfrage -- hatte 76.000 Token verbraucht und 56 einzelne Tool Calls gemacht. Das Schlimmste daran? Die Antwort war trotzdem falsch. Zwei Teammitglieder, die ihr Budgetlimit überschritten hatten, wurden übersehen -- und der Kunde würde diesen Bericht am nächsten Morgen sehen.

Dieser Agent hatte Zugriff auf 60 Tools über zwei MCP-Server. Jede einzelne Tool-Definition wurde zu Beginn jedes Gesprächs in das Kontextfenster geladen. Dreizehntausend Token weg, bevor der Agent überhaupt anfing, über die eigentliche Aufgabe nachzudenken. Ich dachte, ich hätte ein leistungsfähiges System gebaut. Was ich tatsächlich gebaut hatte, war ein Token-Verbrennungsofen mit einem Genauigkeitsproblem.

Die Lösung kam von zwei Funktionen, die ich wochenlang in der Anthropic-Dokumentation ignoriert hatte: Tool Search und programmatisches Tool Calling. Was danach passierte, ist der Grund, warum ich diesen Beitrag schreibe. Aber die eigentliche Geschichte geht nicht ums Token-Sparen -- es geht um einen grundlegenden Wandel in der Art und Weise, wie ich über Agent-Architektur nachdenke.

Das Problem, über das Niemand Spricht, bis die Rechnung Kommt

Das ist das Szenario, das die meisten KI-Agent-Entwickler gut kennen, ob sie es zugeben oder nicht. Du fängst an, einen Agenten zu bauen. Er muss Dateien lesen, Datenbanken abfragen, APIs aufrufen, vielleicht mit GitHub oder Slack interagieren. Jede Fähigkeit bedeutet ein weiteres Tool. Dein erster Prototyp hat 8 Tools und funktioniert wunderbar. Sauberer Kontext, schnelle Antworten, genaue Ergebnisse.

Dann kommen die Feature-Anfragen. Der Agent muss Kalendertermine verwalten. Füge drei Tools hinzu. Er muss Jira-Tickets erstellen. Noch zwei Tools. Slack-Integration? Weitere fünf. Bevor du es weißt, sitzt du bei 35, 40, 60 Tools -- und dein Agent hat eine Persönlichkeitsstörung entwickelt. Er wählt die Hälfte der Zeit das falsche Tool, halluziniert Parameterwerte und kostet dreimal so viel wie budgetiert.

Ich bin bei einem Projekt für einen Kunden, der einen einheitlichen Betriebsagenten wollte, hart gegen diese Wand gelaufen. Der Agent brauchte Zugriff auf dessen GitHub-Repos, den Notion-Arbeitsbereich, Slack-Kanäle, den Kalender und eine benutzerdefinierte Inventar-API. Insgesamt 60 Tools, wenn man alles von beiden MCP-Servern zählte.

Drei Dinge brachten mich um:

Die Tool-Definitionen allein verbrauchten pro Gespräch etwa 13.000 Token. Das ist Kontextfenster-Platz, der für das eigentliche Denken hätte genutzt werden können. Bei Claude 3.5 Sonnet ist das nicht trivial -- und bei längeren Gesprächen stieß ich gegen Kontextgrenzen, bevor der Agent seine Arbeit beendet hatte.

Zwischenergebnisse aus sequenziellen Tool Calls verschmutzten den Kontext. Wenn der Agent Budgets für ein gesamtes Team prüfen musste, rief er zunächst "Teammitglieder abrufen" auf, dann "Ausgaben abrufen" für jede Person, dann "Budget nach Level abrufen" für die Rolle jeder Person. Jede Antwort warf rohen JSON in den Kontext. Als er beim letzten Teammitglied angelangt war, wurden frühere Daten aus dem effektiven Aufmerksamkeitsbereich herausgedrängt.

Die Genauigkeit der Tool-Auswahl nahm ab, je mehr Tools hinzukamen. Mit 60 Tool-Definitionen im Kontext musste das Modell sie jedes Mal durchsuchen, wenn es entschied, welches Tool es verwenden sollte. Stell dir vor, jemandem eine 60-seitige Speisekarte zu geben und zu erwarten, dass er schnell und korrekt bestellt. Gleiches Problem.

Ich probierte die naheliegenden Lösungen. Bessere Tool-Beschreibungen. Weniger Tools mit mehr Parametern. Tools in Gruppen kategorisieren. Nichts davon löste das grundlegende Problem: zu viele Definitionen, die zu früh geladen wurden, und zu viel Zwischendaten, die sich zu schnell ansammelten.

Dann fand ich die zwei Funktionen, die alles an der Art und Weise veränderten, wie ich Agenten baue.

Tool Search: Laden, Was Du Brauchst, Wenn Du Es Brauchst

Das Konzept hinter Tool Search ist so einfach, dass es fast beleidigend ist, dass ich selbst nicht darauf gekommen bin. Anstatt alle 60 Tool-Definitionen zu Beginn in den Kontext zu laden, werden die meisten davon verschoben. Der Agent bekommt eine kleine Menge wesentlicher Tools plus ein spezielles Tool: das Tool Search Tool selbst. Wenn der Agent eine Fähigkeit braucht, die er gerade nicht hat, sucht er nach dem richtigen Tool per Stichwort oder Name, lädt nur das Schema dieses einen Tools und macht weiter.

Die Mathematik ist überzeugend. Mein 60-Tool-Setup verbrauchte etwa 13.000 Token an Tool-Definitionen. Nach der Implementierung von Tool Search und dem upfront Laden von nur 12 wesentlichen Tools sank diese Zahl auf 6.300 Token. Fast die Hälfte des Definitions-Overheads, weg.

Aber die Token-Einsparungen waren nicht einmal die wichtigste Verbesserung. Die Genauigkeit der Tool-Auswahl stieg dramatisch. Wenn der Agent nur 12 Tools im Kontext hat statt 60, wählt er konsequenter das richtige. Es ist der gleiche Grund, warum ein fokussierter Handwerker mit 5 Tools auf der Werkbank präziser arbeitet als einer, der von 50 umgeben ist -- weniger Rauschen, besseres Signal.

So sieht der Ablauf in der Praxis aus. Angenommen, der Agent muss aktuelle Commits aus einem GitHub-Repository abrufen. Mit dem traditionellen Ansatz sind die GitHub MCP-Tools bereits geladen -- alle 35 davon, die etwa 26.000 Token an Definitionen verbrauchen (obwohl neuere MCP-Versionen dies auf etwa 4.000 Token reduziert haben, eine enorme Verbesserung, auf die ich später noch eingehen werde). Der Agent muss sie alle durchsuchen, um das richtige Tool zu finden und dann die richtigen Parameter herausfinden.

Mit Tool Search sind diese GitHub-Tools überhaupt nicht geladen. Der Agent erkennt, dass er Commit-Daten braucht, ruft das Tool Search Tool mit einer Suchanfrage wie "list commits" auf, erhält das spezifische Tool, das er braucht, und lädt nur dieses Schema. Ein Tool. Ein paar Hundert Token. Und einmal geladen, bleibt dieses Tool für nachfolgende Aufrufe im Kontext -- kein wiederholtes Laden, keine verschwendeten Token.

Ich möchte spezifisch sein, wie das funktioniert, weil die Implementierungsdetails wichtig sind. Das Tool Search Tool akzeptiert entweder eine Stichwort-Suchanfrage oder einen direkten Tool-Namen. Die Stichwortsuche ist unscharf -- du kannst nach "slack message" suchen und erhältst relevante Slack-Tools zurück, nach Relevanz geordnet. Die direkte Auswahl verwendet ein "select:"-Präfix, wenn du genau weißt, welches Tool du willst. Beide Ansätze laden die zurückgegebenen Tools sofort, es gibt also keinen zweistufigen Prozess aus Suchen und dann seperatem Laden.

Etwas, das ich auf die harte Tour lernte: Du musst sorgfältig überlegen, welche Tools im "immer geladen"-Set bleiben und welche verschoben werden. Tools, die der Agent in fast jedem Gespräch verwendet, sollten geladen bleiben. Tools, die nur für bestimmte Aufgaben benötigt werden, sollten verschoben werden. Diese Aufteilung falsch zu machen bedeutet, dass dein Agent entweder Zeit damit verschwendet, nach häufig genutzten Tools zu suchen, oder immer noch zu viele Definitionen upfront lädt.

Für meinen Betriebsagenten behielt ich Kerntools wie Dateilesen, grundlegende API-Aufrufe und das Tool Search Tool selbst im immer-geladenen Set. Alles andere -- GitHub-Operationen, Slack-Messaging, Kalenderverwaltung, Notion-Abfragen -- wurde verschoben. Der Agent lernte, auf natürliche Weise danach zu suchen, und der Gesprächsablauf änderte sich kaum aus der Perspektive des Benutzers.

Das löste das Definitions-Bloat-Problem. Aber ich hatte immer noch das Zwischenergebnis-Problem -- all den rohen JSON aus sequenziellen Tool Calls, der sich im Kontext ansammelte. Dafür brauchte ich die zweite Funktion.

Programmatisches Tool Calling: Schreib Code, Keine Aufrufketten

Hier wird es wirklich interessant und, ehrlich gesagt, ein bisschen verwirrend, wenn du Agenten bisher auf traditionelle Weise gebaut hast.

Standard-Tool Calling funktioniert so: Das LLM entscheidet, dass es Daten braucht, macht einen Tool Call, erhält das Ergebnis, verarbeitet es, entscheidet, dass es mehr Daten braucht, macht einen weiteren Tool Call, erhält dieses Ergebnis, und so weiter. Jeder Aufruf und jede Antwort lebt im Gesprächskontext. Für einfache Aufgaben mit zwei oder drei Tool Calls ist das in Ordnung. Für komplexe Aufgaben, die Daten aus Dutzenden von Quellen erfordern, ist es eine Katastrophe.

Programmatisches Tool Calling dreht das Modell um. Anstatt einzelne Tool Calls durch das Gespräch zu machen, generiert der Agent ein Code-Skript -- typischerweise Python --, das den gesamten Workflow programmatisch abhandelt. Das Skript läuft in einer sandboxed Umgebung, macht intern alle notwendigen Tool Calls, verarbeitet die Daten mit echter Code-Logik und gibt nur das Endergebnis in den Gesprächskontext zurück.

Lass mich den Unterschied an einem konkreten Beispiel zeigen, das tatsächlich in meinem Budget-Compliance-Projekt passiert ist.

Die Aufgabe war unkompliziert: Prüfen, ob die Ausgaben eines Teammitglieds das genehmigte Budget für seine Rollenebene überschritten. Drei Tools waren verfügbar: Teammitglieder abrufen (gibt eine Liste von Personen und ihren Rollen zurück), Ausgaben abrufen (gibt Ausgabendaten für eine bestimmte Person zurück) und Budget nach Level abrufen (gibt das genehmigte Budgetlimit für eine Rolle zurück).

Mit traditionellem Tool Calling rief der Agent zunächst "Teammitglieder abrufen" auf. Erhielt eine Liste von, sagen wir, 15 Personen. Dann rief er "Ausgaben abrufen" für Person eins auf. Erhielt deren Ausgabendaten. Rief "Budget nach Level abrufen" für die Rolle von Person eins auf. Verglich die Zahlen. Ging zu Person zwei. Rief "Ausgaben abrufen" auf. Rief "Budget nach Level abrufen" auf. Und so weiter. Insgesamt 56 Tool Calls. Jede Antwort -- 15 Teammitglieder-Datensätze, 15 Ausgabenberichte, 15 Budget-Lookups -- saß im Gesprächskontext und fraß Token.

Das Ergebnis? Etwa 76.000 verbrauchte Token. Und der Agent übersah ein Teammitglied, das sein Budget überschritten hatte, wahrscheinlich weil die Aufmerksamkeit auf frühere Daten abgenommen hatte, als er die letzten paar Personen verarbeitete. Die Aufmerksamkeit im Kontextfenster ist nicht gleichmäßig -- Modelle schenken Informationen in der Mitte langer Kontexte weniger Aufmerksamkeit, und meine sequenziellen Tool Calls hatten genau die Bedingungen geschaffen, unter denen diese Schwäche zuschlägt.

Mit programmatischem Tool Calling sah dieselbe Aufgabe völlig anders aus. Der Agent analysierte, was erreicht werden musste, und generierte dann ein Python-Skript. Das Skript rief "Teammitglieder abrufen" einmal auf, iterierte programmatisch durch die Liste, rief "Ausgaben abrufen" und "Budget nach Level abrufen" für jede Person innerhalb einer Schleife auf, verglich die Werte im Code und gab eine übersichtliche Zusammenfassung zurück, wer das Budget überschritten hatte und um wie viel.

Die Zahlen erzählen die Geschichte. Der Token-Verbrauch sank auf irgendwo zwischen 45.000 und 58.000 Token über mehrere Runs. Tool Calls gingen von 56 auf zwischen 4 und 12 zurück. Und Genauigkeit? Perfekt. Der Code hatte keine Aufmerksamkeits-Degradationsprobleme. Eine for-Schleife verarbeitet das fünfzehnte Element genauso gut wie das erste.

Ich sollte ehrlich über etwas sein. Der programmatische Ansatz war nicht jedes Mal ein sauberer One-Shot. Über meine Testruns hinweg generierte der Agent manchmal Code mit Bugs beim ersten Versuch. Ein falscher Variablenname, eine fehlende Null-Prüfung, eine fehlerhafte Annahme über die Datenstruktur. Die Sandbox gab einen Fehler zurück, der Agent analysierte den Fehler, korrigierte den Code und versuchte es erneut. Dieser iterative Zyklus ist Teil des Designs, kein Fehler. Echte Softwareentwicklung funktioniert genau so -- schreiben, ausführen, debuggen, verfeinern.

Manche Runs brauchten zwei Iterationen, manche vier. Aber selbst mit dem Iterations-Overhead war der gesamte Token-Verbrauch und die Anzahl der Tool Calls deutlich geringer als beim traditionellen Ansatz. Und die Genauigkeit war durchgehend besser, weil die Vergleichslogik in echtem Code steckte statt im Arbeitsgedächtnis des LLMs.

Diese iterative Natur ist tatsächlich eines der Dinge, die ich an diesem Ansatz am meisten schätze. Sie spiegelt wider, wie ich als Entwickler arbeite. Ich schreibe auch nicht beim ersten Versuch perfekten Code. Ich schreibe etwas Vernünftiges, teste es, behebe, was kaputt ist, und iteriere. Programmatisches Tool Calling gibt dem Agenten denselben Workflow, und es stellt sich heraus, dass LLMs überraschend gut darin sind, ihren eigenen generierten Code zu debuggen, wenn sie klare Fehlermeldungen aus der Sandbox erhalten.

Die Sandbox-Architektur, die das Sicher Macht

Wenn deine Sicherheitsinstinkte gerade alarmiert haben, gut so. Einem KI-Agenten zu erlauben, beliebigen Code zu generieren und auszuführen, ist die Art von Sache, die Sicherheitsingenieure nachts wachhält. Die Architektur hinter dieser Funktion macht sie für den Produktionseinsatz tauglich, und das Verständnis davon ist wesentlich, bevor du irgendetwas implementierst.

Das System verwendet sandboxed Docker-Container. Jede Code-Ausführung läuft in einem isolierten Container ohne Internetzugang. Das generierte Python-Skript kann die Außenwelt nicht erreichen, hat keinen Zugriff auf das Dateisystem des Hosts, kann keine Umgebungsvariablen vom Host lesen und kann nichts tun, was ein bösartiges Skript tun würde.

Aber warte -- das Skript muss Tools aufrufen. Es muss APIs erreichen. Wie macht es das ohne Internetzugang?

Hier kommt die Tool Bridge ins Spiel, und das ist eine clevere Architekturentscheidung. Die Sandbox hat Zugriff auf einen einzigen Endpunkt: den Tool Bridge-Server, der auf dem Host läuft (oder in einem Sidecar-Container). Wenn das Python-Skript innerhalb der Sandbox ein Tool aufrufen muss -- sagen wir "Ausgaben abrufen" für ein Teammitglied -- sendet es eine Anfrage an die Tool Bridge. Die Bridge authentifiziert die Anfrage über eine Session-ID, überprüft, ob der Tool Call erlaubt ist, führt den eigentlichen API-Aufruf im Namen der Sandbox aus und gibt das Ergebnis zurück.

Die kritische Sicherheitseigenschaft hier ist, dass der Sandbox-Code niemals API-Credentials, Token oder Geheimnisse zu sehen bekommt. Die Tool Bridge hält das gesamte Authentifizierungsmaterial. Die Sandbox kennt nur den Bridge-Endpunkt und ihre Session-ID. Wenn der generierte Code irgendwie bösartig wäre oder durchsickern würde, würden keine Credentials offengelegt.

Ich habe meine Sandbox mit dem LLM Sandbox GitHub-Repository eingerichtet, das den größten Teil der Docker-Verwaltungskomplexität abstrahiert. Es unterstützt Python out of the box und übernimmt den Container-Lebenszyklus, die Ausgabeerfassung und die Bereinigung. Für Teams, die das in der Produktion betreiben, empfehle ich dringend, GVisor über der Standard-Docker-Isolation hinzuzufügen. Docker-Container teilen den Host-Kernel, was bedeutet, dass ein Kernel-Exploit theoretisch aus der Sandbox ausbrechen könnte. GVisor bietet eine zusätzliche Isolationsschicht, indem es Systemaufrufe über seinen eigenen User-Space-Kernel abfängt, was diese Angriffsfläche erheblich reduziert.

Etwas, das ich erst nach dem Aufbau verstand: Der Sandbox-Ansatz ist prinzipiell sprachagnostisch. Das LLM Sandbox-Repo unterstützt mehrere Sprachen, sodass dein Agent JavaScript, Go oder sogar Shell-Skripte generieren könnte, je nach Aufgabe. In der Praxis bin ich bei Python geblieben, weil LLMs den besten Python-Code generieren -- sie haben die meisten Python-Trainingsdaten gesehen, und Pythons Syntax macht es für das Modell einfacher, prozedurale Logik auszudrücken.

Tools Entwerfen, die dein Kontext-Budget Nicht Verschwenden

Tool Search und programmatisches Calling lösen zwei große Probleme: Definitions-Bloat und Zwischenergebnis-Bloat. Aber es gibt eine dritte Optimierungsebene, die ich fast übersehen hätte, und sie hat einen größeren Unterschied gemacht als erwartet: das Tool-Design selbst.

Als ich den GitHub MCP-Server zum ersten Mal mit meinem Agenten verband, verbrauchte der vollständige Satz von 35 Tools etwa 26.000 Token an Definitionen. Das ist absurd. Die neuere Version desselben MCP-Servers liefert gleichwertige Funktionalität in etwa 4.000 Token. Der Unterschied? Engere Beschreibungen, konsolidierte Parameter und Entfernung redundanter Tool-Varianten.

Wenn du benutzerdefinierte Tools für deine Agenten baust, zählt jedes Token in deiner Tool-Definition. Reduziere Beschreibungen auf die wesentlichen Informationen. Verwende klare, prägnante Parameternamen, aus denen das Modell die Verwendung ableiten kann. Entferne Felder, die der Agent selten verwendet -- du kannst sie immer über Tool Search zurückhinzufügen, wenn nötig.

Und hier ist ein Tipp, der die Genauigkeit meines Agenten bei der Parameterverarbeitung dramatisch verbessert hat: Füge Beispiele für die Tool-Verwendung ein. Ein einziges Beispiel korrekter Tool-Verwendung bereitzustellen -- mit den erwarteten Werten für jeden Parameter -- erhöhte meine Parametergenauigkeit von etwa 72% auf rund 90%. Das ist keine geringfügige Verbesserung. Das ist der Unterschied zwischen einem Agenten, der meistens funktioniert, und einem, der zuverlässig funktioniert.

Betrachte Tool-Verwendungsbeispiele als Multi-Shot-Prompting für Tool Calls. Wenn das Modell ein Beispiel wie {"date": "2026-01-15"} sieht, versteht es, dass das erwartete Format Jahr-Monat-Tag ist. Ohne dieses Beispiel könnte es "January 15, 2026" oder "01/15/2026" oder "15-01-2026" generieren -- alles gültige Datumsdarstellungen, aber nur eine stimmt mit dem überein, was die API erwartet. Ein einziges Beispiel eliminiert diese Mehrdeutigkeit fast vollständig.

Ich behandle die Optimierung von Tool-Definitionen jetzt als erstklassige Engineering-Aufgabe, nicht als Nachgedanken. Bevor ich ein Tool zu einem Agenten hinzufüge, frage ich mich: Wie viele Token verbraucht diese Definition? Kann ich die Beschreibung kürzer machen, ohne an Klarheit zu verlieren? Habe ich ein Verwendungsbeispiel beigefügt? Kann dieses Tool hinter Tool Search verschoben werden, oder muss es immer geladen sein?

Diese Fragen sparen Tausende von Token pro Gespräch, was sich über Tausende von Agent-Runs zu echtem Geld summiert.

Alles Zusammenfügen: Die Architektur, die Wirklich Funktioniert

Hier verbinde ich die Fäden, denn diese Funktionen sind keine unabhängigen Schalter, die du umlegen kannst. Sie funktionieren am besten als Schichten in einer durchdachten Architektur.

Schicht 1: Tool Search für das Definitionsmanagement. Verschiebe alles, was nicht in jedem Gespräch benötigt wird. Halte dein immer-geladenes Set klein und fokussiert. Lass den Agenten spezialisierte Tools bei Bedarf entdecken. Das löst Definitions-Bloat.

Schicht 2: Programmatisches Tool Calling für komplexe Workflows. Jede Aufgabe, die Iteration über Daten erfordert, den Vergleich von Werten aus mehreren Quellen oder mehr als fünf sequenzielle Tool Calls benötigt, ist ein Kandidat für die programmatische Ausführung. Schick diese Workflows in die Sandbox. Das löst Zwischerergebnis-Bloat und verbessert die Genauigkeit bei datenintensiven Aufgaben.

Schicht 3: Tool-Verwendungsbeispiele für Parametergenauigkeit. Jedes Tool, das nicht offensichtliche Parameterformate akzeptiert -- Datumsangaben, Enums, IDs, verschachtelte Objekte -- bekommt mindestens ein Verwendungsbeispiel in seiner Definition. Das bekämpft den stillen Genauigkeitskiller, den die meisten Entwickler nicht einmal messen.

Als ich alle drei Schichten auf meinen Betriebsagenten anwendete, waren die Ergebnisse deutlich. Gespräche, die früher 80.000+ Token verbrauchten, sanken in den Bereich von 35.000-50.000. Die Anzahl der Tool Calls für komplexe Aufgaben ging von 40-60 auf 5-15 zurück. Parameterfehler verschwanden praktisch. Und der Agent begann, Aufgaben beim ersten Versuch korrekt zu erledigen, für die er zuvor menschliches Eingreifen benötigt hatte.

Aber ich möchte klar sein: Das ist nicht kostenlos. Die Implementierung von Tool Search erfordert ein Überdenken deiner Tool-Organisation und die Entscheidung, was verschoben werden soll. Programmatisches Calling erfordert die Einrichtung und Wartung einer Sandbox-Infrastruktur. Tool-Verwendungsbeispiele erfordern Tests, um die richtigen Beispiele zu finden, die die Genauigkeit tatsächlich verbessern. Jede Schicht fügt Implementierungskomplexität hinzu.

Meine Empfehlung ist, sie schrittweise hinzuzufügen. Beginne mit Tool Search, wenn du mehr als 15-20 Tools hast. Füge programmatisches Calling hinzu, wenn du spezifische Workflows identifizierst, bei denen sequenzielle Tool Calls Genauigkeits- oder Kostenprobleme verursachen. Füge Tool-Verwendungsbeispiele zu jedem Tool hinzu, bei dem du Parameterfehler in deinen Logs siehst.

Was Ich Falsch Gemacht Habe und Was Ich Anders Machen Würde

Ich möchte drei Fehler teilen, die ich während dieser Umstellung gemacht habe, weil ich denke, dass es Fehler sind, die die meisten Menschen machen werden.

Erstens habe ich mit Tool Search zu aggressiv verschoben. Ich habe fast alles hinter die Suche verlagert, einschließlich Tools, die der Agent in 80% der Gespräche verwendete. Das Ergebnis war, dass die meisten Gespräche damit begannen, dass der Agent sofort nach Tools suchte, die er fast immer brauchte. Es funktionierte trotzdem, aber der Suchschritt fügte Latenz und eine kleine Anzahl zusätzlicher Token hinzu. Ich musste das immer-geladene Set über etwa zwei Wochen der Überwachung tatsächlicher Nutzungsmuster feinabstimmen, um den richtigen Punkt zu finden.

Zweitens ging ich davon aus, dass programmatisches Tool Calling immer günstiger sein würde. Bei einfachen Aufgaben mit zwei oder drei Tool Calls kostet der Overhead des Generierens von Code, des Hochfahrens einer Sandbox und des Ausführens des Skripts tatsächlich mehr als das direkte Machen der Tool Calls. Programmatisches Calling glänzt, wenn der traditionelle Ansatz mehr als etwa fünf sequenzielle Aufrufe erfordern würde. Unterhalb dieser Schwelle ist die traditionelle Methode einfacher und oft günstiger.

Drittens unterschätzte ich, wie viel Zeit ich mit dem Schreiben guter Tool-Verwendungsbeispiele verbringen würde. Ein schlechtes Beispiel ist schlimmer als kein Beispiel, weil es das Modell in die Irre führen kann. Ich hatte ein Tool, bei dem ich ein Beispiel mit einem Datum im Format "2025-12-01" bereitstellte, aber die API eigentlich Unix-Timestamps erwartete. Das Modell folgte treu meinem Beispiel und schickte formatierte Datumsangaben, die die API jedes Mal ablehnte. Das Testen deiner Beispiele gegen die eigentliche API ist nicht verhandelbar.

Es gibt auch eine umfassendere Architekturlektion, die ich noch verarbeite. Diese Funktionen drängten mich dazu, Agenten weniger als Chatbots zu betrachten, die zufällig Tools verwenden, und mehr als Orchestrierungssysteme, die zufällig LLMs verwenden. Die Aufgabe des Agenten ist nicht, ein Gespräch zu führen -- es ist, eine Aufgabe zu zergliedern, die richtige Ausführungsstrategie für jede Teilaufgabe auszuwählen und Ergebnisse zusammenzustellen. Tool Search geht es um dynamisches Laden von Fähigkeiten. Programmatisches Calling geht es um effiziente Ausführung. Wenn man es so betrachtet, sind das keine Claude-spezifischen Funktionen. Es sind Entwurfsmuster, die auf jedes Agenten-Framework anwendbar sind.

Das Über Claude Hinaus Anwenden

Ich erwähnte, dass dies Entwurfsmuster sind, keine reinen Claude-Funktionen, und ich möchte darüber spezifisch sein, weil es wichtig ist.

Tool Search ist grundlegend ein Lazy-Loading-Muster. Wenn du Agenten auf LangChain, CrewAI oder einem eigenen Framework baust, kannst du dasselbe Konzept implementieren. Pflege ein Register verfügbarer Tools mit leichtgewichtigen Metadaten. Gib deinem Agenten eine "Tools suchen"-Funktion, die das Register per Stichwort abfragt. Lade Tool-Schemas nur dann in den Prompt, wenn sie ausgewählt wurden. Die Implementierungsdetails unterscheiden sich, aber die Architektur ist übertragbar.

Programmatisches Tool Calling ist ein Code-Generierungs-und-Ausführungs-Muster. Jedes Agenten-Framework kann erweitert werden, um Python-Skripte zu generieren, sie in einer Sandbox auszuführen und Ergebnisse zurückzuleiten. Der Docker-basierte Sandbox-Ansatz funktioniert unabhängig davon, welches LLM du verwendest. Die Tool Bridge-Architektur ist modellagnostisch -- es ist nur ein HTTP-Server, der authentifizierte API-Aufrufe proxied.

Sogar Tool-Verwendungsbeispiele sind übertragbar. Jedes LLM profitiert davon, Beispiel-Parameterwerte zu sehen. Ob du Claude, GPT-4, Gemini oder ein Open-Source-Modell verwendest -- das Einbeziehen von Beispielen in deine Tool-Beschreibungen verbessert die Parametergenauigkeit. Die spezifische Verbesserung variiert je nach Modell, aber die Richtung ist konsistent.

Ich habe damit begonnen, diese Muster auf ein Nebenprojekt anzuwenden, das eine Mischung aus Claude und GPT-4o je nach Aufgabenkomplexität verwendet. Die Tool Search-Schicht funktioniert für beide Modelle identisch. Die Sandbox für programmatisches Calling kümmert sich nicht darum, welches Modell den Code generiert hat. Das einzige modellspezifische Stück ist die Feinabstimmung der Tool-Definitionen für die spezifischen Stärken und Schwächen jedes Modells bei der Code-Generierung.

Wenn du an ein bestimmtes Framework oder Modell gebunden bist, weise diese Techniken nicht als "nur-Anthropic-Funktionen" ab. Extrahiere die Muster, passe die Implementierung an und wende sie überall an, wo du Agenten baust.

Die Zahlen Nach 30 Tagen in der Produktion

Ich betreibe die optimierte Agent-Architektur jetzt seit etwa einem Monat, und ich möchte echte Produktionszahlen teilen, weil ich es satt bin, Blogbeiträge zu lesen, die cherry-picked Benchmarks zeigen.

Der durchschnittliche Token-Verbrauch pro Gespräch sank um 42% im Vergleich zur vorherigen Architektur. Für den Betriebsagenten speziell sind das etwa 0,03 $ pro Gespräch statt 0,05 $. Bei etwa 200 Gesprächen pro Tag über alle Benutzer hinweg spart das rund 4 $/Tag oder etwa 120 $/Monat. Kein lebensveränderndes Geld, aber eine Reduzierung um 42%, die keine Änderungen an den Fähigkeiten des Agenten erforderte.

Tool Call-Fehler -- Fälle, in denen der Agent das falsche Tool aufgerufen oder ungültige Parameter übergeben hatte -- sanken von etwa 8% der Aufrufe auf unter 2%. Die meisten verbleibenden Fehler sind Randfälle mit mehrdeutigen Tool-Namen, die ich noch verfeinere.

Die End-to-End-Aufgabenabschluss-Genauigkeit für den Budget-Compliance-Workflow verbesserte sich von etwa 85% (der traditionelle Ansatz übersah manchmal Randfälle) auf 97% mit programmatischem Calling. Die Fehlerrate von 3% stammt fast ausschließlich davon, dass die Sandbox bei ungewöhnlich großen Datensätzen Zeitlimits erreicht, was ich durch Erhöhung des Container-Timeouts behebe.

Die von Benutzern wahrgenommene Latenz stieg leicht für einfache Anfragen -- etwa 200ms Overhead von Tool Search bei erster Verwendung. Bei komplexen Anfragen, die zuvor 30+ sequenzielle Tool Calls erforderten, sank die Latenz erheblich, weil die Sandbox Tool Calls schneller ausführt als die serielle Reasoning-Schleife des LLMs.

Diese Zahlen sind nicht hypothetisch. Sie stammen aus Langfuse-Traces auf einem Produktionssystem, das echte Benutzeranfragen verarbeitet. Deine spezifischen Zahlen werden von deiner Tool-Anzahl, Aufgabenkomplexität und Gesprächsmustern abhängen. Aber die Richtungsverbesserung sollte ähnlich sein für jeden, der mit Tool-Count-Bloat oder sequenziellem Aufruf-Overhead zu kämpfen hat.

Die Frage, die Dich Weiterbauen Lässt

Vor sechs Monaten dachte ich, der Weg zu besseren KI-Agenten sei besseres Prompting. Schreibe klarere Anweisungen, biete mehr Kontext, verwende ausgefeiltere System-Prompts. Und Prompting ist wichtig -- ich stelle es nicht in Frage. Aber Prompting allein kann keine Architekturprobleme lösen. Du kannst dich nicht aus einem 13.000-Token Tool-Definitions-Overhead herausprompten. Du kannst dich nicht zu genauer Datenverarbeitung herausprompten, wenn Zwischenergebnisse dein Kontextfenster überfluten.

Die echten Gewinne liegen in der Ausführungsarchitektur: wie Tools geladen werden, wie Daten fließen, wie Code läuft und wie der Agent zwischen Strategien entscheidet. Tool Search, programmatisches Calling und durchdachtes Tool-Design sind die erste Generation dieser architektonischen Werkzeuge. Sie werden nicht die letzten sein.

Die Frage, die ich mir immer wieder stelle -- und mit der ich dich herausfordere zu sitzen -- ist diese: Wie würde deine Agent-Architektur aussehen, wenn du sie für 500 Tools statt 50 entworfen hättest? Denn das ist, wohin wir uns bewegen. Das Ökosystem aus MCP-Servern, API-Integrationen und benutzerdefinierten Tools wächst schnell. Die Agenten, die gedeihen werden, werden nicht diejenigen mit den cleversten Prompts sein. Es werden diejenigen mit Architekturen sein, die elegant skalieren, wenn sich die Tool-Anzahl verdoppelt und dann noch einmal verdoppelt.

Beginne mit den drei Schichten. Miss deinen Token-Verbrauch. Beobachte deine Genauigkeitsmetriken. Und lege jetzt das Fundament, denn die Komplexität wird von hier aus nur zunehmen.

Lass uns Zusammenarbeiten

Möchtest du KI-Systeme aufbauen, Workflows automatisieren oder deine technische Infrastruktur skalieren? Ich helfe dir gerne.

• Fiverr (maßgeschneiderte Builds & Integrationen): fiverr.com/s/EgxYmWD
• Portfolio: mejba.me
• Ramlit Limited (Enterprise-Lösungen): ramlit.com
• ColorPark (Design & Branding): colorpark.io
• xCyberSecurity (Sicherheitsdienstleistungen): xcybersecurity.io