Tool-Use & Function Calling: Wie KI-Agenten handeln lernen

Ein Sprachmodell, das nur Text ausgibt, ist wie ein hervorragender Berater ohne Hände. Es kann erklären, wie man eine Tabelle erstellt, aber es kann sie nicht selbst anlegen. Genau diese Lücke schließt Tool-Use, technisch oft Function Calling genannt. Es ist die Fähigkeit, mit der aus einem Textgenerator ein handelndes System wird – und damit die wichtigste Voraussetzung für jeden KI-Agenten. Dieser Artikel erklärt, wie der Mechanismus wirklich funktioniert, ohne in Code zu ertrinken.

Warum ein Modell allein nicht reicht

Große Sprachmodelle sind erstaunlich gut darin, Sprache zu verstehen und plausible Antworten zu formulieren. Aber sie haben drei eingebaute Schwächen: Sie kennen keine aktuellen Daten jenseits ihres Trainingsstands, sie rechnen unzuverlässig, und sie können nichts in der Welt verändern. Ein Modell, das nach dem heutigen Wechselkurs gefragt wird, rät bestenfalls. Eines, das eine lange Multiplikation lösen soll, verrechnet sich gern. Und eines, das eine E-Mail verschicken soll, kann das aus eigener Kraft schlicht nicht.

Tool-Use behebt alle drei Schwächen auf einen Schlag. Statt selbst zu raten, ruft das Modell ein Werkzeug auf: eine Suchfunktion für aktuelle Daten, einen Taschenrechner für präzise Mathematik, eine E-Mail-API zum Versenden. Das Modell bleibt der Stratege, die Werkzeuge erledigen die Ausführung verlässlich.

Der Ablauf eines Function Calls Schritt für Schritt

Function Calling läuft in einem klar definierten Tanz zwischen Anwendung und Modell ab:

1. Die Anwendung schickt dem Modell die Nutzeranfrage und eine Liste verfügbarer Werkzeuge – jedes mit Name, Beschreibung und erwarteten Parametern.
2. Das Modell entscheidet, ob es ein Werkzeug braucht. Wenn ja, gibt es nicht einfach Text aus, sondern ein strukturiertes Objekt: „Rufe das Werkzeug X mit den Parametern Y auf."
3. Wichtig: Das Modell führt das Werkzeug nicht selbst aus. Es formuliert nur den Wunsch. Die Anwendung fängt diesen Wunsch ab und führt die echte Funktion aus.
4. Das Ergebnis der Funktion wird zurück an das Modell gegeben, das daraus eine Antwort formuliert oder den nächsten Werkzeugaufruf plant.

Diese Trennung ist sicherheitsrelevant: Weil die Anwendung jeden Aufruf abfängt, kann sie prüfen, ob er erlaubt ist, bevor irgendetwas passiert. Das Modell schlägt vor, der Code entscheidet.

Was eine gute Werkzeugbeschreibung ausmacht

Die Qualität eines Tool-Use-Systems steht und fällt mit den Beschreibungen der Werkzeuge. Das Modell sieht keinen Quellcode, sondern nur den Namen, eine kurze Erklärung und das Schema der Parameter. Aus diesen Angaben muss es ableiten, wann das Werkzeug passt. Drei Prinzipien haben sich bewährt:

• Eindeutige Namen: „getCurrentWeather" sagt mehr als „tool3".
• Präzise Beschreibungen: Erkläre nicht nur was, sondern auch wann das Werkzeug einzusetzen ist und wann nicht.
• Klare Parameter: Jeder Parameter braucht Typ und Bedeutung. Ein gut definiertes Schema verhindert, dass das Modell Unsinn übergibt.

Eine Faustregel aus der Praxis: Wenn ein menschlicher Praktikant aus deiner Werkzeugbeschreibung verstehen würde, wann er das Tool nutzen soll, versteht es das Modell meistens auch.

Parallele und sequentielle Aufrufe

Moderne Modelle können 2026 nicht nur ein Werkzeug nach dem anderen aufrufen, sondern auch mehrere gleichzeitig. Fragt jemand „Wie ist das Wetter in Berlin, Hamburg und München?", kann das Modell drei Wetterabfragen parallel anstoßen, statt sie nacheinander abzuarbeiten. Das spart Zeit und reduziert die Zahl der Modelldurchläufe. Sequentielle Aufrufe wiederum sind nötig, wenn ein Ergebnis das nächste bestimmt – etwa erst eine Kunden-ID nachschlagen und dann mit dieser ID die Bestellhistorie laden.

Kosten und Token: der unterschätzte Faktor

Tool-Use ist nicht gratis. Jede Werkzeugbeschreibung wird bei jedem Aufruf mit in den Kontext gegeben und kostet Token. Bindet man zwanzig Werkzeuge ein, von denen das Modell pro Anfrage nur eines braucht, zahlt man trotzdem für alle Beschreibungen. Deshalb gilt: lieber wenige, gut gewählte Werkzeuge als ein überladener Werkzeugkasten. Wer abschätzen will, was die zusätzlichen Tokens kosten, kann das mit dem LLM-API-Kosten-Rechner durchrechnen, der Input- und Output-Token getrennt erfasst.

Auch die Rückgaben der Werkzeuge zählen. Eine API, die eine riesige JSON-Antwort liefert, kann das Kontextfenster sprengen. Hier hilft es, im Werkzeug selbst nur die relevanten Felder zurückzugeben, statt rohe Datenmengen an das Modell durchzureichen.

Ein konkretes Beispiel: die Wetterauskunft

Ein einfaches Szenario macht den Ablauf greifbar. Ein Nutzer fragt: „Soll ich morgen in München einen Regenschirm mitnehmen?" Das Modell allein könnte nur raten, weil es das morgige Wetter nicht kennt. Mit Tool-Use erkennt es jedoch, dass es das Werkzeug „getWeatherForecast" braucht, und gibt strukturiert aus: rufe es auf mit Ort „München" und Datum „morgen". Die Anwendung führt den echten API-Aufruf aus und gibt das Ergebnis – etwa „80 Prozent Regenwahrscheinlichkeit" – zurück an das Modell. Erst jetzt formuliert das Modell die eigentliche Antwort: „Ja, nimm einen Schirm mit, morgen regnet es in München mit hoher Wahrscheinlichkeit."

Dieses kleine Beispiel zeigt das ganze Prinzip in einem Durchlauf: Das Modell denkt, es delegiert die Faktenbeschaffung an ein verlässliches Werkzeug, und es verwandelt das rohe Ergebnis in eine menschenfreundliche Antwort. Genau diese Arbeitsteilung – Strategie beim Modell, Ausführung beim Werkzeug – ist der Grund, warum moderne Assistenten so viel verlässlicher wirken als reine Textgeneratoren.

Typische Fehler und wie man sie vermeidet

Drei Stolperfallen tauchen immer wieder auf. Erstens: zu vage Beschreibungen, die das Modell raten lassen. Zweitens: fehlende Fehlerbehandlung – wenn ein Werkzeug einen Fehler zurückgibt, muss das Modell das verstehen und reagieren können, statt blind weiterzumachen. Drittens: zu viel Autonomie bei riskanten Aktionen. Ein Werkzeug, das Daten löscht oder Geld bewegt, sollte niemals ohne Bestätigung ausgeführt werden.

Wer diese Punkte beachtet, hat das Fundament für robuste Agenten gelegt. Weiterführende Grundlagen zu Modellen und Prompts finden sich in der News-Übersicht, praktische Rechner in den Webtools.

Häufige Fragen

Führt das Modell die Funktion selbst aus?

Nein. Das Modell gibt nur strukturiert an, welches Werkzeug es mit welchen Parametern aufrufen möchte. Die eigentliche Ausführung übernimmt die umgebende Anwendung, die den Aufruf vorher prüfen kann.

Worin unterscheiden sich Tool-Use und Function Calling?

Die Begriffe meinen weitgehend dasselbe. „Function Calling" betont die technische Schnittstelle, „Tool-Use" die Fähigkeit als Konzept. In der Praxis werden sie oft synonym verwendet.

Wie viele Werkzeuge kann ich einem Modell geben?

Technisch viele, sinnvoll wenige. Jede Beschreibung kostet Token und erschwert dem Modell die Auswahl. Eine überschaubare, klar abgegrenzte Auswahl liefert meist bessere Ergebnisse als ein riesiger Werkzeugkasten.

Was passiert, wenn ein Werkzeug einen Fehler zurückgibt?

Idealerweise wird die Fehlermeldung als Beobachtung an das Modell zurückgegeben, das daraufhin seinen Plan anpassen kann – etwa ein anderes Werkzeug wählen oder beim Nutzer nachfragen. Ohne Fehlerbehandlung droht der Agent hängenzubleiben.